From owner-freebsd-current Sun Mar 31 01:07:57 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA10587 for current-outgoing; Sun, 31 Mar 1996 01:07:57 -0800 (PST) Received: from mail.rwth-aachen.de (mail.RWTH-Aachen.DE [137.226.144.9]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id BAA10582 for ; Sun, 31 Mar 1996 01:07:55 -0800 (PST) Received: from gilberto.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de) by mail.rwth-aachen.de (PMDF V5.0-4 #13110) id <01I2ZGOR74W000009T@mail.rwth-aachen.de> for freebsd-current@freefall.FreeBSD.org; Sun, 31 Mar 1996 10:10:45 +0100 Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.6.11/8.6.9) id LAA00327 for freebsd-current@freefall.cdrom.com; Sun, 31 Mar 1996 11:01:11 +0200 Date: Sun, 31 Mar 1996 11:01:11 +0200 From: "Christoph P. Kukulies" Subject: if_ppp.h (struct ppp_header) To: freebsd-current@freefall.FreeBSD.org Message-id: <199603310901.LAA00327@gilberto.physik.rwth-aachen.de> Content-transfer-encoding: 7BIT Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Trying to compile trafshow results in a compilation error in -current. This is because struct ppp_header is gone in /sys/net/if_ppp.h. Is there an easy workaround for this? What was the intention behind removing it? --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-current Sun Mar 31 01:10:52 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA10775 for current-outgoing; Sun, 31 Mar 1996 01:10:52 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id BAA10766 for ; Sun, 31 Mar 1996 01:10:49 -0800 (PST) Received: (from jkh@localhost) by time.cdrom.com (8.7.5/8.6.9) id BAA13477 for current@freebsd.org; Sun, 31 Mar 1996 01:10:15 -0800 (PST) Date: Sun, 31 Mar 1996 01:10:15 -0800 (PST) From: "Jordan K. Hubbard" Message-Id: <199603310910.BAA13477@time.cdrom.com> To: current@freebsd.org Subject: lint.. Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Will the person who enabled lint by default also please add the appropriate magic to the tools target so that `make world' doesn't fall over in -current anymore? We really need to make sure that `make world' keeps working when we make these sorts of changes and just fixing it by hand doesn't cut it. Thanks! Jordan From owner-freebsd-current Sun Mar 31 01:23:11 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA11484 for current-outgoing; Sun, 31 Mar 1996 01:23:11 -0800 (PST) Received: from riley-net170-164.uoregon.edu (cisco-ts10-line12.uoregon.edu [128.223.150.110]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id BAA11470 for ; Sun, 31 Mar 1996 01:23:05 -0800 (PST) Received: (from dwhite@localhost) by riley-net170-164.uoregon.edu (8.6.12/8.6.12) id BAA01061; Sun, 31 Mar 1996 01:24:00 -0800 Date: Sun, 31 Mar 1996 01:23:59 -0800 (PST) From: Doug White Reply-To: dwhite@resnet.uoregon.edu To: Chris Cappuccio cc: current@freebsd.org Subject: Re: your mail In-Reply-To: <199603291843.NAA02951@sefl.satelnet.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 29 Mar 1996, Chris Cappuccio wrote: > I need a little help getting a hewlett packard deskjet 500 > printer working under -current (nothing to do with the fact > that it's current or 2.1 or whatever, just that its kind of > strange..) I can't get he baud rate adn such set correctly > in printcap and once I do, how would I print from applications such as umm netscape or > something.. (ghostscript PS-->PCL?) .. hewlett pakards support goes > as far as to tell me that they dont reccomend their prindeters > for use in a unix environment and that they offer no assistance in > doing so..heh.. I have a DJ 500C and it is working perfectly. I use apsfilter to get it to print postscript from Netscape. apfilter uses ghostscript to get the data converted over. I do believe the Handbook has something to say about getting these online; they're no different from normal printers, other than you do have to make an allowance to convert LF -> CR/LF. Doug White | University of Oregon Internet: dwhite@resnet.uoregon.edu | Residence Networking Assistant http://gladstone.uoregon.edu/~dwhite | Computer Science Major From owner-freebsd-current Sun Mar 31 01:50:35 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA13452 for current-outgoing; Sun, 31 Mar 1996 01:50:35 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id BAA13434 for ; Sun, 31 Mar 1996 01:50:29 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id LAA04991; Sun, 31 Mar 1996 11:50:23 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id LAA19281; Sun, 31 Mar 1996 11:50:22 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id LAA10027; Sun, 31 Mar 1996 11:41:44 +0200 (MET DST) From: J Wunsch Message-Id: <199603310941.LAA10027@uriah.heep.sax.de> Subject: Re: tzsetup To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sun, 31 Mar 1996 11:41:43 +0200 (MET DST) Cc: jmacd@CS.Berkeley.EDU (Josh MacDonald) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199603302322.PAA15110@paris.CS.Berkeley.EDU> from "Josh MacDonald" at Mar 30, 96 03:22:12 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Josh MacDonald wrote: > I think its confused, as I noticed this both in the 2.2-960323-SNAP > installation floppies and when run after installation. When I It still used to be broken for all countries with more than one screenful of locations. There used to be even more brokeness, e.g. you don't need to believe that an /etc/localtime pointing to /usr/share/zoneinfo/Atlantic/Azores must have been the definition for the Azores -- a previous call to tzsetup(8) could easily have written the zone information for Moscow into this file. :-(( A commit is on the way... -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sun Mar 31 01:50:35 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA13454 for current-outgoing; Sun, 31 Mar 1996 01:50:35 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id BAA13445 for ; Sun, 31 Mar 1996 01:50:32 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id LAA05004 for ; Sun, 31 Mar 1996 11:50:30 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id LAA19284 for freebsd-current@FreeBSD.org; Sun, 31 Mar 1996 11:50:30 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id LAA10074 for freebsd-current@FreeBSD.org; Sun, 31 Mar 1996 11:47:20 +0200 (MET DST) From: J Wunsch Message-Id: <199603310947.LAA10074@uriah.heep.sax.de> Subject: Re: Fixit Floppy Broken? To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sun, 31 Mar 1996 11:47:20 +0200 (MET DST) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from "Andreas Klemm" at Mar 30, 96 07:33:53 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Andreas Klemm wrote: > I think you're deadly right in this point... > A simple nice boot disk with a generic kernel with tools like: > fsck, scsi, ed, cat, more, newfs, mkfs, ls, rm ... and ,friends' is > badly needed ;-) It won't work. People demand too much to fit onto a single floppy, so splitting off /kernel onto a second one doesn't seem to be so bad either. > And of course a nicely working MAKEDEV, that creates the needed /dev/ > entries, if you have for example 2 SCSI disks and perhaps even more. It can go away with the advent of devfs. :-) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sun Mar 31 01:50:38 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA13475 for current-outgoing; Sun, 31 Mar 1996 01:50:38 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id BAA13448 for ; Sun, 31 Mar 1996 01:50:33 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id LAA04999; Sun, 31 Mar 1996 11:50:26 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id LAA19283; Sun, 31 Mar 1996 11:50:25 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id LAA10060; Sun, 31 Mar 1996 11:46:01 +0200 (MET DST) From: J Wunsch Message-Id: <199603310946.LAA10060@uriah.heep.sax.de> Subject: Re: Fixit Floppy Broken? To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sun, 31 Mar 1996 11:46:00 +0200 (MET DST) Cc: handy@sxt2.space.lockheed.com (Brian N. Handy) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from "Brian N. Handy" at Mar 30, 96 11:55:44 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Brian N. Handy wrote: > > ..., about nobody really uses file systems on > > floppies... > > Well...I usually don't either. A colleage had blown away his > libc.so.3.0, and needed a new copy so I figured this would be simple. Why didn't you do what everybody else does: create a tar floppy? (Mount a r/o medium read-write.) > (2) Maybe the mount routine should complain and die if it tried to mount > the floppy read-write when the floppy is write-protected. Our floppy driver is not smart enough about write-protected media at open(2) time. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sun Mar 31 02:18:31 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA15235 for current-outgoing; Sun, 31 Mar 1996 02:18:31 -0800 (PST) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id CAA15222 for ; Sun, 31 Mar 1996 02:18:24 -0800 (PST) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) id MAA23573 for current@FreeBSD.org; Sun, 31 Mar 1996 12:00:31 +0200 (MET DST) Received: from localhost (localhost [127.0.0.1]) by gun.de (8.7.5/8.7.3) with SMTP id KAA12460 for ; Sun, 31 Mar 1996 10:57:21 +0200 (MET DST) Date: Sun, 31 Mar 1996 10:57:20 +0200 (MET DST) From: Andreas Klemm To: current@FreeBSD.org Subject: sys/kern/Makefile updated to allow 'make tags' Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hi folks, just a small fix to allow a 'make tags' working. Andreas /// Index: Makefile =================================================================== RCS file: /cvs/src/sys/kern/Makefile,v retrieving revision 1.3 diff -u -r1.3 Makefile - --- Makefile 1995/09/19 13:30:49 1.3 +++ Makefile 1996/03/31 08:54:42 @@ -2,7 +2,7 @@ # Makefile for kernel tags files, init_sysent, etc. - -ARCH= hp300 i386 luna68k news3400 pmax sparc tahoe vax +ARCH= i386 # hp300 luna68k news3400 pmax sparc tahoe vax all: @echo "make tags, make links or init_sysent.c only" - -- andreas@knobel.gun.de /\/\___ Wiechers & Partner Datentechnik GmbH Andreas Klemm ___/\/\/ $$ Support Unix - aklemm@wup.de $$ pgp p-key http://www-swiss.ai.mit.edu/~bal/pks-toplev.html >>> powered by <<< ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz >>> FreeBSD <<< -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMV5I8fMLpmkD/U+FAQHajgP9H0lABYPJ5Tn6wXT2rTVLiBNoHpFFhKTn u1B4RqpVYqATwE3WxAxVKUk/+mGgH137vMjl34Cuo5HLUNAEYyt9JypQUJK//OSn r2PsigZ34cpuDGLVr8uPkz6Qfk+Z8NOYAyogNzv7wS6Fz4Z9rR9wFKad/B7QYHF/ ulKqfmydc4M= =zMIl -----END PGP SIGNATURE----- From owner-freebsd-current Sun Mar 31 02:18:46 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA15281 for current-outgoing; Sun, 31 Mar 1996 02:18:46 -0800 (PST) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id CAA15272 for ; Sun, 31 Mar 1996 02:18:43 -0800 (PST) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) id MAA23528; Sun, 31 Mar 1996 12:00:27 +0200 (MET DST) Received: from localhost (localhost [127.0.0.1]) by gun.de (8.7.5/8.7.3) with SMTP id KAA01423; Sun, 31 Mar 1996 10:02:29 +0200 (MET DST) Date: Sun, 31 Mar 1996 10:02:27 +0200 (MET DST) From: Andreas Klemm To: Terry Lambert cc: j@uriah.heep.sax.de, current@FreeBSD.org Subject: Re: FreeBSD performance vs BSD/OS In-Reply-To: <199603302008.NAA09522@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Sat, 30 Mar 1996, Terry Lambert wrote: > > > > > HZ values? > > > > > > > > Hi Terry ! > > > > > > > > Did nothing special ... only compiled and installed perl, and > > > > after that I did a make test in the ports directory... > > > > > > > > So it's just the normal one I think... > > > > > > The tests may assume HZ=60 (it does on most machines). HZ on BSD > > > is 100. > > > > > > This would make BSD seem to perform 40% slower than other systems. > > > > Ah, now I get it ... ;-) But I thought, HZ on BSD is about 128 ... ?! > > Hmmmm.... > > It should be, since it would mean we could move the HZ clock of the > TOD clock, but I don't think it is. Morning Terry ! If I remember right this was discussed already some months ago and the result was, that freebsd has 128 HZ. BTW, I think it was Joerg, whi told me that. And if you run a benchmark like ssba (I think it was this one) that tries to figure out HZ itself, then you get values about 128 or 130... Perhaps someone else can make this more clear ?! I digged around in the kernel sources in microtime and some other places, but didn't find the right place... Perhaps this should go into a manpage ?! rtc for real time clock or somewhere else ??? Andreas /// - -- andreas@knobel.gun.de /\/\___ Wiechers & Partner Datentechnik GmbH Andreas Klemm ___/\/\/ $$ Support Unix - aklemm@wup.de $$ pgp p-key http://www-swiss.ai.mit.edu/~bal/pks-toplev.html >>> powered by <<< ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz >>> FreeBSD <<< -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMV48FPMLpmkD/U+FAQGfrgP/fyk7nT76uKoSJnI6+CTii8fDUicNHqMJ BsAItjJuavWXwoJcNkBv+6q9gwdI4l/gObytpr0Detw1tnHgB5K31VYfGoUQyiJC TOJE4sNHe/BFNnwBo/5YOGQ6IYFX++65oxmGtpu8XdZ1ISomVDoFR3cLpUHbnYSn eo5qBKroqy4= =1ouB -----END PGP SIGNATURE----- From owner-freebsd-current Sun Mar 31 02:40:37 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA17521 for current-outgoing; Sun, 31 Mar 1996 02:40:37 -0800 (PST) Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id CAA17513 Sun, 31 Mar 1996 02:40:30 -0800 (PST) Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.7.5/8.6.9) id CAA00741; Sun, 31 Mar 1996 02:40:28 -0800 (PST) Date: Sun, 31 Mar 1996 02:40:28 -0800 (PST) Message-Id: <199603311040.CAA00741@silvia.HIP.Berkeley.EDU> To: gibbs@freefall.freebsd.org CC: current@freefall.freebsd.org In-reply-to: <199603310338.TAA12095@freefall.freebsd.org> (gibbs@freefall.freebsd.org) Subject: Re: aic7xxx driver and parity error problems From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk * I've just committed a new version of the aic7xxx driver that * I believe fixes the parity problems people were seeing. If you * had parity problems, please try re-enabling parity checking in * SCSI-Select with the new driver and let me know. I'm afraid it still doesn't work here. I get the same "SCSISIGI=0x0" during fsck, and it later panicks with "timed out command times out again" while trying to start portmap. As you know, sd0 (Atlas 2GB narrow) + sd1 (Microp 4GB wide) + cd0 (Toshiba CDROM). The SCSISIGI message comes during the fsck of sd0. Satoshi From owner-freebsd-current Sun Mar 31 02:51:01 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA18291 for current-outgoing; Sun, 31 Mar 1996 02:51:01 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id CAA18284 for ; Sun, 31 Mar 1996 02:50:55 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id MAA05748 for ; Sun, 31 Mar 1996 12:50:53 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id MAA20317 for freebsd-current@FreeBSD.org; Sun, 31 Mar 1996 12:50:53 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id MAA10659 for freebsd-current@FreeBSD.org; Sun, 31 Mar 1996 12:30:14 +0200 (MET DST) From: J Wunsch Message-Id: <199603311030.MAA10659@uriah.heep.sax.de> Subject: Re: Fixit Floppy Broken? To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sun, 31 Mar 1996 12:30:14 +0200 (MET DST) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199603302103.OAA09744@phaeton.artisoft.com> from "Terry Lambert" at Mar 30, 96 02:03:57 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Terry Lambert wrote: > > Now, if someone is concerned about naive users spamming themselves then > > perhaps we need to think about an automated recovery disk but that's not > > what fixit is all about. > > What, like: > > 1) I forgot my root password, set it it 'dork' > 2) It wants me to fsck my '/' parition > 3) I tried (unsuccessfully) to start X from /etc/ttys > 4) ... All of this can be handled fine by booting with `-s'. Of course, 1) couldn't be helped iff the user declared his console location to be `insecure'. But this ain't the default, and people who care more for security than recoverability have to care for a reasonable recovery strategy anyway. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sun Mar 31 02:58:03 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA18958 for current-outgoing; Sun, 31 Mar 1996 02:58:03 -0800 (PST) Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id CAA18949 Sun, 31 Mar 1996 02:58:00 -0800 (PST) Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.7.5/8.6.9) id CAA00635; Sun, 31 Mar 1996 02:57:57 -0800 (PST) Date: Sun, 31 Mar 1996 02:57:57 -0800 (PST) Message-Id: <199603311057.CAA00635@silvia.HIP.Berkeley.EDU> To: gibbs@freefall.freebsd.org CC: current@freefall.freebsd.org In-reply-to: <199603311040.CAA00741@silvia.HIP.Berkeley.EDU> (asami@cs.berkeley.edu) Subject: Re: aic7xxx driver and parity error problems From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk * I'm afraid it still doesn't work here. I get the same "SCSISIGI=0x0" * during fsck, and it later panicks with "timed out command times out * again" while trying to start portmap. Also, the "disable parity checking" workaround failed here, as I got "timed out in message out phase, SCSISIGI=0xe6" and stuff (I'm not sure, I had to reset the machine while it was still scrolling). This threw the SCSI system into a serious funk as the next three reboots, from cold start, failed with a solid hang during the probe from ahc0 (I've told you about this before). It has come up now (with parity checking disabled), so I guess it (the workaround) does work sometimes. Satoshi From owner-freebsd-current Sun Mar 31 04:42:59 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA23485 for current-outgoing; Sun, 31 Mar 1996 04:42:59 -0800 (PST) Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id EAA23479 Sun, 31 Mar 1996 04:42:54 -0800 (PST) Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.12/8.6.9) id EAA01469; Sun, 31 Mar 1996 04:42:52 -0800 Date: Sun, 31 Mar 1996 04:42:52 -0800 Message-Id: <199603311242.EAA01469@silvia.HIP.Berkeley.EDU> To: gibbs@freefall.freebsd.org CC: current@freefall.freebsd.org In-reply-to: <199603311057.CAA00635@silvia.HIP.Berkeley.EDU> (asami@cs.berkeley.edu) Subject: Re: aic7xxx driver and parity error problems From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk * Also, the "disable parity checking" workaround failed here, as I got * "timed out in message out phase, SCSISIGI=0xe6" and stuff (I'm not * sure, I had to reset the machine while it was still scrolling). * * This threw the SCSI system into a serious funk as the next three * reboots, from cold start, failed with a solid hang during the probe * from ahc0 (I've told you about this before). * * It has come up now (with parity checking disabled), so I guess it (the * workaround) does work sometimes. More update. The machine crashed shortly afterwards (running an old kernel), and it seemed to have caused something to go seriously wrong. I haven't been able to boot -current in about 15 tries, using new kernels, old kernels (unfortunately I have only one version, which is about 3 days old, which WAS running flawlessly until tonight), parity turned on/off, etc. It always dies with the "sd1: timed out in message in phase, SCSISIGI=0xe6" (note it's now sd1). However, I managed to boot the -stable system I haven't touched for months. The funny thing is, this system is on sd1. I'm quite puzzled. Satoshi From owner-freebsd-current Sun Mar 31 05:46:04 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA24868 for current-outgoing; Sun, 31 Mar 1996 05:46:04 -0800 (PST) Received: from diablo.ppp.de (diablo.ppp.de [193.141.101.34]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id FAA24862 for ; Sun, 31 Mar 1996 05:45:59 -0800 (PST) Received: from allegro.lemis.de by diablo.ppp.de with smtp (Smail3.1.28.1 #1) id m0u3NS8-000QXsC; Sun, 31 Mar 96 15:45 MET DST From: grog@lemis.de (Greg Lehey) Organisation: LEMIS, Schellnhausen 2, 36325 Feldatal, Germany Phone: +49-6637-919123 Fax: +49-6637-919122 Received: (grog@localhost) by allegro.lemis.de (8.6.9/8.6.9) id PAA00499 for current@freebsd.org; Sun, 31 Mar 1996 15:43:51 +0200 Message-Id: <199603311343.PAA00499@allegro.lemis.de> Subject: gcc symbols broken in -current? To: current@freebsd.org Date: Sun, 31 Mar 1996 15:43:51 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've just run into a strange problem: when debugging a user-level C program, the symbolic information is all screwed up. Consider this backtrace: > Starting program: /S/FreeBSD/Development/cdtools-1.3/mklinks -k -s2 /src/2.2-CURRENT/src/sys /usr/src/sys > During symbol reading...unknown symbol type 0x1e... What's that? > (gdb) bt > #0 0x8039848 in link () > #1 0x22a1 in checkdir (src=0xefbfd05c "/src/2.2-CURRENT/src/sys/CVS", dst=0xefbfcc5c "/usr/src/sys/CVS") > at mklinks.c:198 > #2 0x1fc3 in checkdir (src=0xefbfd5ba "/src/2.2-CURRENT/src/sys", dst=0xefbfd5d3 "/usr/src/sys") at mklinks.c:290 > #3 0x3e4f in main (argc=5, argv=0xefbfd4a8) at mklinks.c:674 > (gdb) f 1 > #1 0x22a1 in checkdir (src=0xefbfd05c "/src/2.2-CURRENT/src/sys/CVS", dst=0xefbfcc5c "/usr/src/sys/CVS") > at mklinks.c:198 > 198 if (dohardlink) > (gdb) l > 193 fprintf (stderr, "*** Can't unlink %s: %s\n", srcname, strerror (errno)); > 194 else > 195 { > 196 if (verbose > 1) > 197 fprintf (stderr, "--- Unlinked %s\n", srcname); > 198 if (dohardlink) > 199 { > 200 if (link (srcname, dstname)) /* can't link the new source? */ > 201 fprintf (stderr, "*** Can't link %s to %s: %s\n", srcname, dstname, strerror (errno)); > 202 else if (verbose > 1) First, the function name for frame 1 is incorrect: it's in linkreplace, not checkdir. Then the line number is incorrect: it's 200, not 198. The line numbers are, in fact, all off by 2. This problem obviously comes from the compiler: if I compile the same source under BSD/386, and then run it under FreeBSD with the same debugger, things look correct: > (gdb) bt > #0 0x3aa4 in link () > #1 0x155d in linkreplace (srcname=0xefbfbafc "/src/2.2-CURRENT/src/sys/compile/CVS/Root", > dstname=0xefbfb6fc "/usr/src/sys/compile/CVS/Root", dohardlink=1) at mklinks.c:200 > #2 0x268b in checkdir (src=0xefbfc5ac "/src/2.2-CURRENT/src/sys/compile/CVS", > dst=0xefbfc1ac "/usr/src/sys/compile/CVS") at mklinks.c:553 > #3 0x1bb7 in checkdir (src=0xefbfd05c "/src/2.2-CURRENT/src/sys/compile", dst=0xefbfcc5c "/usr/src/sys/compile") > at mklinks.c:292 > #4 0x1bb7 in checkdir (src=0xefbfd5b9 "/src/2.2-CURRENT/src/sys", dst=0xefbfd5d2 "/usr/src/sys") at mklinks.c:292 > #5 0x2df3 in main (argc=5, argv=0xefbfd4a8) at mklinks.c:676 The error message at the start doesn't get printed, either. Greg From owner-freebsd-current Sun Mar 31 09:16:34 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA04815 for current-outgoing; Sun, 31 Mar 1996 09:16:34 -0800 (PST) Received: from cocoa.ops.neosoft.com (root@cocoa.ops.neosoft.com [206.109.5.227]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id JAA04803 Sun, 31 Mar 1996 09:16:27 -0800 (PST) Received: (from dbaker@localhost) by cocoa.ops.neosoft.com (8.7.5/8.6.12) id LAA02288; Sun, 31 Mar 1996 11:16:06 -0600 (CST) Date: Sun, 31 Mar 1996 11:16:02 -0600 (CST) From: Daniel Baker X-Sender: dbaker@cocoa.ops.neosoft.com To: freebsd-current@freebsd.org, freebsd-hardware@freebsd.org Subject: Quickcam qcamcontrol problems Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hey, I think the new qcam drivers and programs are pretty cool, but I've been having some problems.... :-( First of all, if all of the arguments on qcamcontrol work except for the brightness one (-b). It causes it to have a segmentation fault and then it dumps core. Secondly, it causes my machine to reboot sometimes.. I have it in cron to take a picture every once in a while and put it on my webpage, and that makes my machine very very unstable, because it will reboot often, but sometimes when I do it as a command line option, it will just freeze and reboot -- not sure if it's a panic.. Is anybody else having these problems, or is it just me? Daniel Daniel Baker - Daniel@Cuckoo.COM "Uhhhhhhh, thank you, drive through please" From owner-freebsd-current Sun Mar 31 09:38:54 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA06902 for current-outgoing; Sun, 31 Mar 1996 09:38:54 -0800 (PST) Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id JAA06897 for ; Sun, 31 Mar 1996 09:38:52 -0800 (PST) Received: from localhost.shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.5/8.7.3) with SMTP id JAA13197; Sun, 31 Mar 1996 09:38:10 -0800 (PST) Message-Id: <199603311738.JAA13197@precipice.shockwave.com> To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) cc: freebsd-current@FreeBSD.org (FreeBSD-current users), handy@sxt2.space.lockheed.com (Brian N. Handy) Subject: Re: Fixit Floppy Broken? In-reply-to: Your message of "Sun, 31 Mar 1996 11:46:00 +0200." <199603310946.LAA10060@uriah.heep.sax.de> Date: Sun, 31 Mar 1996 09:38:10 -0800 From: Paul Traina Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk From: J Wunsch Subject: Re: Fixit Floppy Broken? As Brian N. Handy wrote: > > ..., about nobody really uses file systems on > > floppies... > > Well...I usually don't either. A colleage had blown away his > libc.so.3.0, and needed a new copy so I figured this would be simple. Why didn't you do what everybody else does: create a tar floppy? (Mount a r/o medium read-write.) > (2) Maybe the mount routine should complain and die if it tried to mount > the floppy read-write when the floppy is write-protected. Our floppy driver is not smart enough about write-protected media at open(2) time. That is a bug. Please file a PR From owner-freebsd-current Sun Mar 31 10:12:14 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA09373 for current-outgoing; Sun, 31 Mar 1996 10:12:14 -0800 (PST) Received: from originat.demon.co.uk (originat.demon.co.uk [158.152.220.9]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id KAA09364 for ; Sun, 31 Mar 1996 10:12:10 -0800 (PST) Received: (from paul@localhost) by originat.demon.co.uk (8.7.5/8.6.9) id TAA00582; Sun, 31 Mar 1996 19:12:35 +0100 (BST) From: Paul Richards Message-Id: <199603311812.TAA00582@originat.demon.co.uk> Subject: Re: lint.. To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Sun, 31 Mar 1996 19:12:35 +0100 (BST) Cc: current@FreeBSD.org In-Reply-To: <199603310910.BAA13477@time.cdrom.com> from "Jordan K. Hubbard" at Mar 31, 96 01:10:15 am Reply-to: paul@netcraft.co.uk X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk In reply to Jordan K. Hubbard who said > > Will the person who enabled lint by default also please add the > appropriate magic to the tools target so that `make world' doesn't > fall over in -current anymore? We really need to make sure that > `make world' keeps working when we make these sorts of changes and > just fixing it by hand doesn't cut it. Thanks! What tools target? What's breaking make world? -- Paul Richards, Originative Solutions Ltd. Internet: paul@netcraft.co.uk, http://www.netcraft.co.uk Phone: 0370 462071 (Mobile), +44 1225 447500 (work) From owner-freebsd-current Sun Mar 31 10:27:11 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA10293 for current-outgoing; Sun, 31 Mar 1996 10:27:11 -0800 (PST) Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA10284 Sun, 31 Mar 1996 10:27:09 -0800 (PST) Message-Id: <199603311827.KAA10284@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: Host localhost.cdrom.com [127.0.0.1] didn't use HELO protocol To: asami@cs.berkeley.edu (Satoshi Asami) cc: current@freefall.freebsd.org Subject: Re: aic7xxx driver and parity error problems In-reply-to: Your message of "Sun, 31 Mar 1996 04:42:52 PST." <199603311242.EAA01469@silvia.HIP.Berkeley.EDU> Date: Sun, 31 Mar 1996 10:27:09 -0800 From: "Justin T. Gibbs" Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > * Also, the "disable parity checking" workaround failed here, as I got > * "timed out in message out phase, SCSISIGI=0xe6" and stuff (I'm not > * sure, I had to reset the machine while it was still scrolling). > * > * This threw the SCSI system into a serious funk as the next three > * reboots, from cold start, failed with a solid hang during the probe > * from ahc0 (I've told you about this before). > * > * It has come up now (with parity checking disabled), so I guess it (the > * workaround) does work sometimes. > >More update. The machine crashed shortly afterwards (running an old >kernel), and it seemed to have caused something to go seriously wrong. >I haven't been able to boot -current in about 15 tries, using new >kernels, old kernels (unfortunately I have only one version, which is >about 3 days old, which WAS running flawlessly until tonight), parity >turned on/off, etc. It always dies with the "sd1: timed out in >message in phase, SCSISIGI=0xe6" (note it's now sd1). > >However, I managed to boot the -stable system I haven't touched for >months. The funny thing is, this system is on sd1. I'm quite >puzzled. > >Satoshi Could it be a power supply problem? Or perhaps your Atlas is causing SCSI bus noise? Are other 7880 owners seeing this as well with the -current driver? -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Sun Mar 31 10:36:29 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA10958 for current-outgoing; Sun, 31 Mar 1996 10:36:29 -0800 (PST) Received: from veda.is (root@ubiq.veda.is [193.4.230.60]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id KAA10953 for ; Sun, 31 Mar 1996 10:36:22 -0800 (PST) Received: (from adam@localhost) by veda.is (8.7.5/8.7.3) id SAA01378; Sun, 31 Mar 1996 18:35:36 GMT Date: Sun, 31 Mar 1996 18:35:36 GMT From: Adam David Message-Id: <199603311835.SAA01378@veda.is> To: mmead@glock.com Cc: freebsd-current@freebsd.org Subject: kernel locking hangs system? X-Newsreader: NN version 6.5.0 #2 (NOV) Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I just supped everything this evening and did a make install. > Of course, /var/mail was set mode 755 owned by bin.bin > > mmead@Glock.COM If you make /var/mail a symlink to somewhere else, mtree will leave it alone. -- Adam David From owner-freebsd-current Sun Mar 31 10:51:44 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA11618 for current-outgoing; Sun, 31 Mar 1996 10:51:44 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id KAA11613 for ; Sun, 31 Mar 1996 10:51:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with SMTP id KAA19892; Sun, 31 Mar 1996 10:50:06 -0800 (PST) To: paul@netcraft.co.uk cc: current@FreeBSD.org Subject: Re: lint.. In-reply-to: Your message of "Sun, 31 Mar 1996 19:12:35 +0100." <199603311812.TAA00582@originat.demon.co.uk> Date: Sun, 31 Mar 1996 10:50:06 -0800 Message-ID: <19890.828298206@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk First it blew up trying to run lint on something when lint wasn't even installed. So then I installed lint by hand, figuring that was the temporary fix, and I ran make world again: gzip -c /a/src-current/usr.bin/xlint/xlint/lint.1 > lint.1.gz ===> usr.bin/xlint/llib lint -Cc /a/src-current/usr.bin/xlint/llib/llib-lc llib-lc: lint: cannot exec /usr/libexec/lint1: No such file or directory *** Error code 1 Stop. Nope, no cigar. It's easy to test this, simply nuke lint off your system and do a make world - it will fall over. Please fix this soon or let me back lint out of the various *.mk files so that nothing tries to use it before it's ready. I'll give you a couple of days before taking that step, but I'd really like to have make world working again. Jordan > In reply to Jordan K. Hubbard who said > > > > Will the person who enabled lint by default also please add the > > appropriate magic to the tools target so that `make world' doesn't > > fall over in -current anymore? We really need to make sure that > > `make world' keeps working when we make these sorts of changes and > > just fixing it by hand doesn't cut it. Thanks! > > > What tools target? What's breaking make world? > > -- > Paul Richards, Originative Solutions Ltd. > Internet: paul@netcraft.co.uk, http://www.netcraft.co.uk > Phone: 0370 462071 (Mobile), +44 1225 447500 (work) From owner-freebsd-current Sun Mar 31 10:54:00 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA11753 for current-outgoing; Sun, 31 Mar 1996 10:54:00 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id KAA11740 for ; Sun, 31 Mar 1996 10:53:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with SMTP id KAA19929; Sun, 31 Mar 1996 10:53:14 -0800 (PST) To: Andreas Klemm cc: current@FreeBSD.org Subject: Re: sys/kern/Makefile updated to allow 'make tags' In-reply-to: Your message of "Sun, 31 Mar 1996 10:57:20 +0200." Date: Sun, 31 Mar 1996 10:53:13 -0800 Message-ID: <19927.828298393@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > -----BEGIN PGP SIGNED MESSAGE----- > > Hi folks, just a small fix to allow a 'make tags' working. Got it! Jordan From owner-freebsd-current Sun Mar 31 11:04:07 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA12150 for current-outgoing; Sun, 31 Mar 1996 11:04:07 -0800 (PST) Received: from originat.demon.co.uk (originat.demon.co.uk [158.152.220.9]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id LAA12145 for ; Sun, 31 Mar 1996 11:04:02 -0800 (PST) Received: (from paul@localhost) by originat.demon.co.uk (8.7.5/8.6.9) id UAA09220; Sun, 31 Mar 1996 20:04:19 +0100 (BST) From: Paul Richards Message-Id: <199603311904.UAA09220@originat.demon.co.uk> Subject: Re: lint.. To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Sun, 31 Mar 1996 20:04:19 +0100 (BST) Cc: paul@netcraft.co.uk, current@FreeBSD.org In-Reply-To: <19890.828298206@time.cdrom.com> from "Jordan K. Hubbard" at Mar 31, 96 10:50:06 am Reply-to: paul@netcraft.co.uk X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk In reply to Jordan K. Hubbard who said > > First it blew up trying to run lint on something when lint wasn't even > installed. So then I installed lint by hand, figuring that was the > temporary fix, and I ran make world again: > > gzip -c /a/src-current/usr.bin/xlint/xlint/lint.1 > lint.1.gz > ===> usr.bin/xlint/llib > lint -Cc /a/src-current/usr.bin/xlint/llib/llib-lc > llib-lc: > lint: cannot exec /usr/libexec/lint1: No such file or directory > *** Error code 1 > > Stop. > > Nope, no cigar. It's easy to test this, simply nuke lint off your > system and do a make world - it will fall over. Sounds like your Makefile is out of date. There's a bootstrap target that installs lint before anything else. world: hierarchy mk $(WORLD_CLEANDIST) bootstrap include-tools includes lib-too ls libraries build-tools @echo "--------------------------------------------------------------" @echo " Rebuilding ${DESTDIR} The whole thing" @echo "--------------------------------------------------------------" @echo ${MAKE} depend all install cd ${.CURDIR}/share/man && ${MAKE} makedb @echo "make world completed on `date`" bootstrap: cd ${.CURDIR}/usr.bin/xlint && ${MAKE} lint1 lint2 xlint cd ${.CURDIR}/usr.bin/xlint/lint1 && ${MAKE} install cd ${.CURDIR}/usr.bin/xlint/lint2 && ${MAKE} install cd ${.CURDIR}/usr.bin/xlint/xlint && ${MAKE} install lint isn't enabled anywhere, all I've done is install the binary. -- Paul Richards, Originative Solutions Ltd. Internet: paul@netcraft.co.uk, http://www.netcraft.co.uk Phone: 0370 462071 (Mobile), +44 1225 447500 (work) From owner-freebsd-current Sun Mar 31 11:07:04 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA12295 for current-outgoing; Sun, 31 Mar 1996 11:07:04 -0800 (PST) Received: from neon.Glock.COM (neon.glock.com [198.82.228.159]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id LAA12289 for ; Sun, 31 Mar 1996 11:07:02 -0800 (PST) Received: (from mmead@localhost) by neon.Glock.COM (8.7.5/8.7.3) id OAA08482; Sun, 31 Mar 1996 14:06:06 -0500 (EST) From: "matthew c. mead" Message-Id: <199603311906.OAA08482@neon.Glock.COM> Subject: Re: kernel locking hangs system? To: adam@veda.is (Adam David) Date: Sun, 31 Mar 1996 14:06:05 -0500 (EST) Cc: freebsd-current@freebsd.org In-Reply-To: <199603311835.SAA01378@veda.is> from "Adam David" at Mar 31, 96 06:35:36 pm X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Adam David writes: > > I just supped everything this evening and did a make install. > > Of course, /var/mail was set mode 755 owned by bin.bin > If you make /var/mail a symlink to somewhere else, mtree will leave it alone. Well, yeah. There are also other ways of making "make world" not touch it with mtree. My point is, a system should not hang when a kernel lock is requested for a readonly directory! -matt -- Matthew C. Mead mmead@Glock.COM http://www.Glock.COM/~mmead/ From owner-freebsd-current Sun Mar 31 11:08:55 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA12581 for current-outgoing; Sun, 31 Mar 1996 11:08:55 -0800 (PST) Received: from originat.demon.co.uk (originat.demon.co.uk [158.152.220.9]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id LAA12561 for ; Sun, 31 Mar 1996 11:08:49 -0800 (PST) Received: (from paul@localhost) by originat.demon.co.uk (8.7.5/8.6.9) id UAA12895; Sun, 31 Mar 1996 20:09:14 +0100 (BST) From: Paul Richards Message-Id: <199603311909.UAA12895@originat.demon.co.uk> Subject: Re: lint.. To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Sun, 31 Mar 1996 20:09:14 +0100 (BST) Cc: paul@netcraft.co.uk, current@FreeBSD.org In-Reply-To: <19890.828298206@time.cdrom.com> from "Jordan K. Hubbard" at Mar 31, 96 10:50:06 am Reply-to: paul@netcraft.co.uk X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk In reply to Jordan K. Hubbard who said > > > Please fix this soon or let me back lint out of the various *.mk files > so that nothing tries to use it before it's ready. I'll give you a Missed this in my last reply, but to make it absolutely clear, nothing's been changed in the mk files. All that's happened is that I've added a bootstrap target to install the lint binaries early and the only place lint is actually used is in the building of lint itself which is why a bootstrap target was needed in the first place. We're a long way off enabling lint in the mk files but at least lint is there for people to use now and if you ignore all the library function errors it's actually usefull for detecting a lot of things as it is. -- Paul Richards, Originative Solutions Ltd. Internet: paul@netcraft.co.uk, http://www.netcraft.co.uk Phone: 0370 462071 (Mobile), +44 1225 447500 (work) From owner-freebsd-current Sun Mar 31 11:21:07 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA14329 for current-outgoing; Sun, 31 Mar 1996 11:21:07 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id LAA14323 for ; Sun, 31 Mar 1996 11:21:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with SMTP id LAA20143; Sun, 31 Mar 1996 11:19:42 -0800 (PST) To: paul@netcraft.co.uk cc: current@FreeBSD.org Subject: Re: lint.. In-reply-to: Your message of "Sun, 31 Mar 1996 20:04:19 +0100." <199603311904.UAA09220@originat.demon.co.uk> Date: Sun, 31 Mar 1996 11:19:42 -0800 Message-ID: <20141.828299982@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Sounds like your Makefile is out of date. There's a bootstrap target that > installs lint before anything else. Bizarre! I just updated my tree last night (using RCVS straight from freefall's repository) and that's not in there. Hmmmmmm. OK, I'm investigating. If this turns out to be some cvs update bogosity, please accept my apologies in advance! Jordan From owner-freebsd-current Sun Mar 31 11:37:35 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA17943 for current-outgoing; Sun, 31 Mar 1996 11:37:35 -0800 (PST) Received: from veda.is (root@ubiq.veda.is [193.4.230.60]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id LAA17905 for ; Sun, 31 Mar 1996 11:37:26 -0800 (PST) Received: (from adam@localhost) by veda.is (8.7.5/8.7.3) id TAA01462 for freebsd-current@freebsd.org; Sun, 31 Mar 1996 19:37:16 GMT From: Adam David Message-Id: <199603311937.TAA01462@veda.is> Subject: panic: freeing held page, count=%d To: freebsd-current@freebsd.org Date: Sun, 31 Mar 1996 19:37:14 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL13 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk March 30th kernel... GDB 4.13 (i386-unknown-freebsd), Copyright 1994 Free Software Foundation, Inc... IdlePTD 1b1000 current pcb at 1a2820 panic: freeing held page, count=%d #0 boot (howto=256) at ../../i386/i386/machdep.c:942 942 dumppcb.pcb_ptd = rcr3(); (kgdb) bt #0 boot (howto=256) at ../../i386/i386/machdep.c:942 #1 0xf0112606 in panic (fmt=0xf0168f52 "freeing held page, count=%d") at ../../kern/subr_prf.c:133 #2 0xf0169042 in vm_page_free (m=0xf01d7100) at ../../vm/vm_page.c:827 #3 0xf0166ef1 in vm_object_terminate (object=0xf08a4900) at ../../vm/vm_object.c:409 #4 0xf0166d5b in vm_object_deallocate (object=0xf08a4900) at ../../vm/vm_object.c:356 #5 0xf016513c in vm_map_entry_delete (map=0xf08be300, entry=0xf08cd400) at ../../vm/vm_map.c:1620 #6 0xf016528e in vm_map_delete (map=0xf08be300, start=0, end=4026265600) at ../../vm/vm_map.c:1715 #7 0xf0163c85 in vmspace_free (vm=0xf08be300) at ../../vm/vm_map.c:255 #8 0xf0178576 in cpu_wait (p=0xf0923e00) at ../../i386/i386/vm_machdep.c:628 #9 0xf0108301 in wait1 (q=0xf08b4200, uap=0xefbfff94, retval=0xefbfff84, compat=0) at ../../kern/kern_exit.c:427 #10 0xf010812f in wait4 (p=0xf08b4200, uap=0xefbfff94, retval=0xefbfff84) at ../../kern/kern_exit.c:324 #11 0xf0174e05 in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = 0, tf_esi = 1, tf_ebp = -272638812, tf_isp = -272629788, tf_ebx = -272638748, tf_edx = 2, tf_ecx = -272638748, tf_eax = 7, tf_trapno = 12, tf_err = 7, tf_eip = 177973, tf_cs = 31, tf_eflags = 514, tf_esp = -272638832, tf_ss = 39}) at ../../i386/i386/trap.c:904 #12 0xf016d275 in Xsyscall () [...] (kgdb) up 2 #2 0xf0169042 in vm_page_free (m=0xf01d7100) at ../../vm/vm_page.c:827 827 panic("freeing held page, count=%d", m->hold_count); (kgdb) print m->hold_count $1 = 1 (kgdb) I will keep this coredump for a maximum of 3 days, if anyone needs more detail from it. -- Adam David From owner-freebsd-current Sun Mar 31 12:01:14 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA24154 for current-outgoing; Sun, 31 Mar 1996 12:01:14 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA24142 for ; Sun, 31 Mar 1996 12:01:09 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id GAA10850; Mon, 1 Apr 1996 06:00:01 +1000 Date: Mon, 1 Apr 1996 06:00:01 +1000 From: Bruce Evans Message-Id: <199603312000.GAA10850@godzilla.zeta.org.au> To: andreas@knobel.gun.de, terry@lambert.org Subject: Re: FreeBSD performance vs BSD/OS Cc: current@FreeBSD.org, j@uriah.heep.sax.de Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >If I remember right this was discussed already some months ago and >the result was, that freebsd has 128 HZ. BTW, I think it was Joerg, >whi told me that. HZ is not part of the application interface in BSD. >And if you run a benchmark like ssba (I think it was this one) that >tries to figure out HZ itself, then you get values about 128 or 130... >Perhaps someone else can make this more clear ?! I digged around in >the kernel sources in microtime and some other places, but didn't find >the right place... There are many different real and virtual (timekeeping) clocks with different frequencies: - the scheduling clock. This is a real clock with frequency that happens to be 100. It isn't available to applications. - the statistics clock. This is a real clock with frequency that happens to be 128. It isn't directly available to applications. - the clock reported by clock(3). This is a virtual clock with a frequency that happens to be 128. It's actual frequency is given by the macro CLOCKS_PER_SEC. Note that CLOCKS_PER_SEC may be floating point. Don't use clock() in new programs under FreeBSD. It is feeble compared with getrusage(). It is provided for ANSI conformance. It is implemented by calling getrusage() and throwing away information and resolution. - the clock reported by times(3). This is a virtual clock with a frequency that happens to be 128. It's actual frequency is given by the macro CLK_TCK (deprecated; don't use) and by sysconf(_SC_CLK_TCK) and by sysctl(3). Note that its frequency may be different fro CLOCKS_PER_SEC. Don't use times() in new programs under FreeBSD. It is feeble compared with gettimeofday() together with getrusage(). It is provided for POSIX conformance. It is implemented by calling gettimeofday() and getrusage() and throwing away information and resolution. - the profiling clock. This is a real clock with frequency 1024. It is used mainly by moncontrol(3), kgmon(8) and gprof(1). Applications should determine its actual frequency using sysctl(3) or by reading it from the header in the profiling data file. - the mc14618a clock. This is a real clock with a nominal frequency of 32768. It is divided down to give the statistic clock and the profiling clock. It isn't available to applications. - the microseconds clock. This is a virtual clock with frequency 1000000. It is used for most timekeeping in BSD and is exported to applications in getrusage(2), gettimeofday(2), select(2), getitimer(2), ... This is the clock that should normally be used by BSD applications. - the i8254 clock. This is a real clock with a nominal frequency of 1193182. It is divided down to give the scheduling clock. It isn't available to applications. - the i586 clock on i586 systems. This is a real clock with a frequency of up to 200000000. It is used to interpolate between values of the scheduling clock. It isn't available to applications. Summary: if "HZ" isn't 1000000 then the application is probably using the wrong clock. Bruce From owner-freebsd-current Sun Mar 31 12:22:14 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA25350 for current-outgoing; Sun, 31 Mar 1996 12:22:14 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA25345 for ; Sun, 31 Mar 1996 12:22:07 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id WAA16839; Sun, 31 Mar 1996 22:21:40 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id WAA26962; Sun, 31 Mar 1996 22:21:40 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id VAA00526; Sun, 31 Mar 1996 21:02:40 +0200 (MET DST) From: J Wunsch Message-Id: <199603311902.VAA00526@uriah.heep.sax.de> Subject: Re: Fixit Floppy Broken? To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sun, 31 Mar 1996 21:02:40 +0200 (MET DST) Cc: handy@sxt2.space.lockheed.com Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199603311738.JAA13197@precipice.shockwave.com> from "Paul Traina" at Mar 31, 96 09:38:10 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Paul Traina wrote: > Our floppy driver is not smart enough about write-protected media at > open(2) time. > > That is a bug. Please file a PR Filing a PR won't help very much. The floppy driver is in bad need for a rewrite. If you're willing to rewrite it, and submitting PRs would accelerate this process, i could immediately submit half a dozen PRs for it. :-) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sun Mar 31 12:52:45 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA27113 for current-outgoing; Sun, 31 Mar 1996 12:52:45 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA27101 for ; Sun, 31 Mar 1996 12:52:39 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id WAA17389; Sun, 31 Mar 1996 22:52:19 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id WAA27342; Sun, 31 Mar 1996 22:52:19 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id WAA00886; Sun, 31 Mar 1996 22:40:15 +0200 (MET DST) From: J Wunsch Message-Id: <199603312040.WAA00886@uriah.heep.sax.de> Subject: Re: FreeBSD performance vs BSD/OS To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sun, 31 Mar 1996 22:40:14 +0200 (MET DST) Cc: bde@zeta.org.au (Bruce Evans) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199603312000.GAA10850@godzilla.zeta.org.au> from "Bruce Evans" at Apr 1, 96 06:00:01 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Bruce Evans wrote: > There are many different real and virtual (timekeeping) clocks with > different frequencies: Should this become time(9)? -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sun Mar 31 12:52:45 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA27119 for current-outgoing; Sun, 31 Mar 1996 12:52:45 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA27078 for ; Sun, 31 Mar 1996 12:52:33 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id WAA17374 for ; Sun, 31 Mar 1996 22:52:15 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id WAA27339 for freebsd-current@FreeBSD.org; Sun, 31 Mar 1996 22:52:14 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id WAA00808 for freebsd-current@FreeBSD.org; Sun, 31 Mar 1996 22:31:00 +0200 (MET DST) From: J Wunsch Message-Id: <199603312031.WAA00808@uriah.heep.sax.de> Subject: Re: cvs commit: src/usr.sbin/tzsetup Makefile main.c tzmenu.c To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sun, 31 Mar 1996 22:31:00 +0200 (MET DST) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <20041.828299250@time.cdrom.com> from "Jordan K. Hubbard" at Mar 31, 96 11:07:30 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk (Moved to -current, where this better fits.) As Jordan K. Hubbard wrote: > I think this is reasonable. If I'm running single-user with nothing > but root mounted, I *expect* some things not to work quite right. I > can't run vi very nicely without my /var mounted either, for that > matter, and I usually find this far more objectionable than the > timezone being set wrong. Funny you should mention this -- vi needs /usr/share/misc/termcap as well. :-)) I hope we won't install termcap directly into /etc now... IMHO, dumping over the entire zoneinfo file into /etc defeats the idea of keeping the zoneinfo files in a separate directory, and it adds yet another file of binary junk to /etc. Anyway, this file is rather small, and i'm not willing to fight yet another absolutely sensefree argumentation war about it. So tell me folks whether my compromise proposal (re-establish the symlink if it's already been one, copy the file if it's been a regular file) would find a majority. This still leaves the question of which kind of /etc/localtime to install in the first place, but i'm sick of arguing here and simply copy over the file in this case. As long as i could have a symlink for myself, and one that won't be clobbered, it'll be ok for me. Funny btw., tzsetup was almost absolutely useless before. Now that it's at least working, people complain about how it works. :-)) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sun Mar 31 13:12:23 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA28262 for current-outgoing; Sun, 31 Mar 1996 13:12:23 -0800 (PST) Received: from mail.think.com (Mail1.Think.COM [131.239.33.245]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA28253 for ; Sun, 31 Mar 1996 13:12:18 -0800 (PST) Received: from Early-Bird-1.Think.COM by mail.think.com; Sun, 31 Mar 96 16:12:16 -0500 Received: from compound ([206.10.99.151]) by Early-Bird.Think.COM; Sun, 31 Mar 96 16:12:12 EST Received: (from alk@localhost) by compound (8.6.12/8.6.112) id PAA26582; Sun, 31 Mar 1996 15:13:34 -0600 Date: Sun, 31 Mar 1996 15:13:34 -0600 Message-Id: <199603312113.PAA26582@compound> From: Tony Kimball To: current@freefall.freebsd.org In-Reply-To: <199603310923.BAA11501@freefall.freebsd.org> (owner-current-digest@freefall.freebsd.org) Subject: Re: We need to do another XFree86 release for -current someday soon.. Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The $80,000 question. > : Please, that isn't good enough to justify the cost. Stub them to > : return errors. There isn't anything to vote on; you're a month too late. That's just silly. Anything that can be done can be undone. It's just bits. The better part of wisdom lies in learning to gracefully correct mistakes. This is a mistake. Funny, nobody complained back when Garrett did announce his intention. Different audience. Fortunately there is now someone here to say that this was a mistake and should be corrected. All of these objections bear absolutely no logical relationship to the significant points, merely a rhetorical one. The overriding significant point lies in the question whether or not it is a good thing to do, upping the major version, consonant with the goals of the project. If it is not, it was a mistake and should be corrected if the cost of correcting it is less than the cost of living with it. I say it was a mistake, although not a terribly serious one. It is, however, serious enough so that I claim that correcting it is a worthwhile act. My claim is dubious in part because I do not have the power to correct it. However, that does not discourage me from pressing my claim: Quite the contrary, it encourages me, for I understand the inertia involved all too well, and if my claim is correct I understand that it must be vigorously pressed in order to obtain fair hearing. You're talking about thousands of people suffering an aggregate loss on the order of 100 petabyte-seconds of DRAM usage (given 5000 people suffering 500kB loss over the course of one year.) In dollar terms, that's roughly $80,000 in lost productivity. I expect with some confidence that the relatively minor trouble of fixing the problem is worth much less than $80,000. Perhaps $1000 at the most. An 80:1 payback is not bad at all. Missing such an opportunity to do good is a mistake indeed. //alk From owner-freebsd-current Sun Mar 31 13:15:03 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA28432 for current-outgoing; Sun, 31 Mar 1996 13:15:03 -0800 (PST) Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA28415 Sun, 31 Mar 1996 13:14:54 -0800 (PST) Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.12/8.6.9) id NAA01151; Sun, 31 Mar 1996 13:14:40 -0800 Date: Sun, 31 Mar 1996 13:14:40 -0800 Message-Id: <199603312114.NAA01151@silvia.HIP.Berkeley.EDU> To: gibbs@freefall.freebsd.org CC: current@freefall.freebsd.org In-reply-to: <199603311827.KAA10284@freefall.freebsd.org> (gibbs@freefall.freebsd.org) Subject: Re: aic7xxx driver and parity error problems From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk * Could it be a power supply problem? Or perhaps your Atlas is causing * SCSI bus noise? Are other 7880 owners seeing this as well with the * -current driver? Yes, it could be the powwer supply, I have a 300W PS and only two disks, it may not be loaded enough. I'll try to connect more disks and see.... Satoshi From owner-freebsd-current Sun Mar 31 13:37:13 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA29764 for current-outgoing; Sun, 31 Mar 1996 13:37:13 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA29756 for ; Sun, 31 Mar 1996 13:37:10 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA11938; Sun, 31 Mar 1996 14:33:59 -0700 From: Terry Lambert Message-Id: <199603312133.OAA11938@phaeton.artisoft.com> Subject: Re: Fixit Floppy Broken? To: joerg_wunsch@uriah.heep.sax.de Date: Sun, 31 Mar 1996 14:33:59 -0700 (MST) Cc: freebsd-current@FreeBSD.ORG, handy@sxt2.space.lockheed.com In-Reply-To: <199603311902.VAA00526@uriah.heep.sax.de> from "J Wunsch" at Mar 31, 96 09:02:40 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-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > As Paul Traina wrote: > > > Our floppy driver is not smart enough about write-protected media at > > open(2) time. > > > > That is a bug. Please file a PR > > Filing a PR won't help very much. The floppy driver is in bad need > for a rewrite. > > If you're willing to rewrite it, and submitting PRs would accelerate > this process, i could immediately submit half a dozen PRs for it. :-) You should submit them even if there is no victim^H^H^H^H^Holunteer at the present time. All bugs should be recorded somewhere. 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 Mar 31 13:43:14 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA00166 for current-outgoing; Sun, 31 Mar 1996 13:43:14 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA00160 for ; Sun, 31 Mar 1996 13:43:10 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA11972; Sun, 31 Mar 1996 14:38:56 -0700 From: Terry Lambert Message-Id: <199603312138.OAA11972@phaeton.artisoft.com> Subject: Re: FreeBSD performance vs BSD/OS To: bde@zeta.org.au (Bruce Evans) Date: Sun, 31 Mar 1996 14:38:56 -0700 (MST) Cc: andreas@knobel.gun.de, terry@lambert.org, current@FreeBSD.org, j@uriah.heep.sax.de In-Reply-To: <199603312000.GAA10850@godzilla.zeta.org.au> from "Bruce Evans" at Apr 1, 96 06:00:01 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-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > There are many different real and virtual (timekeeping) clocks with > different frequencies: [ ... Bruce's exhaustive clock list ... ] THANK YOU. This should go into some documentation somewhere. Maybe clock(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 Sun Mar 31 13:48:44 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA00544 for current-outgoing; Sun, 31 Mar 1996 13:48:44 -0800 (PST) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id NAA00537 Sun, 31 Mar 1996 13:48:38 -0800 (PST) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) id XAA04773; Sun, 31 Mar 1996 23:30:15 +0200 (MET DST) Received: from localhost (localhost [127.0.0.1]) by gun.de (8.7.5/8.7.3) with SMTP id XAA01631; Sun, 31 Mar 1996 23:07:27 +0200 (MET DST) Date: Sun, 31 Mar 1996 23:07:26 +0200 (MET DST) From: Andreas Klemm To: "Justin T. Gibbs" cc: Satoshi Asami , current@freefall.freebsd.org Subject: Re: aic7xxx driver and parity error problems In-Reply-To: <199603311827.KAA10284@freefall.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Sun, 31 Mar 1996, Justin T. Gibbs wrote: > Could it be a power supply problem? Or perhaps your Atlas is causing > SCSI bus noise? Are other 7880 owners seeing this as well with the > -current driver? I'm running two SCSI disks on a AHA 2940 with parity checking enabled. I have absolutely no problems at all. FreeBSD 2.2-CURRENT #0: Sun Mar 31 11:48:28 MET DST 1996 root@knobel.gun.de:/disk2/src/sys/compile/KNOBEL CPU: Pentium (99.46-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x525 Stepping=5 Features=0x1bf real memory = 33554432 (32768K bytes) avail memory = 31338496 (30604K bytes) Probing for devices on PCI bus 0: chip0 rev 2 on pci0:0 chip1 rev 2 on pci0:7 pci0:7: Intel Corporation, device=0x1230, class=storage (ide) [no driver assigned] vga0 rev 0 int a irq 12 on pci0:10 ahc0 rev 3 int a irq 11 on pci0:12 ahc0: aic7870 Single Channel, SCSI Id=7, 16 SCBs ahc0: target 0 Tagged Queuing Device (ahc0:0:0): "QUANTUM XP34301 1051" type 0 fixed SCSI 2 sd0(ahc0:0:0): Direct-Access 4106MB (8410200 512 byte sectors) sd0(ahc0:0:0): with 4076 cyls, 20 heads, and an average 103 sectors/track (ahc0:1:0): "FUJITSU M2694ES-512 8139" type 0 fixed SCSI 1 sd1(ahc0:1:0): Direct-Access 1033MB (2117025 512 byte sectors) sd1(ahc0:1:0): with 1819 cyls, 15 heads, and an average 77 sectors/track (ahc0:6:0): "TOSHIBA CD-ROM XM-3601TA 0725" type 5 removable SCSI 2 cd0(ahc0:6:0): CD-ROM cd0(ahc0:6:0): NOT READY asc:4,1 cd0(ahc0:6:0): Logical unit is in process of becoming ready Check proper termination, don't use the termination of a CD-Rom (this caused trouble here) or best use a separate active termination ! And make a test, not to connect SCSI devices internal and external on the same SCSI controller. Heard from people, that this may cause trouble as well (if the SCSI controller is in the middle of the SCSI "chain"). That's it, good luck Andreas /// - -- andreas@knobel.gun.de /\/\___ Wiechers & Partner Datentechnik GmbH Andreas Klemm ___/\/\/ $$ Support Unix - aklemm@wup.de $$ pgp p-key http://www-swiss.ai.mit.edu/~bal/pks-toplev.html >>> powered by <<< ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz >>> FreeBSD <<< -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMV70D/MLpmkD/U+FAQFaRAP+L+T1F1iH4ickdSafkwhg4Sk58dH+05U/ 6nq2A2O295sakPNCpzjqjwtYxoDmrk6W78R5Fr3DofpQDpsiHfHlTvkeTpbgkaBm rCuI28b8GDNmMO6asZFEFnpHbwP4ky7l80eEYGtah1yBDVpmq79Vdm8WOedFT0hY m8/MRrfqOIc= =J2X6 -----END PGP SIGNATURE----- From owner-freebsd-current Sun Mar 31 13:56:19 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA01013 for current-outgoing; Sun, 31 Mar 1996 13:56:19 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA01005 for ; Sun, 31 Mar 1996 13:56:13 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA12006; Sun, 31 Mar 1996 14:52:58 -0700 From: Terry Lambert Message-Id: <199603312152.OAA12006@phaeton.artisoft.com> Subject: Re: We need to do another XFree86 release for -current someday soon.. To: joerg_wunsch@uriah.heep.sax.de Date: Sun, 31 Mar 1996 14:52:58 -0700 (MST) Cc: freebsd-current@freebsd.org In-Reply-To: <199603302314.AAA05356@uriah.heep.sax.de> from "J Wunsch" at Mar 31, 96 00:14:05 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-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > : Please, that isn't good enough to justify the cost. Stub them to > > : return errors. > > > > i would vote for this too > > Funny, nobody complained back when Garrett did announce his intention. I did, on principle that you should never delete code, and that the code was not intrinsically broken ...it was just an incomplete job of changing some related code that is causing it to not operate. IMO, it is the responsibility of an engineer changing an interface to change the system code using the interface as well. I wouldn't expect a change in the proc structure to get in without a corresponding change in "ps". I didn't complain about libraries because I was unaware that this would cause a library change, rather than an alloable parameter change to some system calls (I assumed the interface was parametric). Now I need to complain about the interface not being parametric. I think the stubs should go in and the version bump can wait for the parameterization, which should make the library not care about the underlying transport code (this will also let someone stick it back in if they need it later without having to invoke arcane rituals on the library to make it work). 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 Mar 31 14:05:05 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA01907 for current-outgoing; Sun, 31 Mar 1996 14:05:05 -0800 (PST) Received: from sovcom.kiae.su (sovcom.kiae.su [144.206.136.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA01893 for ; Sun, 31 Mar 1996 14:05:00 -0800 (PST) Received: by sovcom.kiae.su id AA17423 (5.65.kiae-1 ); Mon, 1 Apr 1996 00:57:36 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Mon, 1 Apr 96 00:57:36 +0300 Received: (from ache@localhost) by astral.msk.su (8.7.5/8.7.3) id BAA01325; Mon, 1 Apr 1996 01:55:18 +0400 (MSD) Message-Id: <199603312155.BAA01325@astral.msk.su> Subject: Re: cvs commit: src/usr.sbin/tzsetup Makefile main.c tzmenu.c To: joerg_wunsch@uriah.heep.sax.de Date: Mon, 1 Apr 1996 01:55:18 -4400 (MSD) Cc: freebsd-current@FreeBSD.ORG In-Reply-To: <199603312031.WAA00808@uriah.heep.sax.de> from "J Wunsch" at "Mar 31, 96 10:31:00 pm" From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast X-Mailer: ELM [version 2.4ME+ PL14 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > (Moved to -current, where this better fits.) > > As Jordan K. Hubbard wrote: > > > I think this is reasonable. If I'm running single-user with nothing > > but root mounted, I *expect* some things not to work quite right. I > > can't run vi very nicely without my /var mounted either, for that > > matter, and I usually find this far more objectionable than the > > timezone being set wrong. > > Funny you should mention this -- vi needs /usr/share/misc/termcap as > well. :-)) I hope we won't install termcap directly into /etc now... If you can't start vi due to missing termcap, it isn't dangerous at all. But when your /etc/localtime is missing or clobbered by NFS, it really dangerous because even BIOS clock can be changed to wrong value! -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-current Sun Mar 31 14:46:35 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA05157 for current-outgoing; Sun, 31 Mar 1996 14:46:35 -0800 (PST) Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id OAA05146 for ; Sun, 31 Mar 1996 14:46:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by Root.COM (8.7.5/8.6.5) with SMTP id OAA07341; Sun, 31 Mar 1996 14:46:44 -0800 (PST) Message-Id: <199603312246.OAA07341@Root.COM> X-Authentication-Warning: implode.Root.COM: Host localhost [127.0.0.1] didn't use HELO protocol To: Terry Lambert cc: joerg_wunsch@uriah.heep.sax.de, freebsd-current@freebsd.org Subject: Re: We need to do another XFree86 release for -current someday soon.. In-reply-to: Your message of "Sun, 31 Mar 1996 14:52:58 MST." <199603312152.OAA12006@phaeton.artisoft.com> From: David Greenman Reply-To: davidg@Root.COM Date: Sun, 31 Mar 1996 14:46:44 -0800 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> > : Please, that isn't good enough to justify the cost. Stub them to >> > : return errors. >> > >> > i would vote for this too >> >> Funny, nobody complained back when Garrett did announce his intention. > >I did, on principle that you should never delete code, and that the >code was not intrinsically broken ...it was just an incomplete job of >changing some related code that is causing it to not operate. IMO, it >is the responsibility of an engineer changing an interface to change >the system code using the interface as well. I wouldn't expect a >change in the proc structure to get in without a corresponding change >in "ps". In general this is true. In this case, however, we made a conscious and deliberate decision to stop supporting the code. This coupled with the consensus that broken and unsupported code should be removed rather than fester in the source tree is what led to its removal. The "2.2" release is a long way off and we'll likely have other reasons for bumping the library major number before the release happens. If people want to run code that is 6-9 months away from release, then they should be prepared to deal with a few "bumps" along the way. This has always been our stated policy about -current, so nothing 'new' here. I fully support the removal of code from libc as well as the major number bump. We have a policy of providing backward compatibility via our "compat" distributions and we'll continue to support older binaries with this mechanism. Future XFree86 releases should be built against RELEASE versions of FreeBSD. I believe this has always been their policy, so nothing 'new' here, either. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-current Sun Mar 31 14:50:14 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA05318 for current-outgoing; Sun, 31 Mar 1996 14:50:14 -0800 (PST) Received: from sovcom.kiae.su (sovcom.kiae.su [144.206.136.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA05308 for ; Sun, 31 Mar 1996 14:50:06 -0800 (PST) Received: by sovcom.kiae.su id AA25035 (5.65.kiae-1 ); Mon, 1 Apr 1996 01:46:06 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Mon, 1 Apr 96 01:46:05 +0300 Received: (from ache@localhost) by astral.msk.su (8.7.5/8.7.3) id CAA01491; Mon, 1 Apr 1996 02:33:26 +0400 (MSD) Message-Id: <199603312233.CAA01491@astral.msk.su> Subject: Re: random .. not so .. To: bde@zeta.org.au (Bruce Evans) Date: Mon, 1 Apr 1996 02:33:25 -4400 (MSD) Cc: bde@zeta.org.au, current@FreeBSD.org, davidg@Root.COM, imb@scgt.oz.au In-Reply-To: <199603310320.NAA08023@godzilla.zeta.org.au> from "Bruce Evans" at "Mar 31, 96 01:20:26 pm" From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast X-Mailer: ELM [version 2.4ME+ PL14 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > >Calling srandom(time() f.e.) is common case. Without this fix two > >programs calling srandom in _different_ times produces very predictable > >almost same sequences. > > This must be a poor way to initialize random(). First, time() isn't > random. Second, srandom() isn't claimed to give a state that varies > randomly with its arg. In fact, it doesn't. Seed isn't supposed to be random at all, it must be just DIFFERENT. Seeding can be treated as some sort of one way function (like MD5) where different initial number produces different random sequence. BTW, proposed formula doesn't do any harm even from different points of view on seed nature. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-current Sun Mar 31 14:50:59 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA05367 for current-outgoing; Sun, 31 Mar 1996 14:50:59 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA05345 for ; Sun, 31 Mar 1996 14:50:43 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id AAA20536 for ; Mon, 1 Apr 1996 00:50:40 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id AAA28820 for freebsd-current@FreeBSD.org; Mon, 1 Apr 1996 00:50:40 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id AAA01657 for freebsd-current@FreeBSD.org; Mon, 1 Apr 1996 00:44:42 +0200 (MET DST) From: J Wunsch Message-Id: <199603312244.AAA01657@uriah.heep.sax.de> Subject: Re: Fixit Floppy Broken? To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Mon, 1 Apr 1996 00:44:42 -4600 (MET DST) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199603312133.OAA11938@phaeton.artisoft.com> from "Terry Lambert" at Mar 31, 96 02:33:59 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Terry Lambert wrote: > > If you're willing to rewrite it, and submitting PRs would accelerate > > this process, i could immediately submit half a dozen PRs for it. :-) > > You should submit them even if there is no victim^H^H^H^H^Holunteer > at the present time. All bugs should be recorded somewhere. Ah, yeah, well, what should i write there? Bugs: The fdc(4) driver is one single large bug. Fix: Rewrite. :-) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sun Mar 31 14:51:03 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA05379 for current-outgoing; Sun, 31 Mar 1996 14:51:03 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA05349 for ; Sun, 31 Mar 1996 14:50:47 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id AAA20532 for ; Mon, 1 Apr 1996 00:50:39 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id AAA28815 for freebsd-current@FreeBSD.org; Mon, 1 Apr 1996 00:50:38 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id AAA01620 for freebsd-current@FreeBSD.org; Mon, 1 Apr 1996 00:41:51 +0200 (MET DST) From: J Wunsch Message-Id: <199603312241.AAA01620@uriah.heep.sax.de> Subject: Re: cvs commit: src/usr.sbin/tzsetup Makefile main.c tzmenu.c To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Mon, 1 Apr 1996 00:41:51 -4600 (MET DST) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199603312137.BAA00975@astral.msk.su> from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Apr 1, 96 01:37:47 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= wrote: > > Would the following be agreeable? > > > > if (is_symlink("/etc/localtime")) { > > unlink("/etc/localtime"); > > symlink(zoneinfo, "/etc/localtime"); > > } else { > > copy(zoneinfo, "/etc/localtime"); > > } > Why not simple? > > unlink("/etc/localtime"); > copy(zoneinfo, "/etc/localtime"); Since there are people like me who find: j@uriah 54% ls -l /etc/localtime lrwxr-xr-x 1 root wheel 23 Mar 28 22:26 /etc/localtime@ -> /usr/share/zoneinfo/MET more informative, and don't wanna have it broken by the next run of tzsetup(8). > Basically, having symlink outside /etc is bad idea. > Especially pointing to probably mounted /usr: your system date > can be very damaged when remote NFS hangs on /usr/share f.e. Like /usr/sbin/rmt, or /usr/share/misc/terminfo, you mean? :-) (Funny, these are the only symlinks that are normally be found in /etc, and they all point to /usr.) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sun Mar 31 17:13:39 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA15656 for current-outgoing; Sun, 31 Mar 1996 17:13:39 -0800 (PST) Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id RAA15650 for ; Sun, 31 Mar 1996 17:13:35 -0800 (PST) Received: by sequent.kiae.su id AA09907 (5.65.kiae-2 ); Mon, 1 Apr 1996 04:05:11 +0300 Received: by sequent.KIAE.su (UUMAIL/2.0); Mon, 1 Apr 96 04:05:10 +0300 Received: (from ache@localhost) by astral.msk.su (8.7.5/8.7.3) id EAA01805; Mon, 1 Apr 1996 04:45:38 +0400 (MSD) Message-Id: <199604010045.EAA01805@astral.msk.su> Subject: Re: cvs commit: src/usr.sbin/tzsetup Makefile main.c tzmenu.c To: joerg_wunsch@uriah.heep.sax.de Date: Mon, 1 Apr 1996 04:45:37 +0400 (MSD) Cc: freebsd-current@FreeBSD.ORG In-Reply-To: <199603312241.AAA01620@uriah.heep.sax.de> from "J Wunsch" at "Apr 1, 96 00:41:51 am" From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast X-Mailer: ELM [version 2.4ME+ PL14 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Basically, having symlink outside /etc is bad idea. > > Especially pointing to probably mounted /usr: your system date > > can be very damaged when remote NFS hangs on /usr/share f.e. > > Like /usr/sbin/rmt, or /usr/share/misc/terminfo, you mean? :-) Missing or corrupting or hanging on (via NFS) any of those files not critical, but missing/corrupting/hanging on /etc/localtime is very critical, because even RTC clock can be corrupted. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-current Sun Mar 31 18:28:55 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA20263 for current-outgoing; Sun, 31 Mar 1996 18:28:55 -0800 (PST) Received: from ki.net (root@ki.net [205.150.102.1]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id SAA20258 for ; Sun, 31 Mar 1996 18:28:53 -0800 (PST) Received: from localhost (scrappy@localhost) by ki.net (8.7.4/8.7.4) with SMTP id VAA05665 for ; Sun, 31 Mar 1996 21:28:53 -0500 (EST) Date: Sun, 31 Mar 1996 21:28:52 -0500 (EST) From: "Marc G. Fournier" To: current@freebsd.org Subject: Alot of signal 11 faults in new -current Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi... I'm having a major time trying to get the newest -current compiled and installed. Based on sources sup'd in this afternoon, and kernel installed this evening. I saw some changes go through in the vm system, and am wondering if something got changed in there that might affect this? I'm running a 16Meg machine with 51Meg of swap space, so little chance I'm running out of Virtual Memory...and nobody but me is using that machine. Thanks.. Marc G. Fournier | POP Mail Telnet Acct DNS Hosting System | WWW Services Database Services | Knowledge, Administrator | | Information and scrappy@ki.net | WWW: http://www.ki.net | Communications, Inc From owner-freebsd-current Sun Mar 31 19:12:18 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id TAA22138 for current-outgoing; Sun, 31 Mar 1996 19:12:18 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id TAA22116 for ; Sun, 31 Mar 1996 19:12:13 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id NAA27627; Mon, 1 Apr 1996 13:09:54 +1000 Date: Mon, 1 Apr 1996 13:09:54 +1000 From: Bruce Evans Message-Id: <199604010309.NAA27627@godzilla.zeta.org.au> To: bde@zeta.org.au, terry@lambert.org Subject: Re: FreeBSD performance vs BSD/OS Cc: andreas@knobel.gun.de, current@FreeBSD.org, j@uriah.heep.sax.de Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >> There are many different real and virtual (timekeeping) clocks with >> different frequencies: >[ ... Bruce's exhaustive clock list ... ] It wasn't exhaustive :-). I didn't attempt to cover clocks that aren't currently used for timekeeping. E.g., video clocks, UART clocks, ... Bruce From owner-freebsd-current Sun Mar 31 19:43:28 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id TAA23880 for current-outgoing; Sun, 31 Mar 1996 19:43:28 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id TAA23867 for ; Sun, 31 Mar 1996 19:43:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by rover.village.org (8.6.11/8.6.6) with SMTP id UAA11579 for ; Sun, 31 Mar 1996 20:42:55 -0700 Message-Id: <199604010342.UAA11579@rover.village.org> To: current@freebsd.org Subject: Re: We need to do another XFree86 release for -current someday soon.. In-reply-to: Your message of Sun, 31 Mar 1996 14:52:58 MST Date: Sun, 31 Mar 1996 20:42:55 -0700 From: Warner Losh Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk : I didn't complain about libraries because I was unaware that this would : cause a library change, rather than an alloable parameter change to : some system calls (I assumed the interface was parametric). I also didn't complain because quite frankly there was too much flamage over the topic and I missed the "we gotta bump libc.so to 3.0" part of the discussions at the time. I don't like flamage, so I tend to stop reading those threads, or similar sounding ones. It was also stated that no one is using this code, so that no one will be impacted by its removal. However, now everyone either has to keep multiple copies of libc around the disk and memory of their machines, or recompile everything. That hardly sounds like "nobody" to me. Saying we're a month too late, especially when the original discussion took place the way it did is somewhat unfortunate. While I understand that it has been a while, at least listen to the people that want just stubs and engage them in a reasonable debate. Any change can be backed out, or a new change written so that we don't need to bump the major rev. If there are *OTHER* reasons or plans that will require a major rev bump, please let communicate that fact. If that is indeed the plans, then there is no reason to continue this debate, since we gotta do it. Sorry if I'm sounding a little hot under the collar, but it really upsets me when reasonable things are requested, and unreasonable answers come back sounding like "Oh, you should have said something during the Terry vs the world flame fest. It is too late now. You lose. Stop bothing us and get lost." Warner From owner-freebsd-current Sun Mar 31 20:01:17 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id UAA25197 for current-outgoing; Sun, 31 Mar 1996 20:01:17 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id UAA25180 for ; Sun, 31 Mar 1996 20:01:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by rover.village.org (8.6.11/8.6.6) with SMTP id VAA11807 for ; Sun, 31 Mar 1996 21:00:44 -0700 Message-Id: <199604010400.VAA11807@rover.village.org> To: current@FreeBSD.org Subject: Re: We need to do another XFree86 release for -current someday soon.. In-reply-to: Your message of Sun, 31 Mar 1996 20:42:55 MST Date: Sun, 31 Mar 1996 21:00:44 -0700 From: Warner Losh Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk : Sorry if I'm sounding a little hot under the collar, but it really : upsets me when reasonable things are requested, and unreasonable : answers come back sounding like :... Ick! I've got to learn to read the entire queue before replying... Given the 6-9 month release target and what sound like plans for other interface changes, my childish outburst was uncalled for. Please pretend that I didn't send it :-(. Warner From owner-freebsd-current Sun Mar 31 21:44:25 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA01383 for current-outgoing; Sun, 31 Mar 1996 21:44:25 -0800 (PST) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id VAA01378 for ; Sun, 31 Mar 1996 21:44:23 -0800 (PST) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15959(12)>; Sun, 31 Mar 1996 21:43:46 PST Received: by crevenia.parc.xerox.com id <177475>; Sun, 31 Mar 1996 21:43:36 -0800 From: Bill Fenner To: current@freebsd.org Subject: Another "does LINT compile?" question Message-Id: <96Mar31.214336pst.177475@crevenia.parc.xerox.com> Date: Sun, 31 Mar 1996 21:43:29 PST Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk The "make" released with 2.1 doesn't appear to ever do much with the "$<" makefile variable when the target doesn't have a suffix; if I do foo: foo.c echo $< I get % make echo % The only difference in "make" from 2.1 to -current is revision 1.5 date: 1995/11/01 12:18:32; author: adam; state: Exp; lines: +6 -16 Fix the :S modifier to substitute in each word of the variable, according to the description in the manpage. g flag means "replace every occurence in each word", and its absence means "replace first occurence in each word". Previously, absence of the g flag was implemented to mean "replace first occurence found in all words, and then stop replacing", which was incorrect. which I don't think applies to $<. /sys/compile/LINT/Makefile ends up using $< when building linux_genassym: linux_genassym: $S/i386/linux/linux_genassym.c $S/i386/linux/linux.h ${CC} ${CFLAGS} -o $@ $< which confuses cc mightily since it replaces the $< with an empty string. Am I doing something wrong, or is this wrong? (I didn't complain when I first noticed it last week since I assumed I was doing something wrong or someone else would notice it). I have a shell script that tries to build LINT nightly and sends me email if it fails. Perhaps this output should go to the mailing list? (I will have a hard time keeping my vow to always build LINT before committing anything if LINT is always broken). Bill From owner-freebsd-current Sun Mar 31 23:21:27 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA05068 for current-outgoing; Sun, 31 Mar 1996 23:21:27 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA05062 for ; Sun, 31 Mar 1996 23:21:20 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id JAA02549 for ; Mon, 1 Apr 1996 09:20:46 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id JAA04546 for freebsd-current@FreeBSD.org; Mon, 1 Apr 1996 09:20:45 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id JAA04183 for freebsd-current@FreeBSD.org; Mon, 1 Apr 1996 09:16:48 +0200 (MET DST) From: J Wunsch Message-Id: <199604010716.JAA04183@uriah.heep.sax.de> Subject: Re: cvs commit: src/usr.sbin/tzsetup Makefile main.c tzmenu.c To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Mon, 1 Apr 1996 09:16:48 +0200 (MET DST) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199604010045.IAA23853@jhome.DIALix.COM> from "Peter Wemm" at Apr 1, 96 08:45:47 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Peter Wemm wrote: > The only thing I'd suggest for Joerg's method would be to > unlink("/etc/localtime") even for the copy case, in case it's a hard link > somewhere. Ok. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sun Mar 31 23:22:06 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA05108 for current-outgoing; Sun, 31 Mar 1996 23:22:06 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA05099 for ; Sun, 31 Mar 1996 23:21:56 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id JAA02601 for ; Mon, 1 Apr 1996 09:21:49 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id JAA04569 for freebsd-current@FreeBSD.org; Mon, 1 Apr 1996 09:21:48 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id JAA04226 for freebsd-current@FreeBSD.org; Mon, 1 Apr 1996 09:20:41 +0200 (MET DST) From: J Wunsch Message-Id: <199604010720.JAA04226@uriah.heep.sax.de> Subject: Re: adjkerntz (was: cvs commit: src/usr.sbin/tzsetup ...) To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Mon, 1 Apr 1996 09:20:40 +0200 (MET DST) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199604010045.EAA01805@astral.msk.su> from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Apr 1, 96 04:45:37 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= wrote: > > Like /usr/sbin/rmt, or /usr/share/misc/terminfo, you mean? :-) > Missing or corrupting or hanging on (via NFS) any of those files not > critical, but missing/corrupting/hanging on /etc/localtime is very > critical, because even RTC clock can be corrupted. Huh? Perhaps only when adjkerntz is running? It is never running on ``serious'' machines. ;-) Btw., there have been many problem reports about bogus adjkerntz activities here in Germany yesterday. (We had a DST switchover.) I can't tell you what exactly it has been (i don't use it myself, all my CMOS clocks run UTC), but the pattern seems to be consistent among the German users. Ah, minute... that's from the de-freebsd lists: Mar 31 04:01:00 zit1 adjkerntz[23396]: Nonexistent local time -- will retry afte r 1800 secs Mar 31 04:31:00 zit1 adjkerntz[23396]: Nonexistent local time -- will retry afte r 1800 secs Mar 31 04:31:00 zit1 adjkerntz[23454]: Nonexistent local time -- will retry afte r 1800 secs Mar 31 05:01:00 zit1 adjkerntz[23396]: Nonexistent (final) local time -- will re try after 1800 secs Mar 31 05:01:00 zit1 adjkerntz[23454]: Nonexistent (final) local time -- will re try after 1800 secs Mar 31 05:31:00 zit1 adjkerntz[23396]: Nonexistent (final) local time -- will re try after 1800 secs Mar 31 05:31:00 zit1 adjkerntz[23454]: Nonexistent (final) local time -- will re try after 1800 secs -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sun Mar 31 23:53:04 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA06613 for current-outgoing; Sun, 31 Mar 1996 23:53:04 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA06606 for ; Sun, 31 Mar 1996 23:53:02 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id XAA00258 for ; Sun, 31 Mar 1996 23:52:57 -0800 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id JAA05089 for ; Mon, 1 Apr 1996 09:50:43 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id JAA04746 for freebsd-current@FreeBSD.org; Mon, 1 Apr 1996 09:50:43 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id JAA04377 for freebsd-current@FreeBSD.org; Mon, 1 Apr 1996 09:28:07 +0200 (MET DST) From: J Wunsch Message-Id: <199604010728.JAA04377@uriah.heep.sax.de> Subject: Re: cvs commit: src/usr.sbin/tzsetup Makefile main.c tzmenu.c To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Mon, 1 Apr 1996 09:28:06 +0200 (MET DST) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199604010323.NAA28337@godzilla.zeta.org.au> from "Bruce Evans" at Apr 1, 96 01:23:45 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Bruce Evans wrote: > Why not simpler: > > system("install -C -o $binown -g $bingroup -m $filemode" > "$zoneinfo /etc/localtime") > > ? :-). I've already thought about using `cp', but your method is superior. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sun Mar 31 23:54:08 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA06685 for current-outgoing; Sun, 31 Mar 1996 23:54:08 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA06665 for ; Sun, 31 Mar 1996 23:53:56 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id JAA05097 for ; Mon, 1 Apr 1996 09:50:47 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id JAA04751 for freebsd-current@FreeBSD.org; Mon, 1 Apr 1996 09:50:47 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id JAA04564 for freebsd-current@FreeBSD.org; Mon, 1 Apr 1996 09:50:05 +0200 (MET DST) From: J Wunsch Message-Id: <199604010750.JAA04564@uriah.heep.sax.de> Subject: Re: cvs commit: src/usr.sbin/tzsetup Makefile main.c tzmenu.c To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Mon, 1 Apr 1996 09:50:05 +0200 (MET DST) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199604010045.EAA01805@astral.msk.su> from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Apr 1, 96 04:45:37 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= wrote: > Missing or corrupting or hanging on (via NFS) any of those files not > critical, but missing/corrupting/hanging on /etc/localtime is very > critical, because even RTC clock can be corrupted. It just occured me (while modifying tzsetup again) that your argumentation has one weak point: you are already screwed in your case, since /etc/localtime covers only the very special case of a missing `TZ' environmental variable. :-P -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Mon Apr 1 00:16:24 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA08092 for current-outgoing; Mon, 1 Apr 1996 00:16:24 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id AAA08071 for ; Mon, 1 Apr 1996 00:16:16 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id KAA06105 for ; Mon, 1 Apr 1996 10:16:12 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id KAA04983 for freebsd-current@FreeBSD.org; Mon, 1 Apr 1996 10:16:12 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id KAA04787 for freebsd-current@FreeBSD.org; Mon, 1 Apr 1996 10:00:40 +0200 (MET DST) From: J Wunsch Message-Id: <199604010800.KAA04787@uriah.heep.sax.de> Subject: Re: FreeBSD performance vs BSD/OS To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Mon, 1 Apr 1996 10:00:40 +0200 (MET DST) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199603312138.OAA11972@phaeton.artisoft.com> from "Terry Lambert" at Mar 31, 96 02:38:56 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Terry Lambert wrote: > THANK YOU. > > This should go into some documentation somewhere. Maybe clock(8)? timer(9)? (I've sent a draft of timer.9 to Bruce for review.) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Mon Apr 1 00:27:25 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA08657 for current-outgoing; Mon, 1 Apr 1996 00:27:25 -0800 (PST) Received: from gw.pinewood.nl (gw.pinewood.nl [192.31.139.9]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id AAA08649 for ; Mon, 1 Apr 1996 00:27:22 -0800 (PST) Received: (from smap@localhost) by gw.pinewood.nl (8.6.12/8.6.12) id KAA18459 for ; Mon, 1 Apr 1996 10:27:14 +0200 Received: from pwood1.pinewood.nl(192.168.1.10) by gw.pinewood.nl via smap (V1.3) id sma018347; Mon Apr 1 10:26:20 1996 Received: (from franky@localhost) by pwood1.pinewood.nl (8.7.3/8.6.12) id JAA20724; Mon, 1 Apr 1996 09:26:19 +0100 (MET) From: "Frank ten Wolde" Message-Id: <9604010926.ZM20722@pwood1.pinewood.nl> Date: Mon, 1 Apr 1996 09:26:18 +0100 X-Face: 'BsFf8'k.q?J#?|$D*,)/?sRB{woUK&9\5K{ERmT;VTSyNLBb?muLf>b:Pt&VTDw8YCaC]6 C!MRSMr5UNjZLa]fi? X-Mailer: Z-Mail (3.2.1 10oct95) To: current@FreeBSD.ORG Subject: src/sbin/ipfw/ipfw.c broken (2.2-960323-SNAPSHOT, fix supplied) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hello, I think I have found some small bugs in /usr/src/sbin/ipfw/ipfw.c (2.2-960323-SNAPSHOT): 1. Adding a port-range causes a SEGV: ipfw add accept all from any 1024-2048 to any Problem is at line 366 where (*av == NULL). 2. Listing a DST port-range when a SRC port range is in effect causes the DST port range to be listed with a ',' instead of a '-'. Problem is at line 178. 3. The usage is misleading: ... action: {allow|deny|reject|count}[,log] ... Should read: action: {allow|deny|reject|count} [log] (note the space and the removal of the ',') I'm not sure who maintains this code so I post it here expecting it to be picked up by the appropriate person(s). --- SNIP SNIP SNIP SNIP SNIP SNIP SNIP SNIP SNIP SNIP SNIP SNIP --- *** /usr/src/sbin/ipfw/ipfw.c.orig Sat Feb 24 14:39:46 1996 --- /usr/src/sbin/ipfw/ipfw.c Mon Apr 1 10:24:22 1996 *************** *** 175,181 **** comma = " "; for (i=0;ifw_ndp;i++) { printf("%s%d",comma,chain->fw_pts[chain->fw_nsp+i]); ! if (i==chain->fw_nsp && (chain->fw_flg & IP_FW_F_DRNG)) comma = "-"; else comma = ","; --- 175,181 ---- comma = " "; for (i=0;ifw_ndp;i++) { printf("%s%d",comma,chain->fw_pts[chain->fw_nsp+i]); ! if (i==0 && (chain->fw_flg & IP_FW_F_DRNG)) comma = "-"; else comma = ","; *************** *** 281,287 **** "\t\tlist [number]\n" "\t\tzero [number]\n" "\trule:\taction proto src dst extras...\n" ! "\t\taction: {allow|deny|reject|count}[,log]\n" "\t\tproto: {ip|tcp|udp|icmp}}\n" "\t\tsrc: {any|ip[{/bits|:mask}]} [{port|port-port},...]\n" "\t\tdst: {any|ip[{/bits|:mask}]} [{port|port-port},...]\n" --- 281,287 ---- "\t\tlist [number]\n" "\t\tzero [number]\n" "\trule:\taction proto src dst extras...\n" ! "\t\taction: {allow|deny|reject|count} [log]\n" "\t\tproto: {ip|tcp|udp|icmp}}\n" "\t\tsrc: {any|ip[{/bits|:mask}]} [{port|port-port},...]\n" "\t\tdst: {any|ip[{/bits|:mask}]} [{port|port-port},...]\n" *************** *** 362,368 **** sc = 0; i = 1; } ! while (1) { s = strchr(*av,','); if (s) { sc = *s; --- 362,368 ---- sc = 0; i = 1; } ! while (*av != NULL) { s = strchr(*av,','); if (s) { sc = *s; --- SNIP SNIP SNIP SNIP SNIP SNIP SNIP SNIP SNIP SNIP SNIP SNIP --- -Frank -- ---------------------------------------------------------------------- F.W. ten Wolde (PA3FMT) Pinewood Automation B.V. E-mail: franky@pinewood.nl Kluyverweg 2a Phone: +31-15 2682543 2629 HT Delft From owner-freebsd-current Mon Apr 1 01:11:05 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA10538 for current-outgoing; Mon, 1 Apr 1996 01:11:05 -0800 (PST) Received: from Campino.Informatik.RWTH-Aachen.DE (campino.Informatik.RWTH-Aachen.DE [137.226.225.2]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id BAA10522 for ; Mon, 1 Apr 1996 01:10:16 -0800 (PST) Received: from gilberto.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.31.2]) by Campino.Informatik.RWTH-Aachen.DE (RBI-Z-5/8.6.12) with ESMTP id LAA04331 for ; Mon, 1 Apr 1996 11:05:23 +0200 Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.6.11/8.6.9) id LAA03996 for freebsd-current@freefall.cdrom.com; Mon, 1 Apr 1996 11:13:21 +0200 Date: Mon, 1 Apr 1996 11:13:21 +0200 From: "Christoph P. Kukulies" Message-Id: <199604010913.LAA03996@gilberto.physik.rwth-aachen.de> To: freebsd-current@freefall.FreeBSD.org Subject: calcru: negative time: Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Below is a dmesg of today - this is not a 1st April joke :-) ,MCE,CX8> real memory = 33554432 (32768K bytes) avail memory = 30728192 (30008K bytes) Probing for devices on PCI bus 0: chip0 rev 2 on pci0:0 chip1 rev 2 on pci0:7 piix0 rev 2 on pci0:7 vga0 rev 0 int a irq 11 on pci0:11 Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> ed0 at 0x300-0x31f irq 10 on isa ed0: address 00:40:95:50:5d:6e, type NE2000 (16 bit) 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 fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 72065B fd0: 1.44MB 3.5in wdc0 at 0x1f0-0x1f7 irq 14 on isa wdc0: unit 0 (wd0): wd0: 1548MB (3171168 sectors), 3146 cyls, 16 heads, 63 S/T, 512 B/S wdc0: unit 1 (wd1): wd1: 1548MB (3171168 sectors), 3146 cyls, 16 heads, 63 S/T, 512 B/S npx0 on motherboard npx0: INT 16 interface wd1: raw partition size != slice size wd1: start 0, end 3171166, size 3171167 wd1c: start 0, end 3171167, size 3171168 wd1: truncating raw partition wd1: rejecting partition in BSD label: it isn't entirely within the slice wd1: start 0, end 3171166, size 3171167 wd1e: start 0, end 3171167, size 3171168 wd1: raw partition size != slice size wd1: start 0, end 3171166, size 3171167 wd1c: start 0, end 3171167, size 3171168 wd1: truncating raw partition wd1: rejecting partition in BSD label: it isn't entirely within the slice wd1: start 0, end 3171166, size 3171167 wd1e: start 0, end 3171167, size 3171168 ed0: device timeout syncing disks... 9 9 5 done FreeBSD 2.2-CURRENT #0: Fri Mar 29 16:50:03 1996 kuku@toots.physik.rwth-aachen.de:/usr/src/sys/compile/TOOTS CPU: Pentium (149.67-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x52c Stepping=12 Features=0x1bf real memory = 33554432 (32768K bytes) avail memory = 30728192 (30008K bytes) Probing for devices on PCI bus 0: chip0 rev 2 on pci0:0 chip1 rev 2 on pci0:7 piix0 rev 2 on pci0:7 vga0 rev 0 int a irq 11 on pci0:11 Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> ed0 at 0x300-0x31f irq 10 on isa ed0: address 00:40:95:50:5d:6e, type NE2000 (16 bit) 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 [deleted] npx0 on motherboard npx0: INT 16 interface [deleted] calcru: negative time: -11929 usec calcru: negative time: -3909 usec calcru: negative time: -3842 usec calcru: negative time: -17709 usec calcru: negative time: -3480 usec --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-current Mon Apr 1 01:21:05 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA11061 for current-outgoing; Mon, 1 Apr 1996 01:21:05 -0800 (PST) Received: from gw.pinewood.nl (gw.pinewood.nl [192.31.139.9]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id BAA11054 for ; Mon, 1 Apr 1996 01:20:56 -0800 (PST) Received: (from smap@localhost) by gw.pinewood.nl (8.6.12/8.6.12) id LAA19850 for ; Mon, 1 Apr 1996 11:20:13 +0200 Received: from pwood1.pinewood.nl(192.168.1.10) by gw.pinewood.nl via smap (V1.3) id sma019848; Mon Apr 1 11:20:07 1996 Received: (from franky@localhost) by pwood1.pinewood.nl (8.7.3/8.6.12) id KAA20911; Mon, 1 Apr 1996 10:20:06 +0100 (MET) From: "Frank ten Wolde" Message-Id: <9604011020.ZM20909@pwood1.pinewood.nl> Date: Mon, 1 Apr 1996 10:20:05 +0100 X-Face: 'BsFf8'k.q?J#?|$D*,)/?sRB{woUK&9\5K{ERmT;VTSyNLBb?muLf>b:Pt&VTDw8YCaC]6 C!MRSMr5UNjZLa]fi? X-Mailer: Z-Mail (3.2.1 10oct95) To: current@FreeBSD.ORG Subject: [Q] Semantics of 'established' in ipfw tcp Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hello, I would like to know other people's reactions to the current semantics of the 'established' keyword for TCP connections in the 2.2-960323-SNAPSHOT implementation of the ipfw in the kernel. Currently 'established' means (according to the manpage *and* some experimentation): established Matches packets that do not have the SYN bit set. TCP packets only. Should this not be: established Matches packets that do have the ACK bit set. TCP packets only. (To my knowledge this is the way conventional packet filters interpret 'established'.) Or put it in another way... Consider the TCP three way handshake: # packet direction TCP flags matched by rule ---------------------------------------------------------------- 1. client --> server: SYN 'setup' 2. server --> client: SYN+ACK NO RULE 3. client --> server: ACK 'established' other packets: ACK 'established' There is no way to specifically specify the second packet (with SYN *and* ACK on). For example, if I wanted to allow outgoing telnet sessions I need a rule: accept tcp from 1024-65535 to any 23 out accept tcp from any 23 to 1024-65535 in 'ACK-set' That is, I *do* allow incoming packets to ports >=1024, but I do *not* allow new TCP conenctions to these ports... (See also Building Internet Firewalls, page 240.) The problem is in the 'ACK-set' keyword, which is *not* available at this moment... Your opinions please... :-) -Frank P.S. The established and setup filtering is not yet implemented in ipfw... -- ---------------------------------------------------------------------- F.W. ten Wolde (PA3FMT) Pinewood Automation B.V. E-mail: franky@pinewood.nl Kluyverweg 2a Phone: +31-15 2682543 2629 HT Delft From owner-freebsd-current Mon Apr 1 02:27:35 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA15151 for current-outgoing; Mon, 1 Apr 1996 02:27:35 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id CAA15145 for ; Mon, 1 Apr 1996 02:27:31 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0u3gpd-0003vnC; Mon, 1 Apr 96 02:27 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id KAA15280; Mon, 1 Apr 1996 10:27:20 GMT X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: "Frank ten Wolde" cc: current@FreeBSD.ORG Subject: Re: [Q] Semantics of 'established' in ipfw tcp In-reply-to: Your message of "Mon, 01 Apr 1996 10:20:05 +0100." <9604011020.ZM20909@pwood1.pinewood.nl> Date: Mon, 01 Apr 1996 10:27:18 +0000 Message-ID: <15278.828354438@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I would like to know other people's reactions to the current semantics of > the 'established' keyword for TCP connections in the 2.2-960323-SNAPSHOT > implementation of the ipfw in the kernel. > The problem is in the 'ACK-set' keyword, which is *not* available at this > moment... Yes indeed it is available. You can specify any combination of flags you want. > Your opinions please... :-) I got side tracked by some real-world problems but I'm on my way back to the IPFW stuff. Please send any suggestions you have. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Mon Apr 1 02:33:11 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA15488 for current-outgoing; Mon, 1 Apr 1996 02:33:11 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id CAA15480 for ; Mon, 1 Apr 1996 02:33:05 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0u3gv1-0003vnC; Mon, 1 Apr 96 02:33 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id KAA15323; Mon, 1 Apr 1996 10:33:01 GMT X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: "Frank ten Wolde" cc: current@FreeBSD.ORG Subject: Re: src/sbin/ipfw/ipfw.c broken (2.2-960323-SNAPSHOT, fix supplied) In-reply-to: Your message of "Mon, 01 Apr 1996 09:26:18 +0100." <9604010926.ZM20722@pwood1.pinewood.nl> Date: Mon, 01 Apr 1996 10:33:00 +0000 Message-ID: <15321.828354780@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I'm not sure who maintains this code so I post it here expecting it > to be picked up by the appropriate person(s). Presently I do, please keep them patches comming! Poul-Henning -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Mon Apr 1 02:45:43 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA16107 for current-outgoing; Mon, 1 Apr 1996 02:45:43 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id CAA16102 for ; Mon, 1 Apr 1996 02:45:39 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id UAA14428; Mon, 1 Apr 1996 20:44:34 +1000 Date: Mon, 1 Apr 1996 20:44:34 +1000 From: Bruce Evans Message-Id: <199604011044.UAA14428@godzilla.zeta.org.au> To: current@freebsd.org, fenner@parc.xerox.com Subject: Re: Another "does LINT compile?" question Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >The "make" released with 2.1 doesn't appear to ever do much with the >"$<" makefile variable when the target doesn't have a suffix; if I do >foo: foo.c > echo $< >I get >% make >echo >% >The only difference in "make" from 2.1 to -current is >revision 1.5 >... The difference is actually in sys.mk. The 2.1 make works if the null suffix `.c:' rule in sys.mk is uncommented. There used to be bugs in make that stopped this rule from working. However, these bugs were fixed long before 2.1R. The rule is still commented out in -stable. Sigh. >/sys/compile/LINT/Makefile ends up using $< when building linux_genassym: >linux_genassym: $S/i386/linux/linux_genassym.c $S/i386/linux/linux.h > ${CC} ${CFLAGS} -o $@ $< This is a bug in the Makefile. In the original version of make, `$<' was only valid for targets generated by a suffix rule. Some versions of make, e.g., gnu make, generate a useful `$<' for explicit rules. Our make doesn't. E.g., the makefile bar: foo.c echo $< works "right" for gnu make but not for BSD make. The linux_genassym rule works right in -current because the null suffix rule is matched and is bogusly not completely overridden by the explict rule. The genassym rule works right even in 2.1 because it uses genassym.o and not $<. See the cvs log for revision 1.48 for why the intermediate file genassym.o is built. `$<' is also bogus for hundreds of other explicit rules in the kernel Makefile. E.g., in ${NORMAL_C} it works because the implicit .c.o rule is matched and is bogusly not completely overridden by the explicit rule. >I have a shell script that tries to build LINT nightly and sends me email >if it fails. Perhaps this output should go to the mailing list? Only once a week until all the warnings are fixed. Bruce From owner-freebsd-current Mon Apr 1 03:08:23 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA17909 for current-outgoing; Mon, 1 Apr 1996 03:08:23 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id DAA17900 for ; Mon, 1 Apr 1996 03:08:18 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id UAA14960; Mon, 1 Apr 1996 20:57:55 +1000 Date: Mon, 1 Apr 1996 20:57:55 +1000 From: Bruce Evans Message-Id: <199604011057.UAA14960@godzilla.zeta.org.au> To: freebsd-current@freebsd.org, j@uriah.heep.sax.de Subject: Re: FreeBSD performance vs BSD/OS Cc: bde@zeta.org.au Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> There are many different real and virtual (timekeeping) clocks with >> different frequencies: >Should this become time(9)? No, it has very little to do with time or the kernel. clocks(7) would be better, and half of it is i386-specific so it would need to be split up. I don't like section 9. It is hard to improve on the sources, and harder to keep up to date with the sources. Bruce From owner-freebsd-current Mon Apr 1 03:24:08 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA19019 for current-outgoing; Mon, 1 Apr 1996 03:24:08 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id DAA18953 for ; Mon, 1 Apr 1996 03:23:15 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id VAA15805; Mon, 1 Apr 1996 21:15:40 +1000 Date: Mon, 1 Apr 1996 21:15:40 +1000 From: Bruce Evans Message-Id: <199604011115.VAA15805@godzilla.zeta.org.au> To: freebsd-current@freefall.freebsd.org, kuku@gilberto.physik.rwth-aachen.de Subject: Re: calcru: negative time: Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >[deleted] >calcru: negative time: -11929 usec >calcru: negative time: -3909 usec >calcru: negative time: -3842 usec >calcru: negative time: -17709 usec >calcru: negative time: -3480 usec This is caused by hardclock() interrupt latency. The problem is especially noticable on i586's and i686's because any latency causes the clock to go backwards; on i386's and i486's, the latency must be > 1 clock tick (10000 usec) to cause problems. Normally the latency on i586's is > 0 but < 10 usec and isn't detectable. There must be bugs elsewhere to cause latencies of more than a few tens of usecs. Bruce From owner-freebsd-current Mon Apr 1 03:29:57 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA19317 for current-outgoing; Mon, 1 Apr 1996 03:29:57 -0800 (PST) Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id DAA19312 Mon, 1 Apr 1996 03:29:53 -0800 (PST) Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.7.5/8.6.9) id DAA13308; Mon, 1 Apr 1996 03:29:50 -0800 (PST) Date: Mon, 1 Apr 1996 03:29:50 -0800 (PST) Message-Id: <199604011129.DAA13308@silvia.HIP.Berkeley.EDU> To: ports@freebsd.org CC: current@freebsd.org Reply-to: ports@freebsd.org Subject: Ports README changes committed (Proposal 6) From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk (Note crosspost - discussion followups to "ports" only please.) I just committed changes necessary to generate ports' README.html files automatically. You will need the latest version of ports/Makefile ports/templates/* ports/pkg/* (well not really necessary) share/mk/bsd.port[.subdir].mk This will essentially add two targets, "readme" and "readmes" to port directories. "make readme" will create a README.html from the templates in the current directory; "make readmes" will also descend into the subdirectories. Thus, cd /usr/ports; make readmes (separated for your triple-clicking pleasure) will walk through the whole ports tree and generate a bunch of README.htmls linked together with hypertext links. For all this to look great, we will need pkg/COMMENT and pkg/DESCR for every subdirectory, as well as a (much) better /usr/ports/pkg/DESCR. I'll work on that later this week. But at least you'll have something to look on. I tried to make the individual ports' README.htmls as plaintext as possible, so I'd like to request the html-illiterate out there to take a look at them and see if they are readable enough. (Sadly, I don't qualify anymore, as I can sort of read through markup tags to see how it's gonna look like on the browser....) Eventually, I will commit all the README.htmls (if it's not there right after installation, it kinda defeats the purpose of being the guide to newbies, right?), but it will be a while until then, 'cause any change in the templates will cause 400+ files to be changed. So, for now, I'd like people to try it on their own system and give us feedback. Thanks!!! Satoshi and the quiet ports team From owner-freebsd-current Mon Apr 1 04:05:36 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA21052 for current-outgoing; Mon, 1 Apr 1996 04:05:36 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id EAA21047 for ; Mon, 1 Apr 1996 04:05:34 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0u3iMO-0003w1C; Mon, 1 Apr 96 04:05 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id MAA15518; Mon, 1 Apr 1996 12:05:18 GMT X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: Bruce Evans cc: freebsd-current@freefall.freebsd.org, kuku@gilberto.physik.rwth-aachen.de Subject: Re: calcru: negative time: In-reply-to: Your message of "Mon, 01 Apr 1996 21:15:40 +1000." <199604011115.VAA15805@godzilla.zeta.org.au> Date: Mon, 01 Apr 1996 12:05:18 +0000 Message-ID: <15516.828360318@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >[deleted] > >calcru: negative time: -11929 usec > >calcru: negative time: -3909 usec > >calcru: negative time: -3842 usec > >calcru: negative time: -17709 usec > >calcru: negative time: -3480 usec > > This is caused by hardclock() interrupt latency. The problem is > especially noticable on i586's and i686's because any latency causes the > clock to go backwards; on i386's and i486's, the latency must be > 1 > clock tick (10000 usec) to cause problems. Normally the latency on > i586's is > 0 but < 10 usec and isn't detectable. There must be bugs > elsewhere to cause latencies of more than a few tens of usecs. My i386 has really high numbers here. Could this be a spl; Mon, 1 Apr 1996 04:52:05 -0800 (PST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by skiddaw.elsevier.co.uk (8.6.13/8.6.12) with ESMTP id NAA21484 for ; Mon, 1 Apr 1996 13:49:54 +0100 Received: from tees by snowdon with SMTP (PP); Mon, 1 Apr 1996 13:43:57 +0100 Received: (from dpr@localhost) by tees (SMI-8.6/8.6.12) id NAA05446; Mon, 1 Apr 1996 13:50:13 +0100 From: Paul Richards Message-Id: <199604011250.NAA05446@tees> Subject: Re: cvs commit: src/usr.sbin/tzsetup Makefile main.c tzmenu.c To: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Date: Mon, 1 Apr 1996 13:50:12 +0100 (BST) Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-current@FreeBSD.ORG In-Reply-To: <199604010045.EAA01805@astral.msk.su> from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Apr 1, 96 04:45:37 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In reply to =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= who said > > > > Basically, having symlink outside /etc is bad idea. > > > Especially pointing to probably mounted /usr: your system date > > > can be very damaged when remote NFS hangs on /usr/share f.e. > > > > Like /usr/sbin/rmt, or /usr/share/misc/terminfo, you mean? :-) > > Missing or corrupting or hanging on (via NFS) any of those files not critical, > but missing/corrupting/hanging on /etc/localtime is very critical, > because even RTC clock can be corrupted. Umm, what would be causing all these problems? Surely if the localtime file is missing then everything should just think it's GMT. If you're in a single user situation with only root mounted I don't see why this would be such a major problem? -- Paul Richards. Originative Solutions Ltd. (Netcraft Ltd. contractor) Elsevier Science TIS online journal project. Email: p.richards@elsevier.co.uk Phone: 0370 462071 (Mobile), +44 (0)1865 843155 From owner-freebsd-current Mon Apr 1 06:47:51 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA28223 for current-outgoing; Mon, 1 Apr 1996 06:47:51 -0800 (PST) Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id GAA28211 for ; Mon, 1 Apr 1996 06:47:39 -0800 (PST) Received: by sequent.kiae.su id AA28960 (5.65.kiae-2 ); Mon, 1 Apr 1996 17:26:31 +0300 Received: by sequent.KIAE.su (UUMAIL/2.0); Mon, 1 Apr 96 17:26:28 +0300 Received: (from ache@localhost) by astral.msk.su (8.7.5/8.7.3) id SAA00420; Mon, 1 Apr 1996 18:18:50 +0400 (MSD) Message-Id: <199604011418.SAA00420@astral.msk.su> Subject: Re: cvs commit: src/usr.sbin/tzsetup Makefile main.c tzmenu.c To: p.richards@elsevier.co.uk (Paul Richards) Date: Mon, 1 Apr 1996 18:18:50 +0400 (MSD) Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-current@FreeBSD.ORG In-Reply-To: <199604011250.NAA05446@tees> from "Paul Richards" at "Apr 1, 96 01:50:12 pm" From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast X-Mailer: ELM [version 2.4ME+ PL14 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Umm, what would be causing all these problems? Surely if the localtime > file is missing then everything should just think it's GMT. If you're in a > single user situation with only root mounted I don't see why this would be > such a major problem? adjkerntz -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-current Mon Apr 1 06:54:06 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA28614 for current-outgoing; Mon, 1 Apr 1996 06:54:06 -0800 (PST) Received: from sovcom.kiae.su (sovcom.kiae.su [144.206.136.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id GAA28607 for ; Mon, 1 Apr 1996 06:53:57 -0800 (PST) Received: by sovcom.kiae.su id AA09596 (5.65.kiae-1 ); Mon, 1 Apr 1996 17:48:41 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Mon, 1 Apr 96 17:48:41 +0300 Received: (from ache@localhost) by astral.msk.su (8.7.5/8.7.3) id SAA00682; Mon, 1 Apr 1996 18:37:55 +0400 (MSD) Message-Id: <199604011437.SAA00682@astral.msk.su> Subject: Re: adjkerntz (was: cvs commit: src/usr.sbin/tzsetup ...) To: joerg_wunsch@uriah.heep.sax.de Date: Mon, 1 Apr 1996 18:37:55 +0400 (MSD) Cc: freebsd-current@FreeBSD.org In-Reply-To: <199604010720.JAA04226@uriah.heep.sax.de> from "J Wunsch" at "Apr 1, 96 09:20:40 am" From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast X-Mailer: ELM [version 2.4ME+ PL14 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Perhaps only when adjkerntz is running? It is never running on > ``serious'' machines. ;-) I always run it on all my machines without any problem. > Btw., there have been many problem reports about bogus adjkerntz > activities here in Germany yesterday. (We had a DST switchover.) I It very depends on adjkerntz version. Old versions have a bugs. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-current Mon Apr 1 07:11:50 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA29204 for current-outgoing; Mon, 1 Apr 1996 07:11:50 -0800 (PST) Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA29199 for ; Mon, 1 Apr 1996 07:11:46 -0800 (PST) Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA29614; Mon, 1 Apr 1996 10:11:32 -0500 Date: Mon, 1 Apr 1996 10:11:32 -0500 From: Garrett Wollman Message-Id: <9604011511.AA29614@halloran-eldar.lcs.mit.edu> To: Terry Lambert Cc: freebsd-current@freebsd.org Subject: Re: We need to do another XFree86 release for -current someday soon.. In-Reply-To: <199603312152.OAA12006@phaeton.artisoft.com> References: <199603302314.AAA05356@uriah.heep.sax.de> <199603312152.OAA12006@phaeton.artisoft.com> Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk < said: > I think the stubs should go in and the version bump can wait for the > parameterization, It's TOO BLOODY LATE! Shared library version numbers are an INCREASING function with respect to time. > which should make the library not care about the > underlying transport code The library doesn't give a damn about the underlying transport code (as would have been obvious to you if you actually used the code rather than wasting my time whining about its removal). The library routine iso_ntoa() requires header files defining the structure of a CLNP address and `struct sockaddr_iso'. Those header files no longer exist. Therefore, the code will no longer compile. Period. End of story. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-current Mon Apr 1 08:22:18 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA03037 for current-outgoing; Mon, 1 Apr 1996 08:22:18 -0800 (PST) Received: from ki.net (root@ki.net [205.150.102.1]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id IAA03030 for ; Mon, 1 Apr 1996 08:22:13 -0800 (PST) Received: from localhost (scrappy@localhost) by ki.net (8.7.4/8.7.4) with SMTP id LAA03137 for ; Mon, 1 Apr 1996 11:22:09 -0500 (EST) Date: Mon, 1 Apr 1996 11:22:00 -0500 (EST) From: "Marc G. Fournier" To: current@freebsd.org Subject: Advice/Recommendation needed Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi... I've been running -stable on my main machine for the past little while, but due to what I believe to be a hard drive problem, I'm replacing the root drive. What I'm wondering is, what is the reliability level of -SNAP currently? Should I stick with -stable on that machine? Or is -SNAP more stable then -stable? Main thing to consider is that I have a partner that is against FreeBSD (cause its free) and would like to get our main server as rock-solid as possible so that she can't use instability as an argument against me :( Marc G. Fournier | POP Mail Telnet Acct DNS Hosting System | WWW Services Database Services | Knowledge, Administrator | | Information and scrappy@ki.net | WWW: http://www.ki.net | Communications, Inc From owner-freebsd-current Mon Apr 1 08:39:51 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA04035 for current-outgoing; Mon, 1 Apr 1996 08:39:51 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id IAA04030 for ; Mon, 1 Apr 1996 08:39:47 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0u3mdc-0003voC; Mon, 1 Apr 96 08:39 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id OAA15822; Mon, 1 Apr 1996 14:41:24 GMT X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: "Frank ten Wolde" cc: current@FreeBSD.ORG Subject: Re: [Q] Semantics of 'established' in ipfw tcp In-reply-to: Your message of "Mon, 01 Apr 1996 10:20:05 +0100." <9604011020.ZM20909@pwood1.pinewood.nl> Date: Mon, 01 Apr 1996 14:41:23 +0000 Message-ID: <15820.828369683@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Now I have had more time to read your email, I have more comments: First of all, "setup" and "established" are just shortform for "tcpflags foo" for various values of "foo", so you can have it anyway you want, even if you disagree with the semantics of those two keywords. > Currently 'established' means (according to the manpage *and* some > experimentation): > > established Matches packets that do not have the SYN bit set. > TCP packets only. > > Should this not be: > > established Matches packets that do have the ACK bit set. > TCP packets only. I added the "establised" keyword as I remembered it to be used from memory, it is very possible I got it wrong. > Or put it in another way... Consider the TCP three way handshake: > > # packet direction TCP flags matched by rule > ---------------------------------------------------------------- > 1. client --> server: SYN 'setup' > 2. server --> client: SYN+ACK NO RULE > 3. client --> server: ACK 'established' > other packets: ACK 'established' My own prefered way is allow tcp something or other setup allow tcp somebody else setup deny tcp all setup allow tcp all In this context the "established" keyword isn't needed. > There is no way to specifically specify the second packet (with SYN *and* > ACK on). For example, if I wanted to allow outgoing telnet sessions I > need a rule: > [...] > The problem is in the 'ACK-set' keyword, which is *not* available at this > moment... Yes it is, you can use the "tcpflags foo" for that. > P.S. The established and setup filtering is not yet implemented in ipfw... What ??? Could you explain this to me ? -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Mon Apr 1 08:43:29 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA04442 for current-outgoing; Mon, 1 Apr 1996 08:43:29 -0800 (PST) Received: from vector.jhs.local (slip139-92-42-129.ut.nl.ibm.net [139.92.42.129]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id IAA04316 Mon, 1 Apr 1996 08:42:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by vector.jhs.local (8.7.3/8.6.9) with SMTP id LAA00499; Mon, 1 Apr 1996 11:09:26 +0200 (MET DST) Message-Id: <199604010909.LAA00499@vector.jhs.local> X-Authentication-Warning: vector.jhs.local: Host localhost [127.0.0.1] didn't use HELO protocol To: Chris Cappuccio cc: current@freebsd.org From: "Julian H. Stacey" Reply-To: "Julian H. Stacey" Organization: Vector Systems Ltd. Address: Holz Strasse 27d, 80469 Munich, Germany Phone: +49.89.268616 Fax: +49.89.2608126 (pending modem change) Web: http://www.freebsd.org/~jhs/ Mailer: EXMH version 1.6.5 95 12 11, PGP available In-reply-to: Your message of "Fri, 29 Mar 1996 13:43:50 EST." <199603291843.NAA02951@sefl.satelnet.org> Date: Mon, 01 Apr 1996 11:09:25 +0200 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, Reference: > From: Chris Cappuccio > Date: Fri, 29 Mar 1996 13:43:50 -0500 > Message-id: <199603291843.NAA02951@sefl.satelnet.org> > > strange..) I can't get he baud rate adn such set correctly > in printcap and once I do, how would I print from applications such as umm ne - tscape or > something.. (ghostscript PS-->PCL?) Here's a ~1 year old entry I used to use on my hp3p laser (before I changed from serial to parallel): # serial|hp3p.raw|Raw output device hp3p:\ # :lp=/dev/ttyb:br#19200:xc#0177777:ms=-parity,ixon,-opost: You can see the 19200 baud lurking in there, The FAQ has more examples I guess, Suggested Reading: man printcap, /usr/share/doc/FAQ/freebsd-faq.html Printer docs :-) Julian -- Julian H. Stacey jhs@freebsd.org http://www.freebsd.org/~jhs/ From owner-freebsd-current Mon Apr 1 08:44:03 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA05089 for current-outgoing; Mon, 1 Apr 1996 08:44:03 -0800 (PST) Received: from vector.jhs.local (slip139-92-42-129.ut.nl.ibm.net [139.92.42.129]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id IAA04640 Mon, 1 Apr 1996 08:43:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by vector.jhs.local (8.7.3/8.6.9) with SMTP id KAA00437; Mon, 1 Apr 1996 10:59:40 +0200 (MET DST) Message-Id: <199604010859.KAA00437@vector.jhs.local> X-Authentication-Warning: vector.jhs.local: Host localhost [127.0.0.1] didn't use HELO protocol To: "Christoph P. Kukulies" cc: freebsd-current@freefall.FreeBSD.org Subject: Re: spurious problems with a P150 system From: "Julian H. Stacey" Reply-To: "Julian H. Stacey" Organization: Vector Systems Ltd. Address: Holz Strasse 27d, 80469 Munich, Germany Phone: +49.89.268616 Fax: +49.89.2608126 (pending modem change) Web: http://www.freebsd.org/~jhs/ Mailer: EXMH version 1.6.5 95 12 11, PGP available In-reply-to: Your message of "Fri, 29 Mar 1996 18:08:01 +0100." <199603291708.SAA24113@gilberto.physik.rwth-aachen.de> Date: Mon, 01 Apr 1996 10:59:40 +0200 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, Reference: > From: "Christoph P. Kukulies" > Subject: Re: spurious problems with a P150 system > Date: Fri, 29 Mar 1996 18:08:01 +0100 > Message-id: <199603291708.SAA24113@gilberto.physik.rwth-aachen.de> > > Now and then it happens now that files are clobbered. How clobbered ? Zero sized or screwed data ? I have a current problem that was initially assumed software/OS rev/incompat. libs etc, but turns out to be a flaky disk: HP 97548S C023" type 0 fixed SCSI 1 Every so often 8 bytes in my files get zapped to 0xFF. Your err. condition is no doubt different to mine, but you might want to check your disc, so I'm privately mailing you a little program called testblock.c + man, simply use it to write than check one enormous file on the remaining space on that file system. Unix FSs dont generally have Cksums in, 'cos it would heavily impact the performance particularly when accessing large files. Normally disks supposedly have error recovery electronics, but if that fails .... Intriguingly I have 2 `identical' HP drives, & the bad one has an extra jumper on, without which the scsi bus hangs during boot, I rather suspect this is some kind of `over-ride the default hang-on-err-detect-in-cache-boot-check' strap, but I don't know 'cos I only have the `Product Description Manual' & not a factory/service manual. testblock.c should hopefully help nail down where your problem is, it's probably software, but if it unexpectedly is flaky hardware, testblock.c might catch it for you :-) Julian -- Julian H. Stacey jhs@freebsd.org http://www.freebsd.org/~jhs/ From owner-freebsd-current Mon Apr 1 08:46:39 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA05393 for current-outgoing; Mon, 1 Apr 1996 08:46:39 -0800 (PST) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id IAA05387 for ; Mon, 1 Apr 1996 08:46:37 -0800 (PST) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <17441(1)>; Mon, 1 Apr 1996 08:45:45 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177475>; Mon, 1 Apr 1996 08:45:41 -0800 To: Bruce Evans cc: current@freebsd.org Subject: Re: Another "does LINT compile?" question In-reply-to: Your message of "Mon, 01 Apr 96 02:44:34 PST." <199604011044.UAA14428@godzilla.zeta.org.au> Date: Mon, 1 Apr 1996 08:45:29 PST From: Bill Fenner Message-Id: <96Apr1.084541pst.177475@crevenia.parc.xerox.com> Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199604011044.UAA14428@godzilla.zeta.org.au> bde wrote: >>I have a shell script that tries to build LINT nightly and sends me email >>if it fails. Perhaps this output should go to the mailing list? > >Only once a week until all the warnings are fixed. I'm not counting warnings, only build failures. However, since at least this particular failure was because I'm building on -stable, it probably doesn't make sense. I could move the script to thud, though... Bill From owner-freebsd-current Mon Apr 1 08:58:45 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA06067 for current-outgoing; Mon, 1 Apr 1996 08:58:45 -0800 (PST) Received: from Campino.Informatik.RWTH-Aachen.DE (campino.Informatik.RWTH-Aachen.DE [137.226.225.2]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id IAA06035 Mon, 1 Apr 1996 08:58:33 -0800 (PST) Received: from gilberto.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.31.2]) by Campino.Informatik.RWTH-Aachen.DE (RBI-Z-5/8.6.12) with ESMTP id SAA11004; Mon, 1 Apr 1996 18:55:58 +0200 Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.6.11/8.6.9) id TAA05136; Mon, 1 Apr 1996 19:02:44 +0200 From: "Christoph P. Kukulies" Message-Id: <199604011702.TAA05136@gilberto.physik.rwth-aachen.de> Subject: Re: spurious problems with a P150 system To: jhs@freebsd.org Date: Mon, 1 Apr 1996 19:02:43 +0200 (MET DST) Cc: kuku@gilberto.physik.rwth-aachen.de, freebsd-current@freefall.FreeBSD.org In-Reply-To: <199604010859.KAA00437@vector.jhs.local> from "Julian H. Stacey" at Apr 1, 96 10:59:40 am Reply-To: Christoph Kukulies X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > testblock.c might catch it for you :-) Thanks. > > Julian > -- > Julian H. Stacey jhs@freebsd.org http://www.freebsd.org/~jhs/ > --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-current Mon Apr 1 09:09:41 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA07483 for current-outgoing; Mon, 1 Apr 1996 09:09:41 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA07478 for ; Mon, 1 Apr 1996 09:09:40 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA13606; Mon, 1 Apr 1996 10:00:46 -0700 From: Terry Lambert Message-Id: <199604011700.KAA13606@phaeton.artisoft.com> Subject: Re: We need to do another XFree86 release for -current someday soon.. To: davidg@Root.COM Date: Mon, 1 Apr 1996 10:00:45 -0700 (MST) Cc: terry@lambert.org, joerg_wunsch@uriah.heep.sax.de, freebsd-current@freebsd.org In-Reply-To: <199603312246.OAA07341@Root.COM> from "David Greenman" at Mar 31, 96 02:46:44 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-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > In general this is true. In this case, however, we made a conscious and > deliberate decision to stop supporting the code. This coupled with the > consensus that broken and unsupported code should be removed rather than > fester in the source tree is what led to its removal. > The "2.2" release is a long way off and we'll likely have other reasons for > bumping the library major number before the release happens. If people want to > run code that is 6-9 months away from release, then they should be prepared to > deal with a few "bumps" along the way. This has always been our stated policy > about -current, so nothing 'new' here. > I fully support the removal of code from libc as well as the major number > bump. We have a policy of providing backward compatibility via our "compat" > distributions and we'll continue to support older binaries with this mechanism. > Future XFree86 releases should be built against RELEASE versions of FreeBSD. I > believe this has always been their policy, so nothing 'new' here, either. Are stubs being written for "compat"? Or will the libraries not fail catastrophically (for instance, for an older netstat)? 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 Apr 1 09:18:45 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA08235 for current-outgoing; Mon, 1 Apr 1996 09:18:45 -0800 (PST) Received: from Campino.Informatik.RWTH-Aachen.DE (campino.Informatik.RWTH-Aachen.DE [137.226.225.2]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA08229 for ; Mon, 1 Apr 1996 09:18:38 -0800 (PST) Received: from gilberto.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.31.2]) by Campino.Informatik.RWTH-Aachen.DE (RBI-Z-5/8.6.12) with ESMTP id TAA11353 for ; Mon, 1 Apr 1996 19:16:24 +0200 Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.6.11/8.6.9) id TAA05251 for freebsd-current@freefall.cdrom.com; Mon, 1 Apr 1996 19:23:05 +0200 Date: Mon, 1 Apr 1996 19:23:05 +0200 From: "Christoph P. Kukulies" Message-Id: <199604011723.TAA05251@gilberto.physik.rwth-aachen.de> To: freebsd-current@freefall.FreeBSD.org Subject: -current world build (apropos) Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Making manpath.1 from manpath.man cc -O -DMAIN -DSTDC_HEADERS -DPOSIX -DHAS_TROFF -DDO_UNCOMPRESS -DALT_SYSTEMS -I/usr/src/gnu/usr.bin/man/manpath/../lib -I/usr/src/gnu/usr.bin/man/manpath/../lib/obj -o manpath manpath.o -L/usr/src/gnu/usr.bin/man/manpath/../lib/obj -lman ===> gnu/usr.bin/man/apropos make: don't know how to make apropos. Stop *** Error code 2 Stop. *** Error code 1 (From my daily -current world.log). --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-current Mon Apr 1 09:52:00 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA10130 for current-outgoing; Mon, 1 Apr 1996 09:52:00 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA10102 for ; Mon, 1 Apr 1996 09:51:50 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id TAA29660 for ; Mon, 1 Apr 1996 19:51:42 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id TAA11484 for freebsd-current@FreeBSD.org; Mon, 1 Apr 1996 19:51:42 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id TAA06115 for freebsd-current@FreeBSD.org; Mon, 1 Apr 1996 19:19:59 +0200 (MET DST) From: J Wunsch Message-Id: <199604011719.TAA06115@uriah.heep.sax.de> Subject: Re: FreeBSD performance vs BSD/OS To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Mon, 1 Apr 1996 19:19:58 +0200 (MET DST) In-Reply-To: <199604011057.UAA14960@godzilla.zeta.org.au> from "Bruce Evans" at Apr 1, 96 08:57:55 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Bruce Evans wrote: > >Should this become time(9)? > > No, it has very little to do with time or the kernel. clocks(7) would > be better, and half of it is i386-specific so it would need to be split > up. Ok, make it clocks(7). It's not long enough to be split, so it could be kept i386-specific (at least by now). > I don't like section 9. It's far better than no chance to document the kernel at all. We need more people who start documenting the interfaces once they know. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Mon Apr 1 09:55:41 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA10537 for current-outgoing; Mon, 1 Apr 1996 09:55:41 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA10511 for ; Mon, 1 Apr 1996 09:55:36 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id TAA29648 for ; Mon, 1 Apr 1996 19:51:38 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id TAA11479 for freebsd-current@FreeBSD.org; Mon, 1 Apr 1996 19:51:37 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id TAA06347 for freebsd-current@FreeBSD.org; Mon, 1 Apr 1996 19:36:27 +0200 (MET DST) From: J Wunsch Message-Id: <199604011736.TAA06347@uriah.heep.sax.de> Subject: Re: adjkerntz (was: cvs commit: src/usr.sbin/tzsetup ...) To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Mon, 1 Apr 1996 19:36:27 +0200 (MET DST) In-Reply-To: <199604011437.SAA00682@astral.msk.su> from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Apr 1, 96 06:37:55 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= wrote: > > Perhaps only when adjkerntz is running? It is never running on > > ``serious'' machines. ;-) > > I always run it on all my machines without any problem. I didn't claim it would cause major problems (except those you've been describing to us :-), but it's rather obsolete on machines that don't also run DOS sometimes. For a sole Unix server, i don't know why i should not use UTC. > > Btw., there have been many problem reports about bogus adjkerntz > > activities here in Germany yesterday. (We had a DST switchover.) I > > It very depends on adjkerntz version. Old versions have a bugs. It was with a -current version, and -current timezone settings. So it seems that new versions do also have bugs. ;) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Mon Apr 1 10:30:54 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA13221 for current-outgoing; Mon, 1 Apr 1996 10:30:54 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA13216 for ; Mon, 1 Apr 1996 10:30:50 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id EAA32194; Tue, 2 Apr 1996 04:24:37 +1000 Date: Tue, 2 Apr 1996 04:24:37 +1000 From: Bruce Evans Message-Id: <199604011824.EAA32194@godzilla.zeta.org.au> To: bde@zeta.org.au, phk@critter.tfs.com Subject: Re: calcru: negative time: Cc: freebsd-current@freefall.freebsd.org, kuku@gilberto.physik.rwth-aachen.de Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> >[deleted] >> >calcru: negative time: -11929 usec >> ... >> This is caused by hardclock() interrupt latency. The problem is >> ... >My i386 has really high numbers here. Highly negative numbers? They can't go more than 10000 usec negative on i386's due to the causes that I know about. >Could this be a spl; Mon, 1 Apr 1996 10:35:10 -0800 (PST) Received: from localhost (scrappy@localhost) by ki.net (8.7.4/8.7.4) with SMTP id NAA01225 for ; Mon, 1 Apr 1996 13:35:08 -0500 (EST) Date: Mon, 1 Apr 1996 13:35:06 -0500 (EST) From: "Marc G. Fournier" To: current@freebsd.org Subject: Finally...a core dump that works -- ed_start() bug Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi... Well, after I don't know *how* many attempts to get a core dump from the ed_start() panic...I've got one. Now what do I do? :) I've checked the handbook, and followed the steps given for analysing the core, and came up with this. I've moved my core/kernel.debug to a seperate place so that I don't delete it accidentally, so if there is another command I should use to give better output, or if I've totally confused what I'm looking at, please let me know...this bug is about the only bug that I'm getting with -current right now, and would really love to see higher then 24hr uptimes on that machine :( BTW...since I already have a PR submitted for this, but not this information, is there a way of appending this onto the existing PR? Script started on Mon Apr 1 13:22:43 1996 freebsd# gdb -k /usr/src/sys/compile/freebsd/kernel.debug vmcore.4 GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.13 (i386-unknown-freebsd), Copyright 1994 Free Software Foundation, Inc... IdlePTD 20d000 current pcb at 1dae20 panic: from debugger #0 boot (howto=260) at ../../i386/i386/machdep.c:942 942 dumppcb.pcb_ptd = rcr3(); (kgdb) where #0 boot (howto=260) at ../../i386/i386/machdep.c:942 #1 0xf0113707 in panic (fmt=0xf01011f8 "from debugger") at ../../kern/subr_prf.c:133 #2 0xf0101215 in db_panic (dummy1=-266744989, dummy2=0, dummy3=-1, dummy4=0xf01c9aac "") at ../../ddb/db_command.c:395 #3 0xf01010fe in db_command (last_cmdp=0xf01cab34, cmd_table=0xf01ca994) at ../../ddb/db_command.c:288 #4 0xf010127d in db_command_loop () at ../../ddb/db_command.c:417 #5 0xf01035e8 in db_trap (type=3, code=0) at ../../ddb/db_trap.c:73 #6 0xf019c93a in kdb_trap (type=3, code=0, regs=0xf01c9ba8) at ../../i386/i386/db_interface.c:136 #7 0xf01a48ec in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = -266556620, tf_esi = -267382280, tf_ebp = -266560532, tf_isp = -266560560, tf_ebx = 256, tf_edx = -266745035, tf_ecx = 1920, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -266744989, tf_cs = -266600440, tf_eflags = 582, tf_esp = -266745051, tf_ss = -267307362}) at ../../i386/i386/trap.c:399 #8 0xf019d1b1 in calltrap () #9 0xf01136fe in panic (fmt=0xf01011f8 "from debugger") at ../../kern/subr_prf.c:129 #10 0xf0101215 in db_panic (dummy1=-266652479, dummy2=0, dummy3=-1, dummy4=0xf01c9c3c "") at ../../ddb/db_command.c:395 #11 0xf01010fe in db_command (last_cmdp=0xf01cab34, cmd_table=0xf01ca994) at ../../ddb/db_command.c:288 #12 0xf010127d in db_command_loop () at ../../ddb/db_command.c:417 #13 0xf01035e8 in db_trap (type=12, code=0) at ../../ddb/db_trap.c:73 #14 0xf019c93a in kdb_trap (type=12, code=0, regs=0xf01c9d8c) at ../../i386/i386/db_interface.c:136 #15 0xf01a50af in trap_fatal (frame=0xf01c9d8c) at ../../i386/i386/trap.c:736 #16 0xf01a4bac in trap_pfault (frame=0xf01c9d8c, usermode=0) at ../../i386/i386/trap.c:651 #17 0xf01a483f in trap (frame={tf_es = -267190256, tf_ds = -266534896, tf_edi = -267583428, tf_esi = -266477172, tf_ebp = -266560020, tf_isp = -266560076, tf_ebx = 656, tf_edx = 662, tf_ecx = 662, tf_eax = -267583488, tf_trapno = 12, tf_err = -266665984, tf_eip = -266652479, tf_cs = -267583480, tf_eflags = 66134, tf_esp = -1073610752, tf_ss = -258322176}) at ../../i386/i386/trap.c:319 #18 0xf019d1b1 in calltrap () #19 0xf01387d5 in ether_output (ifp=0xf01de18c, m0=0xf09a5100, dst=0xf09c5d70, rt0=0xf099ab00) at ../../net/if_ethersubr.c:307 #20 0xf0141ee1 in ip_output (m0=0xf09a5100, opt=0x0, ro=0xf09b5d2c, flags=0, imo=0x0) at ../../netinet/ip_output.c:355 #21 0xf0145e4d in tcp_output (tp=0xf094c900) at ../../netinet/tcp_output.c:689 #22 0xf0144cb2 in tcp_input (m=0xf09bf380, iphlen=20) at ../../netinet/tcp_input.c:1625 #23 0xf0140bdd in ip_input (m=0xf09bf380) at ../../netinet/ip_input.c:447 #24 0xf0140c54 in ipintr () at ../../netinet/ip_input.c:468 (kgdb) up 19 #19 0xf01387d5 in ether_output (ifp=0xf01de18c, m0=0xf09a5100, dst=0xf09c5d70, rt0=0xf099ab00) at ../../net/if_ethersubr.c:307 307 (*ifp->if_start)(ifp); (kgdb) list 302 splx(s); 303 senderr(ENOBUFS); 304 } 305 IF_ENQUEUE(&ifp->if_snd, m); 306 if ((ifp->if_flags & IFF_OACTIVE) == 0) 307 (*ifp->if_start)(ifp); 308 splx(s); 309 ifp->if_obytes += len + sizeof (struct ether_header); 310 if (m->m_flags & M_MCAST) 311 ifp->if_omcasts++; (kgdb) print ifp $1 = (struct ifnet *) 0xf00d003c (kgdb) print ifp->if_obytes There is no member named if_obytes. (kgdb) printf  ifp->if_start $2 = (void (*)()) 0xffffffff (kgdb) print ifp->if_flags $3 = -1 (kgdb) print m->m_flags There is no member named m_flags. (kgdb) quit freebsd# exit exit Script done on Mon Apr 1 13:28:33 1996 Marc G. Fournier | POP Mail Telnet Acct DNS Hosting System | WWW Services Database Services | Knowledge, Administrator | | Information and scrappy@ki.net | WWW: http://www.ki.net | Communications, Inc From owner-freebsd-current Mon Apr 1 10:38:54 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA14706 for current-outgoing; Mon, 1 Apr 1996 10:38:54 -0800 (PST) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id KAA14701 Mon, 1 Apr 1996 10:38:50 -0800 (PST) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) id UAA08528; Mon, 1 Apr 1996 20:15:19 +0200 (MET DST) Received: from localhost (localhost [127.0.0.1]) by gun.de (8.7.5/8.7.3) with SMTP id UAA23697; Mon, 1 Apr 1996 20:05:23 +0200 (MET DST) Date: Mon, 1 Apr 1996 20:05:21 +0200 (MET DST) From: Andreas Klemm To: ports@freebsd.org cc: current@freebsd.org Subject: Re: Ports README changes committed (Proposal 6) In-Reply-To: <199604011129.DAA13308@silvia.HIP.Berkeley.EDU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Mon, 1 Apr 1996, Satoshi Asami wrote: > (Note crosspost - discussion followups to "ports" only please.) > > I just committed changes necessary to generate ports' README.html > files automatically. You will need the latest version of Looks and works really GREAT !!!! > For all this to look great, we will need pkg/COMMENT and pkg/DESCR for > every subdirectory, as well as a (much) better /usr/ports/pkg/DESCR. A more html conform "good looking" solution ?! > I'll work on that later this week. But at least you'll have something > to look on. Well I have a nice idea, which is not very expensive (in work) ... What about nationalizing the template files ?!?!?! /usr/ports/templates/${LANG}/README.category /README.port /README.top Where values for LANG could be something like: us,de,... or something like being used in sysinstall (for the helpfiles). The only addition you need then in /usr/share/mk/bsd.port* (2 files) is to replace TEMPLATES?= ${PORTSDIR}/templates by LANG?= us TEMPLATES?= ${PORTSDIR}/templates/${LANG} I think this idea is straightforward ;-) What do you think ?! If you like, I could try to give you the German templates... I'd start with this if you are interested and give me your ok ;-) > Satoshi and the quiet ports team ^^^^^ hehehe ;-) ROTFL Andreas /// - -- andreas@knobel.gun.de /\/\___ Wiechers & Partner Datentechnik GmbH Andreas Klemm ___/\/\/ $$ Support Unix - aklemm@wup.de $$ pgp p-key http://www-swiss.ai.mit.edu/~bal/pks-toplev.html >>> powered by <<< ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz >>> FreeBSD <<< -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMWAa4vMLpmkD/U+FAQHr5gP/RT01/4IO/DwPd9FyXJCDP6QPmt7XESwc 3kdBJAt8FDUbk1wXj1yOedHWTbgx8wclTCWqcPbRwxVSt+Bn4jQVUZ8guAcNAYLk fabjdjZVBresNX5lc3w+1AovemrVqQCEhW8dCmKfI7p2IWc3RJnPzocO/XA7Sx8D YDU4EH6IEis= =pmLz -----END PGP SIGNATURE----- From owner-freebsd-current Mon Apr 1 10:41:31 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA14993 for current-outgoing; Mon, 1 Apr 1996 10:41:31 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA14988 for ; Mon, 1 Apr 1996 10:41:29 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0u3oXd-0003xgC; Mon, 1 Apr 96 10:41 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id SAA00519; Mon, 1 Apr 1996 18:41:22 GMT X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: J Wunsch cc: freebsd-current@FreeBSD.org (FreeBSD-current users) Subject: Re: FreeBSD performance vs BSD/OS In-reply-to: Your message of "Mon, 01 Apr 1996 19:19:58 +0200." <199604011719.TAA06115@uriah.heep.sax.de> Date: Mon, 01 Apr 1996 18:41:21 +0000 Message-ID: <517.828384081@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > I don't like section 9. > > It's far better than no chance to document the kernel at all. We need > more people who start documenting the interfaces once they know. YES! -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Mon Apr 1 10:43:36 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA15123 for current-outgoing; Mon, 1 Apr 1996 10:43:36 -0800 (PST) Received: from ki.net (root@ki.net [205.150.102.1]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id KAA15102 for ; Mon, 1 Apr 1996 10:43:31 -0800 (PST) Received: from localhost (scrappy@localhost) by ki.net (8.7.4/8.7.4) with SMTP id NAA01293 for ; Mon, 1 Apr 1996 13:43:29 -0500 (EST) Date: Mon, 1 Apr 1996 13:43:28 -0500 (EST) From: "Marc G. Fournier" To: current@freebsd.org Subject: ed_start() bug...more information Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi... Went through the handbook again, and would like to change my story from the last time :) Here is my revised story...this one seems to make more sense then the last one...I sort of totally fudged up the last one, I think :( If there is more information I should/could be providing, please let me know... Oh, the Ethernet card is an SMC 8013EPC @ irq 5, maddr 0xd8000 with an msize of 16384 Script started on Mon Apr 1 13:39:35 1996 freebsd# gdb -k /usr/src/sys/compile/freebsd/kernel.debug vmcore.54 GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.13 (i386-unknown-freebsd), Copyright 1994 Free Software Foundation, Inc... IdlePTD 20d000 current pcb at 1dae20 panic: from debugger #0 boot (howto=260) at ../../i386/i386/machdep.c:942 942 dumppcb.pcb_ptd = rcr3(); (kgdb) where #0 boot (howto=260) at ../../i386/i386/machdep.c:942 #1 0xf0113707 in panic (fmt=0xf01011f8 "from debugger") at ../../kern/subr_prf.c:133 #2 0xf0101215 in db_panic (dummy1=-266744989, dummy2=0, dummy3=-1, dummy4=0xf01c9aac "") at ../../ddb/db_command.c:395 #3 0xf01010fe in db_command (last_cmdp=0xf01cab34, cmd_table=0xf01ca994) at ../../ddb/db_command.c:288 #4 0xf010127d in db_command_loop () at ../../ddb/db_command.c:417 #5 0xf01035e8 in db_trap (type=3, code=0) at ../../ddb/db_trap.c:73 #6 0xf019c93a in kdb_trap (type=3, code=0, regs=0xf01c9ba8) at ../../i386/i386/db_interface.c:136 #7 0xf01a48ec in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = -266556620, tf_esi = -267382280, tf_ebp = -266560532, tf_isp = -266560560, tf_ebx = 256, tf_edx = -266745035, tf_ecx = 1920, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -266744989, tf_cs = -266600440, tf_eflags = 582, tf_esp = -266745051, tf_ss = -267307362}) at ../../i386/i386/trap.c:399 #8 0xf019d1b1 in calltrap () #9 0xf01136fe in panic (fmt=0xf01011f8 "from debugger") at ../../kern/subr_prf.c:129 #10 0xf0101215 in db_panic (dummy1=-266652479, dummy2=0, dummy3=-1, dummy4=0xf01c9c3c "") at ../../ddb/db_command.c:395 #11 0xf01010fe in db_command (last_cmdp=0xf01cab34, cmd_table=0xf01ca994) at ../../ddb/db_command.c:288 #12 0xf010127d in db_command_loop () at ../../ddb/db_command.c:417 #13 0xf01035e8 in db_trap (type=12, code=0) at ../../ddb/db_trap.c:73 #14 0xf019c93a in kdb_trap (type=12, code=0, regs=0xf01c9d8c) at ../../i386/i386/db_interface.c:136 #15 0xf01a50af in trap_fatal (frame=0xf01c9d8c) at ../../i386/i386/trap.c:736 #16 0xf01a4bac in trap_pfault (frame=0xf01c9d8c, usermode=0) at ../../i386/i386/trap.c:651 #17 0xf01a483f in trap (frame={tf_es = -267190256, tf_ds = -266534896, tf_edi = -267583428, tf_esi = -266477172, tf_ebp = -266560020, tf_isp = -266560076, tf_ebx = 656, tf_edx = 662, tf_ecx = 662, tf_eax = -267583488, tf_trapno = 12, tf_err = -266665984, tf_eip = -266652479, tf_cs = -267583480, tf_eflags = 66134, tf_esp = -1073610752, tf_ss = -258322176}) at ../../i386/i386/trap.c:319 #18 0xf019d1b1 in calltrap () #19 0xf01387d5 in ether_output (ifp=0xf01de18c, m0=0xf09a5100, dst=0xf09c5d70, rt0=0xf099ab00) at ../../net/if_ethersubr.c:307 #20 0xf0141ee1 in ip_output (m0=0xf09a5100, opt=0x0, ro=0xf09b5d2c, flags=0, imo=0x0) at ../../netinet/ip_output.c:355 #21 0xf0145e4d in tcp_output (tp=0xf094c900) at ../../netinet/tcp_output.c:689 #22 0xf0144cb2 in tcp_input (m=0xf09bf380, iphlen=20) at ../../netinet/tcp_input.c:1625 #23 0xf0140bdd in ip_input (m=0xf09bf380) at ../../netinet/ip_input.c:447 #24 0xf0140c54 in ipintr () at ../../netinet/ip_input.c:468 (kgdb) up 17 #17 0xf01a483f in trap (frame={tf_es = -267190256, tf_ds = -266534896, tf_edi = -267583428, tf_esi = -266477172, tf_ebp = -266560020, tf_isp = -266560076, tf_ebx = 656, tf_edx = 662, tf_ecx = 662, tf_eax = -267583488, tf_trapno = 12, tf_err = -266665984, tf_eip = -266652479, tf_cs = -267583480, tf_eflags = 66134, tf_esp = -1073610752, tf_ss = -258322176}) at ../../i386/i386/trap.c:319 319 (void) trap_pfault(&frame, FALSE); (kgdb) frame frame->tf_ebp frame->tf_eip #0 ed_start (ifp=0xf01de18c) at ../../i386/isa/if_ed.c:1744 1744 outb(sc->nic_addr + ED_P0_CR, sc->cr_proto | ED_CR_TXP | ED_CR_STA); (kgdb) list 1739 outb(sc->nic_addr + ED_P0_TBCR1, len >> 8); 1740 1741 /* 1742 * Set page 0, Remote DMA complete, Transmit Packet, and *Start* 1743 */ 1744 outb(sc->nic_addr + ED_P0_CR, sc->cr_proto | ED_CR_TXP | ED_CR_STA); 1745 sc->xmit_busy = 1; 1746 1747 /* 1748 * Point to next transmit buffer slot and wrap if necessary. (kgdb) print sc $1 = (struct ed_softc *) 0xf0905000 (kgdb) print sc->nic_addr $2 = 61575 (kgdb) up #1 0xf01387d5 in ether_output (ifp=0xf01de18c, m0=0xf09a5100, dst=0xf09c5d70, rt0=0xf099ab00) at ../../net/if_ethersubr.c:307 307 (*ifp->if_start)(ifp); (kgdb) up #2 0xf0141ee1 in ip_output (m0=0xf09a5100, opt=0x0, ro=0xf09b5d2c, flags=0, imo=0x0) at ../../netinet/ip_output.c:355 355 error = (*ifp->if_output)(ifp, m, (kgdb) up #3 0xf0145e4d in tcp_output (tp=0xf094c900) at ../../netinet/tcp_output.c:689 689 error = ip_output(m, tp->t_inpcb->inp_options, &tp->t_inpcb->inp_route, (kgdb) up #4 0xf0144cb2 in tcp_input (m=0xf09bf380, iphlen=20) at ../../netinet/tcp_input.c:1625 1625 (void) tcp_output(tp); (kgdb) up #5 0xf0140bdd in ip_input (m=0xf09bf380) at ../../netinet/ip_input.c:447 447 (*inetsw[ip_protox[ip->ip_p]].pr_input)(m, hlen); (kgdb) up #6 0xf0140c54 in ipintr () at ../../netinet/ip_input.c:468 468 ip_input(m); (kgdb) up Initial frame selected; you cannot go up. (kgdb) quit freebsd# exit exit Script done on Mon Apr 1 13:41:53 1996 Marc G. Fournier | POP Mail Telnet Acct DNS Hosting System | WWW Services Database Services | Knowledge, Administrator | | Information and scrappy@ki.net | WWW: http://www.ki.net | Communications, Inc From owner-freebsd-current Mon Apr 1 10:59:34 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA17413 for current-outgoing; Mon, 1 Apr 1996 10:59:34 -0800 (PST) Received: from Campino.Informatik.RWTH-Aachen.DE (campino.Informatik.RWTH-Aachen.DE [137.226.225.2]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA17377 Mon, 1 Apr 1996 10:59:23 -0800 (PST) Received: from gilberto.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.31.2]) by Campino.Informatik.RWTH-Aachen.DE (RBI-Z-5/8.6.12) with ESMTP id UAA13424; Mon, 1 Apr 1996 20:56:36 +0200 Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.6.11/8.6.9) id VAA05546; Mon, 1 Apr 1996 21:03:24 +0200 From: "Christoph P. Kukulies" Message-Id: <199604011903.VAA05546@gilberto.physik.rwth-aachen.de> Subject: Re: your mail To: jhs@FreeBSD.org Date: Mon, 1 Apr 1996 21:03:24 +0200 (MET DST) Cc: ccappuc@satelnet.org, current@FreeBSD.org In-Reply-To: <199604010909.LAA00499@vector.jhs.local> from "Julian H. Stacey" at Apr 1, 96 11:09:25 am Reply-To: Christoph Kukulies X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > > Hi, Reference: > > From: Chris Cappuccio > > Date: Fri, 29 Mar 1996 13:43:50 -0500 > > Message-id: <199603291843.NAA02951@sefl.satelnet.org> > > > > strange..) I can't get he baud rate adn such set correctly > > in printcap and once I do, how would I print from applications such as umm ne > - tscape or > > something.. (ghostscript PS-->PCL?) > > Here's a ~1 year old entry I used to use on my hp3p laser (before I changed > from serial to parallel): > # serial|hp3p.raw|Raw output device hp3p:\ > # :lp=/dev/ttyb:br#19200:xc#0177777:ms=-parity,ixon,-opost: This is my printcap for a serial DecLn03r Scriptprinter (Adobe PS): # @(#)printcap 5.3 (Berkeley) 6/30/90 lp0|lp|local laser printer:\ :lp=/dev/cuaa2:\ :rw:\ :of=/usr/local/bin/lpof:\ :fc#0000374:fs#0000003:br#38400:\ :xc#0:xs#0040040:sf:sb:br#38400:\ :mx#0:sd=/var/spool/output/lpd:lf=/var/log/lpd-errs: lp1|remote laser printer:\ :rm=declaser3500:\ :rw:sb:sf:\ :mx#0:sd=/var/spool/output/lpd:lf=/var/log/lpd-errs: And here a printcap for a local HP Laserjet III: lps|lp-postscript|hp ljet III using GS filter:\ :lp=/dev/lpt0:\ :sd=/var/spool/lps:\ :sh:\ :of=/usr/local/bin/gsljps:\ :lf=/var/log/lpd-errs:\ :mx#0: With gsljps: #!/bin/sh /usr/local/bin/gs -q -dSAFER -sDEVICE=laserjet -r300 -dNOPAUSE -sOutputFile=- - > > You can see the 19200 baud lurking in there, > The FAQ has more examples I guess, Suggested Reading: > man printcap, > /usr/share/doc/FAQ/freebsd-faq.html > Printer docs :-) > > Julian > -- > Julian H. Stacey jhs@freebsd.org http://www.freebsd.org/~jhs/ > --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-current Mon Apr 1 12:00:22 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA22025 for current-outgoing; Mon, 1 Apr 1996 12:00:22 -0800 (PST) Received: from ghost.uunet.ca (ghost.uunet.ca [142.77.1.100]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id MAA22019 for ; Mon, 1 Apr 1996 12:00:17 -0800 (PST) Received: by ghost.uunet.ca id <60064-1>; Mon, 1 Apr 1996 14:40:00 -0500 Date: Mon, 1 Apr 1996 14:39:56 -0500 From: Cat Okita To: current@freebsd.org Subject: Re: Advice/Recommendation needed Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Marc writes: > Main thing to consider is that I have a partner that is against > FreeBSD (cause its free) and would like to get our main server as rock-solid > as possible so that she can't use instability as an argument against me :( ...and his partner responds: It's not the stability/lack thereof (although running a production environment on the latest and greatest always makes me nervous - couldn't possibly imagine why...). Much of my quibble has to do with responsiblity and support. I *need* to know that I've got a support contract for the OS, and have someone to hang out the window if things aren't working. (Hell - someone to sue, if it comes to that). Free OS's are a wonderful thing - they let people use UNIX that might never otherwise be able to afford to do so; they offer source so that people can learn about how things work...but they don't offer a place for the buck to stop. Cat From owner-freebsd-current Mon Apr 1 12:07:06 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA22361 for current-outgoing; Mon, 1 Apr 1996 12:07:06 -0800 (PST) Received: from ki.net (root@ki.net [205.150.102.1]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id MAA22352 for ; Mon, 1 Apr 1996 12:07:00 -0800 (PST) Received: from localhost (scrappy@localhost) by ki.net (8.7.4/8.7.4) with SMTP id PAA03365; Mon, 1 Apr 1996 15:06:52 -0500 (EST) Date: Mon, 1 Apr 1996 15:06:50 -0500 (EST) From: "Marc G. Fournier" To: JULIAN Elischer cc: current@FreeBSD.org Subject: Re: ed_start() bug...more information In-Reply-To: <199604012001.MAA04976@ref.tfs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 1 Apr 1996, JULIAN Elischer wrote: > eh? sc seems ok, so what else could be needed? > maybe the optimisation is catching us... maybe we're actually on the next line > or somewhere else nearby.. remember that -O and -g together give a result > that is ok MOSTof the time, but CAN be 'only approximate' some times.... > > if you can compile if_ed.c without the -O it might be worth it... > Okay, pulling in the newest source and doing a recompile now... Will let you know in 24 hours :) Marc G. Fournier | POP Mail Telnet Acct DNS Hosting System | WWW Services Database Services | Knowledge, Administrator | | Information and scrappy@ki.net | WWW: http://www.ki.net | Communications, Inc From owner-freebsd-current Mon Apr 1 12:33:22 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA26226 for current-outgoing; Mon, 1 Apr 1996 12:33:22 -0800 (PST) Received: from ki.net (root@ki.net [205.150.102.1]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id MAA26219 for ; Mon, 1 Apr 1996 12:33:17 -0800 (PST) Received: from localhost (scrappy@localhost) by ki.net (8.7.4/8.7.4) with SMTP id PAA04637 for ; Mon, 1 Apr 1996 15:33:17 -0500 (EST) Date: Mon, 1 Apr 1996 15:33:16 -0500 (EST) From: "Marc G. Fournier" To: current@freebsd.org Subject: disabling -O for kernel Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi... Exactly *where* do I disable -O from? I've just modified /usr/src/sys/compile//Makefile to get rid of it, but as soon as I do another config, its going to put it back in again, so where exactly do I disable it so that when I do do a config, it doesn't put it in again? I've checked /usr/share/mk...but none in there look like what I'm looking for. Thanks... Marc G. Fournier | POP Mail Telnet Acct DNS Hosting System | WWW Services Database Services | Knowledge, Administrator | | Information and scrappy@ki.net | WWW: http://www.ki.net | Communications, Inc From owner-freebsd-current Mon Apr 1 12:35:45 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA26511 for current-outgoing; Mon, 1 Apr 1996 12:35:45 -0800 (PST) Received: from sovcom.kiae.su (sovcom.kiae.su [144.206.136.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA26501 for ; Mon, 1 Apr 1996 12:35:39 -0800 (PST) Received: by sovcom.kiae.su id AA21810 (5.65.kiae-1 ); Mon, 1 Apr 1996 23:27:23 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Mon, 1 Apr 96 23:27:23 +0300 Received: (from ache@localhost) by astral.msk.su (8.7.5/8.7.3) id AAA01620; Tue, 2 Apr 1996 00:24:21 +0400 (MSD) Message-Id: <199604012024.AAA01620@astral.msk.su> Subject: Re: adjkerntz (was: cvs commit: src/usr.sbin/tzsetup ...) To: j@uriah.heep.sax.de (J Wunsch) Date: Tue, 2 Apr 1996 00:24:20 +0400 (MSD) Cc: freebsd-current@FreeBSD.org In-Reply-To: <199604011736.TAA06347@uriah.heep.sax.de> from "J Wunsch" at "Apr 1, 96 07:36:27 pm" From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast X-Mailer: ELM [version 2.4ME+ PL14 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > As =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= wrote: > > > Perhaps only when adjkerntz is running? It is never running on > > > ``serious'' machines. ;-) > > > > I always run it on all my machines without any problem. > > I didn't claim it would cause major problems (except those you've been > describing to us :-), but it's rather obsolete on machines that don't > also run DOS sometimes. For a sole Unix server, i don't know why i > should not use UTC. Of course, pure Unix machine don't need it. But if you sometimes mount DOS floppies (msdosfs), you need it. > > > Btw., there have been many problem reports about bogus adjkerntz > > > activities here in Germany yesterday. (We had a DST switchover.) I > > > > It very depends on adjkerntz version. Old versions have a bugs. > > It was with a -current version, and -current timezone settings. So it > seems that new versions do also have bugs. ;) I need more info on this subject, i.e. some test results, DST rules and what finally happens. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-current Mon Apr 1 13:02:54 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA28338 for current-outgoing; Mon, 1 Apr 1996 13:02:54 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA28332 for ; Mon, 1 Apr 1996 13:02:51 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA14351; Mon, 1 Apr 1996 13:58:48 -0700 From: Terry Lambert Message-Id: <199604012058.NAA14351@phaeton.artisoft.com> Subject: Re: We need to do another XFree86 release for -current someday soon.. To: wollman@lcs.mit.edu (Garrett Wollman) Date: Mon, 1 Apr 1996 13:58:47 -0700 (MST) Cc: terry@lambert.org, freebsd-current@FreeBSD.org In-Reply-To: <9604011511.AA29614@halloran-eldar.lcs.mit.edu> from "Garrett Wollman" at Apr 1, 96 10:11:32 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > I think the stubs should go in and the version bump can wait for the > > parameterization, > > It's TOO BLOODY LATE! Shared library version numbers are an > INCREASING function with respect to time. With respect to release times, yes. > > which should make the library not care about the > > underlying transport code > > The library doesn't give a damn about the underlying transport code > (as would have been obvious to you if you actually used the code > rather than wasting my time whining about its removal). The library > routine iso_ntoa() requires header files defining the structure of a > CLNP address and `struct sockaddr_iso'. Those header files no longer > exist. Therefore, the code will no longer compile. Period. End of > story. Well, for fear you were right as you usually are, I went and looked. You weren't. Allow me to explain. The library cares, because it attributes ntoa by protocol family in the symbol name space. This is, to be entirely too blunt, fucked up. It should use something like: #define inet_ntoa( in_addrp) ntoa( AF_INET, in_addrp) ... #define iso_ntoa( iso_addrp) ntoa( AF_ISO, iso_addrp) ... etc. Which is to say, the library interface should be invariant over the death/birth of protocols. Ie: no version number changes when a protocol is no longer supportedi, no version number changes when a new protocol becomes supported. The #define is for legacy code, and goes in the appropriate protocol-specific header. To get to the protocol specific pieces, it would ideally dlopen protocol specific function vectors for such routines, and these would be located in libexec, and there would be a registration list that was consulted to find them (or they would exist in a directory by them selves so that all entries in the directory could be iterated). Barring that, the code should be associated with the protocol module in the kernel and the operation completed as an ioctl() on /dev/net or something similar, which in the absence of dlopen in user space, as is proper, could provide a kludge soloution using the LKM init procedure to hook family specific callbacks. Even if a parameter were to be invalidated, for instance, AF_ISO, and the interface was still parametric, this would result in automatic an implicit stubbing of the affected routines -- which would, again, not require a major version number bump, since it would not constitute an interface change. Obviously, to put any of this in place to avoid similar future problems requires a major version number bump. What we are arguing is whether the ultimate coloution can be included in the forthcoming release. If not, unless there is sufficient other changes to require the bump, the change should be delayed. One incorrect soloution (a partial namespace fix) is no worse than another (function stubs in place of a partial fix). Attribution of protocol family in the symbol space is insufficiently dynamic and should not be tolerated. This is the parameterization, as previously discussed. 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 Apr 1 13:11:45 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA29169 for current-outgoing; Mon, 1 Apr 1996 13:11:45 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA29130 for ; Mon, 1 Apr 1996 13:11:37 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA14384; Mon, 1 Apr 1996 14:07:40 -0700 From: Terry Lambert Message-Id: <199604012107.OAA14384@phaeton.artisoft.com> Subject: Re: Fixit Floppy Broken? To: joerg_wunsch@uriah.heep.sax.de Date: Mon, 1 Apr 1996 14:07:40 -0700 (MST) Cc: freebsd-current@FreeBSD.ORG In-Reply-To: <199603312244.AAA01657@uriah.heep.sax.de> from "J Wunsch" at Apr 1, 96 00:44: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-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > If you're willing to rewrite it, and submitting PRs would accelerate > > > this process, i could immediately submit half a dozen PRs for it. :-) > > > > You should submit them even if there is no victim^H^H^H^H^Holunteer > > at the present time. All bugs should be recorded somewhere. > > Ah, yeah, well, what should i write there? > > Bugs: > The fdc(4) driver is one single large bug. > > Fix: > Rewrite. > > :-) So you were going to submit this "half a dozen" times? 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 Mon Apr 1 13:51:22 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA04949 for current-outgoing; Mon, 1 Apr 1996 13:51:22 -0800 (PST) Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id NAA04939 for ; Mon, 1 Apr 1996 13:51:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by Root.COM (8.7.5/8.6.5) with SMTP id NAA09740; Mon, 1 Apr 1996 13:51:31 -0800 (PST) Message-Id: <199604012151.NAA09740@Root.COM> X-Authentication-Warning: implode.Root.COM: Host localhost [127.0.0.1] didn't use HELO protocol To: Bruce Evans cc: freebsd-current@freefall.freebsd.org, kuku@gilberto.physik.rwth-aachen.de Subject: Re: calcru: negative time: In-reply-to: Your message of "Mon, 01 Apr 1996 21:15:40 +1000." <199604011115.VAA15805@godzilla.zeta.org.au> From: David Greenman Reply-To: davidg@Root.COM Date: Mon, 01 Apr 1996 13:51:31 -0800 Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >>[deleted] >>calcru: negative time: -11929 usec >>calcru: negative time: -3909 usec >>calcru: negative time: -3842 usec >>calcru: negative time: -17709 usec >>calcru: negative time: -3480 usec > >This is caused by hardclock() interrupt latency. The problem is >especially noticable on i586's and i686's because any latency causes the >clock to go backwards; on i386's and i486's, the latency must be > 1 >clock tick (10000 usec) to cause problems. Normally the latency on >i586's is > 0 but < 10 usec and isn't detectable. There must be bugs >elsewhere to cause latencies of more than a few tens of usecs. I'm not convinced that this is a latency problem. The problem has suddenly gotten about 1000 times worse earlier today on both -current and -stable simultaneously...and it's not due to any code changes or load changes. I saw the problem on machines ranging from wcarchive to my X terminal (which is a FreeBSD machine). Note also that as of right now the problem seems to have disappeared again. This looks to me like a strange bug related to the date/ time of year (that it coincides with April Fools Day, has got to be the most amazing thing of all). -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-current Mon Apr 1 14:35:09 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA08022 for current-outgoing; Mon, 1 Apr 1996 14:35:09 -0800 (PST) Received: from pegasus.isr.uc.pt (pegasus.isr.uc.pt [193.136.230.60]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA07997 for ; Mon, 1 Apr 1996 14:34:56 -0800 (PST) Received: from pioneer (pioneer.isr.uc.pt) by pegasus.isr.uc.pt (5.x/SMI-SVR4) id AA02644; Mon, 1 Apr 1996 23:29:37 +0100 Date: Mon, 1 Apr 1996 23:34:19 +0100 (WET DST) From: Paulo Menezes X-Sender: paulo@pioneer To: current@FreeBSD.ORG Subject: localtime needs changes for Portugal Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, Yesterday we did not adjust our watches and VCR's as usual :-) but our UN*X systems did !! This because we changed our timezone from MET to WET... Were you have the patch to the europe file that was distributed with 2.1R regards, Paulo -------------- *** europe.old Mon Apr 1 23:20:51 1996 --- europe Mon Apr 1 23:19:12 1996 *************** *** 1718,1724 **** # From Rui Pedro Salgueiro (November 12, 1992): # Portugal has recently (September, 27) changed timezone # (from WET to MET or CET) to harmonize with EEC. ! 1:00 EC MET%s # We don't know what happened to Madeira or the Azores, # so we'll just use Shanks for now. # Zone NAME GMTOFF RULES FORMAT [UNTIL] --- 1718,1725 ---- # From Rui Pedro Salgueiro (November 12, 1992): # Portugal has recently (September, 27) changed timezone # (from WET to MET or CET) to harmonize with EEC. ! 1:00 EC MET%s 1996 Mar 31 2:00s ! 0:00 EC WET%s # We don't know what happened to Madeira or the Azores, # so we'll just use Shanks for now. # Zone NAME GMTOFF RULES FORMAT [UNTIL] From owner-freebsd-current Mon Apr 1 15:09:05 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA10478 for current-outgoing; Mon, 1 Apr 1996 15:09:05 -0800 (PST) Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id PAA10473 for ; Mon, 1 Apr 1996 15:09:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by Root.COM (8.7.5/8.6.5) with SMTP id PAA10081; Mon, 1 Apr 1996 15:09:23 -0800 (PST) Message-Id: <199604012309.PAA10081@Root.COM> X-Authentication-Warning: implode.Root.COM: Host localhost [127.0.0.1] didn't use HELO protocol To: Bruce Evans cc: freebsd-current@freefall.freebsd.org, kuku@gilberto.physik.rwth-aachen.de Subject: Re: calcru: negative time: From: David Greenman Reply-To: davidg@Root.COM Date: Mon, 01 Apr 1996 15:09:22 -0800 Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >>>[deleted] >>>calcru: negative time: -11929 usec >>>calcru: negative time: -3909 usec >>>calcru: negative time: -3842 usec >>>calcru: negative time: -17709 usec >>>calcru: negative time: -3480 usec >> >>This is caused by hardclock() interrupt latency. The problem is >>especially noticable on i586's and i686's because any latency causes the >>clock to go backwards; on i386's and i486's, the latency must be > 1 >>clock tick (10000 usec) to cause problems. Normally the latency on >>i586's is > 0 but < 10 usec and isn't detectable. There must be bugs >>elsewhere to cause latencies of more than a few tens of usecs. > > I'm not convinced that this is a latency problem. The problem has suddenly >gotten about 1000 times worse earlier today on both -current and -stable >simultaneously...and it's not due to any code changes or load changes. I saw >the problem on machines ranging from wcarchive to my X terminal (which is I'd like to also add that regardless of latency, there's only one word that can describe a clock going backwards: broken. This simply shouldn't happen, ever, and should be fixed. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-current Mon Apr 1 16:33:37 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA16502 for current-outgoing; Mon, 1 Apr 1996 16:33:37 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id QAA16497 for ; Mon, 1 Apr 1996 16:33:34 -0800 (PST) Received: from palmer.demon.co.uk (palmer.demon.co.uk [158.152.50.150]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id QAA22798 for ; Mon, 1 Apr 1996 16:33:26 -0800 Received: from localhost (localhost [127.0.0.1]) by palmer.demon.co.uk (8.7.5/8.6.11) with SMTP id BAA03280 for ; Tue, 2 Apr 1996 01:31:59 +0100 (BST) To: FreeBSD-Current From: "Gary Palmer" Subject: Linker sets & structures for networking code Date: Tue, 02 Apr 1996 01:31:58 +0100 Message-ID: <3278.828405118@palmer.demon.co.uk> Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi There seems to be something fundamentally WRONG in some of the networking stuff which I'm not sure how to fix. (I'm going through LINT trying to fix as many warnings as I can). People have noticed warnings like: ../../kern/uipc_proto.c:62: warning: initialization from incompatible pointer type If you look, the error is part of this structure: static struct protosw localsw[] = { [snip snip] { 0, 0, 0, 0, raw_input, 0, raw_ctlinput, 0, raw_usrreq, raw_init, 0, 0, 0, } }; (the error comes from the `raw_input' initialiser); /sys/sys/protosw.h defines the input field to be: void (*pr_input) __P((struct mbuf *, int len)); raw_input is prototyped as: void raw_input __P((struct mbuf *, struct sockproto *, struct sockaddr *, struct sockaddr *)); /sys/net/raw_usrreq.c says: void raw_input(m0, proto, src, dst) struct mbuf *m0; register struct sockproto *proto; struct sockaddr *src, *dst; { register struct rawcb *rp; register struct mbuf *m = m0; register int sockets = 0; struct socket *last; last = 0; for (rp = rawcb.rcb_next; rp != &rawcb; rp = rp->rcb_next) { if (rp->rcb_proto.sp_family != proto->sp_family) continue; So if raw_input is called with the parameters as defined by (*pr_input), the first thing it does is pull a pile of garbage off the stack. Which brings me to another problem with this code. The first field of the `protosw' structure is: short pr_type; /* socket type used for */ Which (if I understand the way this works right - I haven't been able to backtrack through the networking code enough to verify this) is used to match the requested protocol type against available protocol types. Since (in uipc_proto.c) pr_type for the raw_* stuff is declared as `0', I can't see how raw_input ever gets call via the localsw array. (Infact there are several examples of `raw_input' being called which bypasses localsw totally). So why on earth is it there?!? Of course, that is just a warm up for this: ../../netinet/in_proto.c:96: warning: initialization from incompatible pointer type ../../netinet/in_proto.c:112: warning: initialization from incompatible pointer type ../../netinet/in_proto.c:117: warning: initialization from incompatible pointer type ../../netinet/in_proto.c:121: warning: initialization from incompatible pointer type ../../netinet/in_proto.c:126: warning: initialization from incompatible pointer type ../../netinet/in_proto.c:131: warning: initialization from incompatible pointer type ../../netinet/in_proto.c:152: warning: initialization from incompatible pointer type ../../netinet/in_proto.c:152: warning: initialization from incompatible pointer type ../../netinet/in_proto.c:166: warning: initialization from incompatible pointer type Which is a lot of the same :( Gary From owner-freebsd-current Mon Apr 1 16:51:00 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA17672 for current-outgoing; Mon, 1 Apr 1996 16:51:00 -0800 (PST) Received: from palmer.demon.co.uk (palmer.demon.co.uk [158.152.50.150]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id QAA17666 for ; Mon, 1 Apr 1996 16:50:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by palmer.demon.co.uk (8.7.5/8.6.11) with SMTP id BAA03553 ; Tue, 2 Apr 1996 01:50:08 +0100 (BST) To: "Marc G. Fournier" cc: current@FreeBSD.ORG From: "Gary Palmer" Subject: Re: disabling -O for kernel In-reply-to: Your message of "Mon, 01 Apr 1996 15:33:16 CDT." Date: Tue, 02 Apr 1996 01:50:06 +0100 Message-ID: <3551.828406206@palmer.demon.co.uk> Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk "Marc G. Fournier" wrote in message ID : > Exactly *where* do I disable -O from? I've just modified > /usr/src/sys/compile//Makefile to get rid of it, but as soon as I > do another config, its going to put it back in again, so where exactly > do I disable it so that when I do do a config, it doesn't put it > in again? Two places: /etc/make.conf can define local options using `COPTFLAGS', else /sys/i386/conf/Makefile.i386 defines it to be `-O'. Gary From owner-freebsd-current Mon Apr 1 17:04:16 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA18806 for current-outgoing; Mon, 1 Apr 1996 17:04:16 -0800 (PST) Received: from pegasus.isr.uc.pt (pegasus.isr.uc.pt [193.136.230.60]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id RAA18800 for ; Mon, 1 Apr 1996 17:04:12 -0800 (PST) Received: from pioneer (pioneer.isr.uc.pt) by pegasus.isr.uc.pt (5.x/SMI-SVR4) id AA02850; Tue, 2 Apr 1996 01:59:29 +0100 Date: Mon, 1 Apr 1996 23:34:19 +0100 (WET DST) From: Paulo Menezes X-Sender: paulo@pioneer To: current@FreeBSD.ORG Subject: localtime needs changes for Portugal Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Date: Tue, 2 Apr 1996 02:04:04 +0100 (WET DST) Resent-From: Paulo Menezes Resent-To: freebsd-current@FreeBSD.ORG Resent-Message-Id: Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, Yesterday we did not adjust our watches and VCR's as usual :-) but our UN*X systems did !! This because we changed our timezone from MET to WET... Were you have the patch to the europe file that was distributed with 2.1R regards, Paulo -------------- *** europe.old Mon Apr 1 23:20:51 1996 --- europe Mon Apr 1 23:19:12 1996 *************** *** 1718,1724 **** # From Rui Pedro Salgueiro (November 12, 1992): # Portugal has recently (September, 27) changed timezone # (from WET to MET or CET) to harmonize with EEC. ! 1:00 EC MET%s # We don't know what happened to Madeira or the Azores, # so we'll just use Shanks for now. # Zone NAME GMTOFF RULES FORMAT [UNTIL] --- 1718,1725 ---- # From Rui Pedro Salgueiro (November 12, 1992): # Portugal has recently (September, 27) changed timezone # (from WET to MET or CET) to harmonize with EEC. ! 1:00 EC MET%s 1996 Mar 31 2:00s ! 0:00 EC WET%s # We don't know what happened to Madeira or the Azores, # so we'll just use Shanks for now. # Zone NAME GMTOFF RULES FORMAT [UNTIL] From owner-freebsd-current Mon Apr 1 17:18:21 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA19811 for current-outgoing; Mon, 1 Apr 1996 17:18:21 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id RAA19697 for ; Mon, 1 Apr 1996 17:16:02 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id LAA08742; Tue, 2 Apr 1996 11:07:45 +0930 From: Michael Smith Message-Id: <199604020137.LAA08742@genesis.atrad.adelaide.edu.au> Subject: Re: Advice/Recommendation needed To: scrappy@ki.net (Marc G. Fournier) Date: Tue, 2 Apr 1996 11:07:44 +0930 (CST) Cc: current@FreeBSD.org In-Reply-To: from "Marc G. Fournier" at Apr 1, 96 11:22:00 am MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Marc G. Fournier stands accused of saying: > > Main thing to consider is that I have a partner that is against > FreeBSD (cause its free) and would like to get our main server as rock-solid > as possible so that she can't use instability as an argument against me :( Stick with -stable. > Marc G. Fournier | POP Mail Telnet Acct DNS Hosting -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[ From owner-freebsd-current Mon Apr 1 17:25:43 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA20521 for current-outgoing; Mon, 1 Apr 1996 17:25:43 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id RAA20515 for ; Mon, 1 Apr 1996 17:25:41 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id SAA14932; Mon, 1 Apr 1996 18:22:11 -0700 From: Terry Lambert Message-Id: <199604020122.SAA14932@phaeton.artisoft.com> Subject: Re: Advice/Recommendation needed To: cat@ghost.uunet.ca (Cat Okita) Date: Mon, 1 Apr 1996 18:22:11 -0700 (MST) Cc: current@freebsd.org In-Reply-To: from "Cat Okita" at Apr 1, 96 02:39: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-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Marc writes: > > Main thing to consider is that I have a partner that is against > > FreeBSD (cause its free) and would like to get our main server as rock-solid > > as possible so that she can't use instability as an argument against me :( > > ...and his partner responds: > > It's not the stability/lack thereof (although running a production environment > on the latest and greatest always makes me nervous - couldn't possibly > imagine why...). Much of my quibble has to do with responsiblity and > support. > > I *need* to know that I've got a support contract for the OS, and have > someone to hang out the window if things aren't working. (Hell - someone > to sue, if it comes to that). I've never really fully understood this argument; oh sure, if you were going to install lots of commercial packages yourself, and were likely to call for support on the install process, I could see it. I could also see it if you were installing mission critical commercial software and didn't want to use a compatability mode (validation suite and vendor support availability for third party packages, among other reasons: why "there's a BSDI version" or "there's an SCO version" isn't a good enough answer). But: "...Implied fitness or merchantability..." I think the best you can get is your money back. I have not seen a successful suit. I have seen a threat of a suit kick an otherwise abominable support staff into action, though this is rare. It depends on how much it would cost them to support you vs. how much it would cost them to give you the money back. I believe the break-even on Solaris is 2.6 support calls, so you can get your money back on the third call on your insolvable problem. Generally, they have a 3-6 month lead wherein they try to fix all outstanding problems (or reclassify them as non-problems). So say 3-6 months an 3 phone calls until you are back where you started. > Free OS's are a wonderful thing - they let people use UNIX that might never > otherwise be able to afford to do so; they offer source so that people can > learn about how things work...but they don't offer a place for the buck to > stop. The point for me is the ability to do research and share the results, and source availability. If you are a commercial shop with MIS, and no available programmer, then commercial becomes much more attractive. 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 Apr 1 17:45:50 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA21978 for current-outgoing; Mon, 1 Apr 1996 17:45:50 -0800 (PST) Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id RAA21972 Mon, 1 Apr 1996 17:45:46 -0800 (PST) Received: by sequent.kiae.su id AA01094 (5.65.kiae-2 ); Tue, 2 Apr 1996 04:39:10 +0300 Received: by sequent.KIAE.su (UUMAIL/2.0); Tue, 2 Apr 96 04:39:09 +0300 Received: (from ache@localhost) by astral.msk.su (8.7.5/8.7.3) id FAA02523; Tue, 2 Apr 1996 05:38:49 +0400 (MSD) Message-Id: <199604020138.FAA02523@astral.msk.su> Subject: Probably -current tzsetup & sysinstall conflict To: current@freebsd.org (FreeBSD-current) Date: Tue, 2 Apr 1996 05:38:49 +0400 (MSD) Cc: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch), jkh@freebsd.org (Jordan Hubbard) From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast X-Mailer: ELM [version 2.4ME+ PL14 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I notice that tzsetup called from sysinstall. I also notice that -current tzsetup uses "install" program to install localtime. The question: is "install" available for sysinstall too? If not things are broken... -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-current Mon Apr 1 18:00:57 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA23322 for current-outgoing; Mon, 1 Apr 1996 18:00:57 -0800 (PST) Received: from ki.net (root@ki.net [205.150.102.1]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id SAA23313 for ; Mon, 1 Apr 1996 18:00:54 -0800 (PST) Received: from localhost (scrappy@localhost) by ki.net (8.7.4/8.7.4) with SMTP id VAA11715; Mon, 1 Apr 1996 21:01:02 -0500 (EST) Date: Mon, 1 Apr 1996 21:00:59 -0500 (EST) From: "Marc G. Fournier" To: Cat Okita cc: current@freebsd.org Subject: Re: Advice/Recommendation needed In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 1 Apr 1996, Cat Okita wrote: > > Marc writes: > > Main thing to consider is that I have a partner that is against > > FreeBSD (cause its free) and would like to get our main server as rock-solid > > as possible so that she can't use instability as an argument against me :( > > ...and his partner responds: > *Ack* *grin* Marc G. Fournier | POP Mail Telnet Acct DNS Hosting System | WWW Services Database Services | Knowledge, Administrator | | Information and scrappy@ki.net | WWW: http://www.ki.net | Communications, Inc From owner-freebsd-current Mon Apr 1 18:10:11 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA24382 for current-outgoing; Mon, 1 Apr 1996 18:10:11 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id SAA24310 for ; Mon, 1 Apr 1996 18:09:58 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id MAA09482; Tue, 2 Apr 1996 12:01:39 +0930 From: Michael Smith Message-Id: <199604020231.MAA09482@genesis.atrad.adelaide.edu.au> Subject: Re: Advice/Recommendation needed To: cat@ghost.uunet.ca (Cat Okita) Date: Tue, 2 Apr 1996 12:01:39 +0930 (CST) Cc: current@FreeBSD.org In-Reply-To: from "Cat Okita" at Apr 1, 96 02:39:56 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Cat Okita stands accused of saying: > > I *need* to know that I've got a support contract for the OS, and have > someone to hang out the window if things aren't working. (Hell - someone > to sue, if it comes to that). Heh. You should read your support contracts more carefully, unless you're spending _large_ sums of money on them, you _still_ don't have anyone to 'hang out the window' at the end of the day. And as for someone to sue - I can't imagine a vendor offering a contract that would make them vulnerable to that sort of abuse. 8) If having a team of trained monkeys paid to try to understand your problem lets you sleep at night, that's wonderful. Don't insult us by suggesting that any of the major vendors are any quicker at identifying or responding to faults in their code than any of the 'serious' free operating systems. > Free OS's are a wonderful thing - they let people use UNIX that > might never otherwise be able to afford to do so; they offer source > so that people can learn about how things work...but they don't > offer a place for the buck to stop. Er, yes they do. It stops with _you_. For a lot of us, that's just fine; I spend too much of my time second-guessing flaws in commercial software - having the source means I can find and fix them and then _get_on_with_my_business_ - something that would be totally impossible if I was at the mercy of a vendor. Sure, it's not for everyone, but there _are_ reasons to avoid the McDonalds mentality, and for those that can cook, the alternatives are pleasantly refreshing 8) > Cat -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[ From owner-freebsd-current Mon Apr 1 18:31:24 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA25560 for current-outgoing; Mon, 1 Apr 1996 18:31:24 -0800 (PST) Received: from mail.think.com (Mail1.Think.COM [131.239.33.245]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id SAA25555 for ; Mon, 1 Apr 1996 18:31:20 -0800 (PST) Received: from Early-Bird-1.Think.COM by mail.think.com; Mon, 1 Apr 96 21:30:35 -0500 Received: from compound (fergus-26.dialup.cfa.org) by Early-Bird.Think.COM; Mon, 1 Apr 96 21:30:32 EST Received: (from alk@localhost) by compound (8.6.12/8.6.112) id UAA09715; Mon, 1 Apr 1996 20:32:13 -0600 Date: Mon, 1 Apr 1996 20:32:13 -0600 Message-Id: <199604020232.UAA09715@compound> From: Tony Kimball To: cat@ghost.uunet.ca Cc: current@freefall.freebsd.org Subject: Re: Advice/Recommendation needed Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Free OS's are a wonderful thing ...but they don't offer a place for the buck to stop. Ah but they do: It stops with you. If you want to pay someone else to take the buck, that's your gig, but I'd take care to get your money's worth, because I don't know of any commercial OS that actually gets supported in small installations. If you don't have a 7 digit contract in the future, my experience has been that a source license is worth something, but a support contract is not. Hardware is another matter. Hardware support contracts are generally worth the money. Software is a joke, because they can't fix it in time for the fix to matter, because they have a whole dev cycle of latency between your problem and your solution. You get the source and you fix it yourself. Same as FreeBSD, same as Linux, same as IRIX or Solaris or SVR4. Besides which, commercial/freeware is irrelevant to specifying the solution to a fixed and well-specified problem. If the software works, it works, now and forever. Change the problem and the range of software solutions appropriate to the problem may change. That's when you will find that you need the source. I'd find some humor in seeing you sue IBM for a bug in AIX. Unless you have a contract that specifies that the bug in question does not exist or will be remedied within some specified trimeframe. And like I said, you're not going to get such a contract without some seriously deep pockets. Frankly, I think your reasoning is erroneous. Your conclusion may be correct -- I don't have any insight into the nature of your problem upon which to base any speculation -- but not the stated justifications. From owner-freebsd-current Mon Apr 1 19:47:13 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id TAA29966 for current-outgoing; Mon, 1 Apr 1996 19:47:13 -0800 (PST) Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id TAA29941 for ; Mon, 1 Apr 1996 19:47:05 -0800 (PST) Received: (from julian@localhost) by ref.tfs.com (8.7.3/8.6.9) id PAA05402; Mon, 1 Apr 1996 15:04:12 -0800 (PST) Message-Id: <199604012304.PAA05402@ref.tfs.com> Subject: Re: Advice/Recommendation needed To: cat@ghost.uunet.ca (Cat Okita) Date: Mon, 1 Apr 1996 15:04:11 -0800 (PST) From: "JULIAN Elischer" Cc: current@freebsd.org In-Reply-To: from "Cat Okita" at Apr 1, 96 02:39:56 pm X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Oh I forgot..... > someone to hang out the window if things aren't working. (Hell - someone > to sue, if it comes to that). (*) > > Free OS's are a wonderful thing - they let people use UNIX that might never > otherwise be able to afford to do so; they offer source so that people can > learn about how things work...but they don't offer a place for the buck to stop. (*) what a depressingly american attitude.. offered the oportunity to control your own destiny, the answer is "sorry I don't want the responsibility.. I'd rather be able top blame some-one else.. unfortunatly we're seeing more and more of this elsewhere in the world too.. julian > From owner-freebsd-current Mon Apr 1 19:47:14 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id TAA29974 for current-outgoing; Mon, 1 Apr 1996 19:47:14 -0800 (PST) Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id TAA29955 for ; Mon, 1 Apr 1996 19:47:09 -0800 (PST) Received: (from julian@localhost) by ref.tfs.com (8.7.3/8.6.9) id OAA05385; Mon, 1 Apr 1996 14:59:02 -0800 (PST) Message-Id: <199604012259.OAA05385@ref.tfs.com> Subject: Re: Advice/Recommendation needed To: cat@ghost.uunet.ca (Cat Okita) Date: Mon, 1 Apr 1996 14:59:02 -0800 (PST) From: "JULIAN Elischer" Cc: current@freebsd.org In-Reply-To: from "Cat Okita" at Apr 1, 96 02:39:56 pm X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'm involved with three companies that are using BSD as integral parts of high-end systems (as a non-customer-visible compnent) or in embedded products. in each case the decision has been that the support available from the vendors is not timely enough or reliable enough for the systems in question.. (in some cases processing 100's of millions of dollars per day) and the large number of people familair with the inside of BSD, and the fact that the sources are easily available lead to the oppposite conclusion to that you draw. The general experience has been that companies such as SUN and HP are very unresponsive to unexpected problems (we waited for 2 months before SUN would admit a problem exeisted recently) and that their beaurocracy simply serves to wear-down the customer until only the persistant are left.. BSD in it's various forms has allowed us to create systems that could easily be tailored to the task at hand with the ultimate in "warm fuzzy feelings.." the source code, and am email alias with hundreds of people who can give productive advice on what ever your problem might be.. These companies I mention are not always small fry.. you'd be surprised at where BSD turns up... to recap.. we've found we get better response by using FreeBSD and friends, than by trusting SUN and HP to hold our hands.. If we had commercial packages in greater abundance, it would be perfect.. > > > Marc writes: > > Main thing to consider is that I have a partner that is against > > FreeBSD (cause its free) and would like to get our main server as rock-solid > > as possible so that she can't use instability as an argument against me :( > > ...and his partner responds: > > It's not the stability/lack thereof (although running a production environment > on the latest and greatest always makes me nervous - couldn't possibly > imagine why...). Much of my quibble has to do with responsiblity and > support. > > I *need* to know that I've got a support contract for the OS, and have > someone to hang out the window if things aren't working. (Hell - someone > to sue, if it comes to that). > > Free OS's are a wonderful thing - they let people use UNIX that might never > otherwise be able to afford to do so; they offer source so that people can > learn about how things work...but they don't offer a place for the buck to stop. > > Cat > From owner-freebsd-current Mon Apr 1 19:47:21 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id TAA00110 for current-outgoing; Mon, 1 Apr 1996 19:47:21 -0800 (PST) Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id TAA29962 for ; Mon, 1 Apr 1996 19:47:13 -0800 (PST) Received: (from julian@localhost) by ref.tfs.com (8.7.3/8.6.9) id MAA04976; Mon, 1 Apr 1996 12:01:45 -0800 (PST) Message-Id: <199604012001.MAA04976@ref.tfs.com> Subject: Re: ed_start() bug...more information To: scrappy@ki.net (Marc G. Fournier) Date: Mon, 1 Apr 1996 12:01:45 -0800 (PST) From: "JULIAN Elischer" Cc: current@freebsd.org In-Reply-To: from "Marc G. Fournier" at Apr 1, 96 01:43:28 pm X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Ok, I can't see a reason for the trap.. [...] > #17 0xf01a483f in trap (frame={tf_es = -267190256, tf_ds = -266534896, > tf_edi = -267583428, tf_esi = -266477172, tf_ebp = -266560020, > tf_isp = -266560076, tf_ebx = 656, tf_edx = 662, tf_ecx = 662, > tf_eax = -267583488, tf_trapno = 12, tf_err = -266665984, > tf_eip = -266652479, tf_cs = -267583480, tf_eflags = 66134, > tf_esp = -1073610752, tf_ss = -258322176}) at ../../i386/i386/trap.c:319 > #18 0xf019d1b1 in calltrap () > #19 0xf01387d5 in ether_output (ifp=0xf01de18c, m0=0xf09a5100, dst=0xf09c5d70, > rt0=0xf099ab00) at ../../net/if_ethersubr.c:307 > #20 0xf0141ee1 in ip_output (m0=0xf09a5100, opt=0x0, ro=0xf09b5d2c, flags=0, [...] > (kgdb) frame frame->tf_ebp frame->tf_eip > #0 ed_start (ifp=0xf01de18c) at ../../i386/isa/if_ed.c:1744 > 1744 outb(sc->nic_addr + ED_P0_CR, sc->cr_proto | ED_CR_TXP | ED_CR_STA); > (kgdb) list > 1739 outb(sc->nic_addr + ED_P0_TBCR1, len >> 8); > 1740 > 1741 /* > 1742 * Set page 0, Remote DMA complete, Transmit Packet, and *Start* > 1743 */ > 1744 outb(sc->nic_addr + ED_P0_CR, sc->cr_proto | ED_CR_TXP | ED_CR_STA); eh? sc seems ok, so what else could be needed? maybe the optimisation is catching us... maybe we're actually on the next line or somewhere else nearby.. remember that -O and -g together give a result that is ok MOSTof the time, but CAN be 'only approximate' some times.... if you can compile if_ed.c without the -O it might be worth it... > 1745 sc->xmit_busy = 1; > 1746 > 1747 /* > 1748 * Point to next transmit buffer slot and wrap if necessary. > (kgdb) print sc > $1 = (struct ed_softc *) 0xf0905000 > (kgdb) print sc->nic_addr > $2 = 61575 looks fine to me.... julian From owner-freebsd-current Mon Apr 1 20:35:23 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id UAA03819 for current-outgoing; Mon, 1 Apr 1996 20:35:23 -0800 (PST) Received: from ki.net (root@ki.net [205.150.102.1]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id UAA03810 for ; Mon, 1 Apr 1996 20:35:17 -0800 (PST) Received: from localhost (scrappy@localhost) by ki.net (8.7.4/8.7.4) with SMTP id XAA14765 for ; Mon, 1 Apr 1996 23:35:30 -0500 (EST) Date: Mon, 1 Apr 1996 23:35:29 -0500 (EST) From: "Marc G. Fournier" To: current@freebsd.org Subject: SCSI_2_DEF? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi... Just looking through LINT, and saw the options SCSI_2_DEF at the very bottom, but no description of what it does... So, what does it do? :) Marc G. Fournier | POP Mail Telnet Acct DNS Hosting System | WWW Services Database Services | Knowledge, Administrator | | Information and scrappy@ki.net | WWW: http://www.ki.net | Communications, Inc From owner-freebsd-current Tue Apr 2 00:13:39 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA19281 for current-outgoing; Tue, 2 Apr 1996 00:13:39 -0800 (PST) Received: from lassie.eunet.fi (lassie.eunet.fi [192.26.119.7]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id AAA19252 for ; Tue, 2 Apr 1996 00:13:32 -0800 (PST) Received: from key.hole.fi by lassie.eunet.fi with SMTP id AA19011 (5.67a/IDA-1.5 for ); Tue, 2 Apr 1996 11:13:28 +0300 Received: (from count@localhost) by key.hole.fi (8.7.4/8.6.12) id LAA04262; Tue, 2 Apr 1996 11:13:27 +0300 (EET DST) From: "Bror 'Count' Heinola" Message-Id: <199604020813.LAA04262@key.hole.fi> Subject: Re: Fixit Floppy Broken? To: joerg_wunsch@uriah.heep.sax.de Date: Tue, 2 Apr 1996 11:13:27 +0300 (EET DST) Cc: freebsd-current@freebsd.org In-Reply-To: <199603311902.VAA00526@uriah.heep.sax.de> from "J Wunsch" at Mar 31, 96 09:02:40 pm X-Mailer: ELM [version 2.4 PL24alpha5] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk J Wunsch taisi sanoa: > > Filing a PR won't help very much. The floppy driver is in bad need > for a rewrite. > > If you're willing to rewrite it, and submitting PRs would accelerate > this process, i could immediately submit half a dozen PRs for it. :-) Hey, couldn't 'we' use the magnificent dancing and whistling fd driver made by Jesus Monroy Jr. ? :-) -- Bror 'Count' Heinola % count@key.hole.fi % http://pobox.com/~count/ Pengerkatu 13b A5 % IRC: Count NIC: BH271 % FI-00530 HELSINKI % Work: bror@sms.fi % Roads? Where we're going, Cell: +358-40-5533-554 % Santa Monica Software % we don't need roads. From owner-freebsd-current Tue Apr 2 00:14:14 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA19349 for current-outgoing; Tue, 2 Apr 1996 00:14:14 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id AAA19343 for ; Tue, 2 Apr 1996 00:14:12 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0u40G5-0003wrC; Mon, 1 Apr 96 23:12 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id GAA01367; Tue, 2 Apr 1996 06:15:42 GMT X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: Cat Okita cc: current@FreeBSD.org Subject: Re: Advice/Recommendation needed In-reply-to: Your message of "Mon, 01 Apr 1996 14:39:56 EST." Date: Tue, 02 Apr 1996 06:15:40 +0000 Message-ID: <1365.828425740@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > I *need* to know that I've got a support contract for the OS, and have > someone to hang out the window if things aren't working. (Hell - someone > to sue, if it comes to that). Tell me how much you think would be reasonable for a support contract, and I'll consider taking the job. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Tue Apr 2 00:14:17 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA19368 for current-outgoing; Tue, 2 Apr 1996 00:14:17 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id AAA19357 for ; Tue, 2 Apr 1996 00:14:14 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0u40G8-0003xKC; Mon, 1 Apr 96 23:12 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id GAA01407; Tue, 2 Apr 1996 06:18:49 GMT X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: "Marc G. Fournier" cc: current@FreeBSD.org Subject: Re: disabling -O for kernel In-reply-to: Your message of "Mon, 01 Apr 1996 15:33:16 EST." Date: Tue, 02 Apr 1996 06:18:48 +0000 Message-ID: <1405.828425928@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > Hi... > > Exactly *where* do I disable -O from? I've just modified > /usr/src/sys/compile//Makefile to get rid of it, but as soon as I > do another config, its going to put it back in again, so where exactly > do I disable it so that when I do do a config, it doesn't put it > in again? > > I've checked /usr/share/mk...but none in there look like what > I'm looking for. /etc/make.conf -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Tue Apr 2 00:16:49 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA19562 for current-outgoing; Tue, 2 Apr 1996 00:16:49 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id AAA19553 for ; Tue, 2 Apr 1996 00:16:46 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0u40GH-0003xPC; Mon, 1 Apr 96 23:12 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id FAA01217; Tue, 2 Apr 1996 05:56:24 GMT X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: Bruce Evans cc: freebsd-current@freefall.freebsd.org, kuku@gilberto.physik.rwth-aachen.de Subject: Re: calcru: negative time: In-reply-to: Your message of "Tue, 02 Apr 1996 04:24:37 +1000." <199604011824.EAA32194@godzilla.zeta.org.au> Date: Tue, 02 Apr 1996 05:56:21 +0000 Message-ID: <1215.828424581@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >> >[deleted] > >> >calcru: negative time: -11929 usec > >> ... > >> This is caused by hardclock() interrupt latency. The problem is > >> ... > > >My i386 has really high numbers here. > > Highly negative numbers? They can't go more than 10000 usec negative > on i386's due to the causes that I know about. Generally in the ~5000 range (+/-3000) and occasionally >>10000. > >Could this be a spl > Probably a splhigh botch. It seems to be connected to fork/exec on my mach. How about ESDI disks, could they monopolize the cpu on slow systems ? -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Tue Apr 2 02:53:26 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA04832 for current-outgoing; Tue, 2 Apr 1996 02:53:26 -0800 (PST) Received: from MediaCity.com (root@easy1.mediacity.com [205.216.172.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id CAA04826 for ; Tue, 2 Apr 1996 02:53:25 -0800 (PST) Received: (from brian@localhost) by MediaCity.com (8.6.11/8.6.9) id CAA07912; Tue, 2 Apr 1996 02:58:25 -0800 From: Brian Litzinger Message-Id: <199604021058.CAA07912@MediaCity.com> Subject: Re: Advice/Recommendation needed To: cat@ghost.uunet.ca (Cat Okita) Date: Tue, 2 Apr 1996 02:58:24 -0800 (PST) Cc: current@freebsd.org In-Reply-To: from Cat Okita at "Apr 1, 96 02:39:56 pm" Reply-To: brian@MediaCity.com X-Mailer: ELM [version 2.4ME+ PL11 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Cat Okita wrote: > I *need* to know that I've got a support contract for the OS, and have > someone to hang out the window if things aren't working. (Hell - someone > to sue, if it comes to that). I've always considered it more important to have a working OS, than to have someone to blame for a lack thereof. -- Brian Litzinger From owner-freebsd-current Tue Apr 2 03:23:59 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA06976 for current-outgoing; Tue, 2 Apr 1996 03:23:59 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id DAA06951 for ; Tue, 2 Apr 1996 03:23:38 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id VAA10642; Tue, 2 Apr 1996 21:18:01 +1000 Date: Tue, 2 Apr 1996 21:18:01 +1000 From: Bruce Evans Message-Id: <199604021118.VAA10642@godzilla.zeta.org.au> To: bde@zeta.org.au, phk@critter.tfs.com Subject: Re: calcru: negative time: Cc: freebsd-current@freefall.freebsd.org, kuku@gilberto.physik.rwth-aachen.de Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> >My i386 has really high numbers here. >> >> Highly negative numbers? They can't go more than 10000 usec negative >> on i386's due to the causes that I know about. >Generally in the ~5000 range (+/-3000) and occasionally >>10000. I think 5000 means that you missed a whole clock interrupt. E.g.: actual time event reported time comments 0 Xintr0() 10 hardclock() 9000 splhigh() 10000 Xintr0() sets ipending bit for intr0 19000 microtime() 19000 no problem yet 20000 Xintr0() oops, missed a whole intr0 24000 microtime() 14000 oops 25000 splx() 25005 hardclock() 26000 microtime() 16000 oops Another possibility is that TIMER0_LATCH_COUNT = 20 is too small. Now I'm worried that it is too small if there are bus-hogging DMA controllers. My U34F seems to cause a maximum latency of > 160 usec. siointr() can also cause a latency of a few hundred usec if there multiple active lines. TIMER0_LATCH_COUNT should be smaller than 62.5 for operation at 16Khz (used by pcaudio). Perhaps the correct fix is to drop support for pcaudio. >It seems to be connected to fork/exec on my mach. It (actually failing of a more complete test in mi_switch()) seems to be connected with doing a bunch of disk accesses after the system has been idle for some time. I suspect vm. I didn't like changing splimp() in vm to splhigh(). I turned off my i586 clock fixup code in hardclock() and got the expected reports from test code in hardclock() about negative microtime deltas. The worst case over a period of 8 hours was -37 usec. This normally isn't a problem because microtime() calls are normally separated by more than 37 usec. >How about ESDI disks, could they monopolize the cpu on slow systems ? The could only monopolize the cpu, not the clock. The worst case is if wdstrategy() is called at splhigh() (it shouldn't be) and writes 16 (?) 512-byte sectors in 2 ms to 4ms. After doing the initial transfer it can only be called at splbio() when it can't hurt the clock. Bruce From owner-freebsd-current Tue Apr 2 03:39:26 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA08134 for current-outgoing; Tue, 2 Apr 1996 03:39:26 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id DAA08115 Tue, 2 Apr 1996 03:39:10 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id VAA11042; Tue, 2 Apr 1996 21:27:47 +1000 Date: Tue, 2 Apr 1996 21:27:47 +1000 From: Bruce Evans Message-Id: <199604021127.VAA11042@godzilla.zeta.org.au> To: FreeBSD-Current@freebsd.org, gpalmer@freebsd.org Subject: Re: Linker sets & structures for networking code Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >There seems to be something fundamentally WRONG in some of the >networking stuff which I'm not sure how to fix. (I'm going through >LINT trying to fix as many warnings as I can). >People have noticed warnings like: >../../kern/uipc_proto.c:62: warning: initialization from incompatible pointer type This is because of bad type puns in ancient (pre-STDC) networking code. It has nothing to do with linker sets. The correct fix isn't obvious. Many incorrect fixes are obvious :-). E.g., cast away the warnings. >... >Which brings me to another problem with this code. The first field of >the `protosw' structure is: > short pr_type; /* socket type used for */ >Which (if I understand the way this works right - I haven't been able >to backtrack through the networking code enough to verify this) is >used to match the requested protocol type against available protocol >types. Since (in uipc_proto.c) pr_type for the raw_* stuff is declared >as `0', I can't see how raw_input ever gets call via the localsw >array. (Infact there are several examples of `raw_input' being called >which bypasses localsw totally). So why on earth is it there?!? I didn't attempt to fix it because I don't completely understand the calling sequences, in particular this point. I think some of the functions in the switches are only accessed through the switches for protocols that we don't support. Bruce From owner-freebsd-current Tue Apr 2 04:11:34 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA11256 for current-outgoing; Tue, 2 Apr 1996 04:11:34 -0800 (PST) Received: from mail.rwth-aachen.de (mail.RWTH-Aachen.DE [137.226.144.9]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id EAA11249 for ; Tue, 2 Apr 1996 04:11:28 -0800 (PST) Received: from gilberto.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de) by mail.rwth-aachen.de (PMDF V5.0-4 #13110) id <01I3296LPJV40000X2@mail.rwth-aachen.de> for freebsd-current@freefall.FreeBSD.org; Tue, 02 Apr 1996 10:08:27 +0100 Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.6.11/8.6.9) id KAA07931 for freebsd-current@freefall.cdrom.com; Tue, 02 Apr 1996 10:15:08 +0200 Date: Tue, 02 Apr 1996 10:15:08 +0200 From: "Christoph P. Kukulies" Subject: Huh? cc1 text file busy? To: freebsd-current@freefall.FreeBSD.org Message-id: <199604020815.KAA07931@gilberto.physik.rwth-aachen.de> Content-transfer-encoding: 7BIT Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I'm building a -current world and in parallel I wanted to build a kernel on that same machine. This is what I suddenly got: Ouch, lost the paste buffer, anyway, make stopped saying something like: /usr/libexec/cc1: text file busy *** Error code 1 --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-current Tue Apr 2 04:23:18 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA13948 for current-outgoing; Tue, 2 Apr 1996 04:23:18 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id EAA13929 Tue, 2 Apr 1996 04:23:13 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0u4579-0003vmC; Tue, 2 Apr 96 04:23 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id MAA02948; Tue, 2 Apr 1996 12:23:11 GMT X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: Bruce Evans cc: FreeBSD-Current@freebsd.org, gpalmer@freebsd.org Subject: Re: Linker sets & structures for networking code In-reply-to: Your message of "Tue, 02 Apr 1996 21:27:47 +1000." <199604021127.VAA11042@godzilla.zeta.org.au> Date: Tue, 02 Apr 1996 12:23:10 +0000 Message-ID: <2946.828447790@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >Which brings me to another problem with this code. The first field of > >the `protosw' structure is: > > > short pr_type; /* socket type used for */ > > >Which (if I understand the way this works right - I haven't been able > >to backtrack through the networking code enough to verify this) is > >used to match the requested protocol type against available protocol > >types. Since (in uipc_proto.c) pr_type for the raw_* stuff is declared > >as `0', I can't see how raw_input ever gets call via the localsw > >array. (Infact there are several examples of `raw_input' being called > >which bypasses localsw totally). So why on earth is it there?!? My conclusion was that it was an attempt to please the OSI powers that were, without completely wrecking the performance. I could, for all I can see, be ripped out. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Tue Apr 2 04:31:11 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA15840 for current-outgoing; Tue, 2 Apr 1996 04:31:11 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id EAA15825 for ; Tue, 2 Apr 1996 04:31:09 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0u45Ep-0003vnC; Tue, 2 Apr 96 04:31 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id MAA02974; Tue, 2 Apr 1996 12:31:07 GMT X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: Bruce Evans cc: freebsd-current@freefall.freebsd.org, kuku@gilberto.physik.rwth-aachen.de Subject: Re: calcru: negative time: In-reply-to: Your message of "Tue, 02 Apr 1996 21:18:01 +1000." <199604021118.VAA10642@godzilla.zeta.org.au> Date: Tue, 02 Apr 1996 12:31:06 +0000 Message-ID: <2972.828448266@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > actual time event reported time comments > 0 Xintr0() > 10 hardclock() > 9000 splhigh() > 10000 Xintr0() sets ipending bit for intr0 > 19000 microtime() 19000 no problem yet > 20000 Xintr0() oops, missed a whole intr0 Could we add a check for this under some suitable #ifdef ? Alternatively, could we make a check in spl*() so that if splhigh has been active >long< time we will print a warning ? -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Tue Apr 2 04:57:23 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA18985 for current-outgoing; Tue, 2 Apr 1996 04:57:23 -0800 (PST) Received: from whyy.org (jehrenkrantz@internal-gw.whyy.org [199.234.236.254]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id EAA18973 for ; Tue, 2 Apr 1996 04:57:20 -0800 (PST) Received: (from jehrenkrantz@localhost) by whyy.org (8.6.12/8.6.9) id HAA26632; Tue, 2 Apr 1996 07:57:33 -0500 Date: Tue, 2 Apr 1996 07:57:32 -0500 (EST) From: Jeff Ehrenkrantz To: Poul-Henning Kamp cc: Cat Okita , current@FreeBSD.ORG Subject: Re: Advice/Recommendation needed In-Reply-To: <1365.828425740@critter.tfs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Carefullll what you ask for Poul! I'm reminded of a frog at the end of a large runway thinking 'gee if I could only get my tongue around that big ass fly' On Tue, 2 Apr 1996, Poul-Henning Kamp wrote: > > I *need* to know that I've got a support contract for the OS, and have > > someone to hang out the window if things aren't working. (Hell - someone > > to sue, if it comes to that). > > Tell me how much you think would be reasonable for a support contract, > and I'll consider taking the job. > > -- > Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. > http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. > whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. > Future will arrive by its own means, progress not so. > From owner-freebsd-current Tue Apr 2 05:16:38 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA21132 for current-outgoing; Tue, 2 Apr 1996 05:16:38 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id FAA21125 Tue, 2 Apr 1996 05:16:36 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0u45wp-0003vrC; Tue, 2 Apr 96 05:16 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id NAA03256; Tue, 2 Apr 1996 13:16:35 GMT X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol cc: Bruce Evans , FreeBSD-Current@FreeBSD.org, gpalmer@FreeBSD.org Subject: Re: Linker sets & structures for networking code In-reply-to: Your message of "Tue, 02 Apr 1996 12:23:10 GMT." <2946.828447790@critter.tfs.com> Date: Tue, 02 Apr 1996 13:16:33 +0000 Message-ID: <3254.828450993@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > My conclusion was that it was an attempt to please the OSI powers that > were, without completely wrecking the performance. > > I could, for all I can see, be ripped out. Argh! that is >not< a freudian slip! :-) s/I/It/ -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Tue Apr 2 05:18:03 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA21249 for current-outgoing; Tue, 2 Apr 1996 05:18:03 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id FAA21244 for ; Tue, 2 Apr 1996 05:18:01 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0u45yB-0003vrC; Tue, 2 Apr 96 05:17 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id NAA03267; Tue, 2 Apr 1996 13:17:55 GMT X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: Jeff Ehrenkrantz cc: Cat Okita , current@freebsd.org Subject: Re: Advice/Recommendation needed In-reply-to: Your message of "Tue, 02 Apr 1996 07:57:32 EST." Date: Tue, 02 Apr 1996 13:17:55 +0000 Message-ID: <3265.828451075@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I do this for a living. I know what it takes. Have done that for 10+ years now. Been there, done that. Poul-Henning > Carefullll what you ask for Poul! I'm reminded of a frog at the end of a > large runway thinking 'gee if I could only get my tongue around that big ass > fly' > > On Tue, 2 Apr 1996, Poul-Henning Kamp wrote: > > > > I *need* to know that I've got a support contract for the OS, and have > > > someone to hang out the window if things aren't working. (Hell - someone > > > to sue, if it comes to that). > > > > Tell me how much you think would be reasonable for a support contract, > > and I'll consider taking the job. > > > > -- > > Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. > > http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. > > whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. > > Future will arrive by its own means, progress not so. > > -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Tue Apr 2 05:19:54 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA21387 for current-outgoing; Tue, 2 Apr 1996 05:19:54 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id FAA21382 for ; Tue, 2 Apr 1996 05:19:53 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0u45zz-0003w4C; Tue, 2 Apr 96 05:19 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id NAA03304 for ; Tue, 2 Apr 1996 13:19:53 GMT X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: current@freebsd.org Subject: make world broken Date: Tue, 02 Apr 1996 13:19:52 +0000 Message-ID: <3302.828451192@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk ===> usr.bin/calendar install -c -o bin -g bin -m 444 /usr/src/usr.bin/calendar/calendars/calendar.* /usr/share/calendar install -c -o bin -g bin -m 444 /usr/src/usr.bin/calendar/calendars/hr_HR.ISO_8859-2/calendar.* /usr/share/calendar/hr_HR.ISO_8859-2; install -c -o bin -g bin -m 444 /usr/src/usr.bin/calendar/calendars/de_DE.ISO_8859-1/calendar.* /usr/share/calendar/de_DE.ISO_8859-1; install -c -s -o bin -g bin -m 555 calendar /usr/bin install -c -o bin -g bin -m 444 calendar.1.gz /usr/share/calendar/man/man1 install: /usr/share/calendar/man/man1: No such file or directory *** Error code 71 Stop. *** Error code 1 Stop. *** Error code 1 Poul-Henning From owner-freebsd-current Tue Apr 2 05:40:46 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA23064 for current-outgoing; Tue, 2 Apr 1996 05:40:46 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id FAA23055 for ; Tue, 2 Apr 1996 05:40:40 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id XAA23396; Tue, 2 Apr 1996 23:17:57 +1000 Date: Tue, 2 Apr 1996 23:17:57 +1000 From: Bruce Evans Message-Id: <199604021317.XAA23396@godzilla.zeta.org.au> To: bde@zeta.org.au, phk@critter.tfs.com Subject: Re: calcru: negative time: Cc: freebsd-current@freefall.freebsd.org, kuku@gilberto.physik.rwth-aachen.de Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> actual time event reported time comments >> 0 Xintr0() >> 10 hardclock() >> 9000 splhigh() >> 10000 Xintr0() sets ipending bit for intr0 >> 19000 microtime() 19000 no problem yet >> 20000 Xintr0() oops, missed a whole intr0 >Could we add a check for this under some suitable #ifdef ? Oops, the second Xintr0() shouldn't be there - irq0 is masked until the interrupt is processed. If irq0 is edge triggered than it could be left unmasked so that the second irq0 is detectable, but this isn't the default and edge triggering should die when ISA dies. Thus it is only practical to detect missed clock interrupts if another clock is available. We have enough - the rtc on all systems and the tsc on i586's. I plan to compare the clocks every second or 10. This should be standard to detect drift. >Alternatively, could we make a check in spl*() so that if splhigh has been >active >long< time we will print a warning ? I plan to do this too. This should only be enabled for debugging. My current tests have been detecting lots of problems but haven't been any help for finding where the high latency comes from. The problem should be reported by stopping at a breakpoint in spl0 or in doreti before the cpl has been reduced. Then there will be a chance of seeing what set cpl high for too long. Bruce From owner-freebsd-current Tue Apr 2 05:53:51 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA23850 for current-outgoing; Tue, 2 Apr 1996 05:53:51 -0800 (PST) Received: from mail1.digital.com (mail1.digital.com [204.123.2.50]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id FAA23845 for ; Tue, 2 Apr 1996 05:53:49 -0800 (PST) From: garyj@frt.dec.com Received: from cssmuc.frt.dec.com by mail1.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA29741; Tue, 2 Apr 1996 05:49:26 -0800 Received: from localhost by cssmuc.frt.dec.com; (5.65v3.2/1.1.8.2/14Nov95-0232PM) id AA29457; Tue, 2 Apr 1996 15:49:07 +0200 Message-Id: <9604021349.AA29457@cssmuc.frt.dec.com> X-Mailer: exmh version 1.6.4 10/10/95 To: current%freebsd.org@inet-gw-1.pa.dec.com In-Reply-To: Message from "Christoph P. Kukulies" of Tue, 02 Apr 96 10:15:08 +0200. Reply-To: gjennejohn@frt.dec.com Subject: Re: Huh? cc1 text file busy? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 02 Apr 96 15:49:06 +0200 X-Mts: smtp Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk kuku@gilberto.physik.rwth-aachen.de writes: > I'm building a -current world and in parallel I wanted to build > a kernel on that same machine. This is what I suddenly got: > > Ouch, lost the paste buffer, anyway, make stopped > saying something like: > > /usr/libexec/cc1: text file busy > > *** Error code 1 > make probably tried to install the new cc1 but it was being used to compile part of the kernel. Seems like a reasonable error message to me. --- Gary Jennejohn (work) gjennejohn@frt.dec.com (home) Gary.Jennejohn@munich.netsurf.de (play) gj@freebsd.org From owner-freebsd-current Tue Apr 2 06:20:08 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA26480 for current-outgoing; Tue, 2 Apr 1996 06:20:08 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id GAA26471 for ; Tue, 2 Apr 1996 06:20:04 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0u46wE-0003vrC; Tue, 2 Apr 96 06:20 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id OAA03491; Tue, 2 Apr 1996 14:20:03 GMT X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: Bruce Evans cc: freebsd-current@freefall.freebsd.org, kuku@gilberto.physik.rwth-aachen.de Subject: Re: calcru: negative time: In-reply-to: Your message of "Tue, 02 Apr 1996 23:17:57 +1000." <199604021317.XAA23396@godzilla.zeta.org.au> Date: Tue, 02 Apr 1996 14:20:02 +0000 Message-ID: <3489.828454802@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >Alternatively, could we make a check in spl*() so that if splhigh has been > >active >long< time we will print a warning ? > > I plan to do this too. This should only be enabled for debugging. My > current tests have been detecting lots of problems but haven't been any > help for finding where the high latency comes from. The problem should > be reported by stopping at a breakpoint in spl0 or in doreti before the > cpl has been reduced. Then there will be a chance of seeing what set > cpl high for too long. Couldn't you just record the %eip in splhigh() ? -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Tue Apr 2 06:38:15 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA28523 for current-outgoing; Tue, 2 Apr 1996 06:38:15 -0800 (PST) Received: from ghost.uunet.ca (ghost.uunet.ca [142.77.1.100]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id GAA28517 for ; Tue, 2 Apr 1996 06:38:12 -0800 (PST) Received: by ghost.uunet.ca id <60069-1>; Tue, 2 Apr 1996 09:17:51 -0500 Date: Tue, 2 Apr 1996 09:17:49 -0500 From: Cat Okita To: Brian Litzinger cc: current@freebsd.org Subject: Re: Advice/Recommendation needed In-Reply-To: <199604021058.CAA07912@MediaCity.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 2 Apr 1996, Brian Litzinger wrote: > I've always considered it more important to have a working OS, than > to have someone to blame for a lack thereof. So have I... Cat From owner-freebsd-current Tue Apr 2 06:45:14 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA29042 for current-outgoing; Tue, 2 Apr 1996 06:45:14 -0800 (PST) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id GAA29037 for ; Tue, 2 Apr 1996 06:45:11 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.7.5/8.6.9) id JAA00430; Tue, 2 Apr 1996 09:41:15 -0500 (EST) From: "John S. Dyson" Message-Id: <199604021441.JAA00430@dyson.iquest.net> Subject: Re: calcru: negative time: To: bde@zeta.org.au (Bruce Evans) Date: Tue, 2 Apr 1996 09:41:15 -0500 (EST) Cc: bde@zeta.org.au, phk@critter.tfs.com, freebsd-current@freefall.freebsd.org, kuku@gilberto.physik.rwth-aachen.de In-Reply-To: <199604021118.VAA10642@godzilla.zeta.org.au> from "Bruce Evans" at Apr 2, 96 09:18:01 pm X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > >> >My i386 has really high numbers here. > >> > >> Highly negative numbers? They can't go more than 10000 usec negative > >> on i386's due to the causes that I know about. > > >Generally in the ~5000 range (+/-3000) and occasionally >>10000. > > I think 5000 means that you missed a whole clock interrupt. E.g.: > > actual time event reported time comments > 0 Xintr0() > 10 hardclock() > 9000 splhigh() > 10000 Xintr0() sets ipending bit for intr0 > 19000 microtime() 19000 no problem yet > 20000 Xintr0() oops, missed a whole intr0 > 24000 microtime() 14000 oops > 25000 splx() > 25005 hardclock() > 26000 microtime() 16000 oops > > Another possibility is that TIMER0_LATCH_COUNT = 20 is too small. Now > I'm worried that it is too small if there are bus-hogging DMA > controllers. My U34F seems to cause a maximum latency of > 160 usec. > siointr() can also cause a latency of a few hundred usec if there > multiple active lines. TIMER0_LATCH_COUNT should be smaller than 62.5 > for operation at 16Khz (used by pcaudio). Perhaps the correct fix is > to drop support for pcaudio. > > >It seems to be connected to fork/exec on my mach. > > It (actually failing of a more complete test in mi_switch()) seems > to be connected with doing a bunch of disk accesses after the system > has been idle for some time. I suspect vm. I didn't like changing > splimp() in vm to splhigh(). > > I turned off my i586 clock fixup code in hardclock() and got the > expected reports from test code in hardclock() about negative > microtime deltas. The worst case over a period of 8 hours was > -37 usec. This normally isn't a problem because microtime() calls > are normally separated by more than 37 usec. > > >How about ESDI disks, could they monopolize the cpu on slow systems ? > > The could only monopolize the cpu, not the clock. The worst case is if > wdstrategy() is called at splhigh() (it shouldn't be) and writes 16 (?) > 512-byte sectors in 2 ms to 4ms. After doing the initial transfer it > can only be called at splbio() when it can't hurt the clock. > > Bruce > > From owner-freebsd-current Tue Apr 2 06:45:49 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA29083 for current-outgoing; Tue, 2 Apr 1996 06:45:49 -0800 (PST) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id GAA29076 for ; Tue, 2 Apr 1996 06:45:46 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.7.5/8.6.9) id JAA00446; Tue, 2 Apr 1996 09:45:11 -0500 (EST) From: "John S. Dyson" Message-Id: <199604021445.JAA00446@dyson.iquest.net> Subject: Re: calcru: negative time: To: bde@zeta.org.au (Bruce Evans) Date: Tue, 2 Apr 1996 09:45:11 -0500 (EST) Cc: bde@zeta.org.au, phk@critter.tfs.com, freebsd-current@freefall.freebsd.org, kuku@gilberto.physik.rwth-aachen.de In-Reply-To: <199604021118.VAA10642@godzilla.zeta.org.au> from "Bruce Evans" at Apr 2, 96 09:18:01 pm X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > It (actually failing of a more complete test in mi_switch()) seems > to be connected with doing a bunch of disk accesses after the system > has been idle for some time. I suspect vm. I didn't like changing > splimp() in vm to splhigh(). > If there are some times where splhigh() is on for too long, that needs to be changed (we aren't using another interlock mechanism when we should be.) Splhigh is correct for it's intended purpose -- lock out ANY other access to the VM data structures. Splimp is just a hack in it's own right implying that the networking code is the ONLY code in the system that needs potentially concurrent access -- and that is potentially NOT true. John From owner-freebsd-current Tue Apr 2 07:06:01 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA00212 for current-outgoing; Tue, 2 Apr 1996 07:06:01 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA00184 for ; Tue, 2 Apr 1996 07:05:57 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id BAA28807; Wed, 3 Apr 1996 01:05:31 +1000 Date: Wed, 3 Apr 1996 01:05:31 +1000 From: Bruce Evans Message-Id: <199604021505.BAA28807@godzilla.zeta.org.au> To: bde@zeta.org.au, phk@critter.tfs.com Subject: Re: calcru: negative time: Cc: freebsd-current@freefall.freebsd.org, kuku@gilberto.physik.rwth-aachen.de Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> >Alternatively, could we make a check in spl*() so that if splhigh has been >> >active >long< time we will print a warning ? >> ... The problem should >> be reported by stopping at a breakpoint in spl0 or in doreti before the >> cpl has been reduced. Then there will be a chance of seeing what set >> cpl high for too long. >Couldn't you just record the %eip in splhigh() ? Yes, unless the problem was more to do with the flow of control from where splhigh was set to where it was cleared. This would be hard to see, but it might help to look at the stack frame. You would also have to be careful about nested splhigh()s and nonlinear flows of control (context switches). I like breakpoints. They're faster to write than printfs. Bryce From owner-freebsd-current Tue Apr 2 07:31:17 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA02376 for current-outgoing; Tue, 2 Apr 1996 07:31:17 -0800 (PST) Received: from lear35.cytex.com (root@lear35.cytex.com [38.252.97.5]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id HAA02345 for ; Tue, 2 Apr 1996 07:30:52 -0800 (PST) Received: (from mbartley@localhost) by lear35.cytex.com (8.7.5/8.7.3) id HAA22058 for current@freebsd.org; Tue, 2 Apr 1996 07:30:49 -0800 (PST) From: Matt Bartley Message-Id: <199604021530.HAA22058@lear35.cytex.com> Subject: Re: make world broken To: current@freebsd.org Date: Tue, 2 Apr 1996 07:30:49 -0800 (PST) In-Reply-To: <3302.828451192@critter.tfs.com> from Poul-Henning Kamp at "Apr 2, 96 01:19:52 pm" X-Mailer: ELM [version 2.4ME+ PL14 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > install -c -s -o bin -g bin -m 555 calendar /usr/bin > install -c -o bin -g bin -m 444 calendar.1.gz /usr/share/calendar/man/man1 > install: /usr/share/calendar/man/man1: No such file or directory > *** Error code 71 > > Stop. > *** Error code 1 > > Stop. > *** Error code 1 I was just about to post about this too. This same thing happened to me during the make world I was running last night. Last sup was around 23:00 PST last night (or 07:00 UTC today). From owner-freebsd-current Tue Apr 2 07:31:35 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA02409 for current-outgoing; Tue, 2 Apr 1996 07:31:35 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA02401 for ; Tue, 2 Apr 1996 07:31:30 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id BAA29463; Wed, 3 Apr 1996 01:27:15 +1000 Date: Wed, 3 Apr 1996 01:27:15 +1000 From: Bruce Evans Message-Id: <199604021527.BAA29463@godzilla.zeta.org.au> To: bde@zeta.org.au, toor@dyson.iquest.net Subject: Re: calcru: negative time: Cc: freebsd-current@freefall.freebsd.org, kuku@gilberto.physik.rwth-aachen.de, phk@critter.tfs.com Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >If there are some times where splhigh() is on for too long, that needs >to be changed (we aren't using another interlock mechanism when we >should be.) Splhigh is correct for it's intended purpose -- lock out >ANY other access to the VM data structures. Splimp is just a hack in splvm() would be correct. splhigh() locks out access to _all_ data structures. AFAIK, hardclock() doesn't touch any vm data. statclock() touches some vm statistics. This could probably be handled without locking so much. statclock() is careful not to touch user pages for profiling ticks. This may depend on our fuswintr() and suswintr() always failing so that profiling ticks aren't added immediately. slimp() doesn't contain splbio(), so it must have once been safe to handle disk interrupts in the middle of vm operations. Has this changed? splhigh() is more or less the union of splimp() (which is usually >= spltty() due to other bogins), splbio() and the clock part of splclock(), so the switching from splimp() to splhigh() was essentially adding the masking of bio interrupts together with (unnessarily I hope) adding the masking of clock interrupts. Bruce From owner-freebsd-current Tue Apr 2 07:35:07 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA02733 for current-outgoing; Tue, 2 Apr 1996 07:35:07 -0800 (PST) Received: from novell.com (prv-ums.Provo.Novell.COM [137.65.40.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA02709 Tue, 2 Apr 1996 07:34:45 -0800 (PST) Received: from INET-PRV-Message_Server by fromGW with Novell_GroupWise; Tue, 02 Apr 1996 08:34:09 -0700 Content-Type: text/plain Message-ID: X-Mailer: Novell GroupWise 4.1 Date: Tue, 02 Apr 1996 08:40:19 -0700 From: DARREND@novell.com (Darren Davis) To: hackers@freebsd.org Cc: current@freebsd.org Subject: COFF 386 X Windows application. Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk OK, here's the scoop. I have an X windows application that is a 386 COFF binary. When run from X, the application hangs. The message printed on the console is: IBCS2: 'sysi86' function 114(0x72) not implemented yet Does current have support for this? What is a person without source to the application to do? (woe is me). I really would like to get this working. If I remember rightly, Terry was stating something like the sysi86 function doesn't fully work or something like that if my memory serves me. I believe I have my IBCS emulation stuff set up correctly (I followed the FAQ). Darren R. Davis Senior Software Engineer Novell, Inc. From owner-freebsd-current Tue Apr 2 08:10:47 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA05440 for current-outgoing; Tue, 2 Apr 1996 08:10:47 -0800 (PST) Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id IAA05432 Tue, 2 Apr 1996 08:10:34 -0800 (PST) Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA04475; Tue, 2 Apr 1996 11:10:32 -0500 Date: Tue, 2 Apr 1996 11:10:32 -0500 From: Garrett Wollman Message-Id: <9604021610.AA04475@halloran-eldar.lcs.mit.edu> To: "Gary Palmer" Cc: FreeBSD-Current Subject: Linker sets & structures for networking code In-Reply-To: <3278.828405118@palmer.demon.co.uk> References: <3278.828405118@palmer.demon.co.uk> Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk < said: > There seems to be something fundamentally WRONG in some of the > networking stuff which I'm not sure how to fix. (I'm going through > LINT trying to fix as many warnings as I can). > People have noticed warnings like: > ../../kern/uipc_proto.c:62: warning: initialization from incompatible pointer type > (the error comes from the `raw_input' initialiser); > /sys/sys/protosw.h defines the input field to be: > void (*pr_input) __P((struct mbuf *, int len)); Every protocol family uses a different convention for calling its input functions. This was not a problem before the age of prototypes; now it is. It has never been clear to me why the lower-layer input functions are listed in the protosw[]s at all, since there is no way that they could sensibly ever get called through protocol processing. (I say ``sensibly'' since it is possible to do something really stupid which would do this; hopefully the added warnings will discourage anyone from attempting it.) > as `0', I can't see how raw_input ever gets call via the localsw > array. It never does; it wouldn't make any sense to do so. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-current Tue Apr 2 09:05:02 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA09212 for current-outgoing; Tue, 2 Apr 1996 09:05:02 -0800 (PST) Received: from Campino.Informatik.RWTH-Aachen.DE (campino.Informatik.RWTH-Aachen.DE [137.226.225.2]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA09198 for ; Tue, 2 Apr 1996 09:04:57 -0800 (PST) Received: from gilberto.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.31.2]) by Campino.Informatik.RWTH-Aachen.DE (RBI-Z-5/8.6.12) with ESMTP id TAA04066 for ; Tue, 2 Apr 1996 19:02:41 +0200 Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.6.11/8.6.9) id TAA09739; Tue, 2 Apr 1996 19:09:28 +0200 From: "Christoph P. Kukulies" Message-Id: <199604021709.TAA09739@gilberto.physik.rwth-aachen.de> Subject: Re: Huh? cc1 text file busy? To: kuku@gilberto.physik.rwth-aachen.de (Christoph P. Kukulies) Date: Tue, 2 Apr 1996 19:09:27 +0200 (MET DST) Cc: freebsd-current@freefall.freebsd.org In-Reply-To: <199604020815.KAA07931@gilberto.physik.rwth-aachen.de> from "Christoph P. Kukulies" at Apr 2, 96 10:15:08 am Reply-To: Christoph Kukulies X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > I'm building a -current world and in parallel I wanted to build > a kernel on that same machine. This is what I suddenly got: > > Ouch, lost the paste buffer, anyway, make stopped > saying something like: > > /usr/libexec/cc1: text file busy > > *** Error code 1 Greg Lehey wrote me (in personal mail): Jackpot! you hit the moment when cc1 was being installed by make world. > > > --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de > --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-current Tue Apr 2 09:54:32 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA11794 for current-outgoing; Tue, 2 Apr 1996 09:54:32 -0800 (PST) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA11789 Tue, 2 Apr 1996 09:54:29 -0800 (PST) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <17562(11)>; Tue, 2 Apr 1996 09:53:40 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177475>; Tue, 2 Apr 1996 09:53:27 -0800 To: Bruce Evans cc: FreeBSD-Current@freebsd.org, gpalmer@freebsd.org Subject: Re: Linker sets & structures for networking code In-reply-to: Your message of "Tue, 02 Apr 96 03:27:47 PST." <199604021127.VAA11042@godzilla.zeta.org.au> Date: Tue, 2 Apr 1996 09:53:17 PST From: Bill Fenner Message-Id: <96Apr2.095327pst.177475@crevenia.parc.xerox.com> Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199604021127.VAA11042@godzilla.zeta.org.au> you write: >The correct fix isn't obvious. In the IP case, I believe that the correct fix is to replace the *_output pointers with 0's. I don't think that any of the IP stuff uses the pr_output pointer at all. (I have a kernel with this fix that I haven't booted to test yet.) >>I can't see how raw_input ever gets call via the localsw >>array. (Infact there are several examples of `raw_input' being called >>which bypasses localsw totally). So why on earth is it there?!? Good question. It probably doesn't belong there either. (Have you grep'd for pr_input?) Bill From owner-freebsd-current Tue Apr 2 10:27:04 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA13337 for current-outgoing; Tue, 2 Apr 1996 10:27:04 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id KAA13331 for ; Tue, 2 Apr 1996 10:26:56 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id MAA26726; Tue, 2 Apr 1996 12:25:08 -0600 From: Joe Greco Message-Id: <199604021825.MAA26726@brasil.moneng.mei.com> Subject: Re: Advice/Recommendation needed To: julian@ref.tfs.com (JULIAN Elischer) Date: Tue, 2 Apr 1996 12:25:08 -0600 (CST) Cc: cat@ghost.uunet.ca, current@FreeBSD.org In-Reply-To: <199604012304.PAA05402@ref.tfs.com> from "JULIAN Elischer" at Apr 1, 96 03:04:11 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Oh I forgot..... > > > someone to hang out the window if things aren't working. (Hell - someone > > to sue, if it comes to that). > (*) > > > > Free OS's are a wonderful thing - they let people use UNIX that might never > > otherwise be able to afford to do so; they offer source so that people can > > learn about how things work...but they don't offer a place for the buck to stop. > (*) > what a depressingly american attitude.. You're writing to someone at uunet.ca :-) ^^ > offered the oportunity to control your own destiny, the answer is > "sorry I don't want the responsibility.. I'd rather be able top blame > some-one else.. Well, that's not always the case. Around here, the buck stops here, and even though the answer is sometimes that I can't or won't do something about a particular problem, I'd still rather be running FreeBSD because at least I have a chance to be able to do something about a problem. > unfortunatly we're seeing more and more of this elsewhere in the world too.. A new generation of computer users, with a total lack of regard for what has been done by others, yet expect all those same great things to be handed to them on a silver platter... That sort of falls back to the "support" issue. Even here at work, people don't understand why it is when they find a bug in a GNU tool, I suggest to them that they find and fix the problem, and submit a bug report and patch.. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/546-7968 From owner-freebsd-current Tue Apr 2 10:33:43 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA13771 for current-outgoing; Tue, 2 Apr 1996 10:33:43 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id KAA13765 for ; Tue, 2 Apr 1996 10:33:40 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id MAA26770; Tue, 2 Apr 1996 12:29:38 -0600 From: Joe Greco Message-Id: <199604021829.MAA26770@brasil.moneng.mei.com> Subject: Re: Fixit Floppy Broken? To: count@key.hole.fi (Bror 'Count' Heinola) Date: Tue, 2 Apr 1996 12:29:38 -0600 (CST) Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-current@FreeBSD.ORG In-Reply-To: <199604020813.LAA04262@key.hole.fi> from "Bror 'Count' Heinola" at Apr 2, 96 11:13:27 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > J Wunsch taisi sanoa: > > > > Filing a PR won't help very much. The floppy driver is in bad need > > for a rewrite. > > > > If you're willing to rewrite it, and submitting PRs would accelerate > > this process, i could immediately submit half a dozen PRs for it. :-) > > Hey, couldn't 'we' use the magnificent dancing and whistling > fd driver made by Jesus Monroy Jr. ? :-) Good lord, I was praying nobody would take the name of the Lord in vain. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/546-7968 From owner-freebsd-current Tue Apr 2 10:47:36 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA14567 for current-outgoing; Tue, 2 Apr 1996 10:47:36 -0800 (PST) Received: from ghost.uunet.ca (ghost.uunet.ca [142.77.1.100]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id KAA14559 for ; Tue, 2 Apr 1996 10:47:33 -0800 (PST) Received: by ghost.uunet.ca id <60075-1>; Tue, 2 Apr 1996 13:27:13 -0500 Date: Tue, 2 Apr 1996 13:27:05 -0500 From: Cat Okita To: Joe Greco cc: JULIAN Elischer , current@freebsd.org Subject: Re: Advice/Recommendation needed In-Reply-To: <199604021825.MAA26726@brasil.moneng.mei.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 2 Apr 1996, Joe Greco wrote: > You're writing to someone at uunet.ca :-) > ^^ *grin* > A new generation of computer users, with a total lack of regard for what has > been done by others, yet expect all those same great things to be handed to > them on a silver platter... For which we have Microsoft and other people selling 'vapour ware' to thank > That sort of falls back to the "support" issue. Even here at work, people > don't understand why it is when they find a bug in a GNU tool, I suggest to > them that they find and fix the problem, and submit a bug report and patch.. ...or at least send in a bug report *wry grin*...time doesn't always permit fixes *sigh* Cat From owner-freebsd-current Tue Apr 2 11:02:07 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA15870 for current-outgoing; Tue, 2 Apr 1996 11:02:07 -0800 (PST) Received: from bacall.lodgenet.com (bacall.lodgenet.com [205.138.147.242]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA15857 Tue, 2 Apr 1996 11:01:58 -0800 (PST) Received: (from mail@localhost) by bacall.lodgenet.com (8.6.12/8.6.12) id MAA27113; Tue, 2 Apr 1996 12:56:39 -0600 Received: from tserv.lodgenet.com(204.124.120.10) by bacall via smap (V1.3) id sma027107; Tue Apr 2 12:56:19 1996 Received: from jake.lodgenet.com (jake.lodgenet.com [204.124.120.30]) by tserv.lodgenet.com (8.6.12/8.6.12) with ESMTP id MAA10688; Tue, 2 Apr 1996 12:09:16 -0600 Received: from localhost (localhost [127.0.0.1]) by jake.lodgenet.com (8.7.5/8.6.12) with SMTP id MAA13315; Tue, 2 Apr 1996 12:22:24 -0600 (CST) Message-Id: <199604021822.MAA13315@jake.lodgenet.com> X-Authentication-Warning: jake.lodgenet.com: Host localhost [127.0.0.1] didn't use HELO protocol X-Mailer: exmh version 1.6.2 7/18/95 To: DARREND@novell.com (Darren Davis) cc: hackers@freebsd.org, current@freebsd.org Subject: Re: COFF 386 X Windows application. In-reply-to: Your message of "Tue, 02 Apr 1996 08:40:19 MST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 02 Apr 1996 12:22:23 -0600 From: "Eric L. Hernes" Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk AFAIK sysi86 isn't working at all, except to tell you that it isn't ;). I think you're confusing sysi86() with vm86(), I did too, 'til I read the SCO man page. sysi86() works kind of like an ioctl in a driver, it provides a bunch of different commands that may or may not return useful stuff. From sco's function 114 is ``get os features vector'', whatever that is. Other common uses are get/set swap info and status, get/set hardware clock, SCO's vm86() interface is accesed through this, the ldt/gdt manipulation stuff is done this way too. Many of the functions provided by sysi86() are available on FBSD in other ways, some aren't. It'd be a good exercise to cast those that are available to the sysi86() emulation. I'd call it an `entry level kernel hack'. For your app, you might want to just have sysi86() return a success value, and see what happens. I'm not sure what the app expects back from a `get os features' call, maybe something as usless as a uname, or maybe the whole app depends on it. good luck, eric. Darren Davis writes: >OK, here's the scoop. I have an X windows application that is a 386 COFF >binary. When run from X, the application hangs. The message printed on >the console is: > >IBCS2: 'sysi86' function 114(0x72) not implemented yet > >Does current have support for this? What is a person without source to >the application to do? (woe is me). I really would like to get this working. > If I remember rightly, Terry was stating something like the sysi86 function >doesn't fully work or something like that if my memory serves me. I believe >I have my IBCS emulation stuff set up correctly (I followed the FAQ). > >Darren R. Davis >Senior Software Engineer >Novell, Inc. > > > -- erich@lodgenet.com erich@rrnet.com From owner-freebsd-current Tue Apr 2 11:21:29 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA17756 for current-outgoing; Tue, 2 Apr 1996 11:21:29 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA17719 for ; Tue, 2 Apr 1996 11:21:16 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id VAA21233 for ; Tue, 2 Apr 1996 21:21:12 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id VAA02336 for freebsd-current@FreeBSD.org; Tue, 2 Apr 1996 21:21:12 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id UAA10902 for freebsd-current@FreeBSD.org; Tue, 2 Apr 1996 20:46:53 +0200 (MET DST) From: J Wunsch Message-Id: <199604021846.UAA10902@uriah.heep.sax.de> Subject: Re: Probably -current tzsetup & sysinstall conflict To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Tue, 2 Apr 1996 20:46:53 +0200 (MET DST) In-Reply-To: <199604020138.FAA02523@astral.msk.su> from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Apr 2, 96 05:38:49 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= wrote: > I notice that tzsetup called from sysinstall. > I also notice that -current tzsetup uses "install" program to install > localtime. > The question: is "install" available for sysinstall too? tzsetup is called as the last step in sysinstall. If somebody hasn't installed /usr/bin/install, he is unlikely to have /usr/bin/tzsetup installed. ;-) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Tue Apr 2 11:21:34 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA17788 for current-outgoing; Tue, 2 Apr 1996 11:21:34 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA17724 for ; Tue, 2 Apr 1996 11:21:19 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id VAA21192 for ; Tue, 2 Apr 1996 21:20:51 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id VAA02320 for freebsd-current@FreeBSD.org; Tue, 2 Apr 1996 21:20:50 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id TAA10217 for freebsd-current@FreeBSD.org; Tue, 2 Apr 1996 19:55:57 +0200 (MET DST) From: J Wunsch Message-Id: <199604021755.TAA10217@uriah.heep.sax.de> Subject: Re: adjkerntz (was: cvs commit: src/usr.sbin/tzsetup ...) To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Tue, 2 Apr 1996 19:55:56 +0200 (MET DST) In-Reply-To: <199604012024.AAA01620@astral.msk.su> from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Apr 2, 96 00:24:20 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= wrote: (Applicability of adjkerntz) > Of course, pure Unix machine don't need it. But if you sometimes > mount DOS floppies (msdosfs), you need it. msdosfs? MSDOS' idea of a timezone is broken by design (i.e., it doesn't have an idea about it at all). Someone in Australia could send a file with a DOS timestamp to somebody in California across the Internet, and the recipient will see a file that appears to be written ``in the future''. I don't see how adjkerntz should fix it. Since DOS files don't have an explicit timezone, you can imply any time zone you want, so applying the kernel's idea (UTC) seems to be most logical. (Note that this might conflict with the idea of your local DOS, but applying the localtime does as well conflict with the idea of any other DOS not running in *your* localtime zone.) To be honest, even in cases where i run DOS every now and then, i simply don't care for its broken idea of a timezone. I live with it running in UTC then. (brokeness of adjkerntz for the last DST switchover in the EU) > > It was with a -current version, and -current timezone settings. So it > > seems that new versions do also have bugs. ;) > > I need more info on this subject, i.e. some test results, > DST rules and what finally happens. DST rules: MET How to reproduce: setup localtime as MET, and tweak your clock to run from Mar 31, 1996, 01:58 MET onwards. Watch the syslog at 02:00 MET (where the switch happened to 03:00 MET DST). I think Holm Tiffe was willing to send you all information he's got. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Tue Apr 2 11:21:37 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA17807 for current-outgoing; Tue, 2 Apr 1996 11:21:37 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA17731 for ; Tue, 2 Apr 1996 11:21:20 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id VAA21248 for ; Tue, 2 Apr 1996 21:21:17 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id VAA02339 for freebsd-current@FreeBSD.org; Tue, 2 Apr 1996 21:21:17 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id UAA10633 for freebsd-current@FreeBSD.org; Tue, 2 Apr 1996 20:29:24 +0200 (MET DST) From: J Wunsch Message-Id: <199604021829.UAA10633@uriah.heep.sax.de> Subject: Re: Fixit Floppy Broken? To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Tue, 2 Apr 1996 20:29:24 +0200 (MET DST) In-Reply-To: <199604020813.LAA04262@key.hole.fi> from "Bror 'Count' Heinola" at Apr 2, 96 11:13:27 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Bror 'Count' Heinola wrote: > > If you're willing to rewrite it, and submitting PRs would accelerate > > this process, i could immediately submit half a dozen PRs for it. :-) > > Hey, couldn't 'we' use the magnificent dancing and whistling > fd driver made by Jesus Monroy Jr. ? :-) I've been really dissatisfied that even 386BSD 1.0 didn't ship with His Famous Driver. ;-) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Tue Apr 2 11:51:01 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA20149 for current-outgoing; Tue, 2 Apr 1996 11:51:01 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA20123 for ; Tue, 2 Apr 1996 11:50:43 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id VAA22251 for ; Tue, 2 Apr 1996 21:50:40 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id VAA02817 for freebsd-current@FreeBSD.org; Tue, 2 Apr 1996 21:50:40 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id VAA11227 for freebsd-current@FreeBSD.org; Tue, 2 Apr 1996 21:44:42 +0200 (MET DST) From: J Wunsch Message-Id: <199604021944.VAA11227@uriah.heep.sax.de> Subject: Re: Huh? cc1 text file busy? To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Tue, 2 Apr 1996 21:44:41 +0200 (MET DST) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <9604021349.AA29457@cssmuc.frt.dec.com> from "garyj@frt.dec.com" at Apr 2, 96 03:49:06 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As garyj@frt.dec.com wrote: > > /usr/libexec/cc1: text file busy > > > > *** Error code 1 > > > > make probably tried to install the new cc1 but it was being used to > compile part of the kernel. Seems like a reasonable error message to me. install(1) is supposed to unlink the old file in this situation. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Tue Apr 2 11:53:45 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA20442 for current-outgoing; Tue, 2 Apr 1996 11:53:45 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id LAA20433 for ; Tue, 2 Apr 1996 11:53:41 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.7.5/8.6.12) with ESMTP id LAA22683; Tue, 2 Apr 1996 11:50:30 -0800 (PST) Message-Id: <199604021950.LAA22683@austin.polstra.com> To: jgreco@brasil.moneng.mei.com Cc: cat@ghost.uunet.ca, current@FreeBSD.org Subject: Re: Advice/Recommendation needed In-Reply-To: <199604021825.MAA26726@brasil.moneng.mei.com> Date: Tue, 02 Apr 1996 11:50:30 -0800 From: John Polstra Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > what a depressingly american attitude.. > > You're writing to someone at uunet.ca :-) > ^^ Wow! Things have changed a lot since I took geography in 4th grade. Back then, Canada was part of America. -- 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 Apr 2 11:57:35 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA20899 for current-outgoing; Tue, 2 Apr 1996 11:57:35 -0800 (PST) Received: from ghost.uunet.ca (ghost.uunet.ca [142.77.1.100]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id LAA20893 for ; Tue, 2 Apr 1996 11:57:32 -0800 (PST) Received: by ghost.uunet.ca id <60074-1>; Tue, 2 Apr 1996 14:37:04 -0500 Date: Tue, 2 Apr 1996 14:36:53 -0500 From: Cat Okita To: John Polstra cc: jgreco@brasil.moneng.mei.com, current@freebsd.org Subject: Re: Advice/Recommendation needed In-Reply-To: <199604021950.LAA22683@austin.polstra.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 2 Apr 1996, John Polstra wrote: > > Wow! Things have changed a lot since I took geography in 4th grade. > Back then, Canada was part of America. *BLECHK*...that's almost as bad as the person who thought that Ontario was in Ohio!!! Cat From owner-freebsd-current Tue Apr 2 11:58:20 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA21067 for current-outgoing; Tue, 2 Apr 1996 11:58:20 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id LAA21057 for ; Tue, 2 Apr 1996 11:58:16 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id NAA26965; Tue, 2 Apr 1996 13:56:56 -0600 From: Joe Greco Message-Id: <199604021956.NAA26965@brasil.moneng.mei.com> Subject: Re: Advice/Recommendation needed To: jdp@polstra.com (John Polstra) Date: Tue, 2 Apr 1996 13:56:56 -0600 (CST) Cc: jgreco@brasil.moneng.mei.com, cat@ghost.uunet.ca, current@FreeBSD.org In-Reply-To: <199604021950.LAA22683@austin.polstra.com> from "John Polstra" at Apr 2, 96 11:50:30 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > > what a depressingly american attitude.. > > > > You're writing to someone at uunet.ca :-) > > ^^ > > Wow! Things have changed a lot since I took geography in 4th grade. > Back then, Canada was part of America. Canada is certainly part of North America, but placed back into context, I think the author was referring to attitudes popular here in the States, of which Canada is not a member (yet). ... JG From owner-freebsd-current Tue Apr 2 11:59:48 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA21159 for current-outgoing; Tue, 2 Apr 1996 11:59:48 -0800 (PST) Received: from ghost.uunet.ca (ghost.uunet.ca [142.77.1.100]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id LAA21152 for ; Tue, 2 Apr 1996 11:59:44 -0800 (PST) Received: by ghost.uunet.ca id <60071-1>; Tue, 2 Apr 1996 14:39:22 -0500 Date: Tue, 2 Apr 1996 14:39:21 -0500 From: Cat Okita To: Joe Greco cc: John Polstra , jgreco@brasil.moneng.mei.com, current@freebsd.org Subject: Re: Advice/Recommendation needed In-Reply-To: <199604021956.NAA26965@brasil.moneng.mei.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 2 Apr 1996, Joe Greco wrote: > > Canada is certainly part of North America, but placed back into context, > I think the author was referring to attitudes popular here in the States, of > which Canada is not a member (yet). > Hey - we won the war last time...and we'll win it again *GRIN* Cat [Yup - that's me...Canuck to the bone :>] From owner-freebsd-current Tue Apr 2 12:19:45 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA23018 for current-outgoing; Tue, 2 Apr 1996 12:19:45 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id MAA23012 Tue, 2 Apr 1996 12:19:42 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.7.5/8.6.12) with ESMTP id MAA22918; Tue, 2 Apr 1996 12:19:38 -0800 (PST) Message-Id: <199604022019.MAA22918@austin.polstra.com> To: phk@critter.tfs.com Cc: freebsd-current@freebsd.org, wosch@freebsd.org Subject: Re: make world broken Date: Tue, 02 Apr 1996 12:19:37 -0800 From: John Polstra Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Poul-Henning wrote: > ===> usr.bin/calendar > install -c -o bin -g bin -m 444 /usr/src/usr.bin/calendar/calendars/calendar.* > /usr/share/calendar > install -c -o bin -g bin -m 444 /usr/src/usr.bin/calendar/calendars/hr_HR.ISO_8 > 859-2/calendar.* /usr/share/calendar/hr_HR.ISO_8859-2; > install -c -o bin -g bin -m 444 /usr/src/usr.bin/calendar/calendars/de_DE.ISO_8 > 859-1/calendar.* /usr/share/calendar/de_DE.ISO_8859-1; > install -c -s -o bin -g bin -m 555 calendar /usr/bin > install -c -o bin -g bin -m 444 calendar.1.gz /usr/share/calendar/man/man1 > install: /usr/share/calendar/man/man1: No such file or directory > *** Error code 71 It's caused by the recent changes to bsd.own.mk. In calendar/Makefile, we have: SHAREDIR= /usr/share/calendar and then in bsd.own.mk, we have: SHAREDIR?= /usr/share (Ignored because of the ?=) ... MANDIR?= ${SHAREDIR}/man/man I'm cc-ing this to the person who committed the latest changes in bsd.own.mk. -- 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 Apr 2 12:21:34 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA23256 for current-outgoing; Tue, 2 Apr 1996 12:21:34 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA23250 Tue, 2 Apr 1996 12:21:28 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA16934; Tue, 2 Apr 1996 13:16:02 -0700 From: Terry Lambert Message-Id: <199604022016.NAA16934@phaeton.artisoft.com> Subject: Re: COFF 386 X Windows application. To: DARREND@novell.com (Darren Davis) Date: Tue, 2 Apr 1996 13:16:02 -0700 (MST) Cc: hackers@FreeBSD.org, current@FreeBSD.org In-Reply-To: from "Darren Davis" at Apr 2, 96 08:40:19 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-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > OK, here's the scoop. I have an X windows application that is a 386 COFF > binary. When run from X, the application hangs. The message printed on > the console is: > > IBCS2: 'sysi86' function 114(0x72) not implemented yet > > Does current have support for this? What is a person without source to > the application to do? (woe is me). I really would like to get this working. > If I remember rightly, Terry was stating something like the sysi86 function > doesn't fully work or something like that if my memory serves me. I believe > I have my IBCS emulation stuff set up correctly (I followed the FAQ). Most of the sysi86 functionality is a hack Sean Eric Fagan put together for the call that does math coprocessor detection; specifically, it was as a result of a bug report that I made when I was running WSU's SVR3 Lotus 1-2-3, Word Perfect, and Sybase packages under IBCS2. Basically, sysi86 is what SCO calls their VM86() interface to allow protected mode programs to make DOS calls. 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 Apr 2 12:22:15 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA23341 for current-outgoing; Tue, 2 Apr 1996 12:22:15 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA23279 for ; Tue, 2 Apr 1996 12:21:37 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id WAA23623; Tue, 2 Apr 1996 22:20:49 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id WAA03069; Tue, 2 Apr 1996 22:20:48 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id WAA11574; Tue, 2 Apr 1996 22:17:45 +0200 (MET DST) From: J Wunsch Message-Id: <199604022017.WAA11574@uriah.heep.sax.de> Subject: Re: localtime needs changes for Portugal To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Tue, 2 Apr 1996 22:17:44 +0200 (MET DST) Cc: paulo@pegasus.isr.uc.pt (Paulo Menezes) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from "Paulo Menezes" at Apr 1, 96 11:34:19 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Paulo Menezes wrote: > --- 1718,1725 ---- > # From Rui Pedro Salgueiro (November 12, 1992): > # Portugal has recently (September, 27) changed timezone > # (from WET to MET or CET) to harmonize with EEC. > ! 1:00 EC MET%s 1996 Mar 31 2:00s > ! 0:00 EC WET%s The comment above would be wrong then. Is there anything that could be cited as the source of the change (like a formal act by your parliament)? -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Tue Apr 2 12:57:23 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA25409 for current-outgoing; Tue, 2 Apr 1996 12:57:23 -0800 (PST) Received: from trout.nosc.mil (trout.nosc.mil [128.49.16.7]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA25403 for ; Tue, 2 Apr 1996 12:57:21 -0800 (PST) Received: from cod.nosc.mil by trout.nosc.mil (4.1/SMI-4.1) id AA26448; Tue, 2 Apr 96 12:57:03 PST Received: from [128.49.16.48] (aegis.nosc.mil) by cod.nosc.mil (4.1/SMI-4.1) id AA16962; Tue, 2 Apr 96 12:55:22 PST X-Sender: gshaffer@cod.nosc.mil Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 2 Apr 1996 12:56:30 -0800 To: current@FreeBSD.ORG, report@XFree86.org From: gshaffer@nosc.mil (Greg Shaffer) Subject: Interesting XF86 Problem Cc: gshaffer@nosc.mil Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk My appologies for such a long e-mail, but here is an interesting problem which has had me stumped for a week that I would appriciate some suggestion on. Recently, I upgraded to a new PCI motherboard, UMC chipset, Am586-P75 133MHz CPU, Diamond Stealth 64 (S3-Trio64V+) with 2MB DRAM, and an Adaptec AHA-2940 (see dmesg output below for more specific info). At the same time I upgraded the hardware, I also upgraded XFree86 in my FreeBSD 2.1.0 installation to 3.1.2D since it fixed some S3-Trio64 bugs. Right away I started to have problems with the X server (XF86_S3) locking up the computer. When X starts up there is a flurry of disk activity, the sometimes the screen will change to my default background color, other times the screen would flicker and then the machine would hang. In all cases I noticed the disk access light on my external hard drive was always on (even thought there was no continued disk activity) and remained on until I reset the machine. I rummaged the archives at www.FreeBSD.Org to see if there was any similar reports. I noticed several discussions regarding conflicts with the serial I/O (sio) code and S3 graphics cards. So I downloaded sio.c from FreeBSD-stable, modifyed my config file and rebuilt the kernel. Problem still occurs. Heres the kicker... I noticed a pattern to the success and failures that occured. The first time you run the 3.1.2D S3 server you get a warning message with a 10 second delay before the server starts up. When ever this delay occurs, X will successfully start up with my configuration. If I shut down the server and restart it the server will hang. If you remove the '.X' file created by the 3.1.2D XF86_S3 server before it is restarted the server will successfully start up. I was able to verify this by removing the '.X' file prior to executing startx. Every time this file is removed, X will start up without a problem! At present I cannot find anything obviously wrong with my configuration (see dmesg and X output below). The system runs fine under Windows and appears to operate fine with my work around. Is there some obscure timing thing or dependency that I am not taking into account here? Does anybody have any suggestions on how to solve this problem (e.g. upgrade to FreeBSD-stable)? Thanks Greg Shaffer ** DMESG Output FreeBSD 2.1.0-RELEASE #0: Mon Apr 1 21:21:02 PST 1996 root@intrepid:/usr/src/sys/compile/TEST CPU: i486DX (486-class CPU) Origin = "AuthenticAMD" Id = 0x4f4 real memory = 25165824 (24576K bytes) avail memory = 22810624 (22276K bytes) Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> ed0 at 0x300-0x31f irq 9 on isa ed0: address 1e:80:00:16:b2:84, type NE1000 (8 bit) sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A sio2 not found at 0x3e8 sio3 not found at 0x2e8 lpt1 at 0x378-0x37f irq 7 on isa lpt1: Interrupt-driven port lp1: TCP/IP capable interface pca0 on isa pca0: PC speaker audio driver fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 765 fd0: 1.44MB 3.5in ahc0 not found npx0 on motherboard npx0: INT 16 interface pas0 at 0x388 irq 12 drq 3 on isa pas0: Probing for devices on the PCI bus: ahc0 rev 0 int a irq 10 on pci0:12 ahc0: aic7870 Ultra Single Channel, SCSI Id=7, aic7870, 255 SCBs ahc0 waiting for scsi devices to settle (ahc0:0:0): "SEAGATE ST42400N 0119" type 0 fixed SCSI 2 sd0(ahc0:0:0): Direct-Access 2030MB (4159462 512 byte sectors) (ahc0:1:0): "QUANTUM LPS525S 3100" type 0 fixed SCSI 2 sd1(ahc0:1:0): Direct-Access 501MB (1027548 512 byte sectors) (ahc0:2:0): "TOSHIBA CD-ROM XM-5301TA 0925" type 5 removable SCSI 2 cd0(ahc0:2:0): CD-ROM cd present.[325252 x 2048 byte records] vga0 rev 83 int a irq 11 on pci0:13 pci0:16: UMC, device=0x8881, class=bridge (host) [no driver assigned] pci0:18: UMC, device=0x886a, class=bridge (isa) [no driver assigned] lpt1 switched to polled mode ** XF86_S3 Output This is a beta version of XFree86. This binary may be redistributed providing it is not modified in any way. Please send success and problem reports to . This version ( 3.1.2D ) will expire at Fri May 31 17:00:00 1996 Waiting for 10 seconds... XFree86 Version 3.1.2D / X Window System (protocol Version 11, revision 0, vendor release 6100) Release Date: Feb 24 1996 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (see http://www.XFree86.Org/FAQ) Operating System: FreeBSD 2.0.5 Configured drivers: S3: accelerated server for S3 graphics adaptors (Patchlevel 0) mmio_928, s3_generic Using syscons driver with X support (version 2.0) (using VT number 4) XF86Config: /etc/XF86Config (**) stands for supplied, (--) stands for probed/default values (**) Mouse: type: Mouseman, device: /dev/ttyd1, baudrate: 1200 (**) S3: Graphics device ID: "Diamond Stealth 64" (**) S3: Monitor ID: "SVGA Color Monitor" (**) FontPath set to "/usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/Type1/,/usr/X11R6/l ib/X11/fonts/Speedo/,/usr/X11R6/lib/X11/fonts/75dpi/,/usr/X11R6/lib/X11/font s/100dpi/" (--) S3: PCI: Trio32/64 rev 53, Linear FB @ 0xf8000000 (**) S3: Option flag "nomemaccess" is not defined for this driver (--) S3: Option "nomemaccess" is ignored for 86x/96x/TRIOxx (--) S3: card type: PCI (--) S3: Diamond Stealth BIOS found (--) S3: chipset: Trio64V+ (untested, please report !!) rev. 531 (**) S3: chipset driver: mmio_928 (**) S3: videoram: 2048k (**) S3: Ramdac type: s3_trio64 (**) S3: Ramdac speed: 135 (--) S3: Using Trio32/64 programmable clock (MCLK 54.886 MHz) (--) S3: Maximum allowed dot-clock: 135.000 MHz (**) S3: Mode "1024x768": mode clock = 65.000 (--) S3: Using 6 bits per RGB value (**) S3: Virtual resolution set to 1024x768 From owner-freebsd-current Tue Apr 2 13:08:13 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA26311 for current-outgoing; Tue, 2 Apr 1996 13:08:13 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA26306 for ; Tue, 2 Apr 1996 13:08:09 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA17082; Tue, 2 Apr 1996 14:03:35 -0700 From: Terry Lambert Message-Id: <199604022103.OAA17082@phaeton.artisoft.com> Subject: Re: Advice/Recommendation needed To: jehrenkrantz@whyy.org (Jeff Ehrenkrantz) Date: Tue, 2 Apr 1996 14:03:35 -0700 (MST) Cc: phk@critter.tfs.com, cat@ghost.uunet.ca, current@FreeBSD.org In-Reply-To: from "Jeff Ehrenkrantz" at Apr 2, 96 07:57:32 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > > I *need* to know that I've got a support contract for the OS, and have > > > someone to hang out the window if things aren't working. (Hell - someone > > > to sue, if it comes to that). > > > > Tell me how much you think would be reasonable for a support contract, > > and I'll consider taking the job. > > Carefullll what you ask for Poul! I'm reminded of a frog at the end of a > large runway thinking 'gee if I could only get my tongue around that big ass > fly' With respect, Poul is a big ass frog. 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 Apr 2 13:16:47 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA26903 for current-outgoing; Tue, 2 Apr 1996 13:16:47 -0800 (PST) Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id NAA26886 for ; Tue, 2 Apr 1996 13:16:43 -0800 (PST) Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id XAA15861 ; Tue, 2 Apr 1996 23:16:35 +0200 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id XAA01456 ; Tue, 2 Apr 1996 23:16:46 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.7.5/keltia-uucp-2.7) id WAA08376; Tue, 2 Apr 1996 22:37:26 +0200 (MET DST) From: Ollivier Robert Message-Id: <199604022037.WAA08376@keltia.freenix.fr> Subject: Re: SCSI_2_DEF? To: scrappy@ki.net (Marc G. Fournier) Date: Tue, 2 Apr 1996 22:37:25 +0200 (MET DST) Cc: current@FreeBSD.org In-Reply-To: from "Marc G. Fournier" at "Apr 1, 96 11:35:29 pm" X-Operating-System: FreeBSD 2.2-CURRENT ctm#1839 X-Mailer: ELM [version 2.4ME+ PL11 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk It seems that Marc G. Fournier said: > Just looking through LINT, and saw the options SCSI_2_DEF at > the very bottom, but no description of what it does... > > So, what does it do? :) It convinces some pre-SCSI2 disks which use CCS command set (very close to SCSI2) to answer like a SCSI2 disk. Without it, it acts like a SCSI1 device. My Micropolis MP 1624 is one of them. (ahb0:1:0): "MICROP 1624-07MZ1077801 HZ2P" type 0 fixed SCSI 2 sd11(ahb0:1:0): Direct-Access 642MB (1316751 512 byte sectors) sd11(ahb0:1:0): with 2112 cyls, 7 heads, and an average 89 sectors/track -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 2.2-CURRENT #9: Mon Apr 1 03:18:13 MET DST 1996 From owner-freebsd-current Tue Apr 2 13:18:09 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA27059 for current-outgoing; Tue, 2 Apr 1996 13:18:09 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA27054 for ; Tue, 2 Apr 1996 13:18:07 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA17134; Tue, 2 Apr 1996 14:12:29 -0700 From: Terry Lambert Message-Id: <199604022112.OAA17134@phaeton.artisoft.com> Subject: Re: Fixit Floppy Broken? To: count@key.hole.fi (Bror 'Count' Heinola) Date: Tue, 2 Apr 1996 14:12:29 -0700 (MST) Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-current@FreeBSD.ORG In-Reply-To: <199604020813.LAA04262@key.hole.fi> from "Bror 'Count' Heinola" at Apr 2, 96 11:13:27 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-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Filing a PR won't help very much. The floppy driver is in bad need > > for a rewrite. > > > > If you're willing to rewrite it, and submitting PRs would accelerate > > this process, i could immediately submit half a dozen PRs for it. :-) > > Hey, couldn't 'we' use the magnificent dancing and whistling > fd driver made by Jesus Monroy Jr. ? :-) >From what I could tell looking at it, it was decent code. He had one bad bug... and it seemed to be more of an architectural ordering bug (he wanted to do something one way, and the controller manufactureres wanted him to reverse the logic for it to work). Changing the ordering would have required a timeout in order to retry to eliminate a race window. But the code did not suck, even if many of his ideas were off the wall. 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 Apr 2 13:19:50 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA27213 for current-outgoing; Tue, 2 Apr 1996 13:19:50 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA27203 Tue, 2 Apr 1996 13:19:45 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA17151; Tue, 2 Apr 1996 14:15:49 -0700 From: Terry Lambert Message-Id: <199604022115.OAA17151@phaeton.artisoft.com> Subject: Re: Linker sets & structures for networking code To: phk@critter.tfs.com (Poul-Henning Kamp) Date: Tue, 2 Apr 1996 14:15:49 -0700 (MST) Cc: bde@zeta.org.au, FreeBSD-Current@FreeBSD.org, gpalmer@FreeBSD.org In-Reply-To: <2946.828447790@critter.tfs.com> from "Poul-Henning Kamp" at Apr 2, 96 12:23:10 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-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > My conclusion was that it was an attempt to please the OSI powers that > were, without completely wrecking the performance. > > I could, for all I can see, be ripped out. But then who would rip out the code? 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 Apr 2 13:23:14 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA27493 for current-outgoing; Tue, 2 Apr 1996 13:23:14 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA27486 for ; Tue, 2 Apr 1996 13:23:10 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id NAA11394 for ; Tue, 2 Apr 1996 13:23:09 -0800 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA17106; Tue, 2 Apr 1996 14:06:33 -0700 From: Terry Lambert Message-Id: <199604022106.OAA17106@phaeton.artisoft.com> Subject: Re: Advice/Recommendation needed To: cat@ghost.uunet.ca (Cat Okita) Date: Tue, 2 Apr 1996 14:06:33 -0700 (MST) Cc: jgreco@brasil.moneng.mei.com, julian@ref.tfs.com, current@freebsd.org In-Reply-To: from "Cat Okita" at Apr 2, 96 01:27:05 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-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > A new generation of computer users, with a total lack of regard for what has > > been done by others, yet expect all those same great things to be handed to > > them on a silver platter... > > For which we have Microsoft and other people selling 'vapour ware' to thank Actually, Microsoft simply caters to the least common denominator. The people to "thank" are those that purchase shoddy products because of the company instead of good products because of the product. It's the classic forest/trees problem. 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 Apr 2 13:30:08 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA28146 for current-outgoing; Tue, 2 Apr 1996 13:30:08 -0800 (PST) Received: from trane.uninett.no (trane.uninett.no [129.241.1.16]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id NAA28110 for ; Tue, 2 Apr 1996 13:30:03 -0800 (PST) From: sthaug@nethelp.no Received: from localhost (localhost [127.0.0.1]) by trane.uninett.no (8.7.3/8.7.3) with SMTP id WAA09553; Tue, 2 Apr 1996 22:29:58 +0100 (MET) Message-Id: <199604022129.WAA09553@trane.uninett.no> X-Authentication-Warning: trane.uninett.no: Host localhost [127.0.0.1] didn't use HELO protocol To: franky@pinewood.nl Cc: current@FreeBSD.ORG Subject: Re: [Q] Semantics of 'established' in ipfw tcp In-Reply-To: Your message of "Mon, 1 Apr 1996 10:20:05 +0100" References: <9604011020.ZM20909@pwood1.pinewood.nl> X-Mailer: Mew version 1.03 on Emacs 19.28.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Tue, 02 Apr 1996 23:29:57 +0200 Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I would like to know other people's reactions to the current semantics of > the 'established' keyword for TCP connections in the 2.2-960323-SNAPSHOT > implementation of the ipfw in the kernel. > > Currently 'established' means (according to the manpage *and* some > experimentation): > > established Matches packets that do not have the SYN bit set. > TCP packets only. > > Should this not be: > > established Matches packets that do have the ACK bit set. > TCP packets only. > > (To my knowledge this is the way conventional packet filters interpret > 'established'.) I believe it was Cisco that started using the 'established' keyword, and at least according to Cisco documentation, for instance http://cio.cisco.com/univercd/data/doc/software/11_0/rpcr/rip.htm#REF24774 it should be ACK *or* RST: "A match occurs if the TCP datagram has the ACK or RST bits set. The nonmatching case is that of the initial TCP datagram to form a connection." Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-current Tue Apr 2 13:54:59 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA29889 for current-outgoing; Tue, 2 Apr 1996 13:54:59 -0800 (PST) Received: from palmer.demon.co.uk (palmer.demon.co.uk [158.152.50.150]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id NAA29863 for ; Tue, 2 Apr 1996 13:54:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by palmer.demon.co.uk (8.7.5/8.6.11) with SMTP id WAA01277 ; Tue, 2 Apr 1996 22:49:49 +0100 (BST) To: Poul-Henning Kamp cc: FreeBSD-Current@FreeBSD.ORG From: "Gary Palmer" Subject: Re: Linker sets & structures for networking code In-reply-to: Your message of "Tue, 02 Apr 1996 12:23:10 -0000." <2946.828447790@critter.tfs.com> Date: Tue, 02 Apr 1996 22:49:49 +0100 Message-ID: <1275.828481789@palmer.demon.co.uk> Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Poul-Henning Kamp wrote in message ID <2946.828447790@critter.tfs.com>: > > I could, for all I can see, be ripped out. Anyone want to help Poul with his wish? :-) Gary From owner-freebsd-current Tue Apr 2 13:58:22 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA00320 for current-outgoing; Tue, 2 Apr 1996 13:58:22 -0800 (PST) Received: from palmer.demon.co.uk (palmer.demon.co.uk [158.152.50.150]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id NAA00302 for ; Tue, 2 Apr 1996 13:58:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by palmer.demon.co.uk (8.7.5/8.6.11) with SMTP id WAA01254 ; Tue, 2 Apr 1996 22:46:08 +0100 (BST) To: Bill Fenner cc: Garrett Wollman , FreeBSD-Current@FreeBSD.ORG From: "Gary Palmer" Subject: Re: Linker sets & structures for networking code In-reply-to: Your message of "Tue, 02 Apr 1996 09:53:17 PST." <96Apr2.095327pst.177475@crevenia.parc.xerox.com> Date: Tue, 02 Apr 1996 22:46:07 +0100 Message-ID: <1252.828481567@palmer.demon.co.uk> Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Bill Fenner wrote in message ID <96Apr2.095327pst.177475@crevenia.parc.xerox.com>: [ I wrote : ] > >>I can't see how raw_input ever gets call via the localsw > >>array. (Infact there are several examples of `raw_input' being called > >>which bypasses localsw totally). So why on earth is it there?!? > Good question. It probably doesn't belong there either. > (Have you grep'd for pr_input?) gary@palmer:~/cvswork/2.2/sys> grep pr_input */*.[ch] netinet/ip_input.c: (*inetsw[ip_protox[ip->ip_p]].pr_input)(m, hlen); netinet/ip_mroute.c: old_proto4_input = inetsw[ip_protox[ENCAP_PROTO]].pr_input; netinet/ip_mroute.c: inetsw[ip_protox[ENCAP_PROTO]].pr_input = X_ipip_input; netinet/ip_mroute.c: inetsw[ip_protox[ENCAP_PROTO]].pr_input = old_proto4_input; sys/protosw.h: * the pr_input and pr_output hooks. Pr_input passes data up (towards sys/protosw.h: void (*pr_input) __P((struct mbuf *, int len)); Huh. Looks like it's just used in the TCP/IP stuff for passing to the appropriate protocol handler. I think it's safe to assume then that the `raw_input' could be replaced with a `0' with no damage. Garrett? Any objections? Or should the entire `raw_*' section be ripped out of localsw? Gary From owner-freebsd-current Tue Apr 2 14:19:26 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA03148 for current-outgoing; Tue, 2 Apr 1996 14:19:26 -0800 (PST) Received: from horst.bfd.com ([204.160.242.10]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id OAA03143 for ; Tue, 2 Apr 1996 14:19:22 -0800 (PST) Received: from harlie.bfd.com (bastion.bfd.com [204.160.242.2]) by horst.bfd.com (8.7.3/8.7.3) with SMTP id OAA19732; Tue, 2 Apr 1996 14:18:05 -0800 (PST) Date: Tue, 2 Apr 1996 14:17:49 -0800 (PST) From: "Eric J. Schwertfeger" To: Cat Okita cc: John Polstra , jgreco@brasil.moneng.mei.com, current@FreeBSD.org Subject: Re: Advice/Recommendation needed In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 2 Apr 1996, Cat Okita wrote: > On Tue, 2 Apr 1996, John Polstra wrote: > > > > Wow! Things have changed a lot since I took geography in 4th grade. > > Back then, Canada was part of America. > > *BLECHK*...that's almost as bad as the person who thought that Ontario > was in Ohio!!! Nope. California. I know, I've flown in and out of it :-) (I promise, no more bad jokes on this thread). From owner-freebsd-current Tue Apr 2 14:29:58 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA03955 for current-outgoing; Tue, 2 Apr 1996 14:29:58 -0800 (PST) Received: from ki.net (root@ki.net [205.150.102.1]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id OAA03950 for ; Tue, 2 Apr 1996 14:29:49 -0800 (PST) Received: from localhost (scrappy@localhost) by ki.net (8.7.4/8.7.4) with SMTP id RAA03423 for ; Tue, 2 Apr 1996 17:29:34 -0500 (EST) Date: Tue, 2 Apr 1996 17:29:26 -0500 (EST) From: "Marc G. Fournier" To: current@freebsd.org Subject: Closing off PRs? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi... I'm just curious as to what is required to get Problem reports closed off. Looking at that URL that was just posted, there are problem reports in there that go back to 2.0-RELEASE. If its just a matter of someone willing to go through them all and closing off inapplicable ones, or contacting the submitters to see if they are still having the problem, I'm willing to dedicate time to it, just tell me what needs to be done :) Marc G. Fournier | POP Mail Telnet Acct DNS Hosting System | WWW Services Database Services | Knowledge, Administrator | | Information and scrappy@ki.net | WWW: http://www.ki.net | Communications, Inc From owner-freebsd-current Tue Apr 2 14:30:42 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA04081 for current-outgoing; Tue, 2 Apr 1996 14:30:42 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id OAA04068 Tue, 2 Apr 1996 14:30:38 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.7.5/8.6.12) with ESMTP id OAA23686; Tue, 2 Apr 1996 14:30:34 -0800 (PST) Message-Id: <199604022230.OAA23686@austin.polstra.com> To: phk@critter.tfs.com Cc: freebsd-current@freebsd.org, wosch@freebsd.org Subject: Re: make world broken Date: Tue, 02 Apr 1996 14:30:34 -0800 From: John Polstra Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I wrote: > It's caused by the recent changes to bsd.own.mk. In calendar/Makefile, > we have: > > SHAREDIR= /usr/share/calendar > > and then in bsd.own.mk, we have: > > SHAREDIR?= /usr/share (Ignored because of the ?=) > ... > MANDIR?= ${SHAREDIR}/man/man > > I'm cc-ing this to the person who committed the latest changes in > bsd.own.mk. Never mind, I've committed a fix to calendar/Makefile to solve this problem. I think the real bug was there, rather than in bsd.own.mk. -- 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 Apr 2 15:16:15 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA09258 for current-outgoing; Tue, 2 Apr 1996 15:16:15 -0800 (PST) Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA09250 Tue, 2 Apr 1996 15:16:12 -0800 (PST) Message-Id: <199604022316.PAA09250@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: Host localhost.cdrom.com [127.0.0.1] didn't use HELO protocol To: gshaffer@nosc.mil (Greg Shaffer) cc: current@FreeBSD.org, report@XFree86.org Subject: Re: Interesting XF86 Problem In-reply-to: Your message of "Tue, 02 Apr 1996 12:56:30 PST." Date: Tue, 02 Apr 1996 15:16:12 -0800 From: "Justin T. Gibbs" Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >My appologies for such a long e-mail, but here is an interesting problem >which has had me stumped for a week that I would appriciate some suggestion >on. You are probably triggerering a bug in the aic7xxx driver. I would suggest upgrading to 2.1-STABLE and seeing if your problem persists. There have been many bug fixes to that driver since 2.1R. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Tue Apr 2 16:07:04 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA14724 for current-outgoing; Tue, 2 Apr 1996 16:07:04 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id QAA14691 for ; Tue, 2 Apr 1996 16:06:53 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id JAA16572; Wed, 3 Apr 1996 09:59:46 +0930 From: Michael Smith Message-Id: <199604030029.JAA16572@genesis.atrad.adelaide.edu.au> Subject: Re: Huh? cc1 text file busy? To: kuku@gilberto.physik.rwth-aachen.de (Christoph P. Kukulies) Date: Wed, 3 Apr 1996 09:59:45 +0930 (CST) Cc: freebsd-current@freefall.freebsd.org In-Reply-To: <199604020815.KAA07931@gilberto.physik.rwth-aachen.de> from "Christoph P. Kukulies" at Apr 2, 96 10:15:08 am MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Christoph P. Kukulies stands accused of saying: > > I'm building a -current world and in parallel I wanted to build > a kernel on that same machine. This is what I suddenly got: > > Ouch, lost the paste buffer, anyway, make stopped > saying something like: > > /usr/libexec/cc1: text file busy Yeah, you tried to overwrite the compiler while it was running. Bad Idea; remember we page executables out of their files on disk, not out of swap. > --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de (We? Who am I kidding, it's JD and his bloody genius again 8) -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[ From owner-freebsd-current Tue Apr 2 16:35:17 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA18348 for current-outgoing; Tue, 2 Apr 1996 16:35:17 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id QAA18333 for ; Tue, 2 Apr 1996 16:35:09 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.7.5/8.6.12) with ESMTP id QAA24541; Tue, 2 Apr 1996 16:35:00 -0800 (PST) Message-Id: <199604030035.QAA24541@austin.polstra.com> To: j@uriah.heep.sax.de Cc: freebsd-current@FreeBSD.org Subject: Re: adjkerntz (was: cvs commit: src/usr.sbin/tzsetup ...) Date: Tue, 02 Apr 1996 16:34:59 -0800 From: John Polstra Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > > Btw., there have been many problem reports about bogus adjkerntz > > > activities here in Germany yesterday. (We had a DST switchover.) I > > > > It very depends on adjkerntz version. Old versions have a bugs. > > It was with a -current version, and -current timezone settings. So it > seems that new versions do also have bugs. ;) Speaking of bogus adjkerntz activities ... I notice that on two different systems (-current and -stable), there is an "adjkerntz -i" daemon that never terminates: 20 ?? Is 0:00.02 adjkerntz -i and also, "adjkerntz -a" is run periodically from /etc/crontab: 1,31 0-4 * * * root /sbin/adjkerntz -a Is this really what is supposed to be happening? If there's a persistent daemon, why must there also be separate periodic runs of the same program? -- 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 Apr 2 16:41:27 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA19061 for current-outgoing; Tue, 2 Apr 1996 16:41:27 -0800 (PST) Received: (from ache@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA19054 Tue, 2 Apr 1996 16:41:25 -0800 (PST) From: "Andrey A. Chernov" Message-Id: <199604030041.QAA19054@freefall.freebsd.org> Subject: Re: adjkerntz (was: cvs commit: src/usr.sbin/tzsetup ...) To: jdp@polstra.com (John Polstra) Date: Tue, 2 Apr 1996 16:41:25 -0800 (PST) Cc: j@uriah.heep.sax.de, freebsd-current@FreeBSD.org In-Reply-To: <199604030035.QAA24541@austin.polstra.com> from "John Polstra" at Apr 2, 96 04:34:59 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > > > > Btw., there have been many problem reports about bogus adjkerntz > > > > activities here in Germany yesterday. (We had a DST switchover.) I > > > > > > It very depends on adjkerntz version. Old versions have a bugs. > > > > It was with a -current version, and -current timezone settings. So it > > seems that new versions do also have bugs. ;) > > Speaking of bogus adjkerntz activities ... I notice that on two > different systems (-current and -stable), there is an "adjkerntz -i" > daemon that never terminates: > > 20 ?? Is 0:00.02 adjkerntz -i > > and also, "adjkerntz -a" is run periodically from /etc/crontab: > > 1,31 0-4 * * * root /sbin/adjkerntz -a > > Is this really what is supposed to be happening? If there's a persistent > daemon, why must there also be separate periodic runs of the same program? IMHO reading one screen of adjkerntz manpage is more quick thing then writting such letter. From owner-freebsd-current Tue Apr 2 16:50:10 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA19623 for current-outgoing; Tue, 2 Apr 1996 16:50:10 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id QAA19618 Tue, 2 Apr 1996 16:50:08 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.7.5/8.6.12) with ESMTP id QAA24634; Tue, 2 Apr 1996 16:50:07 -0800 (PST) Message-Id: <199604030050.QAA24634@austin.polstra.com> To: "Andrey A. Chernov" cc: j@uriah.heep.sax.de, freebsd-current@FreeBSD.org Subject: Re: adjkerntz (was: cvs commit: src/usr.sbin/tzsetup ...) In-reply-to: Your message of "Tue, 02 Apr 1996 16:41:25 PST." <199604030041.QAA19054@freefall.freebsd.org> Date: Tue, 02 Apr 1996 16:50:06 -0800 From: John Polstra Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > Is this really what is supposed to be happening? If there's a persistent > > daemon, why must there also be separate periodic runs of the same program? > > IMHO reading one screen of adjkerntz manpage is more quick thing > then writting such letter. IMHO the manual page is unclear. I read it over several times, and also looked at the source. Yet I still have this question. Your reply did nothing to change that. -- 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 Apr 2 17:02:00 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA20851 for current-outgoing; Tue, 2 Apr 1996 17:02:00 -0800 (PST) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id RAA20846 for ; Tue, 2 Apr 1996 17:01:55 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.7.5/8.6.9) id UAA01512; Tue, 2 Apr 1996 20:02:37 -0500 (EST) From: "John S. Dyson" Message-Id: <199604030102.UAA01512@dyson.iquest.net> Subject: Re: calcru: negative time: To: bde@zeta.org.au (Bruce Evans) Date: Tue, 2 Apr 1996 20:02:37 -0500 (EST) Cc: bde@zeta.org.au, freebsd-current@freefall.freebsd.org, kuku@gilberto.physik.rwth-aachen.de, phk@critter.tfs.com In-Reply-To: <199604021527.BAA29463@godzilla.zeta.org.au> from "Bruce Evans" at Apr 3, 96 01:27:15 am X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > >If there are some times where splhigh() is on for too long, that needs > >to be changed (we aren't using another interlock mechanism when we > >should be.) Splhigh is correct for it's intended purpose -- lock out > >ANY other access to the VM data structures. Splimp is just a hack in > > splvm() would be correct. splhigh() locks out access to _all_ data > structures. AFAIK, hardclock() doesn't touch any vm data. statclock() > touches some vm statistics. This could probably be handled without > locking so much. statclock() is careful not to touch user pages for > profiling ticks. This may depend on our fuswintr() and suswintr() > always failing so that profiling ticks aren't added immediately. > So we should probably make splvm: net_imask|bio_imask|tty_imask??? (Keeping tty_imask mostly because of the possibility of some time in the future, the tty code needing to do malloc(s)?) > > slimp() doesn't contain splbio(), so it must have once been safe to > handle disk interrupts in the middle of vm operations. Has this changed? > splhigh() is more or less the union of splimp() (which is usually >= > spltty() due to other bogins), splbio() and the clock part of splclock(), > so the switching from splimp() to splhigh() was essentially adding the > masking of bio interrupts together with (unnessarily I hope) adding the > masking of clock interrupts. > We probably need to keep bio_imask until we come up with a good kernel threading mechanism. Right now, I/O completion can cause manipulation of the pages/page_queues (bio_imask, and perhaps net_imask.) Really, if we wanted to optimize the situation, we could limit the malloc code to net_imask (I don't think that anything else mallocs at interrupt level), and the rest of the VM to net_imask|bio_imask? However, we need to document that very very carefully for future maintainers. John From owner-freebsd-current Tue Apr 2 18:55:51 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA29085 for current-outgoing; Tue, 2 Apr 1996 18:55:51 -0800 (PST) Received: from haywire.DIALix.COM (root@haywire.DIALix.COM [192.203.228.65]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id SAA28494 for ; Tue, 2 Apr 1996 18:49:23 -0800 (PST) Received: (from news@localhost) by haywire.DIALix.COM (8.7.5/8.7.3) id KAA17481 for freebsd-current@freebsd.org; Wed, 3 Apr 1996 10:48:22 +0800 (WST) X-Authentication-Warning: haywire.DIALix.COM: news set sender to usenet-request@haywire.dialix.com using -f Received: from GATEWAY by haywire.DIALix.COM with netnews for freebsd-current@freebsd.org (problems to: usenet@haywire.dialix.com) To: freebsd-current@freebsd.org Date: 2 Apr 96 15:35:41 GMT From: peter@jhome.DIALix.COM (Peter Wemm) Message-ID: Organization: DIALix Services, Perth, Australia. References: (Warner, Losh), <199604010342.UAA11579@rover.village.org> Subject: Re: We need to do another XFree86 release for -current someday soon.. Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk imp@village.org (Warner Losh) writes: [...] >If there are *OTHER* reasons or plans that will require a major rev >bump, please let communicate that fact. If that is indeed the plans, >then there is no reason to continue this debate, since we gotta do it. [...] Another likely candidate for needing the 2.2->3.0 revision bump is that we may use the 4.4Lite-2 calling sequence for getvfsbyname(). Also, the mmap() etc syscalls have changed types, but I dont think there's a real incompatability there.. >Warner -Peter From owner-freebsd-current Tue Apr 2 19:00:49 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id TAA29761 for current-outgoing; Tue, 2 Apr 1996 19:00:49 -0800 (PST) Received: from mramirez.sy.yale.edu (mramirez.sy.yale.edu [130.132.57.207]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id TAA29754 for ; Tue, 2 Apr 1996 19:00:35 -0800 (PST) Received: (from mrami@localhost) by mramirez.sy.yale.edu (8.6.12/8.6.9) id WAA04645; Tue, 2 Apr 1996 22:00:40 -0500 Date: Tue, 2 Apr 1996 22:00:39 -0500 (EST) From: Marc Ramirez Reply-To: mrami@minerva.cis.yale.edu To: Terry Lambert cc: Jeff Ehrenkrantz , phk@critter.tfs.com, cat@ghost.uunet.ca, current@freebsd.org Subject: Re: Advice/Recommendation needed In-Reply-To: <199604022103.OAA17082@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 2 Apr 1996, Terry Lambert wrote: > > Carefullll what you ask for Poul! I'm reminded of a frog at the end of a > > large runway thinking 'gee if I could only get my tongue around that big ass > > fly' > > With respect, Poul is a big ass frog. I didn't know Poul was French! Wow... Marc (running and ducking). (Hey, I can say that! My mom is a Bouvier!) -- "Always try to do things in chronological order; it's less confusing that way." From owner-freebsd-current Tue Apr 2 20:04:28 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id UAA06657 for current-outgoing; Tue, 2 Apr 1996 20:04:28 -0800 (PST) Received: from ambrisko.roble.com (ambrisko@netcom7.netcom.com [192.100.81.115]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id UAA06649 for ; Tue, 2 Apr 1996 20:04:20 -0800 (PST) Received: from big.ambrisko.com (big [1.1.1.4]) by ambrisko.roble.com (8.6.12/8.6.9) with ESMTP id TAA29047 for ; Tue, 2 Apr 1996 19:57:27 -0800 Received: (from ambrisko@localhost) by big.ambrisko.com (8.7.5/8.6.9) id TAA00820 for freebsd-current@freebsd.org; Tue, 2 Apr 1996 19:56:49 -0800 (PST) Message-Id: <199604030356.TAA00820@big.ambrisko.com> Subject: iijppp chat.c patch To: freebsd-current@freebsd.org Date: Tue, 2 Apr 1996 19:56:48 -0800 (PST) From: "Doug Ambrisko" X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Here is a patch for a little bug in the WaitForString routine. The problem is when the matched string spans the end of the inbuff. This fix allocates twice the IBSIZE so that it can keep the last and the current text to search in the inbuff so that the match won't fail if it gets truncated by the read. It also warns if the search string is to long and truncates it. Doug A. *** chat.c.orig Thu Mar 28 18:59:09 1996 --- chat.c Tue Apr 2 19:48:41 1996 *************** *** 45,51 **** static int abort_next, timeout_next; static int numaborts; char *AbortStrings[50]; ! char inbuff[IBSIZE]; extern int ChangeParity(char *); --- 45,51 ---- static int abort_next, timeout_next; static int numaborts; char *AbortStrings[50]; ! char inbuff[IBSIZE*2+1]; extern int ChangeParity(char *); *************** *** 209,214 **** --- 209,219 ---- str = buff; inp = inbuff; + if (strlen(str)>=IBSIZE){ + str[IBSIZE]=0; + LogPrintf(LOG_CHAT, "Truncating String to %d character: %s\n", IBSIZE, str); + } + nfds = modem + 1; s = str; for (;;) { *************** *** 245,252 **** } if (FD_ISSET(modem, &rfds)) { /* got something */ if (DEV_IS_SYNC) { ! nb = read(modem, inbuff, IBSIZE-1); ! inbuff[nb] = 0; if (strstr(inbuff, str)) { #ifdef SIGALRM sigsetmask(omask); --- 250,262 ---- } if (FD_ISSET(modem, &rfds)) { /* got something */ if (DEV_IS_SYNC) { ! int length; ! if ((length=strlen(inbuff))>IBSIZE){ ! bcopy(&(inbuff[IBSIZE]),inbuff,IBSIZE+1); /* shuffle down next part*/ ! length=strlen(inbuff); ! } ! nb = read(modem, &(inbuff[length]), IBSIZE); ! inbuff[nb + length] = 0; if (strstr(inbuff, str)) { #ifdef SIGALRM sigsetmask(omask); From owner-freebsd-current Tue Apr 2 21:25:06 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA13467 for current-outgoing; Tue, 2 Apr 1996 21:25:06 -0800 (PST) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id VAA13458 for ; Tue, 2 Apr 1996 21:25:04 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.7.5/8.6.9) id AAA03206 for current@freebsd.org; Wed, 3 Apr 1996 00:26:04 -0500 (EST) From: "John S. Dyson" Message-Id: <199604030526.AAA03206@dyson.iquest.net> Subject: Warning to current users To: current@freebsd.org Date: Wed, 3 Apr 1996 00:26:04 -0500 (EST) X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk With the recent commit to pmap.h, you'll need to rebuild at least libkvm and ps. Sorry!!! John From owner-freebsd-current Tue Apr 2 21:39:35 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA14806 for current-outgoing; Tue, 2 Apr 1996 21:39:35 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id VAA14801 for ; Tue, 2 Apr 1996 21:39:32 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id WAA18246; Tue, 2 Apr 1996 22:33:48 -0700 From: Terry Lambert Message-Id: <199604030533.WAA18246@phaeton.artisoft.com> Subject: Re: Huh? cc1 text file busy? To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Tue, 2 Apr 1996 22:33:48 -0700 (MST) Cc: kuku@gilberto.physik.rwth-aachen.de, freebsd-current@freefall.freebsd.org In-Reply-To: <199604030029.JAA16572@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Apr 3, 96 09:59:45 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-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Yeah, you tried to overwrite the compiler while it was running. Bad Idea; > remember we page executables out of their files on disk, not out of swap. > > (We? Who am I kidding, it's JD and his bloody genius again 8) I think you'll find that it was standard practice, even for 386BSD 0.1, which is a Mach-derived VM. This is typical of overcommit architectures. JD has done lots of wonderful, innovative other stuff, though. 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 Apr 2 22:21:57 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA21383 for current-outgoing; Tue, 2 Apr 1996 22:21:57 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id WAA21218 for ; Tue, 2 Apr 1996 22:21:25 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id IAA05856 for ; Wed, 3 Apr 1996 08:20:58 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id IAA09625 for freebsd-current@FreeBSD.org; Wed, 3 Apr 1996 08:20:58 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id IAA14691 for freebsd-current@FreeBSD.org; Wed, 3 Apr 1996 08:16:04 +0200 (MET DST) From: J Wunsch Message-Id: <199604030616.IAA14691@uriah.heep.sax.de> Subject: Re: Closing off PRs? To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Wed, 3 Apr 1996 08:16:03 +0200 (MET DST) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from "Marc G. Fournier" at Apr 2, 96 05:29:26 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Marc G. Fournier wrote: > I'm just curious as to what is required to get Problem reports > closed off. 1) Fix the problem, or get confirmation that it doesn't happen anymore :) 2) edit-pr --> replace `open' by `closed' 3) note the CVS file name and revision number where the fix has been applied (as an xref, normally the CVS log should tell the PR that is closed by the change) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Tue Apr 2 22:37:46 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA23785 for current-outgoing; Tue, 2 Apr 1996 22:37:46 -0800 (PST) Received: from nixpbe.pdb.sni.de (mail.sni.de [192.109.2.33]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id WAA23769 for ; Tue, 2 Apr 1996 22:37:37 -0800 (PST) Received: (from nerv@localhost) by nixpbe.pdb.sni.de (8.6.12/8.6.12) id HAA13286 for current@freebsd.org; Wed, 3 Apr 1996 07:18:28 +0200 Message-Id: <199604030518.HAA13286@nixpbe.pdb.sni.de> Subject: Re: Advice/Recommendation needed To: cat@ghost.uunet.ca (Cat Okita) Date: Wed, 3 Apr 96 8:34:01 MET DST From: Greg Lehey Cc: jdp@polstra.com, jgreco@brasil.moneng.mei.com, current@freebsd.org In-Reply-To: ; from "Cat Okita" at Apr 2, 96 2:36 pm X-Mailer: xmail 2.4 (based on ELM 2.2 PL16) Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > On Tue, 2 Apr 1996, John Polstra wrote: >> >> Wow! Things have changed a lot since I took geography in 4th grade. >> Back then, Canada was part of America. > > *BLECHK*...that's almost as bad as the person who thought that Ontario > was in Ohio!!! I thought Canada still was in America. It's just the strange viewpoint of the inhabitants of the USA that America stops at its borders. Why the Canadians should agree with this viewpoint is beyond me. Greg From owner-freebsd-current Tue Apr 2 22:55:01 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA26019 for current-outgoing; Tue, 2 Apr 1996 22:55:01 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id WAA25782 for ; Tue, 2 Apr 1996 22:53:18 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id IAA06598 for ; Wed, 3 Apr 1996 08:51:00 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id IAA09809 for freebsd-current@FreeBSD.org; Wed, 3 Apr 1996 08:50:59 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id IAA14818 for freebsd-current@FreeBSD.org; Wed, 3 Apr 1996 08:25:11 +0200 (MET DST) From: J Wunsch Message-Id: <199604030625.IAA14818@uriah.heep.sax.de> Subject: Re: Huh? cc1 text file busy? To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Wed, 3 Apr 1996 08:25:10 +0200 (MET DST) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199604030029.JAA16572@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Apr 3, 96 09:59:45 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Michael Smith wrote: > > /usr/libexec/cc1: text file busy > > Yeah, you tried to overwrite the compiler while it was running. Bad Idea; > remember we page executables out of their files on disk, not out of swap. Nevertheless, it's supposed to be unlinked before. (Otherwise, you could never re-install the world, at least /sbin/init is always ``busy''.) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Tue Apr 2 23:38:50 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA03068 for current-outgoing; Tue, 2 Apr 1996 23:38:50 -0800 (PST) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA03033 for ; Tue, 2 Apr 1996 23:38:42 -0800 (PST) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id XAA05037; Tue, 2 Apr 1996 23:37:03 -0800 From: "Rodney W. Grimes" Message-Id: <199604030737.XAA05037@GndRsh.aac.dev.com> Subject: Re: calcru: negative time: To: toor@dyson.iquest.net (John S. Dyson) Date: Tue, 2 Apr 1996 23:37:03 -0800 (PST) Cc: bde@zeta.org.au, freebsd-current@freefall.freebsd.org, kuku@gilberto.physik.rwth-aachen.de, phk@critter.tfs.com In-Reply-To: <199604030102.UAA01512@dyson.iquest.net> from "John S. Dyson" at "Apr 2, 96 08:02:37 pm" X-Mailer: ELM [version 2.4ME+ PL11 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > > >If there are some times where splhigh() is on for too long, that needs > > >to be changed (we aren't using another interlock mechanism when we > > >should be.) Splhigh is correct for it's intended purpose -- lock out > > >ANY other access to the VM data structures. Splimp is just a hack in > > > > splvm() would be correct. splhigh() locks out access to _all_ data > > structures. AFAIK, hardclock() doesn't touch any vm data. statclock() > > touches some vm statistics. This could probably be handled without > > locking so much. statclock() is careful not to touch user pages for > > profiling ticks. This may depend on our fuswintr() and suswintr() > > always failing so that profiling ticks aren't added immediately. > > > So we should probably make splvm: net_imask|bio_imask|tty_imask??? > (Keeping tty_imask mostly because of the possibility of some time in the > future, the tty code needing to do malloc(s)?) > > > > > slimp() doesn't contain splbio(), so it must have once been safe to > > handle disk interrupts in the middle of vm operations. Has this changed? > > splhigh() is more or less the union of splimp() (which is usually >= > > spltty() due to other bogins), splbio() and the clock part of splclock(), > > so the switching from splimp() to splhigh() was essentially adding the > > masking of bio interrupts together with (unnessarily I hope) adding the > > masking of clock interrupts. > > > We probably need to keep bio_imask until we come up with a good kernel threading > mechanism. Right now, I/O completion can cause manipulation of the > pages/page_queues (bio_imask, and perhaps net_imask.) > > Really, if we wanted to optimize the situation, we could limit the malloc > code to net_imask (I don't think that anything else mallocs at interrupt > level), and the rest of the VM to net_imask|bio_imask? However, > we need to document that very very carefully for future maintainers. If I am not mistaken one of the potential panic sources from the ccd driver is the fact that it does need to be able to malloc at interrupt time, though that can probably be worked around by pre allocating the buffer before releasing the I/O's. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Wed Apr 3 00:11:27 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA09035 for current-outgoing; Wed, 3 Apr 1996 00:11:27 -0800 (PST) Received: from nixpbe.pdb.sni.de (mail.sni.de [192.109.2.33]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id AAA09018 for ; Wed, 3 Apr 1996 00:11:14 -0800 (PST) Received: (from nerv@localhost) by nixpbe.pdb.sni.de (8.6.12/8.6.12) id IAA19184 for freebsd-current@FreeBSD.ORG; Wed, 3 Apr 1996 08:52:09 +0200 Message-Id: <199604030652.IAA19184@nixpbe.pdb.sni.de> Subject: Re: Huh? cc1 text file busy? To: joerg_wunsch@uriah.heep.sax.de Date: Wed, 3 Apr 96 10:07:44 MET DST From: Greg Lehey Cc: freebsd-current@FreeBSD.ORG In-Reply-To: <199604030625.IAA14818@uriah.heep.sax.de>; from "J Wunsch" at Apr 3, 96 8:25 am X-Mailer: xmail 2.4 (based on ELM 2.2 PL16) Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > As Michael Smith wrote: > >> > /usr/libexec/cc1: text file busy >> >> Yeah, you tried to overwrite the compiler while it was running. Bad Idea; >> remember we page executables out of their files on disk, not out of swap. > > Nevertheless, it's supposed to be unlinked before. (Otherwise, you > could never re-install the world, at least /sbin/init is always > ``busy''.) That seems to work. That will stop currently running processes from crashing; it doesn't help exec when it finds a partial object file. Greg From owner-freebsd-current Wed Apr 3 00:14:17 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA09622 for current-outgoing; Wed, 3 Apr 1996 00:14:17 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id AAA09607 for ; Wed, 3 Apr 1996 00:14:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with SMTP id AAA00494; Wed, 3 Apr 1996 00:11:46 -0800 (PST) To: Cat Okita cc: current@freebsd.org Subject: Re: Advice/Recommendation needed In-reply-to: Your message of "Mon, 01 Apr 1996 14:39:56 EST." Date: Wed, 03 Apr 1996 00:11:45 -0800 Message-ID: <492.828519105@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I *need* to know that I've got a support contract for the OS, and have > someone to hang out the window if things aren't working. (Hell - someone > to sue, if it comes to that). I certainly would be the last to dispute that, though I must at least caution you against putting too much store in support contracts. There is NO substitute for local expertise, and if you expect that a tech support number is going to save your bacon even 3 times out of 5 then I'm sure that many of the other folks on this list will be more than happy to tell you their war stories. As far as litigation goes, by the time you get that far things have also generally passed the point of no return anyway and, short of perhaps making you feel slightly vindicated, generally won't have much of a positive effect - by then your business is suffering mightily and your court case may well drag on for years anyway. Having someone to sue is not all it's cracked up to be. So while your points are all generally valid, I can only point out that your mileage may vary so considerably in different situations that the gap between theory and operations can be very wide indeed. I can only once more recommend local expertise in ALL situations as the only way to truly be sure that your business will not suffer at the caprice of some outside agency, be it one free or commercial. Jordan From owner-freebsd-current Wed Apr 3 00:26:57 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA11835 for current-outgoing; Wed, 3 Apr 1996 00:26:57 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id AAA11830 for ; Wed, 3 Apr 1996 00:26:55 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0u4Nsn-0003vsC; Wed, 3 Apr 96 00:25 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id IAA00324; Wed, 3 Apr 1996 08:25:30 GMT X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: Greg Lehey cc: cat@ghost.uunet.ca (Cat Okita), jdp@polstra.com, jgreco@brasil.moneng.mei.com, current@freebsd.org Subject: Re: Advice/Recommendation needed In-reply-to: Your message of "Wed, 03 Apr 1996 08:34:01 +0700." <199604030518.HAA13286@nixpbe.pdb.sni.de> Date: Wed, 03 Apr 1996 08:25:29 +0000 Message-ID: <322.828519929@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > [...] It's just the strange > viewpoint of the inhabitants of the USA that America stops at its > borders. s/America/The World as such/ And please move to chat@freebsd.org, thankyou. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Wed Apr 3 01:08:06 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA16880 for current-outgoing; Wed, 3 Apr 1996 01:08:06 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id BAA16852 for ; Wed, 3 Apr 1996 01:07:58 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id SAA19962; Wed, 3 Apr 1996 18:47:44 +0930 From: Michael Smith Message-Id: <199604030917.SAA19962@genesis.atrad.adelaide.edu.au> Subject: Re: Huh? cc1 text file busy? To: joerg_wunsch@uriah.heep.sax.de Date: Wed, 3 Apr 1996 18:47:44 +0930 (CST) Cc: freebsd-current@FreeBSD.ORG In-Reply-To: <199604030625.IAA14818@uriah.heep.sax.de> from "J Wunsch" at Apr 3, 96 08:25:10 am MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk J Wunsch stands accused of saying: > > As Michael Smith wrote: > > > > /usr/libexec/cc1: text file busy > > > > Yeah, you tried to overwrite the compiler while it was running. Bad Idea; > > remember we page executables out of their files on disk, not out of swap. > > Nevertheless, it's supposed to be unlinked before. (Otherwise, you > could never re-install the world, at least /sbin/init is always > ``busy''.) Bizarre. Is it possible that unlink() is failing with some error and being ignored? There aren't any flags set on /usr/libexec/cc1 here. > cheers, J"org -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[ From owner-freebsd-current Wed Apr 3 01:24:05 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA17466 for current-outgoing; Wed, 3 Apr 1996 01:24:05 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id BAA17363 for ; Wed, 3 Apr 1996 01:23:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with SMTP id BAA02951; Wed, 3 Apr 1996 01:19:14 -0800 (PST) To: John Polstra cc: jgreco@brasil.moneng.mei.com, cat@ghost.uunet.ca, current@FreeBSD.org Subject: Re: Advice/Recommendation needed In-reply-to: Your message of "Tue, 02 Apr 1996 11:50:30 PST." <199604021950.LAA22683@austin.polstra.com> Date: Wed, 03 Apr 1996 01:19:14 -0800 Message-ID: <2949.828523154@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Wow! Things have changed a lot since I took geography in 4th grade. > Back then, Canada was part of America. Oh, it still is.. There are still a few sadly deluded individuals up there who think they're an autonomous country but most really know that we could march in with the marines any time we liked and take the whole beaver-worshiping place over, assuming that we had a sudden need for lots of trees and a bunch of people who speak a mangled dialect of French.. :-) :-) Jordan P.S. Yes, yes, I'm just joking! I love canada! Please don't send down the mounties! :) From owner-freebsd-current Wed Apr 3 02:27:17 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA00760 for current-outgoing; Wed, 3 Apr 1996 02:27:17 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id CAA00719 for ; Wed, 3 Apr 1996 02:27:10 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by who.cdrom.com (8.6.12/8.6.11) with SMTP id BAA25111 for ; Wed, 3 Apr 1996 01:26:33 -0800 Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0u4OoW-0003vlC; Wed, 3 Apr 96 01:25 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id JAA00494; Wed, 3 Apr 1996 09:25:14 GMT X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: "Jordan K. Hubbard" cc: Cat Okita , current@FreeBSD.ORG Subject: Re: Advice/Recommendation needed In-reply-to: Your message of "Wed, 03 Apr 1996 00:11:45 PST." <492.828519105@time.cdrom.com> Date: Wed, 03 Apr 1996 09:25:13 +0000 Message-ID: <492.828523513@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I *need* to know that I've got a support contract for the OS, and have > > someone to hang out the window if things aren't working. (Hell - someone > > to sue, if it comes to that). > > I can only once more recommend local expertise in ALL situations as the > only way to truly be sure that your business will not suffer at the > caprice of some outside agency, be it one free or commercial. I am 100% in agreement with Jordan here. On the other hand, I can easily imagine that a support organization could still be a nice thing to have. First of all, sometimes the size of the hammer or the mind behind it makes a difference, but second, sometimes local expertise just isn't there at the moment, "Nepal ? What do you mean holiday i Nepal ?? The server is down!! and I mean DOWN!!!! What's the number of that Nepal embassy ???" We generally respond as fast as we can, and I don't think many people have been left behind, unless we simply couldn't do anyting about their problem (ie, insufficient info, special/buggy HW). But I can see that from time to time, somebody might want to skew the priority a bit at the expense of some cash to get their problem fixed, and get it fixed >right now<. Of course if there is a market for that kind of support, I for one is more than happy to help fill it, and I'm sure we could get a company set up and all that. If you have any input on this, please send us email (core@freebsd.org) and we will see what we can do. On the other hand I'm pretty sure that if you were to send an email to core@freebsd.org along the lines of "We will donate $N to FreeBSD if you guys will please help us out of with this problem ASAP" somebody would be on the problem pretty soon. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Wed Apr 3 03:14:05 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA17466 for current-outgoing; Wed, 3 Apr 1996 01:24:05 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id BAA17363 for ; Wed, 3 Apr 1996 01:23:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with SMTP id BAA02951; Wed, 3 Apr 1996 01:19:14 -0800 (PST) To: John Polstra cc: jgreco@brasil.moneng.mei.com, cat@ghost.uunet.ca, current@FreeBSD.ORG Subject: Re: Advice/Recommendation needed In-reply-to: Your message of "Tue, 02 Apr 1996 11:50:30 PST." <199604021950.LAA22683@austin.polstra.com> Date: Wed, 03 Apr 1996 01:19:14 -0800 Message-ID: <2949.828523154@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Wow! Things have changed a lot since I took geography in 4th grade. > Back then, Canada was part of America. Oh, it still is.. There are still a few sadly deluded individuals up there who think they're an autonomous country but most really know that we could march in with the marines any time we liked and take the whole beaver-worshiping place over, assuming that we had a sudden need for lots of trees and a bunch of people who speak a mangled dialect of French.. :-) :-) Jordan P.S. Yes, yes, I'm just joking! I love canada! Please don't send down the mounties! :) From owner-freebsd-current Wed Apr 3 04:26:27 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA09583 for current-outgoing; Wed, 3 Apr 1996 04:26:27 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id EAA09570 for ; Wed, 3 Apr 1996 04:26:23 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id WAA17145; Wed, 3 Apr 1996 22:15:32 +1000 Date: Wed, 3 Apr 1996 22:15:32 +1000 From: Bruce Evans Message-Id: <199604031215.WAA17145@godzilla.zeta.org.au> To: bde@zeta.org.au, toor@dyson.iquest.net Subject: Re: calcru: negative time: Cc: freebsd-current@freefall.freebsd.org, kuku@gilberto.physik.rwth-aachen.de, phk@critter.tfs.com Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >So we should probably make splvm: net_imask|bio_imask|tty_imask??? >(Keeping tty_imask mostly because of the possibility of some time in the >future, the tty code needing to do malloc(s)?) It's convenient to be able to call malloc(), but the prices is high: higher latency and more races to avoid and more bugs when you don't avoid the races. I'd like to make splvm() a no-op or splsoftclock() (mask only timeouts). I think splimp() _was_ completely correct because only the network interrupt handlers abused malloc(). This is stupid because the network drivers can afford to drop packets while the tty drivers can't, and the mallocations are mainly (only?) used to grow the pool of mbuf clusters so the only benefit is that the pool takes longer to reach its limit. >Really, if we wanted to optimize the situation, we could limit the malloc >code to net_imask (I don't think that anything else mallocs at interrupt >level), and the rest of the VM to net_imask|bio_imask? However, >we need to document that very very carefully for future maintainers. Like malloc(3) is very very carefully documented to not work in signal handlers? ;-) Bruce From owner-freebsd-current Wed Apr 3 05:32:47 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA15574 for current-outgoing; Wed, 3 Apr 1996 05:32:47 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id FAA15567 for ; Wed, 3 Apr 1996 05:32:45 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0u4Seb-0003voC; Wed, 3 Apr 96 05:31 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id NAA01011; Wed, 3 Apr 1996 13:31:13 GMT X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: Bruce Evans cc: toor@dyson.iquest.net, freebsd-current@freefall.freebsd.org, kuku@gilberto.physik.rwth-aachen.de Subject: Re: calcru: negative time: In-reply-to: Your message of "Wed, 03 Apr 1996 22:15:32 +1000." <199604031215.WAA17145@godzilla.zeta.org.au> Date: Wed, 03 Apr 1996 13:31:11 +0000 Message-ID: <1009.828538271@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Like malloc(3) is very very carefully documented to not work in signal > handlers? ;-) yeah, right, and people keep making signal handlers along the lines of: sighup() { printf("Ignoring sighub, why did you do that ???\n"); } :-( I don't see the problem in the kernel, if the net code calls malloc, worst case malloc will go to the VM system and ask for space, if the vm system is already locked (splvm or otherwise) it will fail, and (hopefully) malloc was called with NOWAIT so everything is fine, apart from the dropped packets. Anyway, what I really wanted to come down to, is that we should start to look at locks around actual specific datastructures, rather than these global locks, SMP/AMP will be here soon, and we need to address this problem then. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Wed Apr 3 05:51:37 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA16571 for current-outgoing; Wed, 3 Apr 1996 05:51:37 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id FAA16547 for ; Wed, 3 Apr 1996 05:51:16 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id PAA29019 for ; Wed, 3 Apr 1996 15:50:43 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id PAA13269 for freebsd-current@FreeBSD.org; Wed, 3 Apr 1996 15:50:42 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id PAA16138 for freebsd-current@FreeBSD.org; Wed, 3 Apr 1996 15:36:35 +0200 (MET DST) From: J Wunsch Message-Id: <199604031336.PAA16138@uriah.heep.sax.de> Subject: Re: Huh? cc1 text file busy? To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Wed, 3 Apr 1996 15:36:35 +0200 (MET DST) In-Reply-To: <199604030917.SAA19962@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Apr 3, 96 06:47:44 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Michael Smith wrote: > > Nevertheless, it's supposed to be unlinked before. (Otherwise, you > > could never re-install the world, at least /sbin/init is always > > ``busy''.) > > Bizarre. Is it possible that unlink() is failing with some error and > being ignored? You should always be able to unlink() a directory entry. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Wed Apr 3 05:59:54 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA18029 for current-outgoing; Wed, 3 Apr 1996 05:59:54 -0800 (PST) Received: from ghost.uunet.ca (ghost.uunet.ca [142.77.1.100]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id FAA18024 for ; Wed, 3 Apr 1996 05:59:51 -0800 (PST) Received: by ghost.uunet.ca id <59602-1>; Wed, 3 Apr 1996 08:39:34 -0500 Date: Wed, 3 Apr 1996 08:39:30 -0500 From: Cat Okita To: Greg Lehey cc: jdp@polstra.com, jgreco@brasil.moneng.mei.com, current@freebsd.org Subject: Re: Advice/Recommendation needed In-Reply-To: <199604030518.HAA13265@nixpbe.pdb.sni.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 3 Apr 1996, Greg Lehey wrote: > I thought Canada still was in America. It's just the strange > viewpoint of the inhabitants of the USA that America stops at its > borders. Why the Canadians should agree with this viewpoint is beyond > me. Canada is in America as much as Switzerland or France is in Germay. Canada is in *North* America, but that's a slightly different kettle of fish...(talbot, of course :>) Cat From owner-freebsd-current Wed Apr 3 06:24:55 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA24393 for current-outgoing; Wed, 3 Apr 1996 06:24:55 -0800 (PST) Received: from sovcom.kiae.su (sovcom.kiae.su [144.206.136.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id GAA24374 for ; Wed, 3 Apr 1996 06:24:43 -0800 (PST) Received: by sovcom.kiae.su id AA06352 (5.65.kiae-1 ); Wed, 3 Apr 1996 17:20:54 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Wed, 3 Apr 96 17:20:53 +0300 Received: (from ache@localhost) by astral.msk.su (8.7.5/8.7.3) id RAA04490; Wed, 3 Apr 1996 17:48:29 +0400 (MSD) Message-Id: <199604031348.RAA04490@astral.msk.su> Subject: Re: adjkerntz (was: cvs commit: src/usr.sbin/tzsetup ...) To: jdp@polstra.com (John Polstra) Date: Wed, 3 Apr 1996 17:48:29 +0400 (MSD) Cc: ache@freefall.freebsd.org, j@uriah.heep.sax.de, freebsd-current@FreeBSD.org In-Reply-To: <199604030050.QAA24634@austin.polstra.com> from "John Polstra" at "Apr 2, 96 04:50:06 pm" From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast X-Mailer: ELM [version 2.4ME+ PL14 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > > Is this really what is supposed to be happening? If there's a persistent > > > daemon, why must there also be separate periodic runs of the same program? > > > > IMHO reading one screen of adjkerntz manpage is more quick thing > > then writting such letter. > > IMHO the manual page is unclear. I read it over several times, and also > looked at the source. Yet I still have this question. Your reply did > nothing to change that. Well, as I remember, your question is: does both "adjkerntz -i" daemon and "adjkerntz -a" from crontab is valid? -or- >Is this really what is supposed to be happening? Here is manpage quote: --ii initialization call from _/_e_t_c_/_r_c (before any daemons are started). AAddjjkkeerrnnttzz makes the adjustment of kernel clock (CMOS clock not touched) and the initial time zone offset is stored into _a_d_j_k_e_r_n_t_z kernel variable for following subsequent ''aaddjjkkeerrnnttzz --aa'' calls. Then it goes to background pause which ends with SIGTERM. After receiv- ing SIGTERM it acts like ''aaddjjkkeerrnnttzz --aa'' to insure that the CMOS clock reflects the current local time zone. Without going deep into adjkerntz internal logic words here clearly assumed that "YES". Maybe english here not the best one, but I am not native english speaker, sorry. Feel free to change it to better/clear variant. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-current Wed Apr 3 06:30:48 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA24838 for current-outgoing; Wed, 3 Apr 1996 06:30:48 -0800 (PST) Received: from sovcom.kiae.su (sovcom.kiae.su [144.206.136.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id GAA24824 for ; Wed, 3 Apr 1996 06:30:36 -0800 (PST) Received: by sovcom.kiae.su id AA06724 (5.65.kiae-1 ); Wed, 3 Apr 1996 17:22:04 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Wed, 3 Apr 96 17:22:04 +0300 Received: (from ache@localhost) by astral.msk.su (8.7.5/8.7.3) id SAA04539; Wed, 3 Apr 1996 18:06:30 +0400 (MSD) Message-Id: <199604031406.SAA04539@astral.msk.su> Subject: Re: adjkerntz (was: cvs commit: src/usr.sbin/tzsetup ...) To: j@uriah.heep.sax.de (J Wunsch) Date: Wed, 3 Apr 1996 18:06:30 +0400 (MSD) Cc: freebsd-current@FreeBSD.org In-Reply-To: <199604021755.TAA10217@uriah.heep.sax.de> from "J Wunsch" at "Apr 2, 96 07:55:56 pm" From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast X-Mailer: ELM [version 2.4ME+ PL14 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > As =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= wrote: > > msdosfs? MSDOS' idea of a timezone is broken by design (i.e., it > doesn't have an idea about it at all). Someone in Australia could It have an idea: local time zone. Win3*/Win95 have the similar idea. > send a file with a DOS timestamp to somebody in California across the > Internet, and the recipient will see a file that appears to be written > ``in the future''. It fixed in some communication packages like DOS Zmodem from Omen. They use timezone offset variable. > I don't see how adjkerntz should fix it. Since DOS files don't have > an explicit timezone, you can imply any time zone you want, so > applying the kernel's idea (UTC) seems to be most logical. (Note that > this might conflict with the idea of your local DOS, but applying the msdosfs use adjkerntz kernel variable to calculate local timezone for DOS files, check msdosfs sources. adjkerntz kernel variable maintained by adjkerntz uility. I plan to run adjkerntz utility in any case, i.e. for UTC clock too without touching RTC or kernel time but maintain adjkerntz kernel variable only for msdosfs and similar filesystems with local timezone. > localtime does as well conflict with the idea of any other DOS not > running in *your* localtime zone.) Proper DOS/Windows software sends timezone offset of your DOS with any file times. > To be honest, even in cases where i run DOS every now and then, i > simply don't care for its broken idea of a timezone. I live with it > running in UTC then. Your choice. If you'll run Win95 on the same computer (like I do) and use Internet connection to ouside world, you don't think so. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-current Wed Apr 3 06:52:46 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA26675 for current-outgoing; Wed, 3 Apr 1996 06:52:46 -0800 (PST) Received: from ns0.netcraft.co.uk (ns0.netcraft.co.uk [194.72.238.4]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id GAA26646 for ; Wed, 3 Apr 1996 06:52:32 -0800 (PST) Received: (from news@localhost) by ns0.netcraft.co.uk (8.7.4/8.6.9) id PAA25204; Wed, 3 Apr 1996 15:51:13 +0100 (BST) To: freebsd-current@freebsd.org Path: usenet From: jez@netcraft.co.uk (Jeremy Prior) Newsgroups: netcraft.freebsd-current Subject: cmsg cancel <199604031122.MAA15556@ns0.netcraft.co.uk> Control: cancel <199604031122.MAA15556@ns0.netcraft.co.uk> Date: 3 Apr 1996 14:51:12 GMT Organization: Netcraft Ltd. Lines: 8 Message-ID: <4ju390$oji@ns0.netcraft.co.uk> NNTP-Posting-Host: news.netcraft.co.uk Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk cancel <199604031122.MAA15556@ns0.netcraft.co.uk> in newsgroup netcraft.freebsd-current This article was cancelled from within NN version 6.5.0 #1 (NOV) -- o //> > //__/<_ /_/ From owner-freebsd-current Wed Apr 3 07:04:21 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA27938 for current-outgoing; Wed, 3 Apr 1996 07:04:21 -0800 (PST) Received: from pegasus.isr.uc.pt (pegasus.isr.uc.pt [193.136.230.60]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA27909 for ; Wed, 3 Apr 1996 07:04:06 -0800 (PST) Received: from pioneer (pioneer.isr.uc.pt) by pegasus.isr.uc.pt (5.x/SMI-SVR4) id AA08779; Wed, 3 Apr 1996 15:56:51 +0100 Date: Wed, 3 Apr 1996 16:01:31 +0100 (WET DST) From: Paulo Menezes X-Sender: paulo@pioneer To: current@FreeBSD.ORG Cc: Jose Gabriel J Marcelino Subject: Portuguese Keymap Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, Using a keyboard with the wrong key mapping is very annoying... Here is a simple mapping for the portuguese keyboard, that allows=20 PT-people to use FreeBSD without having to "search for the hidden key" :-) BTW: Is there any possibility to use a "mode swicth key" to switch=20 between compose characters and simple characters? mode 1: ~+a=3D=E3 mode 2: ~+a=3D~a Paulo =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D # # Portuguese Keyboard map #=20 # # alt # scan cntrl alt alt cntrl lock # code base shift cntrl shift alt shift cntrl shift state # ------------------------------------------------------------------ 000 nop nop nop nop nop nop nop nop O 001 esc esc esc esc esc esc debug esc O 002 '1' '!' nop nop '1' '!' nop nop O 003 '2' '"' nul nul '@' '@' nul nul O 004 '3' '#' nop nop '3' '#' nop nop O 005 '4' '$' nop nop '4' '$' nop nop O 006 '5' '%' nop nop '5' '%' nop nop O 007 '6' '&' rs rs '6' '^' rs rs O 008 '7' '/' nop nop '{' '&' nop nop O 009 '8' '(' nop nop '[' '*' nop nop O 010 '9' ')' nop nop ']' '(' nop nop O 011 '0' '=3D' nop nop '}' ')' nop nop O 012 ''' '?' ns ns '-' '_' ns ns O 013 '=3D' '+' nop nop '=3D' '+' nop nop O 014 bs bs del del bs bs del del O 015 ht btab nop nop ht btab nop nop O 016 'q' 'Q' dc1 dc1 'q' 'Q' dc1 dc1 C 017 'w' 'W' etb etb 'w' 'W' etb etb C 018 'e' 'E' enq enq 'e' 'E' enq enq C 019 'r' 'R' dc2 dc2 'r' 'R' dc2 dc2 C 020 't' 'T' dc4 dc4 't' 'T' dc4 dc4 C 021 'y' 'Y' em em 'y' 'Y' em em C 022 'u' 'U' nak nak 'u' 'U' nak nak C 023 'i' 'I' ht ht 'i' 'I' ht ht C 024 'o' 'O' si si 'o' 'O' si si C 025 'p' 'P' dle dle 'p' 'P' dle dle C 026 '+' '*' esc esc 'h' '{' esc esc O 027 ''' '`' gs gs ']' '}' gs gs O 028 cr cr nl nl cr cr nl nl O 029 lctrl lctrl lctrl lctrl lctrl lctrl lctrl lctrl O 030 'a' 'A' soh soh 'a' 'A' soh soh C 031 's' 'S' dc3 dc3 's' 'S' dc3 dc3 C 032 'd' 'D' eot eot 'd' 'D' eot eot C 033 'f' 'F' ack ack 'f' 'F' ack ack C 034 'g' 'G' bel bel 'g' 'G' bel bel C 035 'h' 'H' bs bs 'h' 'H' bs bs C 036 'j' 'J' nl nl 'j' 'J' nl nl C 037 'k' 'K' vt vt 'k' 'K' vt vt C 038 'l' 'L' ff ff 'l' 'L' ff ff C 039 135 128 nop nop ';' ':' nop nop O 040 167 166 nop nop ''' '"' nop nop O 041 '\' '|' nop nop '`' '~' nop nop O 042 lshift lshift lshift lshift lshift lshift lshift lshift O 043 '~' '^' fs fs '\' '|' fs fs O 044 'z' 'Z' sub sub 'z' 'Z' sub sub C 045 'x' 'X' can can 'x' 'X' can can C 046 'c' 'C' etx etx 'c' 'C' etx etx C 047 'v' 'V' syn syn 'v' 'V' syn syn C 048 'b' 'B' stx stx 'b' 'B' stx stx C 049 'n' 'N' so so 'n' 'N' so so C 050 'm' 'M' cr cr 'm' 'M' cr cr C 051 ',' ';'=09nop nop nop nop nop nop C 052 '.' ':' nop nop '.' '>' nop nop O 053 '-' '_' nop nop '/' '?' nop nop O 054 rshift rshift rshift rshift rshift rshift rshift rshift O 055 '*' '*' nscr nscr '*' '*' nscr nscr O 056 lalt lalt lalt lalt lalt lalt lalt lalt O 057 ' ' ' ' ' ' ' ' ' ' ' ' 130 ' ' O 058 clock clock clock clock clock clock clock clock O 059 fkey01 fkey13 fkey25 fkey37 scr01 scr11 scr01 scr11 O 060 fkey02 fkey14 fkey26 fkey38 scr02 scr12 scr02 scr12 O 061 fkey03 fkey15 fkey27 fkey39 scr03 scr13 scr03 scr13 O 062 fkey04 fkey16 fkey28 fkey40 scr04 scr14 scr04 scr14 O 063 fkey05 fkey17 fkey29 fkey41 scr05 scr15 scr05 scr15 O 064 fkey06 fkey18 fkey30 fkey42 scr06 scr16 scr06 scr16 O 065 fkey07 fkey19 fkey31 fkey43 scr07 scr07 scr07 scr07 O 066 fkey08 fkey20 fkey32 fkey44 scr08 scr08 scr08 scr08 O 067 fkey09 fkey21 fkey33 fkey45 scr09 scr09 scr09 scr09 O 068 fkey10 fkey22 fkey34 fkey46 scr10 scr10 scr10 scr10 O 069 nlock nlock nlock nlock nlock nlock nlock nlock O 070 slock slock slock slock slock slock slock slock O 071 fkey49 '7' '7' '7' '7' '7' '7' '7' N 072 fkey50 '8' '8' '8' '8' '8' '8' '8' N 073 fkey51 '9' '9' '9' '9' '9' '9' '9' N 074 fkey52 '-' '-' '-' '-' '-' '-' '-' N 075 fkey53 '4' '4' '4' '4' '4' '4' '4' N 076 nop '5' '5' '5' '5' '5' '5' '5' N 077 fkey55 '6' '6' '6' '6' '6' '6' '6' N 078 fkey56 '+' '+' '+' '+' '+' '+' '+' N 079 fkey57 '1' '1' '1' '1' '1' '1' '1' N 080 fkey58 '2' '2' '2' '2' '2' '2' '2' N 081 fkey59 '3' '3' '3' '3' '3' '3' '3' N 082 fkey60 '0' '0' '0' '0' '0' '0' '0' N 083 del '.' del del del del boot del N 084 '=3D' nop nop nop nop nop nop nop O 085 '+' nop nop nop nop nop nop nop O 086 '<' '>' nop nop nop nop nop nop O 087 fkey11 fkey23 fkey35 fkey47 scr11 scr11 scr11 scr11 O 088 fkey12 fkey24 fkey36 fkey48 scr12 scr12 scr12 scr12 O 089 cr cr cr cr cr cr cr cr O 090 rctrl rctrl rctrl rctrl rctrl rctrl rctrl rctrl O 091 '/' '/' '/' '/' '/' '/' '/' '/' O 092 nscr nop debug nop nop nop nop nop O 093 ralt ralt ralt ralt ralt ralt ralt ralt O 094 fkey49 fkey49 fkey49 fkey49 fkey49 fkey49 fkey49 fkey49 O 095 fkey50 fkey50 fkey50 fkey50 fkey50 fkey50 fkey50 fkey50 O 096 fkey51 fkey51 fkey51 fkey51 fkey51 fkey51 fkey51 fkey51 O 097 fkey53 fkey53 fkey53 fkey53 fkey53 fkey53 fkey53 fkey53 O 098 fkey55 fkey55 fkey55 fkey55 fkey55 fkey55 fkey55 fkey55 O 099 fkey57 fkey57 fkey57 fkey57 fkey57 fkey57 fkey57 fkey57 O 100 fkey58 fkey58 fkey58 fkey58 fkey58 fkey58 fkey58 fkey58 O 101 fkey59 fkey59 fkey59 fkey59 fkey59 fkey59 fkey59 fkey59 O 102 fkey60 fkey60 fkey60 fkey60 fkey60 fkey60 fkey60 fkey60 O 103 fkey54 fkey54 fkey54 fkey54 fkey54 fkey54 boot fkey54 O 104 slock slock slock slock slock slock slock slock O 105 fkey61 fkey61 fkey61 fkey61 fkey61 fkey61 fkey61 fkey61 O 106 fkey62 fkey62 fkey62 fkey62 fkey62 fkey62 fkey62 fkey62 O 107 fkey63 fkey63 fkey63 fkey63 fkey63 fkey63 fkey63 fkey63 O From owner-freebsd-current Wed Apr 3 08:57:08 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA07426 for current-outgoing; Wed, 3 Apr 1996 08:57:08 -0800 (PST) Received: from mail.think.com (Mail1.Think.COM [131.239.33.245]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id IAA07421 Wed, 3 Apr 1996 08:57:03 -0800 (PST) Received: from Early-Bird-1.Think.COM by mail.think.com; Wed, 3 Apr 96 11:56:55 -0500 Received: from compound (fergus-26.dialup.cfa.org) by Early-Bird.Think.COM; Wed, 3 Apr 96 11:56:51 EST Received: (from alk@localhost) by compound (8.6.12/8.6.112) id KAA28168; Wed, 3 Apr 1996 10:59:11 -0600 Date: Wed, 3 Apr 1996 10:59:11 -0600 Message-Id: <199604031659.KAA28168@compound> From: Tony Kimball To: chat@freebsd.org Subject: America the Beautiful Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Canada is in America as much as Switzerland or France is in Germay. *Brazil* is in America. Canada is in America as much as Poland is in Europe. Poland is not a part of the European Union, but is firmly situated on its the Continet of Europe. If you disagree, it is only because we speak different dialects of English. Similarly, the Mexican reference to US denizens as 'Norte Americanos' is silly, in a naive translation to Network English, the dialect of most English-speaking readers of this missive. The more interesting question to me personally is how long *Minnesota* will remain a part of the Union. (Not long I hope. Better a dead lion than a dead jackal -- or slave, eh? I hope for a new union with Dakota, Manitoba, Alberta, Saskatchewan, Montana, Wyoming and Idaho, in my lifetime.) (Apposite redirections applied. Through the Dragus Ex Machina of BCC;-) Oh, and ob FBSD: Might Walnut Creek seceed? Then FBSD could issue its own money, send ambassadors to Finland. Hey, why not issue FBSD ecash before that? From owner-freebsd-current Wed Apr 3 10:30:23 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA13273 for current-outgoing; Wed, 3 Apr 1996 10:30:23 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA13268 for ; Wed, 3 Apr 1996 10:30:21 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA19596; Wed, 3 Apr 1996 11:23:23 -0700 From: Terry Lambert Message-Id: <199604031823.LAA19596@phaeton.artisoft.com> Subject: Re: Advice/Recommendation needed To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 3 Apr 1996 11:23:23 -0700 (MST) Cc: jdp@polstra.com, jgreco@brasil.moneng.mei.com, cat@ghost.uunet.ca, current@FreeBSD.org In-Reply-To: <2949.828523154@time.cdrom.com> from "Jordan K. Hubbard" at Apr 3, 96 01:19:14 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-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > P.S. Yes, yes, I'm just joking! I love canada! Please don't send > down the mounties! :) Too late. They've been dispatched, and once dispatched, they always get their man. Don't sleep tonight, or they will sneak up on you with thundering hoofbeats and in a flash of red... 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 Apr 3 16:23:31 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA06800 for current-outgoing; Wed, 3 Apr 1996 16:23:31 -0800 (PST) Received: from ki.net (root@ki.net [205.150.102.1]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id QAA06793 for ; Wed, 3 Apr 1996 16:23:26 -0800 (PST) Received: from localhost (scrappy@localhost) by ki.net (8.7.4/8.7.4) with SMTP id SAA17997; Wed, 3 Apr 1996 18:59:00 -0500 (EST) Date: Wed, 3 Apr 1996 18:58:58 -0500 (EST) From: "Marc G. Fournier" To: Joerg Wunsch cc: FreeBSD-current users Subject: Re: Closing off PRs? In-Reply-To: <199604030616.IAA14691@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 3 Apr 1996, J Wunsch wrote: > As Marc G. Fournier wrote: > > > I'm just curious as to what is required to get Problem reports > > closed off. > > 1) Fix the problem, or get confirmation that it doesn't happen anymore :) So, what...send email out to each person that put in a problem report and say "hey, have you ever seen this problem since"? :) If so, then so be it :) for instance, PR#kern/216, submitted February 14, 1995, dealing with the -current kernel of that time with a bug in ffs_alloccg, with a map corrupted. sys/ufs/ffs/ffs_alloc.c was last changed on the 5th of January this year... This is what the guy was running at the time: Running FreeBSD-current (supped and built 2/11/95 from freefall.cdrom.com) on ASUS SP3G board (486/66, 32mb ram). Using onboard NCR PCI SCSI and two SCSI disks - DEC 1 gig and Seagate Hawk 4 gig. Now, -current has gone through *so* many changes, and a release, plus looking at the log file for ffs_alloc.c, there have been alot of changes to the code in there, yet none that seem to specifically address this problem. (or at least mention it directly) So if its a matter of sending this guy email confirming he hasn't had the problem since, and then just closing it, let me know and I'll go through the whole problem database this way, or at least those that look pertinent :) > 2) edit-pr --> replace `open' by `closed' well, that I can do... > 3) note the CVS file name and revision number where the fix has been > applied (as an xref, normally the CVS log should tell the PR that is > closed by the change) > And in the case where the problem was fixed, but nobody specifically fixed it? Ie. as part of something else? As I stated above, ffs_alloca.c has gone through *alot* of change since the PR was submitted. Just sort of note that "submitter confirms hasn't seen bug since submitting"... especially for -current source that changes alot and quickly? And, if I should just butt my nose out of this...let me know that too *grin* I won't take offence...promise :) Marc G. Fournier | POP Mail Telnet Acct DNS Hosting System | WWW Services Database Services | Knowledge, Administrator | | Information and scrappy@ki.net | WWW: http://www.ki.net | Communications, Inc From owner-freebsd-current Thu Apr 4 00:15:12 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA07702 for current-outgoing; Thu, 4 Apr 1996 00:15:12 -0800 (PST) Received: from multivac.orthanc.com (root@multivac.orthanc.com [206.12.238.2]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id AAA07694 for ; Thu, 4 Apr 1996 00:15:04 -0800 (PST) Received: from localhost (lyndon@localhost) by multivac.orthanc.com (8.7.3/8.7.3) with SMTP id AAA15211 for ; Thu, 4 Apr 1996 00:14:58 -0800 (PST) Message-Id: <199604040814.AAA15211@multivac.orthanc.com> From: Lyndon Nerenberg VE7TCP To: freebsd-current@freebsd.org Subject: Nice Firewall :-) X-Attribution: VE7TCP Date: Thu, 04 Apr 1996 00:14:57 -0800 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I just finished nailing up a recent (3 Apr from sup3) current, rebuilt (twice) from source, rebooted, and got the following ... Any network access returns permission denied (ERRNO == 13). Bizarre. Even remade all of /dev. It's late and I'm not going to chase this any further tonight, but not having seen (or recalling) anything from the -current list, maybe this will give people something to chew on for a bit. What follows is a ktrace from ping, followed by the kernel config I was running. (A 2.1-RELEASE kernel works fine on the same machine.) 3416 ktrace RET ktrace 0 3416 ktrace CALL mmap(0,0x1000,0x3,0x1002,0xffffffff,0,0,0) 3416 ktrace RET mmap 134328320/0x801b000 3416 ktrace CALL break(0x5000) 3416 ktrace RET break 0 3416 ktrace CALL break(0x6000) 3416 ktrace RET break 0 3416 ktrace CALL execve(0xefbfd9a8,0xefbfde04,0xefbfde10) 3416 ktrace NAMI "/sbin/ping" 3416 ping RET execve 0 3416 ping CALL ioctl(0,0x402c7413 ,0xefbfddb8) 3416 ping RET ioctl 0 3416 ping CALL ioctl(0,0x802c7414 ,0xefbfddb8) 3416 ping RET ioctl 0 3416 ping CALL mmap(0,0x1000,0x3,0x1002,0xffffffff,0,0,0) 3416 ping RET mmap 134340608/0x801e000 3416 ping CALL break(0x39000) 3416 ping RET break 0 3416 ping CALL break(0x3a000) 3416 ping RET break 0 3416 ping CALL getpid 3416 ping RET getpid 3416/0xd58 3416 ping CALL open(0x33c2,0,0x1b6) 3416 ping NAMI "/etc/protocols" 3416 ping RET open 3 3416 ping CALL fstat(0x3,0xefbfdb60) 3416 ping RET fstat 0 3416 ping CALL break(0x3c000) 3416 ping RET break 0 3416 ping CALL read(0x3,0x3a000,0x2000) 3416 ping GIO fd 3 read 1137 bytes "# # Internet (IP) protocols # # $Id: protocols,v 1.3 1995/08/29 19:29:35 wollman Exp $ # from: @(#)protocols 5.1 (Berkeley) 4/17/89 # # Updated for FreeBSD based on RFC 1340, Assigned Numbers (July 1992). # ip 0 IP # internet protocol, pseudo protocol n\ umber icmp 1 ICMP # internet control message protocol igmp 2 IGMP # Internet Group Management ggp 3 GGP # gateway-gateway protocol ipencap 4 IP-ENCAP # IP encapsulated in IP (officially ``\ IP'') st 5 ST # ST datagram mode tcp 6 TCP # transmission control protocol egp 8 EGP # exterior gateway protocol pup 12 PUP # PARC universal packet protocol udp 17 UDP # user datagram protocol hmp 20 HMP # host monitoring protocol xns-idp 22 XNS-IDP # Xerox NS IDP rdp 27 RDP # "reliable datagram" protocol iso-tp4 29 ISO-TP4 # ISO Transport Protocol class 4 xtp 36 XTP # Xpress Tranfer Protocol idpr-cmtp 39 IDPR-CMTP # IDPR Control Message Transpo\ rt rsvp 46 RSVP # Resource ReSerVation Protocol vmtp 81 VMTP # Versatile Message Transport ospf 89 OSPFIGP # Open Shortest Path First IGP ipip 94 IPIP # Yet Another IP encapsulation encap 98 ENCAP # Yet Another IP encapsulation " 3416 ping RET read 1137/0x471 3416 ping CALL close(0x3) 3416 ping RET close 0 3416 ping CALL socket(0x2,0x3,0x1) 3416 ping RET socket 3 3416 ping CALL setsockopt(0x3,0xffff,0x1002,0xefbfdc8c,0x4) 3416 ping RET setsockopt 0 3416 ping CALL fstat(0x1,0xefbfd960) 3416 ping RET fstat 0 3416 ping CALL break(0x40000) 3416 ping RET break 0 3416 ping CALL ioctl(0x1,0x402c7413 ,0xefbfd99c) 3416 ping RET ioctl 0 3416 ping CALL write(0x1,0x3c000,0x30) 3416 ping GIO fd 1 wrote 48 bytes "PING 206.12.238.2 (206.12.238.2): 56 data bytes " 3416 ping RET write 48/0x30 3416 ping CALL sigaction(0x2,0xefbfdc38,0xefbfdc2c) 3416 ping RET sigaction 0 3416 ping CALL sigaction(0xe,0xefbfdc30,0xefbfdc24) 3416 ping RET sigaction 0 3416 ping CALL sigaction(0x1d,0xefbfdc28,0xefbfdc1c) 3416 ping RET sigaction 0 3416 ping CALL gettimeofday(0x27100,0) 3416 ping RET gettimeofday 0 3416 ping CALL sendto(0x3,0x270f8,0x40,0,0x26df4,0x10) 3416 ping RET sendto -1 errno 13 Permission denied ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 3416 ping CALL writev(0x2,0xefbfdbfc,0x4) 3416 ping GIO fd 2 wrote 32 bytes "ping: sendto: Permission denied " 3416 ping RET writev 32/0x20 3416 ping CALL write(0x1,0x3c000,0x2a) 3416 ping GIO fd 1 wrote 42 bytes "ping: wrote 206.12.238.2 64 chars, ret=-1 " 3416 ping RET write 42/0x2a 3416 ping CALL sigaction(0xe,0xefbfdc24,0xefbfdc18) 3416 ping RET sigaction 0 3416 ping CALL setitimer(0,0xefbfdc24,0xefbfdc14) 3416 ping RET setitimer 0 3416 ping CALL recvfrom(0x3,0x39000,0xc0,0,0xefbfdc7c,0xefbfdc6c) 3416 ping PSIG SIGALRM caught handler=0x191c mask=0x0 code=0x0 3416 ping RET recvfrom RESTART 3416 ping CALL gettimeofday(0x27100,0) 3416 ping RET gettimeofday 0 3416 ping CALL sendto(0x3,0x270f8,0x40,0,0x26df4,0x10) 3416 ping RET sendto -1 errno 13 Permission denied 3416 ping CALL writev(0x2,0xefbfdb88,0x4) 3416 ping GIO fd 2 wrote 32 bytes "ping: sendto: Permission denied " 3416 ping RET writev 32/0x20 3416 ping CALL write(0x1,0x3c000,0x2a) 3416 ping GIO fd 1 wrote 42 bytes "ping: wrote 206.12.238.2 64 chars, ret=-1 " 3416 ping RET write 42/0x2a 3416 ping CALL sigaction(0xe,0xefbfdbb0,0xefbfdba4) 3416 ping RET sigaction 0 3416 ping CALL setitimer(0,0xefbfdbb0,0xefbfdba0) 3416 ping RET setitimer 0 3416 ping CALL sigreturn(0xefbfdbf4) 3416 ping RET sigreturn JUSTRETURN 3416 ping CALL recvfrom(0x3,0x39000,0xc0,0,0xefbfdc7c,0xefbfdc6c) 3416 ping PSIG SIGALRM caught handler=0x191c mask=0x0 code=0x0 3416 ping RET recvfrom RESTART 3416 ping CALL gettimeofday(0x27100,0) 3416 ping RET gettimeofday 0 3416 ping CALL sendto(0x3,0x270f8,0x40,0,0x26df4,0x10) 3416 ping RET sendto -1 errno 13 Permission denied 3416 ping CALL writev(0x2,0xefbfdb88,0x4) 3416 ping GIO fd 2 wrote 32 bytes "ping: sendto: Permission denied " 3416 ping RET writev 32/0x20 3416 ping CALL write(0x1,0x3c000,0x2a) 3416 ping GIO fd 1 wrote 42 bytes "ping: wrote 206.12.238.2 64 chars, ret=-1 " 3416 ping RET write 42/0x2a 3416 ping CALL sigaction(0xe,0xefbfdbb0,0xefbfdba4) 3416 ping RET sigaction 0 3416 ping CALL setitimer(0,0xefbfdbb0,0xefbfdba0) 3416 ping RET setitimer 0 3416 ping CALL sigreturn(0xefbfdbf4) 3416 ping RET sigreturn JUSTRETURN 3416 ping CALL recvfrom(0x3,0x39000,0xc0,0,0xefbfdc7c,0xefbfdc6c) 3416 ping PSIG SIGINT caught handler=0x23c4 mask=0x0 code=0x0 3416 ping RET recvfrom RESTART 3416 ping CALL sigaction(0x2,0xefbfdb84,0xefbfdb78) 3416 ping RET sigaction 0 3416 ping CALL write(0x1,0x3c000,0x1) 3416 ping GIO fd 1 wrote 1 bytes " " 3416 ping RET write 1 3416 ping CALL write(0x1,0x3c000,0x25) 3416 ping GIO fd 1 wrote 37 bytes "--- 206.12.238.2 ping statistics --- " 3416 ping RET write 37/0x25 3416 ping CALL write(0x1,0x3c000,0x3c) 3416 ping GIO fd 1 wrote 60 bytes "3 packets transmitted, 0 packets received, 100% packet loss " 3416 ping RET write 60/0x3c 3416 ping CALL exit(0x2) # KERNEL CONFIG machine "i386" cpu "I386_CPU" cpu "I486_CPU" cpu "I586_CPU" # aka Pentium(tm) #cpu "I686_CPU" # aka Pentium Pro(tm) ident BLURFL maxusers 64 options FAILSAFE config kernel root on wd0 dumps on wd0 options "COMPAT_43" options USER_LDT #allow user-level control of i386 ldt options SYSVSHM options SYSVSEM options SYSVMSG options DDB options DDB_UNATTENDED options KTRACE #kernel tracing options DIAGNOSTIC options PERFMON options UCONSOLE options INET #Internet communications protocols pseudo-device ether #Generic Ethernet pseudo-device loop #Network loopback device pseudo-device bpfilter 4 #Berkeley packet filter pseudo-device disc #Discard device pseudo-device tun 4 #Tunnel driver(user process ppp) options MROUTING # Multicast routing options IPFIREWALL #firewall options TCPDEBUG options FFS #Fast filesystem options NFS #Network File System pseudo-device pty 64 #Pseudo ttys - can go as high as 64 pseudo-device speaker #Play IBM BASIC-style noises out your speaker pseudo-device log #Kernel syslog interface (/dev/klog) pseudo-device vn #Vnode driver (turns a file into a device) pseudo-device snp 3 #Snoop device - to look at pty/vty/etc.. controller isa0 options "AUTO_EOI_1" device vt0 at isa? port "IO_KBD" tty irq 1 vector pcrint options PCVT_FREEBSD=210 # pcvt running on FreeBSD >= 2.0.5 options XSERVER # include code for XFree86 options FAT_CURSOR # start with block cursor device npx0 at isa? port "IO_NPX" irq 13 vector npxintr controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr disk wd0 at wdc0 drive 0 options ATAPI #Enable ATAPI support for IDE bus controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr disk fd0 at fdc0 drive 0 device lpt0 at isa? port? tty irq 7 vector lptintr device sio0 at isa? port "IO_COM1" tty irq 4 vector siointr device ed0 at isa? port 0x280 net irq 15 iomem 0xd8000 vector edintr controller snd0 device sb0 at isa? port 0x220 irq 5 drq 1 vector sbintr device sbxvi0 at isa? drq 5 device sbmidi0 at isa? port 0x330 device mpu0 at isa? port 0x330 irq 6 drq 0 device pca0 at isa? port IO_TIMER1 tty device scd0 at isa? port 0x230 bio device apm0 at isa? device joy0 at isa? port "IO_GAME" controller pci0 device vx0 From owner-freebsd-current Thu Apr 4 00:22:19 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA07956 for current-outgoing; Thu, 4 Apr 1996 00:22:19 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id AAA07941 for ; Thu, 4 Apr 1996 00:22:05 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id KAA08345 for ; Thu, 4 Apr 1996 10:21:57 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id KAA09181 for freebsd-current@FreeBSD.org; Thu, 4 Apr 1996 10:21:57 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id JAA19358 for freebsd-current@FreeBSD.org; Thu, 4 Apr 1996 09:43:15 +0200 (MET DST) From: J Wunsch Message-Id: <199604040743.JAA19358@uriah.heep.sax.de> Subject: Re: adjkerntz (was: cvs commit: src/usr.sbin/tzsetup ...) To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Thu, 4 Apr 1996 09:43:14 +0200 (MET DST) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199604031406.SAA04539@astral.msk.su> from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Apr 3, 96 06:06:30 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= wrote: > > msdosfs? MSDOS' idea of a timezone is broken by design (i.e., it > > doesn't have an idea about it at all). Someone in Australia could > > It have an idea: local time zone. But that sucks when it comes to communication with other machines in other timezones. > > send a file with a DOS timestamp to somebody in California across the > > Internet, and the recipient will see a file that appears to be written > > ``in the future''. > > It fixed in some communication packages like DOS Zmodem from Omen. > They use timezone offset variable. Well, but that's a crock. Send a tar file over, and the contents of the tar file will have invalid timestamps. Not to speak about IP services like FTP, and the many possibilities to have timestamps hidden somewhere in the archive files. The actual problem is that there is no *inherent* timezone information along with the timestamp. (Unlike the ISO9660 file system, btw.) > > I don't see how adjkerntz should fix it. > msdosfs use adjkerntz kernel variable to calculate local timezone > for DOS files, check msdosfs sources. That's a hack. Probably the best one you can do (and note that hacks might often be useful, e.g. vfork() is another useful hack, or has at least been one in times where COW wasn't available). What if i don't use msdosfs but use mtools instead? (Like i do btw., whenever there's an occasion to handle a DOS floppy. As you could guess, this is only rarely the case for me.) What if i use my own package to export/ import DOS files? (Yes, i really wrote one as paywork years ago. It could do one thing mtools cannot do: decide whether the medium was a floppy, an fdisk-partitioned MOD, or an ``SST-01'' MOD.) > Proper DOS/Windows software sends timezone offset of your DOS > with any file times. How? There's no commonly agreed protocol. I cannot remember any DOS installation program that would even ask for a timezone? Despite, you remember all our hassles we had to undergo until all non-USA timezones ran well, can you imagine how long it would took Billyboy to get this right? :-) Don't get me wrong: i don't say adjkerntz is something totally unneeded, but it's certainly not needed for all of the ``true unix workstations''. You know, that's the class of machines i often have to handle, be it at home or for my paywork. (See the ``dangerously dedicated'' mode, too.) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Thu Apr 4 00:28:35 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA08209 for current-outgoing; Thu, 4 Apr 1996 00:28:35 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id AAA08203 for ; Thu, 4 Apr 1996 00:28:08 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id KAA08291; Thu, 4 Apr 1996 10:21:20 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id KAA09169; Thu, 4 Apr 1996 10:21:19 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id JAA19226; Thu, 4 Apr 1996 09:07:36 +0200 (MET DST) From: J Wunsch Message-Id: <199604040707.JAA19226@uriah.heep.sax.de> Subject: Re: Closing off PRs? To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Thu, 4 Apr 1996 09:07:36 +0200 (MET DST) Cc: scrappy@ki.net (Marc G. Fournier) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from "Marc G. Fournier" at Apr 3, 96 06:58:58 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Marc G. Fournier wrote: > > 1) Fix the problem, or get confirmation that it doesn't happen anymore :) > > So, what...send email out to each person that put in a problem > report and say "hey, have you ever seen this problem since"? :) That's often the only thing you can do. If the submitter cared to tell about ``How to reproduce'', one can try it. If he didn't supply this, there's not so much that could be done after that long time. > So if its a matter of sending this guy email confirming he hasn't > had the problem since, and then just closing it, let me know and I'll go > through the whole problem database this way, or at least those that look > pertinent :) Highly appreciated! > > 3) note the CVS file name and revision number where the fix has been > > applied (as an xref, normally the CVS log should tell the PR that is > > closed by the change) > > > And in the case where the problem was fixed, but nobody specifically > fixed it? [...] Just sort > of note that "submitter confirms hasn't seen bug since submitting"... Yup. > And, if I should just butt my nose out of this...let me know that > too *grin* I won't take offence...promise :) Hehe, no, really, we *appreciate* your service! :) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Thu Apr 4 01:01:35 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA09635 for current-outgoing; Thu, 4 Apr 1996 01:01:35 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id BAA09629 for ; Thu, 4 Apr 1996 01:01:33 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0u4kv1-0003vqC; Thu, 4 Apr 96 01:01 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id JAA01881; Thu, 4 Apr 1996 09:01:19 GMT X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: Lyndon Nerenberg VE7TCP cc: freebsd-current@FreeBSD.org Subject: Re: Nice Firewall :-) In-reply-to: Your message of "Thu, 04 Apr 1996 00:14:57 PST." <199604040814.AAA15211@multivac.orthanc.com> Date: Thu, 04 Apr 1996 09:01:18 +0000 Message-ID: <1879.828608478@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > I just finished nailing up a recent (3 Apr from sup3) current, > rebuilt (twice) from source, rebooted, and got the following ... > > Any network access returns permission denied (ERRNO == 13). Bizarre. > [...] > options IPFIREWALL #firewall If you had paid attention to the mailinglists, you would have known that ipfw was changed to a default policy of deny some time back. Look at the manual and the /etc/rc.firewall I committed yesterday for more info. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Thu Apr 4 01:47:08 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA16155 for current-outgoing; Thu, 4 Apr 1996 01:47:08 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id BAA16117 Thu, 4 Apr 1996 01:46:59 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id TAA05128; Thu, 4 Apr 1996 19:45:39 +1000 Date: Thu, 4 Apr 1996 19:45:39 +1000 From: Bruce Evans Message-Id: <199604040945.TAA05128@godzilla.zeta.org.au> To: ache@freefall.freebsd.org, jdp@polstra.com Subject: Re: adjkerntz (was: cvs commit: src/usr.sbin/tzsetup ...) Cc: freebsd-current@FreeBSD.org, j@uriah.heep.sax.de Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >> > Is this really what is supposed to be happening? If there's a persistent >> > daemon, why must there also be separate periodic runs of the same program? >> >> IMHO reading one screen of adjkerntz manpage is more quick thing >> then writting such letter. >IMHO the manual page is unclear. I read it over several times, and also >looked at the source. Yet I still have this question. Your reply did >nothing to change that. The persistent daemon is used because there's no better way to ensure that adjkerntz is run on reboot. (See another discussion about SYSV run control vs BSD run control.) The periodic runs from cron are because it's easier to schedule such things using cron. The man page is clear enough about what running adjkerntz does and why you might want to run it at boot time and at 03:01. Bruce From owner-freebsd-current Thu Apr 4 04:38:47 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA25262 for current-outgoing; Thu, 4 Apr 1996 04:38:47 -0800 (PST) Received: from innocence.interface-business.de (innocence.interface-business.de [193.101.57.101]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id EAA25253 for ; Thu, 4 Apr 1996 04:38:34 -0800 (PST) Received: from ida.interface-business.de (ida.interface-business.de [193.101.57.203]) by innocence.interface-business.de (8.6.11/8.6.9) with SMTP id OAA05167; Thu, 4 Apr 1996 14:40:42 +0200 Received: (from j@localhost) by ida.interface-business.de (8.7.3/8.7.3) id OAA00366; Thu, 4 Apr 1996 14:37:00 +0200 (MET DST) From: J Wunsch Message-Id: <199604041237.OAA00366@ida.interface-business.de> Subject: Interrupt-mode lpt driver and HP printers To: freebsd-current@FreeBSD.org (FreeBSD-current users), bdodson@beowulf.utmb.edu (M. L. Dodson) Date: Thu, 4 Apr 1996 14:37:00 +0200 (MET DST) Reply-To: joerg_wunsch@interface-business.de (Joerg Wunsch) X-Phone: +49-351-31809-14 X-Fax: +49-351-3361187 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Many people recently complained that they could not use the lpt driver in interrupt mode with newer HP DeskJet or LaserJet printers. The printer went awfully slow, while polled mode works fine. Now i've finally got my hands on a DeskJet 600 (customer's device :), and could reproduce the problem myself. I seem to have found a suitable workaround, and have just committed a fix for it. I would ask people to test it. If it works, i'll also commit this one to the -stable branch, since i believe it couldn't do any harm to configur- ations that used to work before either. (It could spin-loop a few milliseconds inside the interrupt routine for owners of HP printers, but that still seems to be less load than falling back to polled mode entirely.) The idea is to wait a moment inside the interrupt routine to see if the not-yet-ready condition will clear within reasonable time, and if it doesn't, to use an incrementally backoff timeout instead of the fixed 1/2 second timeout we've been using previously. --- lpt.c.orig Sun Dec 10 14:38:56 1995 +++ lpt.c Thu Apr 4 14:00:41 1996 @@ -149,7 +149,8 @@ #define LPINITRDY 4 /* wait up to 4 seconds for a ready */ -#define LPTOUTTIME 4 /* wait up to 4 seconds for a ready */ +#define LPTOUTINITIAL 10 /* initial timeout to wait for ready 1/10 s */ +#define LPTOUTMAX 1 /* maximal timeout 1 s */ #define LPPRI (PZERO+8) #define BUFSIZE 1024 @@ -221,6 +222,7 @@ #define LP_HAS_IRQ 0x01 /* we have an irq available */ #define LP_USE_IRQ 0x02 /* we are using our irq */ #define LP_ENABLE_IRQ 0x04 /* enable IRQ on open */ + u_char sc_backoff ; /* time to call lptout() again */ #ifdef INET struct ifnet sc_if; @@ -588,7 +590,8 @@ lprintf("irq %x\n", sc->sc_irq); if (sc->sc_irq & LP_USE_IRQ) { sc->sc_state |= TOUT; - timeout ((timeout_func_t)lptout, (caddr_t)sc, hz/2); + timeout ((timeout_func_t)lptout, (caddr_t)sc, + (sc->sc_backoff = hz/LPTOUTINITIAL)); } lprintf("opened.\n"); @@ -600,9 +603,12 @@ { int pl; lprintf ("T %x ", inb(sc->sc_port+lpt_status)); - if (sc->sc_state & OPEN) - timeout ((timeout_func_t)lptout, (caddr_t)sc, hz/2); - else + if (sc->sc_state & OPEN) { + sc->sc_backoff++; + if (sc->sc_backoff > hz/LPTOUTMAX) + sc->sc_backoff = sc->sc_backoff > hz/LPTOUTMAX; + timeout ((timeout_func_t)lptout, (caddr_t)sc, sc->sc_backoff); + } else sc->sc_state &= ~TOUT; if (sc->sc_state & ERROR) @@ -783,6 +789,7 @@ { struct lpt_softc *sc = lpt_sc + unit; int port = sc->sc_port, sts; + int i; #ifdef INET if(sc->sc_if.if_flags & IFF_UP) { @@ -791,9 +798,19 @@ } #endif /* INET */ - /* is printer online and ready for output */ - if (((sts=inb(port+lpt_status)) & RDY_MASK) == LP_READY) { + /* + * Is printer online and ready for output? + * + * Avoid falling back to lptout() too quickly. First spin-loop + * to see if the printer will become ready ``really soon now''. + */ + for (i = 0; + i < 100 && + ((sts=inb(port+lpt_status)) & RDY_MASK) != LP_READY; + i++) ; + if ((sts & RDY_MASK) == LP_READY) { sc->sc_state = (sc->sc_state | OBUSY) & ~ERROR; + sc->sc_backoff = hz/LPTOUTINITIAL; if (sc->sc_xfercnt) { /* send char */ @@ -820,6 +837,7 @@ if(((sts & (LPS_NERR | LPS_OUT) ) != LPS_NERR) && (sc->sc_state & OPEN)) sc->sc_state |= ERROR; + /* lptout() will jump in and try to restart. */ } lprintf("sts %x ", sts); } -- J"org Wunsch Unix support engineer joerg_wunsch@interface-business.de http://www.interface-business.de/~j From owner-freebsd-current Thu Apr 4 05:20:47 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA27048 for current-outgoing; Thu, 4 Apr 1996 05:20:47 -0800 (PST) Received: from gw.pinewood.nl (gw.pinewood.nl [192.31.139.9]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id FAA27043 for ; Thu, 4 Apr 1996 05:20:44 -0800 (PST) Received: (from smap@localhost) by gw.pinewood.nl (8.6.12/8.6.12) id PAA14289 for ; Thu, 4 Apr 1996 15:20:43 +0200 Received: from pwood1.pinewood.nl(192.168.1.10) by gw.pinewood.nl via smap (V1.3) id sma014287; Thu Apr 4 15:20:04 1996 Received: (from franky@localhost) by pwood1.pinewood.nl (8.7.3/8.6.12) id PAA03698; Thu, 4 Apr 1996 15:20:03 +0200 (DST) From: "Frank ten Wolde" Message-Id: <9604041520.ZM3696@pwood1.pinewood.nl> Date: Thu, 4 Apr 1996 15:20:03 +0000 X-Face: 'BsFf8'k.q?J#?|$D*,)/?sRB{woUK&9\5K{ERmT;VTSyNLBb?muLf>b:Pt&VTDw8YCaC]6 C!MRSMr5UNjZLa]fi? X-Mailer: Z-Mail (3.2.1 10oct95) To: freebsd-current@FreeBSD.ORG Subject: 2.2-960323 Panic in mount_msdos Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, I just tried to mount a Windows NT file system (NTFS) using: mount -t msdos /dev/sd0s2 /dos (I thought it was an MSDOS-FAT file system :-). The 2.2-960223-SNAPSHOT of FreeBSD immediately paniced: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xb2 fault code = supervisor read, page not present instruction pointer = 0x8:0xb2 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enable, resume, IOPL = 0 current process = 211 (mount_msdos) interrupt mask = panic: page fault panic: unknown/reserved trap I know you cannot mount an NTFS under FreeBSD, but at least the system should not crash. I just report this problem as I have too little knowledge of the internals of the kernel to fix the problem myself :-) Thanks, -Frank ten Wolde -- ---------------------------------------------------------------------- F.W. ten Wolde (PA3FMT) Pinewood Automation B.V. E-mail: franky@pinewood.nl Kluyverweg 2a Phone: +31-15 2682543 2629 HT Delft From owner-freebsd-current Thu Apr 4 07:16:33 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA02454 for current-outgoing; Thu, 4 Apr 1996 07:16:33 -0800 (PST) Received: from cenotaph.snafu.de (root@deadline.berlin.netSurf.DE [194.64.158.25]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA02448 for ; Thu, 4 Apr 1996 07:16:29 -0800 (PST) Received: by cenotaph.snafu.de from deadline.snafu.de using smtp id m0u4qkt-0002bfC; Thu, 4 Apr 96 17:15:23 +0200 (MET DST) (/\##/\ Smail3.1.30.13 #30.1) Received: by deadline.snafu.de id m0u4qn9-0009vMC; Thu, 4 Apr 96 17:17:43 +0200 (MET DST) (/\##/\ Smail3.1.30.13 #30.1) Message-Id: From: root@deadline.snafu.de (Andreas S. Wetzel) Subject: tty-level buffer overflows - what to do? To: current@freebsd.org Date: Thu, 4 Apr 1996 17:17:42 +0200 (MET DST) Organization: A world stranger than you have ever imagined. X-Mailer: ELM [version 2.4ME+ PL13] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi! --- On a relatively fresh installed -current Box which serves as a modem server for two V34+ modems and one V34 Modem on our local LAN, I get lots of messages on the sysconsole when doing high-speed transfers: sio2: 1988 more tty-level buffer overflows (total 23215) etc... This especially happens when transferring pure ASCII data which gets quite good compressed by the two modems so that I actually transfer at bitrates of about 50kbit and higher. Can I do anything about that (i.e. increase memory on this machine) or is this a problem related to the sio driver? Thankful for any advice Regards, mickey -- (__) (@@) Andreas S. Wetzel E-mail: mickey@deadline.snafu.de /-------\/ Utrechter Strasse 41 Web: http://deadline.snafu.de/ / | || 13347 Berlin Voice: <+4930> 456 81 68 * ||----|| Germany Fax/Data: <+4930> 455 19 57 ~~ ~~ From owner-freebsd-current Thu Apr 4 07:47:21 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA04991 for current-outgoing; Thu, 4 Apr 1996 07:47:21 -0800 (PST) Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id HAA04972 for ; Thu, 4 Apr 1996 07:47:14 -0800 (PST) Received: (from julian@localhost) by ref.tfs.com (8.7.3/8.6.9) id NAA09836; Wed, 3 Apr 1996 13:21:30 -0800 (PST) Message-Id: <199604032121.NAA09836@ref.tfs.com> Subject: Re: Advice/Recommendation needed To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 3 Apr 1996 13:21:30 -0800 (PST) From: "JULIAN Elischer" Cc: jdp@polstra.com, jgreco@brasil.moneng.mei.com, cat@ghost.uunet.ca, current@FreeBSD.org In-Reply-To: <2949.828523154@time.cdrom.com> from "Jordan K. Hubbard" at Apr 3, 96 01:19:14 am X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk last I looked America was a continent and not a country.. > > > > Wow! Things have changed a lot since I took geography in 4th grade. > > Back then, Canada was part of America. > > Oh, it still is.. There are still a few sadly deluded individuals up [...] > > P.S. Yes, yes, I'm just joking! I love canada! Please don't send > down the mounties! :) > From owner-freebsd-current Thu Apr 4 08:09:19 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA06646 for current-outgoing; Thu, 4 Apr 1996 08:09:19 -0800 (PST) Received: from phoenix.volant.org (root@phoenix.volant.org [205.179.79.1]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id IAA06641 for ; Thu, 4 Apr 1996 08:09:14 -0800 (PST) From: patl@asimov.volant.org Received: from asimov.volant.org (asimov.phoenix.volant.org [205.179.79.65]) by phoenix.volant.org (8.7.5/8.6.9) with SMTP id IAA13770 for ; Thu, 4 Apr 1996 08:07:47 -0800 (PST) Received: by asimov.volant.org (5.x/SMI-SVR4) id AA20968; Thu, 4 Apr 1996 08:09:27 -0800 Date: Thu, 4 Apr 1996 08:09:27 -0800 Message-Id: <9604041609.AA20968@asimov.volant.org> Subject: ? MBR-7 support in -stable Reply-To: patl@Phoenix.volant.org To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Md5: NtAekF170RYons/VfYsp1g== Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [ I didn't receive any response to this question in either the ] [ freebsd-stable or freebsd-questions list. Given the relatonship ] [ between -current and -stable, I'm hoping that someone on this list ] [ will have both the knowlege and the time to respond. ] I've recently upgraded from 2.05 to 2.1R and then -stable (through CVS 0063). One of my reasons for doing so was to obtain support for the MBR-7 CD-ROM changer. I noticed that it was mounting all seven logical units during some of the intermediate states of my upgrades; but don't seem to be recognized now. I have rebuilt my kernel with 'options "MAX_LUN=8"'; and I have the appropriate /dev entries. But the boot probe doesn't find the extra logical units and mount attempts claim that the units aren't configured (which is expected, given that the probe didn't find them...) I've included the first part of the boot log below, with the timestamp and kernel ids trimmed off for readability. Is there anything else that I need to do to get this to work? (Yes, I did try searching the mailing list archives; but didn't find anything appropriate.) FreeBSD 2.1-STABLE #0: Sun Mar 31 23:37:26 PST 1996 root@phoenix.volant.org:/compile/PHOENIX CPU: Cy486DLC (486-class CPU) Origin = "Cyrix" real memory = 41943040 (40960K bytes) avail memory = 38612992 (37708K bytes) Probing for devices on PCI bus 0: chip0 rev 4 on pci0:0 ncr0 rev 2 int a irq 9 on pci0:1 ncr0 waiting for scsi devices to settle (ncr0:0:0): "SEAGATE ST15230N 0168" type 0 fixed SCSI 2 sd0(ncr0:0:0): Direct-Access sd0(ncr0:0:0): FAST SCSI-2 100ns (10 Mb/sec) offset 8. 4095MB (8386733 512 byte sectors) (ncr0:5:0): "ARCHIVE VIPER 150 21531 -003" type 1 removable SCSI 1 st0(ncr0:5:0): Sequential-Access st0: Archive Viper 150 is a known rogue drive offline (ncr0:6:0): "NRC MBR-7 110" type 5 removable SCSI 2 cd0(ncr0:6:0): CD-ROM cd0(ncr0:6:0): asynchronous. cd present.[326402 x 2048 byte records] chip1 rev 3 on pci0:2 de0 rev 35 int a irq 10 on pci0:6 de0: DC21040 [10Mb/s] pass 2.3 Ethernet address 00:00:c0:f1:a4:0d de0: enabling Thinwire/AUI port Probing for devices on the ISA bus: ... Thanks, -Pat My opinions are my own. For a small royalty, they can be yours as well... Pat Lashley, Senior Software Engineer, Henry Davis Consulting patl@Phoenix.Volant.ORG || http://Phoenix.Volant.ORG/ || lashley@netcom.com From owner-freebsd-current Thu Apr 4 09:22:20 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA12004 for current-outgoing; Thu, 4 Apr 1996 09:22:20 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA11996 for ; Thu, 4 Apr 1996 09:22:13 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id DAA22855; Fri, 5 Apr 1996 03:19:56 +1000 Date: Fri, 5 Apr 1996 03:19:56 +1000 From: Bruce Evans Message-Id: <199604041719.DAA22855@godzilla.zeta.org.au> To: freebsd-current@FreeBSD.org, j@uriah.heep.sax.de Subject: Re: adjkerntz (was: cvs commit: src/usr.sbin/tzsetup ...) Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >(brokeness of adjkerntz for the last DST switchover in the EU) >How to reproduce: setup localtime as MET, and tweak your clock to run >from Mar 31, 1996, 01:58 MET onwards. Watch the syslog at 02:00 MET >(where the switch happened to 03:00 MET DST). I tested this. adjkerntz(8) has problems going from non-DST to DST. date(1) has even more problems with this. The other direction seems to work OK. I tested zones Sydney and Moscow. Your problem is more obvious for MET but easier to debug for Sydney - MET is close to GMT so there are some problem times around 4am when adjkerntz is run by cron. I had to fix `adjkerntz -a' to not wait when there is a problem. Waiting doesn't work for reboot, and it causes too many adjkerntz's when cron starts several waiting ones, and it gets in the way of debugging. --- *** adjkerntz.c~ Wed May 31 19:39:17 1995 --- adjkerntz.c Thu Apr 4 21:46:36 1996 *************** *** 161,166 **** * middle of the nonexistent hour means 3:30 am. */ syslog(LOG_WARNING, ! "Nonexistent local time -- will retry after %d secs", REPORT_PERIOD); (void) signal(SIGTERM, SIG_DFL); (void) sigprocmask(SIG_UNBLOCK, &mask, NULL); --- 161,172 ---- * middle of the nonexistent hour means 3:30 am. */ + if (!init) { + syslog(LOG_WARNING, + "Nonexistent local time -- giving up"); + return 1; + } syslog(LOG_WARNING, ! "Nonexistent local time -- will retry after %d secs", ! REPORT_PERIOD); (void) signal(SIGTERM, SIG_DFL); (void) sigprocmask(SIG_UNBLOCK, &mask, NULL); *************** *** 207,212 **** * but perhaps we never get here. */ syslog(LOG_WARNING, ! "Nonexistent (final) local time -- will retry after %d secs", REPORT_PERIOD); (void) signal(SIGTERM, SIG_DFL); (void) sigprocmask(SIG_UNBLOCK, &mask, NULL); --- 213,224 ---- * but perhaps we never get here. */ + if (!init) { + syslog(LOG_WARNING, + "Nonexistent (final) local time -- giving up"); + return 1; + } syslog(LOG_WARNING, ! "Nonexistent (final) local time -- will retry after %d secs", ! REPORT_PERIOD); (void) signal(SIGTERM, SIG_DFL); (void) sigprocmask(SIG_UNBLOCK, &mask, NULL); --- I used the following test program (warning: it always corrupts the time a little when it terminates and a lot when it is aborted): --- #!/bin/sh date -u +%y%m%d%H%m.%S >/tmp/znow # try(day, time) try() { local day local time day=$1 time=$2 echo $day$time date $day$time; obj/adjkerntz -a sysctl machdep.adjkerntz date obj/adjkerntz -a sysctl machdep.adjkerntz date } # Bugs for Northern Hemisphere in March. export TZ=Europe/Moscow for day in 960331 do # # The 4 hour difference between these groups of times is the initial # # timezone difference for Moscow. for time in 0159 0200 0201 0259 0300 0300 0301 \ 0559 0600 0601 0659 0700 0700 0701 do try $day $time done done # Bugs for Southern Hemisphere in October. export TZ=Australia/Sydney for day in 961027 do # The 11 hour difference between these groups of times is the initial # timezone difference for Sydney. for time in 0159 0200 0201 0259 0300 0300 0301 \ 1259 1300 1301 1359 1400 1400 1401 do try $day $time done done date -u `cat /tmp/znow` --- Running this gave the following output (except for the comment lines begiining with `#'): --- 9603310159 Sun Mar 31 01:59:00 MSK 1996 machdep.adjkerntz: -14400 Sun Mar 31 01:59:00 MSK 1996 machdep.adjkerntz: -14400 Sun Mar 31 01:59:00 MSK 1996 # # OK. # 9603310200 date: illegal time format usage: date [-nu] [-d dst] [-r seconds] [-t west] [+format] [yy[mm[dd[hh]]]]mm[.ss]] machdep.adjkerntz: -14400 Sun Mar 31 01:59:00 MSK 1996 machdep.adjkerntz: -14400 Sun Mar 31 01:59:00 MSK 1996 # # Bug in date(1). date(1) should fail, but the time was nonexistent, not # illegal, and the usage was correct. # 9603310201 date: illegal time format usage: date [-nu] [-d dst] [-r seconds] [-t west] [+format] [yy[mm[dd[hh]]]]mm[.ss]] machdep.adjkerntz: -14400 Sun Mar 31 01:59:01 MSK 1996 machdep.adjkerntz: -14400 Sun Mar 31 01:59:01 MSK 1996 # # Bug in date(1), as above. # 9603310259 date: illegal time format usage: date [-nu] [-d dst] [-r seconds] [-t west] [+format] [yy[mm[dd[hh]]]]mm[.ss]] machdep.adjkerntz: -14400 Sun Mar 31 01:59:01 MSK 1996 machdep.adjkerntz: -14400 Sun Mar 31 01:59:02 MSK 1996 # # Bug in date(1), as above. # 9603310300 Sun Mar 31 04:00:00 MSD 1996 machdep.adjkerntz: -14400 Sun Mar 31 04:00:00 MSD 1996 machdep.adjkerntz: -14400 Sun Mar 31 04:00:00 MSD 1996 # # A different bug in date(1) or in mktime(3). We set 3am but got 4am. # Also, machdep.adjkerntz should probably have changed. It changes when # we switch DST in the other direction. # 9603310300 Sun Mar 31 03:00:00 MSD 1996 machdep.adjkerntz: -14400 Sun Mar 31 03:00:00 MSD 1996 machdep.adjkerntz: -14400 Sun Mar 31 03:00:00 MSD 1996 # # OK, except possibly for the value in machdep.adjkerntz. # We set 3am again an got 3am. Since the DST is the same for the initial # and final dates, date(1) and mktime(3) have an easier task. # 9603310301 Sun Mar 31 03:01:00 MSD 1996 machdep.adjkerntz: -14400 Sun Mar 31 03:01:00 MSD 1996 machdep.adjkerntz: -14400 Sun Mar 31 03:01:00 MSD 1996 # # OK, as above. # 9603310559 Sun Mar 31 05:59:00 MSD 1996 machdep.adjkerntz: -14400 Sun Mar 31 05:59:00 MSD 1996 machdep.adjkerntz: -14400 Sun Mar 31 05:59:00 MSD 1996 # # OK, as above. # 9603310600 Sun Mar 31 06:00:00 MSD 1996 adjkerntz[7741]: Nonexistent local time -- giving up machdep.adjkerntz: -14400 Sun Mar 31 06:00:00 MSD 1996 adjkerntz[7744]: Nonexistent local time -- giving up machdep.adjkerntz: -14400 Sun Mar 31 06:00:00 MSD 1996 # # Bug in adjkerntz(8). I think it subtracts 4 hours from 6am to get 2am, # which is an invalid time. # 9603310601 Sun Mar 31 06:01:00 MSD 1996 adjkerntz[7748]: Nonexistent local time -- giving up machdep.adjkerntz: -14400 Sun Mar 31 06:01:00 MSD 1996 adjkerntz[7751]: Nonexistent local time -- giving up machdep.adjkerntz: -14400 Sun Mar 31 06:01:00 MSD 1996 # # Bug in adjkerntz(8), as above. # 9603310659 Sun Mar 31 06:59:00 MSD 1996 adjkerntz[7755]: Nonexistent local time -- giving up machdep.adjkerntz: -14400 Sun Mar 31 06:59:00 MSD 1996 adjkerntz[7758]: Nonexistent local time -- giving up machdep.adjkerntz: -14400 Sun Mar 31 06:59:00 MSD 1996 # # Bug in adjkerntz(8), as above. # 9603310700 Sun Mar 31 07:00:00 MSD 1996 machdep.adjkerntz: -14400 Sun Mar 31 07:00:00 MSD 1996 machdep.adjkerntz: -14400 Sun Mar 31 07:00:00 MSD 1996 # # OK, as above. # 9603310700 Sun Mar 31 07:00:00 MSD 1996 machdep.adjkerntz: -14400 Sun Mar 31 07:00:00 MSD 1996 machdep.adjkerntz: -14400 Sun Mar 31 07:00:00 MSD 1996 # # OK, as above. # 9603310701 Sun Mar 31 07:01:00 MSD 1996 machdep.adjkerntz: -14400 Sun Mar 31 07:01:00 MSD 1996 machdep.adjkerntz: -14400 Sun Mar 31 07:01:00 MSD 1996 # # OK, as above. # 9610270159 Sun Oct 27 01:59:00 EST 1996 machdep.adjkerntz: -36000 Sun Oct 27 01:59:00 EST 1996 machdep.adjkerntz: -36000 Sun Oct 27 01:59:00 EST 1996 # # OK. # 9610270200 date: illegal time format usage: date [-nu] [-d dst] [-r seconds] [-t west] [+format] [yy[mm[dd[hh]]]]mm[.ss]] machdep.adjkerntz: -36000 Sun Oct 27 01:59:00 EST 1996 machdep.adjkerntz: -36000 Sun Oct 27 01:59:00 EST 1996 # # Bug in date(1), as above. # 9610270201 date: illegal time format usage: date [-nu] [-d dst] [-r seconds] [-t west] [+format] [yy[mm[dd[hh]]]]mm[.ss]] machdep.adjkerntz: -36000 Sun Oct 27 01:59:01 EST 1996 machdep.adjkerntz: -36000 Sun Oct 27 01:59:01 EST 1996 # # Bug in date(1), as above. # 9610270259 date: illegal time format usage: date [-nu] [-d dst] [-r seconds] [-t west] [+format] [yy[mm[dd[hh]]]]mm[.ss]] machdep.adjkerntz: -36000 Sun Oct 27 01:59:01 EST 1996 machdep.adjkerntz: -36000 Sun Oct 27 01:59:01 EST 1996 # # Bug in date(1), as above. # 9610270300 Sun Oct 27 04:00:00 EST 1996 machdep.adjkerntz: -39600 Sun Oct 27 04:00:00 EST 1996 machdep.adjkerntz: -39600 Sun Oct 27 04:00:00 EST 1996 # # A different bug in date(1) or in mktime(3), as above. We set 3am but # got 4am. # machdep.adjkerntz got adjusted correctly, NOT as above. # 9610270300 Sun Oct 27 03:00:00 EST 1996 machdep.adjkerntz: -39600 Sun Oct 27 03:00:00 EST 1996 machdep.adjkerntz: -39600 Sun Oct 27 03:00:00 EST 1996 # # OK. Setting 3am worked the second time, as above. # 9610270301 Sun Oct 27 03:01:00 EST 1996 machdep.adjkerntz: -39600 Sun Oct 27 03:01:00 EST 1996 machdep.adjkerntz: -39600 Sun Oct 27 03:01:00 EST 1996 # # OK. # 9610271259 Sun Oct 27 12:59:00 EST 1996 machdep.adjkerntz: -39600 Sun Oct 27 12:59:00 EST 1996 machdep.adjkerntz: -39600 Sun Oct 27 12:59:00 EST 1996 # # OK. # 9610271300 Sun Oct 27 13:00:00 EST 1996 adjkerntz[8043]: Nonexistent local time -- giving up machdep.adjkerntz: -39600 Sun Oct 27 13:00:00 EST 1996 adjkerntz[8046]: Nonexistent local time -- giving up machdep.adjkerntz: -39600 Sun Oct 27 13:00:00 EST 1996 # # Bug in adjkerntz(8). I think it subtracts 11 hours from 1pm to get 2am, # which is an invalid time. # 9610271301 Sun Oct 27 13:01:00 EST 1996 adjkerntz[8050]: Nonexistent local time -- giving up machdep.adjkerntz: -39600 Sun Oct 27 13:01:00 EST 1996 adjkerntz[8053]: Nonexistent local time -- giving up machdep.adjkerntz: -39600 Sun Oct 27 13:01:00 EST 1996 # # Bug in adjkerntz(8), as above. # 9610271359 Sun Oct 27 13:59:00 EST 1996 adjkerntz[8057]: Nonexistent local time -- giving up machdep.adjkerntz: -39600 Sun Oct 27 13:59:00 EST 1996 adjkerntz[8060]: Nonexistent local time -- giving up machdep.adjkerntz: -39600 Sun Oct 27 13:59:00 EST 1996 # # Bug in adjkerntz(8), as above. # 9610271400 Sun Oct 27 14:00:00 EST 1996 machdep.adjkerntz: -39600 Sun Oct 27 14:00:00 EST 1996 machdep.adjkerntz: -39600 Sun Oct 27 14:00:00 EST 1996 # # OK. # 9610271400 Sun Oct 27 14:00:00 EST 1996 machdep.adjkerntz: -39600 Sun Oct 27 14:00:00 EST 1996 machdep.adjkerntz: -39600 Sun Oct 27 14:00:00 EST 1996 # # OK. # 9610271401 Sun Oct 27 14:01:00 EST 1996 machdep.adjkerntz: -39600 Sun Oct 27 14:01:00 EST 1996 machdep.adjkerntz: -39600 Sun Oct 27 14:01:00 EST 1996 Tue Oct 29 15:10:26 GMT 1996 # # OK. # --- Bruce From owner-freebsd-current Thu Apr 4 09:24:54 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA12214 for current-outgoing; Thu, 4 Apr 1996 09:24:54 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id JAA12199 for ; Thu, 4 Apr 1996 09:24:48 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id LAA01512; Thu, 4 Apr 1996 11:24:03 -0600 From: Joe Greco Message-Id: <199604041724.LAA01512@brasil.moneng.mei.com> Subject: Re: tty-level buffer overflows - what to do? To: root@deadline.snafu.de (Andreas S. Wetzel) Date: Thu, 4 Apr 1996 11:24:02 -0600 (CST) Cc: current@freebsd.org In-Reply-To: from "Andreas S. Wetzel" at Apr 4, 96 05:17:42 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Hi! > --- > > On a relatively fresh installed -current Box which serves as a modem > server for two V34+ modems and one V34 Modem on our local LAN, I get > lots of messages on the sysconsole when doing high-speed transfers: > > sio2: 1988 more tty-level buffer overflows (total 23215) > etc... > > This especially happens when transferring pure ASCII data which gets > quite good compressed by the two modems so that I actually transfer > at bitrates of about 50kbit and higher. > > Can I do anything about that (i.e. increase memory on this machine) or is > this a problem related to the sio driver? > > Thankful for any advice What are you doing? rz/sz? What kind of machine is it? (a 386sx/16 has much less CPU than a P90..) Are you using hardware flow control correctly? What kind of drives? IDE drives bite, particularly if they are being used at the same time as the serial port... etc, etc. "More data, please!" :-) ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/546-7968 From owner-freebsd-current Thu Apr 4 09:36:19 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA13341 for current-outgoing; Thu, 4 Apr 1996 09:36:19 -0800 (PST) Received: from cenotaph.snafu.de (root@deadline.berlin.netSurf.DE [194.64.158.25]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA13293 for ; Thu, 4 Apr 1996 09:36:08 -0800 (PST) Received: by cenotaph.snafu.de from deadline.snafu.de using smtp id m0u4stS-0002bfC; Thu, 4 Apr 96 19:32:22 +0200 (MET DST) (/\##/\ Smail3.1.30.13 #30.1) Received: by deadline.snafu.de id m0u4svg-0009vMC; Thu, 4 Apr 96 19:34:40 +0200 (MET DST) (/\##/\ Smail3.1.30.13 #30.1) Message-Id: From: root@deadline.snafu.de (Andreas S. Wetzel) Subject: Re: tty-level buffer overflows - what to do? To: jgreco@brasil.moneng.mei.com (Joe Greco) Date: Thu, 4 Apr 1996 19:34:40 +0200 (MET DST) Cc: current@freebsd.org In-Reply-To: <199604041724.LAA01512@brasil.moneng.mei.com> from Joe Greco at "Apr 4, 96 11:24:02 am" Organization: A world stranger than you have ever imagined. X-Mailer: ELM [version 2.4ME+ PL13] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi! --- Joe Greco writes: ] > On a relatively fresh installed -current Box which serves as a modem ] > server for two V34+ modems and one V34 Modem on our local LAN, I get ] > lots of messages on the sysconsole when doing high-speed transfers: ] > ] > sio2: 1988 more tty-level buffer overflows (total 23215) ] > etc... ] > ] > This especially happens when transferring pure ASCII data which gets ] > quite good compressed by the two modems so that I actually transfer ] > at bitrates of about 50kbit and higher. ] > ] > Can I do anything about that (i.e. increase memory on this machine) or is ] > this a problem related to the sio driver? ] > ] > Thankful for any advice ] ] What are you doing? rz/sz? What kind of machine is it? (a 386sx/16 has ] much less CPU than a P90..) Are you using hardware flow control correctly? ] What kind of drives? IDE drives bite, particularly if they are being used ] at the same time as the serial port... etc, etc. ] ] "More data, please!" :-) The machine is a 486SX at 40 MHz with 4 Meg. RAM and a 210 Mb IDE hard drive. The serial ports used on the modems are all of type 16550A. RTS/CTS flow control is hardwired for all modem lines. The machine has one dedicated slip line as well as two dialup ports attached to it. The syslog messages all seemed to related to the first dialup port which is a V34+ modem operated at 115k2 bps. The mgetty on the dialup ports is configured to do a direct rlogin onto another FreeBSD machine for all logins, so it just hands off the dialup connections. Regards, mickey -- (__) (@@) Andreas S. Wetzel E-mail: mickey@deadline.snafu.de /-------\/ Utrechter Strasse 41 Web: http://deadline.snafu.de/ / | || 13347 Berlin Voice: <+4930> 456 81 68 * ||----|| Germany Fax/Data: <+4930> 455 19 57 ~~ ~~ From owner-freebsd-current Thu Apr 4 10:23:14 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA17067 for current-outgoing; Thu, 4 Apr 1996 10:23:14 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id KAA17062 for ; Thu, 4 Apr 1996 10:23:08 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id MAA01616; Thu, 4 Apr 1996 12:21:45 -0600 From: Joe Greco Message-Id: <199604041821.MAA01616@brasil.moneng.mei.com> Subject: Re: tty-level buffer overflows - what to do? To: root@deadline.snafu.de (Andreas S. Wetzel) Date: Thu, 4 Apr 1996 12:21:45 -0600 (CST) Cc: jgreco@brasil.moneng.mei.com, current@freebsd.org In-Reply-To: from "Andreas S. Wetzel" at Apr 4, 96 07:34:40 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello, > The machine is a 486SX at 40 MHz Should be OK.. > with 4 Meg. RAM That's a little tight (I put 8 minimum in my boxes).. > and a 210 Mb IDE hard drive. Ow. > The serial ports used on the modems are all of type 16550A. RTS/CTS flow > control is hardwired for all modem lines. The machine has one dedicated > slip line as well as two dialup ports attached to it. The syslog messages > all seemed to related to the first dialup port which is a V34+ modem operated > at 115k2 bps. The mgetty on the dialup ports is configured to do a direct > rlogin onto another FreeBSD machine for all logins, so it just hands off > the dialup connections. My gut instinct is that you would find a correlation between your IDE disk going and these error messages. A 486/40 should be adequate, even for several lines at 115200. The fact that you are tight on memory would tend to cause you to hit the disk correspondingly more often, which would cause some burps in serial I/O... the fact that you're running rlogin also would tend to cause you to swap more, if you have a few active sessions. One of the nice things about kernel-mode SLIP is that no paging is involved.... ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/546-7968 From owner-freebsd-current Thu Apr 4 10:34:44 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA18145 for current-outgoing; Thu, 4 Apr 1996 10:34:44 -0800 (PST) Received: from cenotaph.snafu.de (root@deadline.berlin.netSurf.DE [194.64.158.25]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA18136 for ; Thu, 4 Apr 1996 10:34:37 -0800 (PST) Received: by cenotaph.snafu.de from deadline.snafu.de using smtp id m0u4tpL-0002boC; Thu, 4 Apr 96 20:32:11 +0200 (MET DST) (/\##/\ Smail3.1.30.13 #30.1) Received: by deadline.snafu.de id m0u4trd-000A0mC; Thu, 4 Apr 96 20:34:33 +0200 (MET DST) (/\##/\ Smail3.1.30.13 #30.1) Message-Id: From: root@deadline.snafu.de (Andreas S. Wetzel) Subject: Re: tty-level buffer overflows - what to do? To: jgreco@brasil.moneng.mei.com (Joe Greco) Date: Thu, 4 Apr 1996 20:34:33 +0200 (MET DST) Cc: jgreco@brasil.moneng.mei.com, current@freebsd.org In-Reply-To: <199604041821.MAA01616@brasil.moneng.mei.com> from Joe Greco at "Apr 4, 96 12:21:45 pm" Organization: A world stranger than you have ever imagined. X-Mailer: ELM [version 2.4ME+ PL13] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi! --- Joe Greco writes: ] > The machine is a 486SX at 40 MHz ] ] Should be OK.. ] ] > with 4 Meg. RAM ] ] That's a little tight (I put 8 minimum in my boxes).. I plan to put in 8 Meg shortly but til then it has to live with the 4 Meg. I tried to install another Meg on 256k simms but didn't suceed cause the motherboard only recognizes one meg of memory when I put in the 256k simms additionally to the 4 meg. ] > and a 210 Mb IDE hard drive. ] ] Ow. Not very serious til now... the machine runs at about 40% diskspace used and about 10% swap used (of 40 Mb). ] > The serial ports used on the modems are all of type 16550A. RTS/CTS flow ] > control is hardwired for all modem lines. The machine has one dedicated ] > slip line as well as two dialup ports attached to it. The syslog messages ] > all seemed to related to the first dialup port which is a V34+ modem operated ] > at 115k2 bps. The mgetty on the dialup ports is configured to do a direct ] > rlogin onto another FreeBSD machine for all logins, so it just hands off ] > the dialup connections. ] ] My gut instinct is that you would find a correlation between your IDE disk ] going and these error messages. A 486/40 should be adequate, even for ] several lines at 115200. The fact that you are tight on memory would tend ] to cause you to hit the disk correspondingly more often, which would cause ] some burps in serial I/O... the fact that you're running rlogin also would ] tend to cause you to swap more, if you have a few active sessions. Maybe that happened while I was tormenting the machine with several rsh's from my other box. That seemed to make it swap really *heavily* :-) But another problem is still going on on that machine. During boot there are several occurences of "stray irq 7" messages until syslog says it would not log them anymore. I have no idea where this stray irq's should happen. Physically there is no adaptor card installed which could ever generate a IRQ 7 ? Possible that this has to do with the other thing? ] One of the nice things about kernel-mode SLIP is that no paging is involved.... The SLIP line does not seem to bother the machine. (Fortunately!) Regards, mickey -- (__) (@@) Andreas S. Wetzel E-mail: mickey@deadline.snafu.de /-------\/ Utrechter Strasse 41 Web: http://deadline.snafu.de/ / | || 13347 Berlin Voice: <+4930> 456 81 68 * ||----|| Germany Fax/Data: <+4930> 455 19 57 ~~ ~~ From owner-freebsd-current Thu Apr 4 11:14:02 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA21341 for current-outgoing; Thu, 4 Apr 1996 11:14:02 -0800 (PST) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA21334 for ; Thu, 4 Apr 1996 11:14:00 -0800 (PST) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id MAA17250; Thu, 4 Apr 1996 12:12:03 -0700 Date: Thu, 4 Apr 1996 12:12:03 -0700 From: Nate Williams Message-Id: <199604041912.MAA17250@rocky.sri.MT.net> To: Joe Greco Cc: root@deadline.snafu.de (Andreas S. Wetzel), current@FreeBSD.org Subject: Re: tty-level buffer overflows - what to do? In-Reply-To: <199604041821.MAA01616@brasil.moneng.mei.com> References: <199604041821.MAA01616@brasil.moneng.mei.com> Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > The serial ports used on the modems are all of type 16550A. RTS/CTS flow > > control is hardwired for all modem lines. The machine has one dedicated > > slip line as well as two dialup ports attached to it. The syslog messages > > all seemed to related to the first dialup port which is a V34+ modem operated > > at 115k2 bps. The mgetty on the dialup ports is configured to do a direct > > rlogin onto another FreeBSD machine for all logins, so it just hands off > > the dialup connections. > > My gut instinct is that you would find a correlation between your IDE disk > going and these error messages. A 486/40 should be adequate, even for > several lines at 115200. The fact that you are tight on memory would tend > to cause you to hit the disk correspondingly more often, which would cause > some burps in serial I/O... the fact that you're running rlogin also would > tend to cause you to swap more, if you have a few active sessions. One of > the nice things about kernel-mode SLIP is that no paging is involved.... > That's possible, but let me throw in another data point. 486/66 - 16MB memory 3 16550 UART serial lines - 115K 540MB IDE drive With 2 lines going full blast (sup updates!) I see *NO* overflows on my box. Again, my box is running with about 6MB of free memory all the time, so I rarely hit the disk, but I've done compiles on the machine to upgrade software with no noticeable degradation of serial speed. However, I do no paging at all, so my disk is mostly idle even during compiles. Nate From owner-freebsd-current Thu Apr 4 11:14:19 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA21375 for current-outgoing; Thu, 4 Apr 1996 11:14:19 -0800 (PST) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA21368 for ; Thu, 4 Apr 1996 11:14:15 -0800 (PST) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id MAA17253; Thu, 4 Apr 1996 12:14:09 -0700 Date: Thu, 4 Apr 1996 12:14:09 -0700 From: Nate Williams Message-Id: <199604041914.MAA17253@rocky.sri.MT.net> To: root@deadline.snafu.de (Andreas S. Wetzel) Cc: jgreco@brasil.moneng.mei.com (Joe Greco), current@freebsd.org Subject: Re: tty-level buffer overflows - what to do? In-Reply-To: References: <199604041821.MAA01616@brasil.moneng.mei.com> Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > But another problem is still going on on that machine. During boot there > are several occurences of "stray irq 7" messages until syslog says it would > not log them anymore. I have no idea where this stray irq's should happen. > Physically there is no adaptor card installed which could ever generate a > IRQ 7 ? Possible that this has to do with the other thing? This is a pretty good indication that something is mis-confugred. IRQ 7 is the 'junk' interrupt, which means it gets all of the interrupts not otherwise assigned to a particular piece of hardware. Something is generating interrupts on your system bogusly and you need to find out what. Nate From owner-freebsd-current Thu Apr 4 11:21:54 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA21834 for current-outgoing; Thu, 4 Apr 1996 11:21:54 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id LAA21829 for ; Thu, 4 Apr 1996 11:21:50 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id NAA01863; Thu, 4 Apr 1996 13:19:26 -0600 From: Joe Greco Message-Id: <199604041919.NAA01863@brasil.moneng.mei.com> Subject: Re: tty-level buffer overflows - what to do? To: nate@sri.MT.net (Nate Williams) Date: Thu, 4 Apr 1996 13:19:26 -0600 (CST) Cc: jgreco@brasil.moneng.mei.com, root@deadline.snafu.de, current@FreeBSD.org In-Reply-To: <199604041912.MAA17250@rocky.sri.MT.net> from "Nate Williams" at Apr 4, 96 12:12:03 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > My gut instinct is that you would find a correlation between your IDE disk > > going and these error messages. A 486/40 should be adequate, even for > > several lines at 115200. The fact that you are tight on memory would tend > > to cause you to hit the disk correspondingly more often, which would cause > > some burps in serial I/O... the fact that you're running rlogin also would > > tend to cause you to swap more, if you have a few active sessions. One of > > the nice things about kernel-mode SLIP is that no paging is involved.... > > That's possible, but let me throw in another data point. > > 486/66 - 16MB memory > 3 16550 UART serial lines - 115K > 540MB IDE drive > > With 2 lines going full blast (sup updates!) I see *NO* overflows on my > box. Again, my box is running with about 6MB of free memory all the > time, so I rarely hit the disk, but I've done compiles on the machine to > upgrade software with no noticeable degradation of serial speed. > However, I do no paging at all, so my disk is mostly idle even during > compiles. Run "du /" and watch your serial comms get choppy :-/ If you are running kernel mode SLIP or PPP, remember that you have several additional advantages over the described configuration: 1) the code to deal with the connection can't get swapped out. 2) no context switch overhead.. 3) you don't have to go through all the tty processing layers. with only 4MB of memory, the described configuration is not likely to have "free memory". ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/546-7968 From owner-freebsd-current Thu Apr 4 11:28:38 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA22380 for current-outgoing; Thu, 4 Apr 1996 11:28:38 -0800 (PST) Received: from cenotaph.snafu.de (deadline.berlin.netSurf.DE [194.64.158.25]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA22351 for ; Thu, 4 Apr 1996 11:28:26 -0800 (PST) Received: by cenotaph.snafu.de from deadline.snafu.de using smtp id m0u4ueY-0002eEC; Thu, 4 Apr 96 21:25:06 +0200 (MET DST) (/\##/\ Smail3.1.30.13 #30.1) Received: by deadline.snafu.de id m0u4ugp-000A0mC; Thu, 4 Apr 96 21:27:27 +0200 (MET DST) (/\##/\ Smail3.1.30.13 #30.1) Message-Id: From: root@deadline.snafu.de (Andreas S. Wetzel) Subject: Re: tty-level buffer overflows - what to do? To: nate@sri.MT.net (Nate Williams) Date: Thu, 4 Apr 1996 21:27:26 +0200 (MET DST) Cc: jgreco@brasil.moneng.mei.com, current@freebsd.org In-Reply-To: <199604041914.MAA17253@rocky.sri.MT.net> from Nate Williams at "Apr 4, 96 12:14:09 pm" Organization: A world stranger than you have ever imagined. X-Mailer: ELM [version 2.4ME+ PL13] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi! --- Nate Williams writes: ] > But another problem is still going on on that machine. During boot there ] > are several occurences of "stray irq 7" messages until syslog says it would ] > not log them anymore. I have no idea where this stray irq's should happen. ] > Physically there is no adaptor card installed which could ever generate a ] > IRQ 7 ? Possible that this has to do with the other thing? ] ] This is a pretty good indication that something is mis-confugred. IRQ 7 ] is the 'junk' interrupt, which means it gets all of the interrupts not ] otherwise assigned to a particular piece of hardware. Something is ] generating interrupts on your system bogusly and you need to find out ] what. That means the interrupt that happens is not guaranteed to be IRQ 7 but maybe any other unassigned interrupt? The only cards I have installed in this machine are the following: IDE/FDC controller card (without any other ports etc) Multi I/O card with COM1 COM2 LPT(completely disabled including IRQ) and Gameport (also disabled) Dual I/O card with COM3 and COM4 standard ET4000 video board Ethernet adaptor (ISA 16 bit software configurable) ---- The kernel seems to find all those devices: FreeBSD 2.2-CURRENT #2: Mon Mar 25 15:46:17 MET 1996 root@deadline.snafu.de:/usr/src/sys/compile/CENOTAPH CPU: i486DX (486-class CPU) real memory = 4456448 (4352K bytes) avail memory = 3133440 (3060K bytes) Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA mono <4 virtual consoles, flags=0x0> ed0 at 0x300-0x31f irq 12 on isa ed0: address 08:00:00:19:08:36, type NE2000 (16 bit) sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16450 sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A sio2 at 0x3e8-0x3ef irq 9 on isa sio2: type 16550A sio3 at 0x2e8-0x2ef irq 5 on isa sio3: type 16550A lpt0 not found at 0x278 wdc0 at 0x1f0-0x1f7 irq 14 flags 0x80ff80ff on isa wdc0: unit 0 (wd0): , multi-block-64 wd0: 202MB (415264 sectors), 683 cyls, 16 heads, 38 S/T, 512 B/S fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 765 fd0: 1.44MB 3.5in stray irq 7 stray irq 7 stray irq 7 stray irq 7 stray irq 7 too many stray irq 7's; not logging any more That's what it goes like. Any Ideas? Regards, mickey -- (__) (@@) Andreas S. Wetzel E-mail: mickey@deadline.snafu.de /-------\/ Utrechter Strasse 41 Web: http://deadline.snafu.de/ / | || 13347 Berlin Voice: <+4930> 456 81 68 * ||----|| Germany Fax/Data: <+4930> 455 19 57 ~~ ~~ From owner-freebsd-current Thu Apr 4 11:28:40 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA22387 for current-outgoing; Thu, 4 Apr 1996 11:28:40 -0800 (PST) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA22366 for ; Thu, 4 Apr 1996 11:28:35 -0800 (PST) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id MAA17299; Thu, 4 Apr 1996 12:26:28 -0700 Date: Thu, 4 Apr 1996 12:26:28 -0700 From: Nate Williams Message-Id: <199604041926.MAA17299@rocky.sri.MT.net> To: Joe Greco Cc: nate@sri.MT.net (Nate Williams), root@deadline.snafu.de, current@FreeBSD.org Subject: Re: tty-level buffer overflows - what to do? In-Reply-To: <199604041919.NAA01863@brasil.moneng.mei.com> References: <199604041912.MAA17250@rocky.sri.MT.net> <199604041919.NAA01863@brasil.moneng.mei.com> Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk [ overflows due to IDE interface ] > > Run "du /" and watch your serial comms get choppy :-/ > > If you are running kernel mode SLIP or PPP, remember that you have several > additional advantages over the described configuration: Ahh, I'm using kernel mode SLIP and PPP, so that's probably why. Nate From owner-freebsd-current Thu Apr 4 11:30:32 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA22616 for current-outgoing; Thu, 4 Apr 1996 11:30:32 -0800 (PST) Received: from cenotaph.snafu.de (root@deadline.berlin.netSurf.DE [194.64.158.25]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA22583 for ; Thu, 4 Apr 1996 11:30:20 -0800 (PST) Received: by cenotaph.snafu.de from deadline.snafu.de using smtp id m0u4uhR-0002eFC; Thu, 4 Apr 96 21:28:05 +0200 (MET DST) (/\##/\ Smail3.1.30.13 #30.1) Received: by deadline.snafu.de id m0u4ujl-000A0mC; Thu, 4 Apr 96 21:30:29 +0200 (MET DST) (/\##/\ Smail3.1.30.13 #30.1) Message-Id: From: root@deadline.snafu.de (Andreas S. Wetzel) Subject: Re: tty-level buffer overflows - what to do? To: jgreco@brasil.moneng.mei.com (Joe Greco) Date: Thu, 4 Apr 1996 21:30:29 +0200 (MET DST) Cc: nate@sri.MT.net, jgreco@brasil.moneng.mei.com, current@FreeBSD.org In-Reply-To: <199604041919.NAA01863@brasil.moneng.mei.com> from Joe Greco at "Apr 4, 96 01:19:26 pm" Organization: A world stranger than you have ever imagined. X-Mailer: ELM [version 2.4ME+ PL13] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hi! --- Joe Greco writes: ] > With 2 lines going full blast (sup updates!) I see *NO* overflows on my ] > box. Again, my box is running with about 6MB of free memory all the ] > time, so I rarely hit the disk, but I've done compiles on the machine to ] > upgrade software with no noticeable degradation of serial speed. ] > However, I do no paging at all, so my disk is mostly idle even during ] > compiles. ] ] Run "du /" and watch your serial comms get choppy :-/ I coupled the two modems and did a "ls -Rl /" several times. Seemed ok. ] If you are running kernel mode SLIP or PPP, remember that you have several ] additional advantages over the described configuration: ] ] 1) the code to deal with the connection can't get swapped out. ] 2) no context switch overhead.. ] 3) you don't have to go through all the tty processing layers. ] ] with only 4MB of memory, the described configuration is not likely to have ] "free memory". The SLIP support is compiled into the kernel if that's what you mean. I never used SLIP otherwise nor I did use user mode PPP or some ever. Regards, mickey -- (__) (@@) Andreas S. Wetzel E-mail: mickey@deadline.snafu.de /-------\/ Utrechter Strasse 41 Web: http://deadline.snafu.de/ / | || 13347 Berlin Voice: <+4930> 456 81 68 * ||----|| Germany Fax/Data: <+4930> 455 19 57 ~~ ~~ From owner-freebsd-current Thu Apr 4 11:32:10 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA22802 for current-outgoing; Thu, 4 Apr 1996 11:32:10 -0800 (PST) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA22757 for ; Thu, 4 Apr 1996 11:32:07 -0800 (PST) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id MAA17330; Thu, 4 Apr 1996 12:31:59 -0700 Date: Thu, 4 Apr 1996 12:31:59 -0700 From: Nate Williams Message-Id: <199604041931.MAA17330@rocky.sri.MT.net> To: root@deadline.snafu.de (Andreas S. Wetzel) Cc: nate@sri.MT.net (Nate Williams), jgreco@brasil.moneng.mei.com, current@freebsd.org Subject: Re: tty-level buffer overflows - what to do? In-Reply-To: References: <199604041914.MAA17253@rocky.sri.MT.net> Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > That means the interrupt that happens is not guaranteed to be IRQ 7 but > maybe any other unassigned interrupt? Yep. > The only cards I have installed in this machine are the following: > > IDE/FDC controller card (without any other ports etc) > > Multi I/O card with COM1 COM2 LPT(completely disabled including IRQ) and > Gameport (also disabled) I'll bet dollars to donuts that the 'disabling' of the card doesn't actually disable the generation of suprious interupts. I have found few cheap I/O boards that actually 'disable' interrupts. Most of them no longer assign them to an IRQ handler, but still generate them. Nate From owner-freebsd-current Thu Apr 4 12:14:52 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA26361 for current-outgoing; Thu, 4 Apr 1996 12:14:52 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA26355 for ; Thu, 4 Apr 1996 12:14:50 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA22425; Thu, 4 Apr 1996 13:10:04 -0700 From: Terry Lambert Message-Id: <199604042010.NAA22425@phaeton.artisoft.com> Subject: Re: 2.2-960323 Panic in mount_msdos To: franky@pinewood.nl (Frank ten Wolde) Date: Thu, 4 Apr 1996 13:10:04 -0700 (MST) Cc: freebsd-current@FreeBSD.ORG In-Reply-To: <9604041520.ZM3696@pwood1.pinewood.nl> from "Frank ten Wolde" at Apr 4, 96 03:20:03 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I just tried to mount a Windows NT file system (NTFS) using: > > mount -t msdos /dev/sd0s2 /dos > > (I thought it was an MSDOS-FAT file system :-). The 2.2-960223-SNAPSHOT > of FreeBSD immediately paniced: [ ... ] > I know you cannot mount an NTFS under FreeBSD, but at least the system > should not crash. > > I just report this problem as I have too little knowledge of the internals > of the kernel to fix the problem myself :-) A file system operates by copying on disk strucutures into memory and then using the offsets in the coppy to access additional memory. It does not bounds-check these accesses. If there is a problem with this, it's that the DOSFS did not validate that the device was in fact a DOS partition before going gung-ho into dereferencing. Not bounds-checking dereferences isn't an error; it an optimization, and it's allowable because mount is not a user accessable command (you have to be root). The fix for inconsistent media is to run fsck (or equivalent) on it before attempting a mount; the fix is procedural, in other words, and doesn't require a change to the mount code. The DOSFS code is, unfortunately, well known to be unstable. It does not do the type validation it should, ad there is not a fsck equivalent program as part of the package. The DOSFS is being rewritten (not by me). For now, make sure that you have chkdsk'ed the DOS disk prior to booting FreeBSD. If it fails chkdsk, do not attempt to mount it. 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 Apr 4 12:26:58 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA27523 for current-outgoing; Thu, 4 Apr 1996 12:26:58 -0800 (PST) Received: from multivac.orthanc.com (multivac.orthanc.com [206.12.238.2]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id MAA27514 for ; Thu, 4 Apr 1996 12:26:51 -0800 (PST) Received: from localhost (lyndon@localhost) by multivac.orthanc.com (8.7.3/8.7.3) with SMTP id MAA24533; Thu, 4 Apr 1996 12:26:08 -0800 (PST) Message-Id: <199604042026.MAA24533@multivac.orthanc.com> From: Lyndon Nerenberg VE7TCP To: Poul-Henning Kamp cc: freebsd-current@freebsd.org Subject: Re: Nice Firewall :-) In-reply-to: Your message of "Thu, 04 Apr 1996 09:01:18 GMT." <1879.828608478@critter.tfs.com> Date: Thu, 04 Apr 1996 12:26:07 -0800 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>>>> "Poul-Henning" == Poul-Henning Kamp writes: Poul-Henning> If you had paid attention to the mailinglists, you Poul-Henning> would have known that ipfw was changed to a default Poul-Henning> policy of deny some time back. Yes yes. The surprise was the -1 return from sendto(). This was not consistent with the old behaviour of just swallowing the packet. I don't remember this being mentioned on the list. Poul-Henning> Look at the manual and the /etc/rc.firewall I Poul-Henning> committed yesterday for more info. The rc.firewall file is a very good idea. I'll assume the relevent manpages will be updated at some point to document the new error return. (The sup's still running and hasn't gotten that far yet.) --lyndon From owner-freebsd-current Thu Apr 4 12:30:10 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA27797 for current-outgoing; Thu, 4 Apr 1996 12:30:10 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA27790 for ; Thu, 4 Apr 1996 12:30:07 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0u4vfP-0003wjC; Thu, 4 Apr 96 12:30 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id UAA00449; Thu, 4 Apr 1996 20:29:58 GMT X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: Lyndon Nerenberg VE7TCP cc: freebsd-current@FreeBSD.org Subject: Re: Nice Firewall :-) In-reply-to: Your message of "Thu, 04 Apr 1996 12:26:07 PST." <199604042026.MAA24533@multivac.orthanc.com> Date: Thu, 04 Apr 1996 20:29:57 +0000 Message-ID: <447.828649797@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > >>>>> "Poul-Henning" == Poul-Henning Kamp writes: > > Poul-Henning> If you had paid attention to the mailinglists, you > Poul-Henning> would have known that ipfw was changed to a default > Poul-Henning> policy of deny some time back. > > Yes yes. The surprise was the -1 return from sendto(). This was not > consistent with the old behaviour of just swallowing the packet. I > don't remember this being mentioned on the list. I have not definitively decided on that point. I think ENOACCES is a good idea but it may break too many things. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Thu Apr 4 12:48:00 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA29074 for current-outgoing; Thu, 4 Apr 1996 12:48:00 -0800 (PST) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA29063 for ; Thu, 4 Apr 1996 12:47:51 -0800 (PST) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id MAA07198; Thu, 4 Apr 1996 12:45:18 -0800 From: "Rodney W. Grimes" Message-Id: <199604042045.MAA07198@GndRsh.aac.dev.com> Subject: Re: tty-level buffer overflows - what to do? To: root@deadline.snafu.de (Andreas S. Wetzel) Date: Thu, 4 Apr 1996 12:45:17 -0800 (PST) Cc: jgreco@brasil.moneng.mei.com, nate@sri.MT.net, current@FreeBSD.org In-Reply-To: from "Andreas S. Wetzel" at "Apr 4, 96 09:30:29 pm" X-Mailer: ELM [version 2.4ME+ PL11 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Hi! > --- > > Joe Greco writes: > > ] > With 2 lines going full blast (sup updates!) I see *NO* overflows on my > ] > box. Again, my box is running with about 6MB of free memory all the > ] > time, so I rarely hit the disk, but I've done compiles on the machine to > ] > upgrade software with no noticeable degradation of serial speed. > ] > However, I do no paging at all, so my disk is mostly idle even during > ] > compiles. > ] > ] Run "du /" and watch your serial comms get choppy :-/ > > I coupled the two modems and did a "ls -Rl /" several times. Seemed ok. ls -Rl / spent most of it's time doing console output, try something more aggresive: find / >/dev/null du -s / tar cf /dev/null / -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Thu Apr 4 12:49:35 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA29412 for current-outgoing; Thu, 4 Apr 1996 12:49:35 -0800 (PST) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA29380 for ; Thu, 4 Apr 1996 12:49:12 -0800 (PST) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id MAA07188; Thu, 4 Apr 1996 12:43:29 -0800 From: "Rodney W. Grimes" Message-Id: <199604042043.MAA07188@GndRsh.aac.dev.com> Subject: Re: tty-level buffer overflows - what to do? To: nate@sri.MT.net (Nate Williams) Date: Thu, 4 Apr 1996 12:43:29 -0800 (PST) Cc: root@deadline.snafu.de, jgreco@brasil.moneng.mei.com, current@FreeBSD.org In-Reply-To: <199604041914.MAA17253@rocky.sri.MT.net> from Nate Williams at "Apr 4, 96 12:14:09 pm" X-Mailer: ELM [version 2.4ME+ PL11 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > But another problem is still going on on that machine. During boot there > > are several occurences of "stray irq 7" messages until syslog says it would > > not log them anymore. I have no idea where this stray irq's should happen. > > Physically there is no adaptor card installed which could ever generate a > > IRQ 7 ? Possible that this has to do with the other thing? > > This is a pretty good indication that something is mis-confugred. IRQ 7 > is the 'junk' interrupt, which means it gets all of the interrupts not > otherwise assigned to a particular piece of hardware. Something is > generating interrupts on your system bogusly and you need to find out > what. This is not quite correct, IRQ 7 is signal when someone asserts an IRQ singal then removes that signal _before_ the CPU runs the interrupt acknowledge cycle to the 8259 PIC. Devices that fully assert and hold it asserted do _not_ cause IRQ7, they cause there respective interrupt. Often the cause of stray IRQ7's is noisy or floating IRQ signals from boards that are not recognized by FreeBSD. In any case a system having this problem is going to be marginal at best, you should be able to see the rate of these events with a vmstat -i, watch the irq 7 counter... if you only get a burst of these during boot then you are probably okay and it is caused by some strange piece of hardware that is tickled into bad behavior by the invasive FreeBSD probe code, one way to cut that down is to eliminate all devices from the kernel that you do not really have. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Thu Apr 4 12:53:14 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA29838 for current-outgoing; Thu, 4 Apr 1996 12:53:14 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA29832 for ; Thu, 4 Apr 1996 12:53:12 -0800 (PST) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id MAA27105 for ; Thu, 4 Apr 1996 12:52:51 -0800 Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id MAA07212; Thu, 4 Apr 1996 12:48:33 -0800 From: "Rodney W. Grimes" Message-Id: <199604042048.MAA07212@GndRsh.aac.dev.com> Subject: Re: tty-level buffer overflows - what to do? To: root@deadline.snafu.de (Andreas S. Wetzel) Date: Thu, 4 Apr 1996 12:48:33 -0800 (PST) Cc: nate@sri.MT.net, jgreco@brasil.moneng.mei.com, current@FreeBSD.org In-Reply-To: from "Andreas S. Wetzel" at "Apr 4, 96 09:27:26 pm" X-Mailer: ELM [version 2.4ME+ PL11 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Hi! > --- > > Nate Williams writes: > > ] > But another problem is still going on on that machine. During boot there > ] > are several occurences of "stray irq 7" messages until syslog says it would > ] > not log them anymore. I have no idea where this stray irq's should happen. > ] > Physically there is no adaptor card installed which could ever generate a > ] > IRQ 7 ? Possible that this has to do with the other thing? > ] > ] This is a pretty good indication that something is mis-confugred. IRQ 7 > ] is the 'junk' interrupt, which means it gets all of the interrupts not > ] otherwise assigned to a particular piece of hardware. Something is > ] generating interrupts on your system bogusly and you need to find out > ] what. > > That means the interrupt that happens is not guaranteed to be IRQ 7 but > maybe any other unassigned interrupt? > > The only cards I have installed in this machine are the following: > > IDE/FDC controller card (without any other ports etc) Many of these are norious for glitching IRQ lines... > Multi I/O card with COM1 COM2 LPT(completely disabled including IRQ) and > Gameport (also disabled) > > Dual I/O card with COM3 and COM4 > > standard ET4000 video board And I bet you a $1.00 this puppy is generating IRQ2/9 and causing you grief as a conflict with sio2... > Ethernet adaptor (ISA 16 bit software configurable) These too... > ---- > > The kernel seems to find all those devices: ... > sio2 at 0x3e8-0x3ef irq 9 on isa > sio2: type 16550A Check your ET4000 for an IRQ jumper, if it does not have one check the connector on the board to see if a trace is connected to the IRQ2 signal (pin B4). -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Thu Apr 4 13:04:26 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA01238 for current-outgoing; Thu, 4 Apr 1996 13:04:26 -0800 (PST) Received: from ki.net (root@ki.net [205.150.102.1]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id NAA01225 for ; Thu, 4 Apr 1996 13:04:17 -0800 (PST) Received: from localhost (scrappy@localhost) by ki.net (8.7.4/8.7.4) with SMTP id QAA10874; Thu, 4 Apr 1996 16:01:11 -0500 (EST) Date: Thu, 4 Apr 1996 16:00:58 -0500 (EST) From: "Marc G. Fournier" To: JULIAN Elischer cc: "Jordan K. Hubbard" , jdp@polstra.com, jgreco@brasil.moneng.mei.com, cat@ghost.uunet.ca, current@FreeBSD.org Subject: Re: Advice/Recommendation needed In-Reply-To: <199604032121.NAA09836@ref.tfs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 3 Apr 1996, JULIAN Elischer wrote: > last I looked America was a continent and not a country.. > Depends on your perspective, I guess. Technically, America is the continent that extends from the southern tip of South American to the northern tip of North American... ...unfortunately, to most ppl, America means the USofA. I live on the continent of America, yet, I'm definitely not American. I think that the USofA should change their name to reduce the confusion :) > > > > > > Wow! Things have changed a lot since I took geography in 4th grade. > > > Back then, Canada was part of America. > > > > Oh, it still is.. There are still a few sadly deluded individuals up > [...] > > > > P.S. Yes, yes, I'm just joking! I love canada! Please don't send > > down the mounties! :) > > > Marc G. Fournier | POP Mail Telnet Acct DNS Hosting System | WWW Services Database Services | Knowledge, Administrator | | Information and scrappy@ki.net | WWW: http://www.ki.net | Communications, Inc From owner-freebsd-current Thu Apr 4 14:36:42 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA09880 for current-outgoing; Thu, 4 Apr 1996 14:36:42 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA09867 for ; Thu, 4 Apr 1996 14:36:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by rover.village.org (8.6.12/8.6.6) with SMTP id PAA13355; Thu, 4 Apr 1996 15:31:16 -0700 Message-Id: <199604042231.PAA13355@rover.village.org> To: Nate Williams Subject: Re: tty-level buffer overflows - what to do? Cc: Joe Greco , root@deadline.snafu.de (Andreas S. Wetzel), current@FreeBSD.org In-reply-to: Your message of Thu, 04 Apr 1996 12:12:03 MST Date: Thu, 04 Apr 1996 15:31:16 -0700 From: Warner Losh Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk : With 2 lines going full blast (sup updates!) I see *NO* overflows on my : box. Again, my box is running with about 6MB of free memory all the : time, so I rarely hit the disk, but I've done compiles on the machine to : upgrade software with no noticeable degradation of serial speed. We have 4 SLIP lines going full blast from time to time on our 386 DX-40 (with 387 math co) 8M memory and a 40MB IDE drive. There is also a SMC Ethernet card to boot that all of our mail and news travels out of. While there is little disk activity, we've never had a overflow in our logs. All the internal modems that we use have 16550A UARTs on them (or clones). This is a 1.1.5.1R system, but I doubt that matters. All of the serial lines are locked at 115200 bps. Warner From owner-freebsd-current Thu Apr 4 14:37:19 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA09950 for current-outgoing; Thu, 4 Apr 1996 14:37:19 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA09942 for ; Thu, 4 Apr 1996 14:37:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by rover.village.org (8.6.12/8.6.6) with SMTP id PAA13374; Thu, 4 Apr 1996 15:34:56 -0700 Message-Id: <199604042234.PAA13374@rover.village.org> To: root@deadline.snafu.de (Andreas S. Wetzel) Subject: Re: tty-level buffer overflows - what to do? Cc: nate@sri.MT.net (Nate Williams), jgreco@brasil.moneng.mei.com, current@FreeBSD.org In-reply-to: Your message of Thu, 04 Apr 1996 21:27:26 +0200 Date: Thu, 04 Apr 1996 15:34:56 -0700 From: Warner Losh Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk : That means the interrupt that happens is not guaranteed to be IRQ 7 but : maybe any other unassigned interrupt? We see these from time to time when we have both serial and ethernet activity at the same time. W edon't know if they are afrom the ehtenret card or the serial modems. We suspect the latter, but have no way of proving it. As far as we know, there is no disk I/o when we see these all the time, but there is sometimes. 1.1R used to have more problems with the keyboard on my 486DX33 generating these interrupts, but 21.R and 2.0R didn't. Warner From owner-freebsd-current Thu Apr 4 14:39:59 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA10133 for current-outgoing; Thu, 4 Apr 1996 14:39:59 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA10125 for ; Thu, 4 Apr 1996 14:39:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by rover.village.org (8.6.12/8.6.6) with SMTP id PAA13396; Thu, 4 Apr 1996 15:39:43 -0700 Message-Id: <199604042239.PAA13396@rover.village.org> To: patl@Phoenix.Volant.ORG Subject: Re: ? MBR-7 support in -stable Cc: freebsd-current@FreeBSD.org In-reply-to: Your message of Thu, 04 Apr 1996 08:09:27 PST Date: Thu, 04 Apr 1996 15:39:43 -0700 From: Warner Losh Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk : I've recently upgraded from 2.05 to 2.1R and then -stable (through : CVS 0063). One of my reasons for doing so was to obtain support : for the MBR-7 CD-ROM changer. I noticed that it was mounting all : seven logical units during some of the intermediate states of my : upgrades; but don't seem to be recognized now. I know patches came through for 2.1R a while ago, but I was given to believe that they were folded into -stable. Maybe somebody broken them in recent versions of stable? 2.0R can be made to support the MBR-7 drive's other six disks relatively painlessly with minor adaptations of the patches for 2.1R that were posted to -hackers or -current about four months ago. Please let us know what you find out. Or at least please let me know because I'm keen to move from 2.1R to 2.1R-stable as soon as I can get a level 0 dump of my current disks. Warner From owner-freebsd-current Thu Apr 4 14:48:33 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA10830 for current-outgoing; Thu, 4 Apr 1996 14:48:33 -0800 (PST) Received: from rich.isdn.bcm.tmc.edu (root@RICH.ISDN.BCM.TMC.EDU [128.249.250.34]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA10823 for ; Thu, 4 Apr 1996 14:48:29 -0800 (PST) Received: from richc.isdn.bcm.tmc.edu (root@richc.isdn.bcm.tmc.edu [128.249.250.37]) by rich.isdn.bcm.tmc.edu (8.6.12/8.6.12) with ESMTP id QAA04463; Thu, 4 Apr 1996 16:48:21 -0600 Received: (rich@localhost) by richc.isdn.bcm.tmc.edu (8.6.12/8.6.12) id QAA00808; Thu, 4 Apr 1996 16:48:20 -0600 Date: Thu, 4 Apr 1996 16:48:20 -0600 Message-Id: <199604042248.QAA00808@richc.isdn.bcm.tmc.edu> From: Rich Murphey To: patl@Phoenix.volant.org CC: freebsd-current@freebsd.org In-reply-to: <9604041609.AA20968@asimov.volant.org> (patl@asimov.volant.org) Subject: Re: ? MBR-7 support in -stable Reply-to: rich@lamprey.utmb.edu Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk |From: patl@asimov.volant.org |Date: Thu, 4 Apr 1996 08:09:27 -0800 | |[ I didn't receive any response to this question in either the ] |[ freebsd-stable or freebsd-questions list. Given the relatonship ] |[ between -current and -stable, I'm hoping that someone on this list ] |[ will have both the knowlege and the time to respond. ] | |I've recently upgraded from 2.05 to 2.1R and then -stable (through |CVS 0063). One of my reasons for doing so was to obtain support |for the MBR-7 CD-ROM changer. I noticed that it was mounting all |seven logical units during some of the intermediate states of my |upgrades; but don't seem to be recognized now. | |I have rebuilt my kernel with 'options "MAX_LUN=8"'; and I have |the appropriate /dev entries. But the boot probe doesn't find |the extra logical units and mount attempts claim that the units |aren't configured (which is expected, given that the probe didn't |find them...) I've included the first part of the boot log below, |with the timestamp and kernel ids trimmed off for readability. | |Is there anything else that I need to do to get this to work? |(Yes, I did try searching the mailing list archives; but didn't |find anything appropriate.) I just committed a change to /sys/scsi/scsiconf.c in -stable that puts an entry for the MBR-7 into knowndevs. This makes the driver recognize all 7 platters. As far as I know you don't need 'options "MAX_LUN=8"' or any other kernel changes. Rich From owner-freebsd-current Thu Apr 4 15:36:48 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA16509 for current-outgoing; Thu, 4 Apr 1996 15:36:48 -0800 (PST) Received: from eac.iafrica.com (slipper101139.iafrica.com [196.7.101.139]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA16459 for ; Thu, 4 Apr 1996 15:36:23 -0800 (PST) Received: (from rnordier@localhost) by eac.iafrica.com (8.6.12/8.6.12) id BAA00779 for current@freebsd.org; Fri, 5 Apr 1996 01:30:05 +0200 From: Robert Nordier Message-Id: <199604042330.BAA00779@eac.iafrica.com> Subject: Re: 2.2-960323 Panic in mount_msdos To: current@freebsd.org Date: Fri, 5 Apr 1996 01:30:04 +0200 (SAT) In-Reply-To: <199604042010.NAA22425@phaeton.artisoft.com> from "Terry Lambert" at Apr 4, 96 01:10:04 pm X-Mailer: ELM [version 2.4 PL24 ME8a] Content-Type: text Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 4 Apr 1996, Terry Lambert wrote: > The fix for inconsistent media is to run fsck (or equivalent) on it > before attempting a mount; the fix is procedural, in other words, > and doesn't require a change to the mount code. > > The DOSFS code is, unfortunately, well known to be unstable. It > does not do the type validation it should, ad there is not a fsck > equivalent program as part of the package. > > The DOSFS is being rewritten (not by me). > > For now, make sure that you have chkdsk'ed the DOS disk prior to > booting FreeBSD. If it fails chkdsk, do not attempt to mount it. A dosfsck has been created as part of the rewrite of the msdosfs, and should be ready for beta testing in a few weeks. -- Robert Nordier From owner-freebsd-current Thu Apr 4 19:11:25 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id TAA05945 for current-outgoing; Thu, 4 Apr 1996 19:11:25 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id TAA05936 for ; Thu, 4 Apr 1996 19:11:20 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id NAA13560; Fri, 5 Apr 1996 13:09:00 +1000 Date: Fri, 5 Apr 1996 13:09:00 +1000 From: Bruce Evans Message-Id: <199604050309.NAA13560@godzilla.zeta.org.au> To: jgreco@brasil.moneng.mei.com, root@deadline.snafu.de Subject: Re: tty-level buffer overflows - what to do? Cc: current@freebsd.org Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >What kind of drives? IDE drives bite, particularly if they are being used >at the same time as the serial port... etc, etc. IDE drives have no affect on the operation of the serial unless they are so slow that the system spends too much of its time in the kernel. Bus-hogging SCSI controllers bite. Bruce From owner-freebsd-current Thu Apr 4 19:14:24 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id TAA06169 for current-outgoing; Thu, 4 Apr 1996 19:14:24 -0800 (PST) Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id TAA06162 for ; Thu, 4 Apr 1996 19:14:18 -0800 (PST) Received: by sequent.kiae.su id AA10207 (5.65.kiae-2 ); Fri, 5 Apr 1996 06:01:48 +0300 Received: by sequent.KIAE.su (UUMAIL/2.0); Fri, 5 Apr 96 06:01:47 +0300 Received: (from ache@localhost) by astral.msk.su (8.7.5/8.7.3) id GAA00789; Fri, 5 Apr 1996 06:50:40 +0400 (MSD) Message-Id: <199604050250.GAA00789@astral.msk.su> Subject: Re: adjkerntz (was: cvs commit: src/usr.sbin/tzsetup ...) To: joerg_wunsch@uriah.heep.sax.de Date: Fri, 5 Apr 1996 06:50:40 +0400 (MSD) Cc: freebsd-current@FreeBSD.org In-Reply-To: <199604040743.JAA19358@uriah.heep.sax.de> from "J Wunsch" at "Apr 4, 96 09:43:14 am" From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast X-Mailer: ELM [version 2.4ME+ PL14 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > As =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= wrote: > > > > msdosfs? MSDOS' idea of a timezone is broken by design (i.e., it > > > doesn't have an idea about it at all). Someone in Australia could > > > > It have an idea: local time zone. > > But that sucks when it comes to communication with other machines in > other timezones. Of course, it is one of well-known DOS/Win features. This problem usually solves into file-transfer programs (send timezone), or in the archivers (store files under UTC or add timezone offset to the archive). > Well, but that's a crock. Send a tar file over, and the contents of > the tar file will have invalid timestamps. Not to speak about IP > services like FTP, and the many possibilities to have timestamps > hidden somewhere in the archive files. Tar isn't DOS/Win archiver, so what you expect? Proper FTP software under DOS/Win must count timezone. > > msdosfs use adjkerntz kernel variable to calculate local timezone > > for DOS files, check msdosfs sources. > > That's a hack. Probably the best one you can do (and note that hacks > might often be useful, e.g. vfork() is another useful hack, or has at > least been one in times where COW wasn't available). What if i don't > use msdosfs but use mtools instead? (Like i do btw., whenever there's > an occasion to handle a DOS floppy. As you could guess, this is only I don't think it is hack. It is only way to handle Local Timezone FS'es. > rarely the case for me.) What if i use my own package to export/ > import DOS files? (Yes, i really wrote one as paywork years ago. It Your package must handle timezone in this case. > > Proper DOS/Windows software sends timezone offset of your DOS > > with any file times. > > How? There's no commonly agreed protocol. I cannot remember any DOS No, each software implement its own protocol. > installation program that would even ask for a timezone? Despite, you Win95 asks for timezone. DOS have TZ environment variable (all C implmentations handle it). -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-current Thu Apr 4 19:52:31 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id TAA10213 for current-outgoing; Thu, 4 Apr 1996 19:52:31 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id TAA10200 for ; Thu, 4 Apr 1996 19:52:20 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id NAA15285; Fri, 5 Apr 1996 13:46:05 +1000 Date: Fri, 5 Apr 1996 13:46:05 +1000 From: Bruce Evans Message-Id: <199604050346.NAA15285@godzilla.zeta.org.au> To: nate@sri.MT.net, rgrimes@GndRsh.aac.dev.com Subject: Re: tty-level buffer overflows - what to do? Cc: current@FreeBSD.org, jgreco@brasil.moneng.mei.com, root@deadline.snafu.de Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >> This is a pretty good indication that something is mis-confugred. IRQ 7 >> is the 'junk' interrupt, which means it gets all of the interrupts not >> otherwise assigned to a particular piece of hardware. Something is >> generating interrupts on your system bogusly and you need to find out >> what. >This is not quite correct, IRQ 7 is signal when someone asserts an IRQ singal >then removes that signal _before_ the CPU runs the interrupt acknowledge >cycle to the 8259 PIC. This is not quite correct :-). IRQ7 is signaled when an IRQ signal is removed _during_ the interrupt acknowledge cycle for that IRQ. It isn't signaled if the cycle never begins. >Often the cause of stray IRQ7's is noisy or floating IRQ signals from boards >that are not recognized by FreeBSD. The cause has to be a signal on one of the IRQ lines enabled by FreeBSD (because masked lines are completely ignored). The signal can then interfere with the signal from the enabled board. Bruce From owner-freebsd-current Thu Apr 4 20:27:54 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id UAA13009 for current-outgoing; Thu, 4 Apr 1996 20:27:54 -0800 (PST) Received: from sovcom.kiae.su (sovcom.kiae.su [144.206.136.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id UAA13001 for ; Thu, 4 Apr 1996 20:27:42 -0800 (PST) Received: by sovcom.kiae.su id AA03213 (5.65.kiae-1 for current@freebsd.org); Fri, 5 Apr 1996 07:22:38 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Fri, 5 Apr 96 07:22:36 +0300 Received: (from ache@localhost) by astral.msk.su (8.7.5/8.7.3) id IAA01205 for current@freebsd.org; Fri, 5 Apr 1996 08:23:49 +0400 (MSD) Message-Id: <199604050423.IAA01205@astral.msk.su> Subject: WARNING: new kernel/adjkerntz changes To: current@freebsd.org (FreeBSD-current) Date: Fri, 5 Apr 1996 08:23:49 +0400 (MSD) From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast X-Mailer: ELM [version 2.4ME+ PL14 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk After installing kernel with my recent wall_cmos_clock sysctl addition you need to run recently commited adjkerntz variant with it, old adjkerntz not work with new kernel. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-current Thu Apr 4 20:36:25 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id UAA13989 for current-outgoing; Thu, 4 Apr 1996 20:36:25 -0800 (PST) Received: from cenotaph.snafu.de (root@deadline.berlin.netSurf.DE [194.64.158.25]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id UAA13984 for ; Thu, 4 Apr 1996 20:36:20 -0800 (PST) Received: by cenotaph.snafu.de from deadline.snafu.de using smtp id m0u53En-0002eEC; Fri, 5 Apr 96 06:35:05 +0200 (MET DST) (/\##/\ Smail3.1.30.13 #30.1) Received: by deadline.snafu.de id m0u53H9-0009QNC; Fri, 5 Apr 96 06:37:31 +0200 (MET DST) (/\##/\ Smail3.1.30.13 #30.1) Message-Id: From: root@deadline.snafu.de (Andreas S. Wetzel) Subject: Re: tty-level buffer overflows - what to do? To: bde@zeta.org.au (Bruce Evans) Date: Fri, 5 Apr 1996 06:37:31 +0200 (MET DST) Cc: nate@sri.MT.net, rgrimes@GndRsh.aac.dev.com, current@FreeBSD.org, jgreco@brasil.moneng.mei.com In-Reply-To: <199604050346.NAA15285@godzilla.zeta.org.au> from Bruce Evans at "Apr 5, 96 01:46:05 pm" Organization: A world stranger than you have ever imagined. X-Mailer: ELM [version 2.4ME+ PL13] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hi! --- Bruce Evans writes: ] The cause has to be a signal on one of the IRQ lines enabled by FreeBSD ] (because masked lines are completely ignored). The signal can then interfere ] with the signal from the enabled board. But what card could generate such IRQ? The problem seems to occur _only_ during boot at about the time when fsck gets run and a second time a bit later when some of the daemons get started. A vmstat -i says: interrupt total rate clk0 irq0 2039463 100 rtc0 irq8 2610423 127 wdc0 irq14 17877 0 fdc0 irq6 1 0 sc0 irq1 1 0 sio0 irq4 1657 0 sio1 irq3 283893 13 sio2 irq9 1539814 75 sio3 irq5 25268 1 ed0 irq12 171733 8 stray irq7 5032 0 Total 6695162 328 The rate for irq7 is 0, so I think it hasn't recently occured anymore since bootup. The problem happened with all kernels I used on the machine til now. That included the original 2.2-SNAPSHOT installation kernel, the 2.1.0 RELEASE installation kernel as well as several kernels I built specifically for this machine from actual -current sources. What _really_ made me wonder was that when I used another IDE/FD controller the problem was gone. But the controller card I use on this machine a) has no physical connection to the irq 7 line and b) has been in use for a long time on another machine running -current and did never cause any problem like that. And apart from that the only irq's that this card should ever generate should be irq 14 and irq 6 (It's a pure controller card, no I/O interfaces are on that board). Well... any ideas how to get rid of that stray irq? Regards, mickey -- (__) (@@) Andreas S. Wetzel E-mail: mickey@deadline.snafu.de /-------\/ Utrechter Strasse 41 Web: http://deadline.snafu.de/ / | || 13347 Berlin Voice: <+4930> 456 81 68 * ||----|| Germany Fax/Data: <+4930> 455 19 57 ~~ ~~ From owner-freebsd-current Thu Apr 4 21:02:18 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA15686 for current-outgoing; Thu, 4 Apr 1996 21:02:18 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id VAA15677 for ; Thu, 4 Apr 1996 21:02:12 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id OAA18213; Fri, 5 Apr 1996 14:59:10 +1000 Date: Fri, 5 Apr 1996 14:59:10 +1000 From: Bruce Evans Message-Id: <199604050459.OAA18213@godzilla.zeta.org.au> To: bde@zeta.org.au, root@deadline.snafu.de Subject: Re: tty-level buffer overflows - what to do? Cc: current@FreeBSD.org, jgreco@brasil.moneng.mei.com, nate@sri.MT.net, rgrimes@GndRsh.aac.dev.com Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >] The cause has to be a signal on one of the IRQ lines enabled by FreeBSD >] (because masked lines are completely ignored). The signal can then interfere >] with the signal from the enabled board. >But what card could generate such IRQ? The problem seems to occur _only_ >during boot at about the time when fsck gets run and a second time a bit >later when some of the daemons get started. Any misdesigned, misconfigured or misprogrammed card might do it, so it's hard to say. >A vmstat -i says: >interrupt total rate >clk0 irq0 2039463 100 >rtc0 irq8 2610423 127 >wdc0 irq14 17877 0 >fdc0 irq6 1 0 >sc0 irq1 1 0 >sio0 irq4 1657 0 >sio1 irq3 283893 13 >sio2 irq9 1539814 75 >sio3 irq5 25268 1 >ed0 irq12 171733 8 >stray irq7 5032 0 >Total 6695162 328 >The rate for irq7 is 0, so I think it hasn't recently occured anymore since >bootup. I think you had 5032 irq7's :-). That's a lot for an unused device. I have 6 after running for about twice as long. Bruce From owner-freebsd-current Thu Apr 4 23:35:47 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA00984 for current-outgoing; Thu, 4 Apr 1996 23:35:47 -0800 (PST) Received: from gw.pinewood.nl (gw.pinewood.nl [192.31.139.9]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA00979 for ; Thu, 4 Apr 1996 23:35:44 -0800 (PST) Received: (from smap@localhost) by gw.pinewood.nl (8.6.12/8.6.12) id JAA12889; Fri, 5 Apr 1996 09:35:38 +0200 Received: from pwood1.pinewood.nl(192.168.1.10) by gw.pinewood.nl via smap (V1.3) id sma012887; Fri Apr 5 09:35:27 1996 Received: (from franky@localhost) by pwood1.pinewood.nl (8.7.3/8.6.12) id JAA09065; Fri, 5 Apr 1996 09:35:26 +0200 (DST) From: "Frank ten Wolde" Message-Id: <9604050935.ZM9063@pwood1.pinewood.nl> Date: Fri, 5 Apr 1996 09:35:25 +0000 In-Reply-To: Terry Lambert "Re: 2.2-960323 Panic in mount_msdos" (Apr 4, 13:10) References: <199604042010.NAA22425@phaeton.artisoft.com> X-Face: 'BsFf8'k.q?J#?|$D*,)/?sRB{woUK&9\5K{ERmT;VTSyNLBb?muLf>b:Pt&VTDw8YCaC]6 C!MRSMr5UNjZLa]fi? X-Mailer: Z-Mail (3.2.1 10oct95) To: Terry Lambert Subject: Re: 2.2-960323 Panic in mount_msdos Cc: freebsd-current@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hi, > > I just tried to mount a Windows NT file system (NTFS) using: > > > > mount -t msdos /dev/sd0s2 /dos > > > > (I thought it was an MSDOS-FAT file system :-). The 2.2-960223-SNAPSHOT > > of FreeBSD immediately paniced: > > [ ... ] > > > I know you cannot mount an NTFS under FreeBSD, but at least the system > > should not crash. > > > > I just report this problem as I have too little knowledge of the internals > > of the kernel to fix the problem myself :-) > > A file system operates by copying on disk strucutures into memory > and then using the offsets in the coppy to access additional memory. > > It does not bounds-check these accesses. Yep, I found out :-) > Not bounds-checking dereferences isn't an error; it an optimization, > and it's allowable because mount is not a user accessable command > (you have to be root). I slightly disagree. Even as root I could make a typo and by mistake specifiy the wrong partition/slice to mount, causing the entire system to die. It would have been nice if some sanity checking would have been performed, so that the kernel simply would abort the mount(2) system call with an appropriate error (wrong FS type, or something similar). [...] > The DOSFS is being rewritten (not by me). Neither by me. Don't get me wrong, I *really* like FreeBSD and my remarks are not ment to critisize anyone. I, for sure, do *not* have the time and resources to contribute significantly to FreeBSD and I certainly do not make demands of any kind :-) I simply pointed out the panic. Maybe the code maintainer of the DOSFS can use this info to make the system even more stable. -Frank -- ---------------------------------------------------------------------- F.W. ten Wolde (PA3FMT) Pinewood Automation B.V. E-mail: franky@pinewood.nl Kluyverweg 2a Phone: +31-15 2682543 2629 HT Delft From owner-freebsd-current Thu Apr 4 23:39:07 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA01093 for current-outgoing; Thu, 4 Apr 1996 23:39:07 -0800 (PST) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA01088 for ; Thu, 4 Apr 1996 23:39:02 -0800 (PST) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id XAA08401; Thu, 4 Apr 1996 23:36:02 -0800 From: "Rodney W. Grimes" Message-Id: <199604050736.XAA08401@GndRsh.aac.dev.com> Subject: Re: tty-level buffer overflows - what to do? To: bde@zeta.org.au (Bruce Evans) Date: Thu, 4 Apr 1996 23:36:02 -0800 (PST) Cc: nate@sri.MT.net, current@FreeBSD.org, jgreco@brasil.moneng.mei.com, root@deadline.snafu.de In-Reply-To: <199604050346.NAA15285@godzilla.zeta.org.au> from Bruce Evans at "Apr 5, 96 01:46:05 pm" X-Mailer: ELM [version 2.4ME+ PL11 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > >> This is a pretty good indication that something is mis-confugred. IRQ 7 > >> is the 'junk' interrupt, which means it gets all of the interrupts not > >> otherwise assigned to a particular piece of hardware. Something is > >> generating interrupts on your system bogusly and you need to find out > >> what. > > >This is not quite correct, IRQ 7 is signal when someone asserts an IRQ singal > >then removes that signal _before_ the CPU runs the interrupt acknowledge > >cycle to the 8259 PIC. > > This is not quite correct :-). IRQ7 is signaled when an IRQ signal is > removed _during_ the interrupt acknowledge cycle for that IRQ. It isn't > signaled if the cycle never begins. You had better go read the data book again, and look at the schematics to the real 8259A if you have access to them. 1985 Intel Microsystems Components Handbook, page 2-93: Interrupt Sequence ... The events occur as follows in an MCS-80/85 system: 1. One or more of the INTERRUPT REQUEST lines (IR7-0) are raised high, setting the corresponding IRR bit(s). 2. The 8259A evaluates these requests, and sends an INT to the CPU, if appropriate. 3. The CPU acknowledges the INT and responds with an INTA~ pulse. The events occurring in an iAPX 86 system are the same until step 4. 4. Upon receiving an INTA~ from the CPU group, the high- est priority ISR bit is set and the corresponding IRR bit is reset. The 8259A does not drive the Data Bus during this cycle. .... If no interrupt request is present at step 4 of either sequence (i.e., the request was too short in duration) the 8259A will issue an interrupt level 7. Both the vectoring bytes and the CAS lines will look like an interrupt level 7 was requested. [Here is more info on page 2-101 about the above, even closer to what I stated:] In both the edge and level triggered modes the IR inputs must remain high until after the falling edge of the first INTA. If the IR input goes low before this time a DEFAULT IR7 will occur when the CPU acknowledges the interrupt. > > >Often the cause of stray IRQ7's is noisy or floating IRQ signals from boards > >that are not recognized by FreeBSD. > > The cause has to be a signal on one of the IRQ lines enabled by FreeBSD > (because masked lines are completely ignored). The signal can then interfere > with the signal from the enabled board. Mostly true, ``(because masked lines are completely ignored)'' in not technically accurate, the mask register and AND gate are after the IRR latch, but they can't cause the priority resolver to trigger an INT request at step 2 above, so they should be out of the picture from a software point. Do we ever use the value of the IRR to dispatch an interrupt? As the IRR can be set even though the mask bit is turned on. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Fri Apr 5 00:08:17 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA02445 for current-outgoing; Fri, 5 Apr 1996 00:08:17 -0800 (PST) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id AAA02439 for ; Fri, 5 Apr 1996 00:08:11 -0800 (PST) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id AAA08441; Fri, 5 Apr 1996 00:08:02 -0800 From: "Rodney W. Grimes" Message-Id: <199604050808.AAA08441@GndRsh.aac.dev.com> Subject: Re: tty-level buffer overflows - what to do? To: root@deadline.snafu.de (Andreas S. Wetzel) Date: Fri, 5 Apr 1996 00:08:01 -0800 (PST) Cc: current@FreeBSD.org In-Reply-To: from "Andreas S. Wetzel" at "Apr 5, 96 06:37:31 am" X-Mailer: ELM [version 2.4ME+ PL11 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk [CC: trimmed.. it was getting a bit long...] > Hi! > --- > > Bruce Evans writes: > > ] The cause has to be a signal on one of the IRQ lines enabled by FreeBSD > ] (because masked lines are completely ignored). The signal can then interfere > ] with the signal from the enabled board. > > But what card could generate such IRQ? The problem seems to occur _only_ > during boot at about the time when fsck gets run and a second time a bit > later when some of the daemons get started. See my other mail, IRQ7 is the default interrupt generrated if _any_ of your enabled (clause added to keep Bruce happy) interrupt signals are asserted then deasserted before the INTA cycle from the CPU. > > A vmstat -i says: [Thanks! This is what I needed to nail your problem with an 87% certainty of being correct] > > interrupt total rate > clk0 irq0 2039463 100 > rtc0 irq8 2610423 127 > wdc0 irq14 17877 0 > fdc0 irq6 1 0 > sc0 irq1 1 0 > sio0 irq4 1657 0 > sio1 irq3 283893 13 > sio2 irq9 1539814 75 ^^^ are you REALLY doing that much I/O on sio2? > sio3 irq5 25268 1 > ed0 irq12 171733 8 > stray irq7 5032 0 > Total 6695162 328 I highly suspect you have a video card also sitting on IRQ9 (aka IRQ2) and it is asserting a 60 to 72Hz video refresh interrupt, and do to conflicts with SIO2 is infact on occasion glitching IRQ9 causing a stray interrupt 7. > The rate for irq7 is 0, so I think it hasn't recently occured anymore since > bootup. Do this immediately after a reboot (preverably add this to /etc/rc.local): vmstat -i >/var/tmp/vmstat.atboot Then after being up for 2 or 3 hours do another vmstat -i >/var/tmp/vmstat, take a look to see if your got any more while the system was up. Also if you can stop using sio2 for a day and see if the problem goes away. Also check your video card for a trace going to bin B4, if it is connected to something check your card for an IRQ2/9 jumper. Try another video card that either has the jumper or has no connection to pin B4. > The problem happened with all kernels I used on the machine til now. That > included the original 2.2-SNAPSHOT installation kernel, the 2.1.0 RELEASE > installation kernel as well as several kernels I built specifically for > this machine from actual -current sources. > > What _really_ made me wonder was that when I used another IDE/FD controller > the problem was gone. But the controller card I use on this machine > a) has no physical connection to the irq 7 line and Does not matter, any glitch on IRQ{0,1,3,4,5,6,8,9,12,14} will do the deed. Probably IRQ14 for the IDE channel, many small inexpensive IDE controllers do not buffer the signals between the ISA backplane and the ribbon cable and this is a major source of noise on IRQ14. > b) has been in use > for a long time on another machine running -current and did never cause > any problem like that. The other machine probably has better schmitt trigger thresholds on the IRQ inputs to the chipset. > And apart from that the only irq's that this card > should ever generate should be irq 14 and irq 6 (It's a pure controller > card, no I/O interfaces are on that board). See above... > > Well... any ideas how to get rid of that stray irq? Having fixed about 20 or so machines with this problem and given the data up to this point I am 99% confident it is one of two things, a cheap unbuffered IDE I/O controller or a conflict between your video card and SIO2 on interrupt 9. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Fri Apr 5 00:50:49 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA04356 for current-outgoing; Fri, 5 Apr 1996 00:50:49 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id AAA04343 for ; Fri, 5 Apr 1996 00:50:45 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id KAA17015 for ; Fri, 5 Apr 1996 10:50:24 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id KAA02550 for freebsd-current@FreeBSD.org; Fri, 5 Apr 1996 10:50:23 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id KAA24540 for freebsd-current@FreeBSD.org; Fri, 5 Apr 1996 10:31:29 +0200 (MET DST) From: J Wunsch Message-Id: <199604050831.KAA24540@uriah.heep.sax.de> Subject: Re: adjkerntz (was: cvs commit: src/usr.sbin/tzsetup ...) To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Fri, 5 Apr 1996 10:31:28 +0200 (MET DST) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199604050250.GAA00789@astral.msk.su> from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Apr 5, 96 06:50:40 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= wrote: > > rarely the case for me.) What if i use my own package to export/ > > import DOS files? (Yes, i really wrote one as paywork years ago. It > > Your package must handle timezone in this case. How if i don't know in which timezone the floppy i just wanna read has been created? What about mtools? You can argue how you want: DOS has simply ignored the problem for too long, and now that the technology has been rolling all over it, it's too late for a general solution. That's typical for DOS... > DOS have TZ environment variable (all C implmentations handle it). Well, dir(1) (not that there's really a man page section one, but so you know what i mean :) cannot handle it if i insert a floppy that came from USA, for example. TZ is solely handled by C runtime systems, and at least for my very old TC 2.0 (the only C system i've still got around), the TZ handling is buggy. I've just started pcemu and wrote a small test program: setting TZ affects both, localtime(3) and gmtime(3) similarly. Last not least, DOS timezone idea is broken. You can find work- arounds, and they might be working for you most of the time, but they remain workarounds for something that has been misdesigned in the first place. I won't do anything in my Unix systems to correct their mistakes. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Fri Apr 5 01:35:45 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA07169 for current-outgoing; Fri, 5 Apr 1996 01:35:45 -0800 (PST) Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id BAA07119 for ; Fri, 5 Apr 1996 01:35:29 -0800 (PST) Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.7.5/8.6.9) id BAA24263; Fri, 5 Apr 1996 01:35:16 -0800 (PST) Date: Fri, 5 Apr 1996 01:35:16 -0800 (PST) Message-Id: <199604050935.BAA24263@silvia.HIP.Berkeley.EDU> To: current@freebsd.org CC: nisha@cs.berkeley.edu, tege@matematik.su.se, hasty@rah.star-gate.com Subject: fast memory copy for large data sizes From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk We've put together a fast memory copy that uses floating point registers to speed up large transfers. The original idea was taken from Amancio Hasty's old post to use floating point registers to move 8 bytes at a time. (We tried using integer registers too but with our wits we could only get 10MB/s less than the FP case.) By the way, we plugged this thing in as a replacement to copyin/copyout and our ccd testing machine, (striping disk driver, see http://stampede.cs.berkeley.edu/ccd/ for details) and maximum read performance improved from 21MB/s to 24MB/s using 9 disks. But that's only to our interest, so here's a comparison with the libc bcopy() (which is essentially the same code as the stock copyin/copyout). Here are the kind of numbers we are seeing, and hope you will see, if you run the program attached at the end of this mail: 90MHz Pentium (silvia), SiS chipset, 256KB cache: size libc ours 32 15.258789 MB/s 6.103516 MB/s 64 20.345052 MB/s 15.258789 MB/s 128 17.438616 MB/s 15.258789 MB/s 256 17.438616 MB/s 20.345052 MB/s 512 17.438616 MB/s 22.194602 MB/s 1024 17.438616 MB/s 23.251488 MB/s 2048 17.755682 MB/s 23.818598 MB/s 4096 17.836758 MB/s 23.390719 MB/s 8192 17.715420 MB/s 24.112654 MB/s 16384 17.341842 MB/s 24.338006 MB/s 32768 17.361111 MB/s 25.080257 MB/s 65536 17.715420 MB/s 24.423603 MB/s 131072 17.373176 MB/s 25.237230 MB/s 262144 17.553714 MB/s 24.723101 MB/s 524288 17.401594 MB/s 24.951345 MB/s 1048576 14.804506 MB/s 24.252419 MB/s 2097152 17.732383 MB/s 24.392326 MB/s 4194304 17.219484 MB/s 23.491825 MB/s 133MHz Pentium (sunrise), Triton chipset, 512KB (pipeline burst) cache: size libc ours 32 N/A 30.517578 MB/s 64 61.035156 MB/s 30.517578 MB/s 128 40.690104 MB/s 40.690104 MB/s 256 40.690104 MB/s 40.690104 MB/s 512 40.690104 MB/s 48.828125 MB/s 1024 40.690104 MB/s 51.398026 MB/s 2048 39.859694 MB/s 51.398026 MB/s 4096 39.859694 MB/s 52.083333 MB/s 8192 39.457071 MB/s 52.787162 MB/s 16384 39.556962 MB/s 52.966102 MB/s 32768 39.506953 MB/s 53.146259 MB/s 65536 39.457071 MB/s 53.282182 MB/s 131072 39.457071 MB/s 53.327645 MB/s 262144 39.345294 MB/s 53.350405 MB/s 524288 39.044198 MB/s 53.430220 MB/s 1048576 38.086533 MB/s 53.447354 MB/s 2097152 37.706680 MB/s 53.387433 MB/s 4194304 37.628643 MB/s 53.280763 MB/s As you can see, from a certain size and onwards, it is much faster than the libc version. ("size" is in bytes.) The program allocates two 4MB buffers and calls libc's bcopy (which is essentially a string move using rep/movsl; see below for more on this) or our enhanced version (called "unrolled") repeatedly with "size" increments until all data is copied. The test program itself is taken from lmbench, and I added some random garbage initialization and post-testing to make sure all the data is correctly copied. I'll include the C program too, but it won't do you much good other than as a reference to the testing method because we rewrote the function "unrolled" in assembly language (why such a simple program gets so mungled up by the compiler is a mystery). The "meat" of each code is included here in plaintext. First, the libc bcopy: === movl %ecx,%edx cld /* clear direction flag: copy forward */ shrl $2,%ecx /* count /= 4 for word copy */ rep movsl movl %edx,%ecx andl $3,%ecx /* count %= 4 for the remaining bytes */ rep movsb === This is not exactly what it is doing but I've taken the liberty to simplify it for discussion purposes. The "movs*" instruction, with a "rep" prefix, will copy %ecx ("count") things from %esi ("source index") to %edi ("destination index"). The "movsl" is for 32-bit moves (hence the shift right 2 in the count) and "movsb" is for 8-bit moves (to copy up to 3 bytes left). Of course, the whole thing could be done as: === rep movsb === but that's going to be a little slow 'cause it's byte-by-byte moves. Here's ours: === cmpl $63,%ecx /* if less than 64 bytes, go to end */ jbe L54 # movl %cr0,%edx # movl $8, %eax /* CR0_TS */ # not %eax # andl %eax,%edx /* clear CR0_TS */ # movl %edx,%cr0 subl $108,%esp /* save all floating point registers */ fsave (%esp) .align 2,0x90 L55: fildq 0(%esi) /* load quadword (64-bit) int into FP registers */ fildq 8(%esi) fildq 16(%esi) fildq 24(%esi) fildq 32(%esi) fildq 40(%esi) fildq 48(%esi) fildq 56(%esi) fxch %st(7) /* exchange top of stack with 8th position */ fistpq 0(%edi) /* store quadword */ fxch %st(5) fistpq 8(%edi) fxch %st(3) fistpq 16(%edi) fxch %st(1) fistpq 24(%edi) fistpq 32(%edi) fistpq 40(%edi) fistpq 48(%edi) fistpq 56(%edi) addl $-64,%ecx addl $64,%esi addl $64,%edi cmpl $63,%ecx ja L55 frstor (%esp) /* restore FP registers */ addl $108,%esp # andl $8,%edx # movl %cr0,%eax # orl %edx, %eax /* reset CR0_TS to the original value */ # movl %eax,%cr0 L54: cld /* do the rest; at most 63 bytes so we */ rep /* don't really care about speed here */ movsb === (Don't worry about the commented out lines for now, those were necessary to temporarily enable FP operations in the kernel.) This routine works by loading eight bytes at a time into a floating point register using the fildq (integer load quadword) operation, and storing them with the fistpq (integer store and pop quadword) operation. (You can't use fld and fst because they will trap on illegal (as a floating point number) bit patterns -- by the way, the Pentium FP regs are 80 bits with a 64-bit mantissa so there's no loss of data by using the integer load/store.) The Pentium FP unit is a stack of 8 registers, hence the "pop" and fxch thingies. Also, we save the FP state using fsave and frstor if we decide to use FP regs. Since there are 108 bytes to write/read in this case, the use of this should be limited to large transfers. I'd like people to try the following tarball on their machines, so we can see if it really works for everybody and not just in California. Please type "make" and it will compile & run the tests. The output already formatted (like the table you see above) so you can easily forward it to the list. Of course, before this to go into the library/kernel, we need to make sure it is run only on machines with the FP unit (prob. only on Pentiums), make it work with overlapping copies, etc., but I wanted to see what people think about it first. Satoshi ------- begin 644 bcopy.tar.gz M'XL(`#KD9#$"`^T\:W/;-K;Y2OX*5+%;29%D/B59KK-U4V\F4\?VV,XVO4U& MI4C*8D.16I)RY+2YO_V>@Q=!2G:<;1XS=\UI9>(`.#@X;X!`)GZZN-YY\%D? MXA@#UR4/B&GU;1O^XF/PO[Q`^J9MFGW+Z#N$F(9K60^(^^`+/,N\\#)"'GBY M-X]N:?=V%H;Q@_]WSX3*?Q[.Q_ZBYW^>,4P#I.K<*/^^85A<_J[A.'V0OV6A M_(U[^7_V9Z>MDS:9O!T+%2!=DD?S11P2@*39-4$%(468%]!P1W\8)7Z\#$*M M443S*+FT>GZC!'Z?7^<[4!'V9H]U_6$03J,D)!>_GAZBH(-T.8G#"A@$3^(T MN:0_HD8[?_8_AUH>O0O3:1-;M11<)Q<'1UA/''/7L0U'VVD3Y_F/2)M^E4:! MMDRR-([#H-G:HP"BA?-%<8U%?>Y%2=/S.\2[:NG"^?@S5(!VV[O:T_^4T"@I MZ-]E'OIY)T[3!7LC48=,KH$?>[(IGU\[SP!S.\B+/1VHR*/+)`S8[(KY`F!L M_MI\`N]YD2W]@B"OKKR8%#"VAD,>`Y5:-"5`)?EFG]@M\J>N:=-%!I739EX$ M899U`(+C-E[DWF4X(MLY06:1.)KX?XGI$R^F!`"`O[U*&CCQWXS7P`I-"U=1 MT33Q];VNT1F1?>(5:=2$-B9M@W0T8R\O.(CL[Y/OWGS7(G_]1=;@/W_7:@%: MAJF]#T[<)$SR91:225K, MJ!X!,H*3\P"8I`7)WWJ+!0R;+@LZ/1HVF]3@:^/4F&PAD]$P&U3#.8^31HX@U*X=Y1`?80;5O1W3,&D3,1D-KUJBK`IQYD2Z0$;1"^K!] M@XHIC//PHZB1GO43$23');7G5BJ8-U\C88V"*@%R\C4BWM^D>A7%HT[L1N4# MRUFO1/Q0B>Y,*![U'".*GFP''9+/TF4=)>6SA2QHJ=?8PW"F\XH!9N2&-[2B#$@C)&&%@@,%+` M3DX-:3[!_W&,)L72E?A:`(3D#Y^>T<)QL[!89@EI&E``7\FRCY\G4606[%X0QZ#)^T#X:BRJ-YU0V"MNDJK=6-! M-X4>N;]>A9Z,5X&B`[_9K%0[5OT7Z"K-R;1*)@,ST>0L:`.2A9<1B@*C@=&! M'Q-_+/RQ\L+CC,D!I@!8'&`)@,T! MM@`X'.`(@,L!K@#T.:`O``,.&+SF`0T(`!`2)``F!Y@"8'&`)0`V!]@"X'"` M(P`N![@"T.>`O@`,.&"P)S.@;LDFZB]!G#3DB]#+WZEH:2J%(D1'`!*DTN), M;^?4DVF*`>:_=:W7U`@?W#__Q8^Z_A_V\J^P_C==:V"+_1_#&>#^CV7W^_?K M_R_Q:+TIN`BM(9;_#?W2]ZVQG\X7``]Z(WT\'E\F2PD9^R.]5X2K0M=Z=/%` M++UW&:>3F(QI0@?PXGH1:KS8^6&Z3/PB2A.=`4:0B2_S64RVP\D"LI3T"E_S M18>56=V6(=]8KW%Q!:X-8_M875I`\A)Z5R'U:_K1-#0!>P\7PW)X!'8E9>L4 MIPN5X'11I3==?(#<');T9&O80=!FXM/%C;2OSW"M6XQ947?8Q-%:,(JW*NG! M=X:VN`(Z.'%*8W\E"?974`Z@G&.'+5>4D'REEK<.5GPHUKHO2JRUK*7$-7EW M;]49MC9V\X(`R'(J+9YGR[9'PY%0B)+SDS7.VPKG&2,1V.4\/GIB8+V7^U'T MT=M-IO7*:``*4T'!=DT8W%+@VV5S6P'C$`SJ*-"[KJ,$1E<=Z*:5#&M<*MO1 MDSYVH]MWQLKH&"O'M"F+*XT&:XVL<.@,C0UJBYN/I=9B255:+-_)USA&Q=F` MQD3E>Q[=JMJ3#:J-W9D7&7,2_?D"QK%Y^S]")S_ M\Y$YZ`M\?!DI&YBB`O?+2@8!UW8-'<:0TW?$**PY;DJJYM`51GA#>TR%A5D( MS\SF9!H#;EQT5M8=$#@5!`-7]$\0@0EDHQHS?V<:"FE0.?IH]*:QJ]+G?#Q] M@PI]-I#A2/JL*GVVJ4Q02H`&&60571>6S!=%Y:Q@8- MY[RR:LRBF]6RMN[90.TLJ785;WH#4@$P:J/@,D\)!T$DC)5Y``B[/!2PLLOS M(#\.I!BE?63A(J0\RB?,BIP^[?=N@C.0)LXY+:%L3+^6=4(KZ#\2RF$)@]UL ME9;D!L_HZRK&)3>I>*D_8NSJ;!`=SCB?93S<88DCI*)'_M1UL70)BK"H[1A- MVH5EP3(YW&BH2@ZMFAA+E!5E#90&P:HFS)HU"<2"\'5UKC'E$GC2AQDYHQN5 MDR7@:N2U*EX(':I3.M3Y`G3!7>>9-?J/I68;GT)JMO7UI28RY4\B.!MR3]OX MCP1WJR`VY!2;Q>)^$K$,OKY8Z!;_IY')`&;D?H1,I.6`T8SJO+_%1$I645DX MQH8P)UVYRK(-(G"L$8^'PD-[,1T,`J1'`V0>\5S),:4_K_AXE>EE?;"Q?CUV M0>AQZA&."Z//6`$#CZ0$@E(8-\M%81#(Q0%;<=!6IC&@A74=O&%VFZVGM]W: MDK^2"M>RWHT.4MK`$DRWG!]=Q*8+J0_I0BYAV6L0U;>RN&9=K M2+,&N0YOZNT1:`DZNCNJ3]=5ILNH1V!73JP^X3+&B#D+B#IM`;OC%EE]?Z&V MIR!!M3V%.N,@\1-S[]L\$:2,<\'^]8=\>#\SF*9S`"@BU2$\I/'DS!A?G--3 M:!H>RJ#L>\A6.M)$L*$/7,PJS95]31A!%UIN&J6>`]^%GJ\+$@4QC>+@W\00 M+I$5A]4BG:]2MIQJV;:J9:>&SJGAFLUIIEK27W&SB`DJT"'*,.&-8`KAR!&T#?X4)G95I$W5&*="NJIB%H'"Y( M9)KA!_V:AY/R$VI`_5:I/5R=J)HP;P0:(/4I"_.P$&I2I/340)I%EU$"CNK* MBY=A17D\H3R@L2.^-(*E$-5T6`FMKZ`5_W:K4^LK5B[M%>%=U:#KMLXV@82= M8TFU<2S?Q;,-*]&FKO9#-3E8\>1`1.(56Z2Q1('6T"6:.^0"5*=$'ZD`*LI`NOQMR9YO!.$5SL);I7] M1;RW;TCC3W[4[%6#;`\"0K9W<_H]AI!7C0YT[I!76V[K?:.*47YU^B!6@>]5 M@O@DKFC_]W"UR!#7JS:Q?M>#-`GU_UK[?^Z]"?$Q_X'ARO,??=>E]S\< M]][^OXC]$R%[>NIV(F][Y+H.R[D1X><^B)?GX7P"+_0JB(XI-GZOS.;<+GLY M?Q%V"FU8UY%LH>OB3<)\7?N!^9S'C_E847(I:RE1U^!P(%F;AEF8^&%#URY] MGW1/+++UF'3/@4Y.VFB-`O:B$*`,QGO=<330DB+RZ8@IV?I!H!X*W,,/(!]R M[,@]@-Z(%NLE3A4CA.@$T5'9-'"CC8BHK?]M^Y=W>;Z&_5N6V1?QWW0&)CW_ M9=_;_Q>\_[7U+!@1I@0]OW-%S%Z?F+N[[HXQW+%<8M@CVX#_2#PGAZL%V8(^ MV.T)Z`ZLEV8%:?HM[."0(R_+KLES_U_I=0]DRQL>0&A.E\5B69#+-,QQL<7. MEODO!%3.3=?#L-[)^^:*^@*/_1*"?D',MH!6'GUK.<(&-G4B4 MD'GD9RGP*DV"G%&QI)<(Z>T.2D7]CATP<8I'T6^@CJTK;R0.5KMX)JKY+<73 M(64/.3/UA@-M)63;%N)$*8L*?O7I/3^5S[!SY(4)_QOE58/:5-J\61O;M0M# MO6!`J[J/^BPK79:5/G@AIM;O>Z+0NY&8;K=3'PQO M)S#.4$;_3O[/W>YG&N,#\=^V^H82_^GZWW#M^_C_A>,_5P(:_AT>_OL[ MEDDLG@FX]W%D]/QRX,G%YJ]V[T/]_S7X=FY)GN9,AMBFING_INP(#D` M(=7RK\AD.86E&TD7F#Z\\W`W/-=5?._*09:^!?SIY='&KF M>O.??CG3K#7P\;H%?B/+_ZI*>E7JU)Y?G%X"I5]7L6UEYS_>N[*=NP" M\Z1#XC!I:;`8S,,"BP:#E.W8]>`.":""-O2AC">BL2R;0;X:A"MLY[!7C1EE\_S9TX.CL^<=@L<>6WO$B[ULW@17 MWB9]FB_1?XV!7HWG_Q)#>>&7#<,R-5[G!7^`*Y;%;(F'S65Q`EG@VR@H9A+R M9B)?Y\HK)H5**8XC64*-*#&R=*LE$]NG81)F7@&3GF;IG,SSR]X*+VOZ,SQ/ MSKU/0&:@GB-ZF3R]S+PY06L8GYZ=/,5KC.B8KL(L!YUC%:B[]'XC7LJ#/V>G M3ZC]-+$,V3LQ64JEO6?O]*^].X!L"&DZC4,O#TF0TCOH81#Q:[&X78,I+]YC M?>OED,D*VI; Fri, 5 Apr 1996 02:23:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by Root.COM (8.7.5/8.6.5) with SMTP id CAA00222; Fri, 5 Apr 1996 02:21:48 -0800 (PST) Message-Id: <199604051021.CAA00222@Root.COM> X-Authentication-Warning: implode.Root.COM: Host localhost [127.0.0.1] didn't use HELO protocol To: asami@cs.berkeley.edu (Satoshi Asami) cc: current@FreeBSD.org, nisha@cs.berkeley.edu, tege@matematik.su.se, hasty@rah.star-gate.com Subject: Re: fast memory copy for large data sizes In-reply-to: Your message of "Fri, 05 Apr 1996 01:35:16 PST." <199604050935.BAA24263@silvia.HIP.Berkeley.EDU> From: David Greenman Reply-To: davidg@Root.COM Date: Fri, 05 Apr 1996 02:21:48 -0800 Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >We've put together a fast memory copy that uses floating point >registers to speed up large transfers. The original idea was taken >from Amancio Hasty's old post to use floating point registers to move >8 bytes at a time. (We tried using integer registers too but with our >wits we could only get 10MB/s less than the FP case.) > >By the way, we plugged this thing in as a replacement to >copyin/copyout and our ccd testing machine, (striping disk driver, see >http://stampede.cs.berkeley.edu/ccd/ for details) and maximum read >performance improved from 21MB/s to 24MB/s using 9 disks. But that's >only to our interest, so here's a comparison with the libc bcopy() >(which is essentially the same code as the stock copyin/copyout). > >Here are the kind of numbers we are seeing, and hope you will see, if >you run the program attached at the end of this mail: > > 90MHz Pentium (silvia), SiS chipset, 256KB cache: > > size libc ours > 32 15.258789 MB/s 6.103516 MB/s > 64 20.345052 MB/s 15.258789 MB/s > 128 17.438616 MB/s 15.258789 MB/s This would be a big lose in the kernel since just about all bcopy's fall into this range _except_ disk I/O block copies. I know this can be done better using other techniques (non-FP, see hackers mail from about 3 months ago). You should talk to John Dyson who's also working on this. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-current Fri Apr 5 02:56:05 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA11103 for current-outgoing; Fri, 5 Apr 1996 02:56:05 -0800 (PST) Received: from originat.demon.co.uk (originat.demon.co.uk [158.152.220.9]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id CAA11098 for ; Fri, 5 Apr 1996 02:56:01 -0800 (PST) Received: (from paul@localhost) by originat.demon.co.uk (8.7.5/8.6.9) id MAA00692; Fri, 5 Apr 1996 12:56:29 +0100 (BST) From: Paul Richards Message-Id: <199604051156.MAA00692@originat.demon.co.uk> Subject: Re: fast memory copy for large data sizes To: davidg@Root.COM Date: Fri, 5 Apr 1996 12:56:29 +0100 (BST) Cc: asami@cs.berkeley.edu, current@FreeBSD.org, nisha@cs.berkeley.edu, tege@matematik.su.se, hasty@rah.star-gate.com In-Reply-To: <199604051021.CAA00222@Root.COM> from "David Greenman" at Apr 5, 96 02:21:48 am Reply-to: paul@netcraft.co.uk X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk In reply to David Greenman who said > > size libc ours > > 32 15.258789 MB/s 6.103516 MB/s > > 64 20.345052 MB/s 15.258789 MB/s > > 128 17.438616 MB/s 15.258789 MB/s > > This would be a big lose in the kernel since just about all bcopy's fall > into this range _except_ disk I/O block copies. I know this can be done better > using other techniques (non-FP, see hackers mail from about 3 months ago). You > should talk to John Dyson who's also working on this. A quick check of the size would probably help and use the original method for small copies. Run a benchmark on such a scheme and see what happens. Anyway, I had another thought, do we save the fp registers across context switches? I seem to remember that we don't always and instead save them when something tries to do FP operations, I might be imagining this but if it's true increased use of the fp regs is going to impact context switching. -- Paul Richards, Originative Solutions Ltd. Internet: paul@netcraft.co.uk, http://www.netcraft.co.uk Phone: 0370 462071 (Mobile), +44 1225 447500 (work) From owner-freebsd-current Fri Apr 5 03:01:59 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA11377 for current-outgoing; Fri, 5 Apr 1996 03:01:59 -0800 (PST) Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id DAA11369 Fri, 5 Apr 1996 03:01:55 -0800 (PST) Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.7.5/8.6.9) id CAA24750; Fri, 5 Apr 1996 02:59:13 -0800 (PST) Date: Fri, 5 Apr 1996 02:59:13 -0800 (PST) Message-Id: <199604051059.CAA24750@silvia.HIP.Berkeley.EDU> To: davidg@root.com CC: current@freebsd.org, nisha@cs.berkeley.edu, tege@matematik.su.se, hasty@rah.star-gate.com, dyson@freebsd.org In-reply-to: <199604051021.CAA00222@Root.COM> (message from David Greenman on Fri, 05 Apr 1996 02:21:48 -0800) Subject: Re: fast memory copy for large data sizes From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk * > size libc ours * > 32 15.258789 MB/s 6.103516 MB/s * > 64 20.345052 MB/s 15.258789 MB/s * > 128 17.438616 MB/s 15.258789 MB/s * * This would be a big lose in the kernel since just about all * bcopy's fall into this range _except_ disk I/O block copies. Of course we need to put a cut-off number to use the old routine, this is what we did when we stuck it in the kernel. Sorry if I didn't mention that in my previous mail, the purpose of collecting these data was to see where this threshold is going to be. * I know * this can be done better using other techniques (non-FP, see hackers * mail from about 3 months ago). You should talk to John Dyson who's * also working on this. I have that mail, tried what was in there, but it wasn't as fast as FP copies. Maybe I screwed up something, I'll try again tomorrow. Satoshi From owner-freebsd-current Fri Apr 5 03:19:25 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA11838 for current-outgoing; Fri, 5 Apr 1996 03:19:25 -0800 (PST) Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id DAA11833 Fri, 5 Apr 1996 03:19:20 -0800 (PST) Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.7.5/8.6.9) id DAA24816; Fri, 5 Apr 1996 03:16:38 -0800 (PST) Date: Fri, 5 Apr 1996 03:16:38 -0800 (PST) Message-Id: <199604051116.DAA24816@silvia.HIP.Berkeley.EDU> To: davidg@root.com CC: current@freebsd.org, nisha@cs.berkeley.edu, tege@matematik.su.se, hasty@rah.star-gate.com, dyson@freebsd.org In-reply-to: <199604051021.CAA00222@Root.COM> (message from David Greenman on Fri, 05 Apr 1996 02:21:48 -0800) Subject: Re: fast memory copy for large data sizes From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I have that mail, tried what was in there, but it wasn't as fast as FP > copies. Maybe I screwed up something, I'll try again tomorrow. It wasn't much trouble so I tried it again. Here's what I got on the 133MHz Pentium: size libc ours 32 N/A 30.517578 MB/s 64 61.035156 MB/s 30.517578 MB/s 128 40.690104 MB/s 40.690104 MB/s 256 40.690104 MB/s 34.877232 MB/s 512 40.690104 MB/s 34.877232 MB/s 1024 40.690104 MB/s 33.674569 MB/s 2048 39.859694 MB/s 34.265351 MB/s 4096 39.859694 MB/s 34.265351 MB/s 8192 39.657360 MB/s 34.115721 MB/s 16384 39.556962 MB/s 34.115721 MB/s 32768 39.506953 MB/s 34.153005 MB/s 65536 39.531942 MB/s 34.227820 MB/s 131072 39.345294 MB/s 34.125034 MB/s 262144 39.227993 MB/s 34.227820 MB/s 524288 38.735668 MB/s 34.218451 MB/s 1048576 38.224839 MB/s 34.263003 MB/s 2097152 37.799323 MB/s 34.270635 MB/s 4194304 37.700283 MB/s 34.283265 MB/s Hmm. I can't even get it to be faster than libc now. I think I've seen 40MB/s for large copies before, I don't remember exactly what I did. Satoshi P.S. Here's the "unrolled", pretty much stolen from Torbjorn's mail to -hackers: .align 2 .globl _unrolled .type _unrolled,@function _unrolled: pushl %ebp movl %esp,%ebp pushl %edi pushl %esi movl 8(%ebp),%esi movl 12(%ebp),%edi movl 16(%ebp),%ecx /* count is in bytes */ shrl $5,%ecx jz L54 movl (%edi),%eax /* fetch destination cache line */ .align 2,0x90 L55: movl 28(%edi),%eax /* fetch destination cache line */ orl %eax,%eax /* to make things go in pairs */ movl (%esi),%eax /* load pairwise */ movl 4(%esi),%edx movl %eax,(%edi) /* and store pairwise */ movl %edx,4(%edi) movl 8(%esi),%eax movl 12(%esi),%edx movl %eax,8(%edi) movl %edx,12(%edi) movl 16(%esi),%eax movl 20(%esi),%edx movl %eax,16(%edi) movl %edx,20(%edi) movl 24(%esi),%eax movl 28(%esi),%edx movl %eax,24(%edi) movl %edx,28(%edi) addl $32,%esi /* update source pointer */ addl $32,%edi /* update destnation pointer */ decl %ecx /* decr loop count */ jnz L55 L54: movl 16(%ebp),%ecx andl $31,%ecx movl %ecx,%edx shrl $2,%ecx /* first copy as much as we can in words */ cld rep movsl movl %edx,%ecx andl $3,%ecx /* and then up to 3 bytes */ rep movsb leal -8(%ebp),%esp popl %esi popl %edi leave ret Lfe6: .size _unrolled,Lfe6-_unrolled From owner-freebsd-current Fri Apr 5 03:37:09 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA12444 for current-outgoing; Fri, 5 Apr 1996 03:37:09 -0800 (PST) Received: from eac.iafrica.com (slipper119232.iafrica.com [196.7.119.232]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id DAA12438 for ; Fri, 5 Apr 1996 03:36:59 -0800 (PST) Received: (from rnordier@localhost) by eac.iafrica.com (8.6.12/8.6.12) id NAA00226; Fri, 5 Apr 1996 13:35:48 +0200 From: Robert Nordier Message-Id: <199604051135.NAA00226@eac.iafrica.com> Subject: Re: 2.2-960323 Panic in mount_msdos To: franky@pinewood.nl (Frank ten Wolde) Date: Fri, 5 Apr 1996 13:35:47 +0200 (SAT) Cc: current@freebsd.org In-Reply-To: <9604050935.ZM9063@pwood1.pinewood.nl> from "Frank ten Wolde" at Apr 5, 96 09:35:25 am X-Mailer: ELM [version 2.4 PL24 ME8a] Content-Type: text Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 5 Apr 1996, Frank ten Wolde wrote: > . . . . . > It would have been nice if some sanity checking would have been performed, > so that the kernel simply would abort the mount(2) system call with an > appropriate error (wrong FS type, or something similar). > > [...] > > > The DOSFS is being rewritten (not by me). > Neither by me. Don't get me wrong, I *really* like FreeBSD and my > remarks are not ment to critisize anyone. I, for sure, do *not* have the > time and resources to contribute significantly to FreeBSD and I certainly > do not make demands of any kind :-) > I simply pointed out the panic. Maybe the code maintainer of the DOSFS > can use this info to make the system even more stable. Your feedback is appreciated. I'm currently involved in re-implementing the msdosfs and agree that mounting a non-FAT fs should be trapped as an error. The same logic as used by MS-DOS 'io.sys' in recognizing, and establishing the layout of, a DOS file system is being incorporated into the new msdosfs code. -- Robert Nordier From owner-freebsd-current Fri Apr 5 03:47:25 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA12742 for current-outgoing; Fri, 5 Apr 1996 03:47:25 -0800 (PST) Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id DAA12737 Fri, 5 Apr 1996 03:47:17 -0800 (PST) Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.7.5/8.6.9) id DAA24903; Fri, 5 Apr 1996 03:44:34 -0800 (PST) Date: Fri, 5 Apr 1996 03:44:34 -0800 (PST) Message-Id: <199604051144.DAA24903@silvia.HIP.Berkeley.EDU> To: davidg@root.com CC: current@freebsd.org, nisha@cs.berkeley.edu, tege@matematik.su.se, dyson@freebsd.org, hasty@rah.star-gate.com In-reply-to: <199604051021.CAA00222@Root.COM> (message from David Greenman on Fri, 05 Apr 1996 02:21:48 -0800) Subject: Re: fast memory copy for large data sizes From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk By the way, if someone wants to try putting it into the kernel, here is a patch to support.s. Change the two "cmpl $1024" lines if you want to change the cutoff. We've been running this on our -current system here for a couple of days, it seems to be working fine. As I said, it pushed up the maximum read bandwidth (through the filesystem) for our disk array from 21MB/s to 23MB/s. (I didn't see much speed difference (only about 100KB/s) for single disks though, the bottleneck is probably not here in this case.) I also wrote a small program to just issue multiple reads to the same region of a file, and I got 37MB/s for the stock kernel and 49MB/s for the modified version on the 133MHz Pentium (which is about the same as what I got from the user-level code). Here's the testing program. Sorry I didn't have time to clean it up, it's kinda messy. But all you need to see is the loop that has memcpy() and lseek() (no, the memcpy() is not called by default). === /* rawread.c: repeatedly read from same block over and over */ #include #include #include #include #include #include #include #include #include #include #include #include #include /* some constants */ #define True (1) #define False (0) #define Ok (0) #define Error (1) /* start of onfigurable parameters */ /* default buffer size */ #define BlockSize 8192 /* default size of file */ #define TotalSize 67108864 int removefile = True ; int verbose = False ; int writeonly = False ; int randomize = False ; int readonly = False ; /* end of configurable parameters */ /* default name of temporary file */ #define TmpFile "disktest.tmp" /* default line length */ #define LineLen 1024 char *myname ; void *xmalloc(size_t size) ; void usage(int retval) ; void error(char *msg) ; void remfile(void) ; void flushoutput(void) ; void cuechild(void) ; int main(int argc, char **argv) { int i ; char *filename ; int blocksize = BlockSize ; int totalsize = TotalSize ; int iterations ; void *buffer, *buffer2 ; int fd ; int count ; struct timeval tv_start, tv_end ; double elapsed ; int docopy = False ; myname = argv[0] ; filename = argv[argc-1] ; if (argc < 2) usage(Error) ; for (i = 1 ; i < argc-1 ; i++) { if (argv[i][0] == '-') { /* option */ if (!strcmp(argv[i], "-b")) { if (i+1 == argc) usage(Error) ; blocksize = atoi(argv[i+1]) ; if (blocksize <= 0) usage(Error) ; i++ ; } else if (!strcmp(argv[i], "-s")) { if (i+1 == argc) usage(Error) ; totalsize = atoi(argv[i+1]) ; if (totalsize <= 0) usage(Error) ; i++ ; } else if (!strcmp(argv[i], "-c")) docopy = True ; else if (!strcmp(argv[i], "-h")) usage(Ok) ; else usage(Error) ; } else usage(Error) ; } iterations = totalsize / blocksize ; if (filename[0] == '-') usage(Error); buffer = xmalloc(blocksize) ; if (docopy) buffer2 = xmalloc(blocksize) ; if ((fd = open(filename, O_RDONLY, 0)) < 0) { fprintf(stderr, "file: %s\n", filename) ; error("open") ; } gettimeofday(&tv_start, NULL) ; for (count = 0 ; count < iterations ; count++) { if (read(fd, buffer, blocksize) != blocksize) error("read") ; if (docopy) memcpy(buffer2, buffer, blocksize) ; lseek(fd, 0, SEEK_SET) ; } gettimeofday(&tv_end, NULL) ; elapsed = tv_end.tv_sec-tv_start.tv_sec + ((double) tv_end.tv_usec-tv_start.tv_usec)/1000000 ; if (verbose) printf("%d reads of %d bytes in %f seconds\n", count, blocksize, elapsed) ; printf("%d bytes transferred in %d secs (%d bytes/sec) from \"%s\"\n", totalsize, (int) elapsed, (int) (totalsize/elapsed), filename) ; fflush(stdout) ; close(fd) ; return Ok ; } void usage(int retval) { fprintf(stderr, "usage: %s [-b bufsize] [-s size] [-c] filename\n", myname) ; exit(retval) ; } void *xmalloc(size_t size) { void *vp ; if ((vp = malloc(size)) == NULL) { fprintf(stderr, "panic: memory exausted with request size %d\n", size) ; exit(Error) ; } return vp ; } void error(char *msg) { perror(msg) ; exit(Error) ; } === Use it as: dd if=/dev/zero of=foo bs=1024 count=1024 rawread -b 1048576 -s 104857600 foo The number after -b is the read request size and the one after -s is the total size (it will repeat it 100 times in the above case). Note that for small -b sizes, the copy will always be done within the cache, so the resulting number may not reflect the real world performance. Here's the patch: === Index: support.s =================================================================== RCS file: /usr/cvs/src/sys/i386/i386/support.s,v retrieving revision 1.31 diff -u -r1.31 support.s --- support.s 1995/12/28 23:14:40 1.31 +++ support.s 1996/04/04 06:27:15 @@ -463,6 +463,14 @@ /* bcopy(%esi, %edi, %ebx) */ 3: movl %ebx,%ecx + cmpl $1024,%ecx + jbe slow_copyout + + call fastmove + jmp done_copyout + + ALIGN_TEXT +slow_copyout: shrl $2,%ecx cld rep @@ -510,6 +518,14 @@ cmpl $VM_MAXUSER_ADDRESS,%edx ja copyin_fault + cmpl $1024,%ecx + jbe slow_copyin + + call fastmove + jmp done_copyin + + ALIGN_TEXT +slow_copyin: movb %cl,%al shrl $2,%ecx /* copy longword-wise */ cld @@ -520,6 +536,8 @@ rep movsb + ALIGN_TEXT +done_copyin: popl %edi popl %esi xorl %eax,%eax @@ -534,6 +552,70 @@ movl _curpcb,%edx movl $0,PCB_ONFAULT(%edx) movl $EFAULT,%eax + ret + +/* fastmove(src, dst, len) + src in %esi + dst in %edi + len in %ecx + uses %eax and %edx for tmp. storage + */ + ALIGN_TEXT +fastmove: + movl %cr0,%edx + movl $8, %eax /* CR0_TS */ + not %eax + andl %eax,%edx /* clear CR0_TS */ + movl %edx,%cr0 + + cmpl $63,%ecx + jbe L57 + + subl $108,%esp + fsave (%esp) + + ALIGN_TEXT +L58: + fildq 0(%esi) + fildq 8(%esi) + fildq 16(%esi) + fildq 24(%esi) + fildq 32(%esi) + fildq 40(%esi) + fildq 48(%esi) + fildq 56(%esi) + fxch %st(7) + fistpq 0(%edi) + fxch %st(5) + fistpq 8(%edi) + fxch %st(3) + fistpq 16(%edi) + fxch %st(1) + fistpq 24(%edi) + fistpq 32(%edi) + fistpq 40(%edi) + fistpq 48(%edi) + fistpq 56(%edi) + addl $-64,%ecx + addl $64,%esi + addl $64,%edi + cmpl $63,%ecx + ja L58 + + frstor (%esp) + addl $108,%esp + + ALIGN_TEXT +L57: + cld + rep + movsb + + andl $8,%edx + movl %cr0,%eax + orl %edx, %eax /* reset CR0_TS to the original value */ + movl %eax,%cr0 + ret /* === Enjoy, Satoshi From owner-freebsd-current Fri Apr 5 04:50:33 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA14591 for current-outgoing; Fri, 5 Apr 1996 04:50:33 -0800 (PST) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id EAA14585 Fri, 5 Apr 1996 04:50:23 -0800 (PST) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) id OAA16263; Fri, 5 Apr 1996 14:30:20 +0200 (MET DST) Received: (from andreas@localhost) by knobel.gun.de (8.7.5/8.7.3) id NAA21078; Fri, 5 Apr 1996 13:43:07 +0200 (MET DST) From: Andreas Klemm Message-Id: <199604051143.NAA21078@knobel.gun.de> Subject: make clean should remove README.html in ports collection To: asami@cs.berkeley.edu (Satoshi Asami), ports@freebsd.org, current@freebsd.org Date: Fri, 5 Apr 1996 13:43:06 +0200 (MET DST) X-Mailer: ELM [version 2.4ME+ PL13 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi ! I have automated for me the process of updating and checking out the sources of the main source tree and the ports collection. After creating the README.html files - which are not part of the source repository - I always get the following lines, when I get informed via e-mail, what has been changed ... ? ports/lang/icon/README.html ? ports/lang/itcl/README.html ? ports/lang/logo/README.html ? ports/lang/mit-scheme/README.html ? ports/lang/modula-3/README.html ? ports/lang/p2c/README.html ? ports/lang/pTk/README.html ? ports/lang/pbasic/README.html ? ports/lang/perl5/README.html C ports/lang/pgcc/Makefile ? ports/lang/pgcc/akl.diff ? ports/lang/pgcc/README.html ? ports/lang/python/README.html ? ports/lang/scheme48/README.html ? ports/lang/schemetoc/README.html The many notes, that README.html isn't part of the source repository, is a bit disturbing. Simply filtering out all lines with sed would be possible, but perhaps there is another solution ... What do you think ? a) check the README.html files in into the source repository ? b) create an additional tag into mk/bsd.ports*.mk to remove only those files on demand, so one can get rid of them separately c) remove them generally in the 'make clean' target... I deceided to 'hack' the make clean target, to remove those README's... I'd prefer to add the README.html's into the source repository and to add an additional target to remove them on demand. What I have here is solution c) ... another good working possibility ;-) Index: bsd.port.mk =================================================================== RCS file: /cvs/src/share/mk/bsd.port.mk,v retrieving revision 1.199 diff -u -r1.199 bsd.port.mk --- bsd.port.mk 1996/04/01 11:12:58 1.199 +++ bsd.port.mk 1996/04/05 11:20:20 @@ -899,6 +899,7 @@ .else @${RM} -rf ${WRKDIR} .endif + @${RM} -f README.html .endif # Prints out a list of files to fetch (useful to do a batch fetch) Index: bsd.port.subdir.mk =================================================================== RCS file: /cvs/src/share/mk/bsd.port.subdir.mk,v retrieving revision 1.13 diff -u -r1.13 bsd.port.subdir.mk --- bsd.port.subdir.mk 1996/04/01 11:13:00 1.13 +++ bsd.port.subdir.mk 1996/04/05 11:28:13 @@ -72,6 +72,7 @@ .if !target(clean) clean: _SUBDIRUSE + @rm -f README.html .endif .if !target(depend) -- andreas@knobel.gun.de /\/\___ Wiechers & Partner Datentechnik GmbH Andreas Klemm ___/\/\/ $$ Support Unix - aklemm@wup.de $$ pgp p-key http://www-swiss.ai.mit.edu/~bal/pks-toplev.html >>> powered by <<< ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz >>> FreeBSD <<< From owner-freebsd-current Fri Apr 5 08:03:49 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA22691 for current-outgoing; Fri, 5 Apr 1996 08:03:49 -0800 (PST) Received: from gauss.math.purdue.edu (gauss.math.purdue.edu [128.210.21.2]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id IAA22685 for ; Fri, 5 Apr 1996 08:03:46 -0800 (PST) Received: from hopf.math.purdue.edu (freebsd@hopf.math.purdue.edu [128.210.3.18]) by gauss.math.purdue.edu (8.7.4/Purdue_Math) with ESMTP id LAA12909 for ; Fri, 5 Apr 1996 11:03:44 -0500 (EST) Received: (from freebsd@localhost) by hopf.math.purdue.edu (8.7.1/8.6.11) id LAA21248; Fri, 5 Apr 1996 11:03:41 -0500 (EST) Date: Fri, 5 Apr 1996 11:03:41 -0500 (EST) From: Clarence Wilkerson Message-Id: <199604051603.LAA21248@hopf.math.purdue.edu> To: current@freefall.freebsd.org Subject: AHA1542B and Exabyte drive Cc: netbsd@hopf.math.purdue.edu, wilker@hopf.math.purdue.edu Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk With a current sup as of Wednesday, my kernel hangs with an Exabyte 8200 on scsi id 4. I get the drop into ahadebug mode and error messages similar to those reported by others (crash reports ). With dos and linux this doesn't happen. With the kernel on the recent SNAP-3-23-96 issue boot floppy "boot.flp" it doesn't happen ( although that kernel overwrote the eeprom on my SMCElite 16 ethernet card when it probed). With a SONY single speed CDROM, it works, but is very slow to initialize. Help??? Clarence Wilkerson From owner-freebsd-current Fri Apr 5 08:04:16 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA22743 for current-outgoing; Fri, 5 Apr 1996 08:04:16 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id IAA22736 for ; Fri, 5 Apr 1996 08:04:12 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id BAA12866; Sat, 6 Apr 1996 01:51:01 +1000 Date: Sat, 6 Apr 1996 01:51:01 +1000 From: Bruce Evans Message-Id: <199604051551.BAA12866@godzilla.zeta.org.au> To: bde@zeta.org.au, rgrimes@GndRsh.aac.dev.com Subject: Re: tty-level buffer overflows - what to do? Cc: current@freebsd.org, jgreco@brasil.moneng.mei.com, nate@sri.MT.net, root@deadline.snafu.de Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> >This is not quite correct, IRQ 7 is signal when someone asserts an IRQ singal >> >then removes that signal _before_ the CPU runs the interrupt acknowledge >> >cycle to the 8259 PIC. >> >> This is not quite correct :-). IRQ7 is signaled when an IRQ signal is >> removed _during_ the interrupt acknowledge cycle for that IRQ. It isn't >> signaled if the cycle never begins. >You had better go read the data book again, and look at the schematics to >the real 8259A if you have access to them. Of course I checked before posting, and it has to work like I said or there would be a stray interrupt every time a debugger disables clock interrupts for more than one clock tick (since interrupts are edge sensitive the edge trigger latch would hold any acknowledged interrupt until it is EOI'ed). >1985 Intel Microsystems Components Handbook, page 2-93: >Interrupt Sequence >... >The events occur as follows in an MCS-80/85 system: >1. One or more of the INTERRUPT REQUEST lines > (IR7-0) are raised high, setting the corresponding IRR > bit(s). >2. The 8259A evaluates these requests, and sends an > INT to the CPU, if appropriate. >3. The CPU acknowledges the INT and responds with an > INTA~ pulse. >The events occurring in an iAPX 86 system are the same until step 4. Step 3 isn't reached if the interrupt occurs and goes away while interrupts are disabled. I've watched this many times (e.g. by reading the IRR in a debugger), and turned off the interrupt source directly - the interrupt doesn't occur. >In both the edge and level triggered modes the IR inputs >must remain high until after the falling edge of the first ^^^^^ >INTA. If the IR input goes low before this time a DEFAULT ^^^^ >IR7 will occur when the CPU acknowledges the interrupt. When there's no INTA, there's no first INTA, so it doesn't matter what the IR inputs do. >> The cause has to be a signal on one of the IRQ lines enabled by FreeBSD >> (because masked lines are completely ignored). The signal can then interfere >> with the signal from the enabled board. >Mostly true, ``(because masked lines are completely ignored)'' in not >technically accurate, the mask register and AND gate are after the IRR latch, >but they can't cause the priority resolver to trigger an INT request at >step 2 above, so they should be out of the picture from a software point. Oops. Yes, they are only ignored for the purpose of generating interrupts. >Do we ever use the value of the IRR to dispatch an interrupt? As the IRR >can be set even though the mask bit is turned on. We only use it to determine if a clock interrupt has just occurred in microtime(). It's too expensive to read it on the chance that it might be set becuse the chance isn't high (except possibly after interrupts have been masked for a long time) and it takes too long to read (about 1 usec). It is only of much use for examining the state of unacknowledged (necessarily masked) interrupts - then it follows the real-time IRQ signals. For acknowledged interrupts, it suffers from edge triggering braindamage - it is 0 from when you send EOI until the next rising edge on the IRQ, so reading it doesn't tell you if the IRQ is still there. Bruce From owner-freebsd-current Fri Apr 5 08:07:07 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA22868 for current-outgoing; Fri, 5 Apr 1996 08:07:07 -0800 (PST) Received: from gauss.math.purdue.edu (gauss.math.purdue.edu [128.210.21.2]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id IAA22856 for ; Fri, 5 Apr 1996 08:07:00 -0800 (PST) Received: from hopf.math.purdue.edu (freebsd@hopf.math.purdue.edu [128.210.3.18]) by gauss.math.purdue.edu (8.7.4/Purdue_Math) with ESMTP id LAA12978 for ; Fri, 5 Apr 1996 11:06:57 -0500 (EST) Received: (from freebsd@localhost) by hopf.math.purdue.edu (8.7.1/8.6.11) id LAA21264; Fri, 5 Apr 1996 11:06:53 -0500 (EST) Date: Fri, 5 Apr 1996 11:06:53 -0500 (EST) From: Clarence Wilkerson Message-Id: <199604051606.LAA21264@hopf.math.purdue.edu> To: current@freefall.freebsd.org Subject: Clean reboot on current Cc: freebsd@hopf.math.purdue.edu, wilker@hopf.math.purdue.edu Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk When I do a few syncs and a "reboot" command, I get a string of numbers like 3 3 3 3 3 3 "giving up" On rebooting the system, I get notified that the clean flag has not been reset and it fscks completely every time. My FreeBSD disk is the second disk on a EIDE controller and I boot using "bootany" . Clarence Wilkerson From owner-freebsd-current Fri Apr 5 08:17:07 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA23215 for current-outgoing; Fri, 5 Apr 1996 08:17:07 -0800 (PST) Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id IAA23143 for ; Fri, 5 Apr 1996 08:15:29 -0800 (PST) Received: by sequent.kiae.su id AA06374 (5.65.kiae-2 ); Fri, 5 Apr 1996 19:02:51 +0300 Received: by sequent.KIAE.su (UUMAIL/2.0); Fri, 5 Apr 96 19:02:49 +0300 Received: (from ache@localhost) by astral.msk.su (8.7.5/8.7.3) id TAA00466; Fri, 5 Apr 1996 19:58:41 +0400 (MSD) Message-Id: <199604051558.TAA00466@astral.msk.su> Subject: Re: adjkerntz (was: cvs commit: src/usr.sbin/tzsetup ...) To: joerg_wunsch@uriah.heep.sax.de Date: Fri, 5 Apr 1996 19:58:40 +0400 (MSD) Cc: freebsd-current@FreeBSD.org In-Reply-To: <199604050831.KAA24540@uriah.heep.sax.de> from "J Wunsch" at "Apr 5, 96 10:31:28 am" From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast X-Mailer: ELM [version 2.4ME+ PL14 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > As =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= wrote: > > > > rarely the case for me.) What if i use my own package to export/ > > > import DOS files? (Yes, i really wrote one as paywork years ago. It > > > > Your package must handle timezone in this case. > > How if i don't know in which timezone the floppy i just wanna read has > been created? What about mtools? It was error in DOS filesystem data structure: there must be field to store timezone. Due to this error all fpysical media exchange between timezones are illegal. :-) > You can argue how you want: DOS has simply ignored the problem for too > long, and now that the technology has been rolling all over it, it's > too late for a general solution. That's typical for DOS... I don't argue, I agree. > > DOS have TZ environment variable (all C implmentations handle it). > > Well, dir(1) (not that there's really a man page section one, but so > you know what i mean :) cannot handle it if i insert a floppy that > came from USA, for example. > > TZ is solely handled by C runtime systems, and at least for my very > old TC 2.0 (the only C system i've still got around), the TZ handling > is buggy. I've just started pcemu and wrote a small test program: > setting TZ affects both, localtime(3) and gmtime(3) similarly. New C/Pascal compilers handle it corretcly. time() returns UTC when your BIOS have wall clock. > Last not least, DOS timezone idea is broken. You can find work- > arounds, and they might be working for you most of the time, but they > remain workarounds for something that has been misdesigned in the > first place. I won't do anything in my Unix systems to correct their > mistakes. My intention is not correct Microsoft mistakes in general, but run FreeBSD & DOS/Win on the same machine. Be more specific: I dislike DOS filesystem times changed when I change OS. I.e I run 'make' under DOS after I edit DOS files under FreeBSD: file times must remain 'the same'. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-current Fri Apr 5 08:42:26 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA24496 for current-outgoing; Fri, 5 Apr 1996 08:42:26 -0800 (PST) Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id IAA24491 for ; Fri, 5 Apr 1996 08:42:22 -0800 (PST) Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id SAA20317 ; Fri, 5 Apr 1996 18:42:17 +0200 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id SAA14945 ; Fri, 5 Apr 1996 18:42:22 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.7.5/keltia-uucp-2.7) id HAA17188; Fri, 5 Apr 1996 07:55:04 +0200 (MET DST) From: Ollivier Robert Message-Id: <199604050555.HAA17188@keltia.freenix.fr> Subject: Re: tty-level buffer overflows - what to do? To: root@deadline.snafu.de (Andreas S. Wetzel) Date: Fri, 5 Apr 1996 07:55:04 +0200 (MET DST) Cc: jgreco@brasil.moneng.mei.com, current@FreeBSD.org In-Reply-To: from "Andreas S. Wetzel" at "Apr 4, 96 08:34:33 pm" X-Operating-System: FreeBSD 2.2-CURRENT ctm#1839 X-Mailer: ELM [version 2.4ME+ PL11 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk It seems that Andreas S. Wetzel said: > I tried to install another Meg on 256k simms but didn't suceed cause the > motherboard only recognizes one meg of memory when I put in the 256k simms > additionally to the 4 meg. Try to swap the memory banks (e.g. bank#0 with 4x 256 and bank#1 with 4x 1M). I remember trying this when I upgraded to 20 MB a while ago and the 4 additional MB weren't recognized till I swapped the banks... -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 2.2-CURRENT #9: Mon Apr 1 03:18:13 MET DST 1996 From owner-freebsd-current Fri Apr 5 09:00:12 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA25331 for current-outgoing; Fri, 5 Apr 1996 09:00:12 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id JAA25308 for ; Fri, 5 Apr 1996 09:00:05 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id KAA04780; Fri, 5 Apr 1996 10:59:12 -0600 From: Joe Greco Message-Id: <199604051659.KAA04780@brasil.moneng.mei.com> Subject: Re: tty-level buffer overflows - what to do? To: imp@village.org (Warner Losh) Date: Fri, 5 Apr 1996 10:59:11 -0600 (CST) Cc: nate@sri.MT.net, jgreco@brasil.moneng.mei.com, root@deadline.snafu.de, current@FreeBSD.org In-Reply-To: <199604042231.PAA13355@rover.village.org> from "Warner Losh" at Apr 4, 96 03:31:16 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > : With 2 lines going full blast (sup updates!) I see *NO* overflows on my > : box. Again, my box is running with about 6MB of free memory all the > : time, so I rarely hit the disk, but I've done compiles on the machine to > : upgrade software with no noticeable degradation of serial speed. > > We have 4 SLIP lines going full blast from time to time on our 386 > DX-40 (with 387 math co) 8M memory and a 40MB IDE drive. There is > also a SMC Ethernet card to boot that all of our mail and news travels > out of. While there is little disk activity, we've never had a > overflow in our logs. All the internal modems that we use have 16550A > UARTs on them (or clones). This is a 1.1.5.1R system, but I doubt > that matters. All of the serial lines are locked at 115200 bps. This is my experience as well, most of my routers and infrastructure is made out of 386/40 class machines with 8MB RAM and 100-300MB IDE hard disks. I recently brought a 486DX2/50 into service to see how well I could handle more lines (6-12) on a single machine, I want to be running a more extensive firewall ruleset and the 386/40 will start to huff and puff under serious load with 3 or 4 lines active with a dozen or two IPFW rules. Heck, I ran a 386sx/16 at 115200 with 16450's, one SLIP link, and was getting 5000cps :-) ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/546-7968 From owner-freebsd-current Fri Apr 5 09:02:56 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA25574 for current-outgoing; Fri, 5 Apr 1996 09:02:56 -0800 (PST) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA25552 Fri, 5 Apr 1996 09:02:48 -0800 (PST) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <16737(5)>; Fri, 5 Apr 1996 09:02:10 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177476>; Fri, 5 Apr 1996 09:02:01 -0800 To: Andreas Klemm cc: asami@cs.berkeley.edu (Satoshi Asami), ports@freebsd.org, current@freebsd.org Subject: Re: make clean should remove README.html in ports collection In-reply-to: Your message of "Fri, 05 Apr 96 03:43:06 PST." <199604051143.NAA21078@knobel.gun.de> Date: Fri, 5 Apr 1996 09:01:56 PST From: Bill Fenner Message-Id: <96Apr5.090201pst.177476@crevenia.parc.xerox.com> Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199604051143.NAA21078@knobel.gun.de> you write: >? ports/lang/icon/README.html >? ports/lang/itcl/README.html >? ports/lang/logo/README.html How about "cvs -I README.html"? Or add README.html to CVSROOT/cvsignore? Bill From owner-freebsd-current Fri Apr 5 09:07:23 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA25988 for current-outgoing; Fri, 5 Apr 1996 09:07:23 -0800 (PST) Received: from chrome.jdl.com (chrome.onramp.net [199.1.166.202]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA25973 for ; Fri, 5 Apr 1996 09:07:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by chrome.jdl.com (8.6.12/8.6.12) with SMTP id LAA14190; Fri, 5 Apr 1996 11:06:35 -0600 Message-Id: <199604051706.LAA14190@chrome.jdl.com> X-Authentication-Warning: chrome.jdl.com: Host localhost didn't use HELO protocol To: davidg@Root.COM cc: asami@cs.berkeley.edu (Satoshi Asami), current@FreeBSD.org, nisha@cs.berkeley.edu, tege@matematik.su.se, hasty@rah.star-gate.com Subject: Re: fast memory copy for large data sizes In-reply-to: Your message of "Fri, 05 Apr 1996 02:21:48 PST." <199604051021.CAA00222@Root.COM> Clarity-Index: null Threat-Level: none Software-Engineering-Dead-Seriousness: There's no excuse for unreadable code. Net-thought: If you meet the Buddha on the net, put him in your Kill file. Compiler-Motto: Wintermute is dead. Long live Wintermute. Date: Fri, 05 Apr 1996 11:06:31 -0600 From: Jon Loeliger Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk So, like David Greenman was saying to me just the other day: > >Here are the kind of numbers we are seeing, and hope you will see, if > >you run the program attached at the end of this mail: > > > > 90MHz Pentium (silvia), SiS chipset, 256KB cache: > > > > size libc ours > > 32 15.258789 MB/s 6.103516 MB/s > > 64 20.345052 MB/s 15.258789 MB/s > > 128 17.438616 MB/s 15.258789 MB/s > > This would be a big lose in the kernel since just about all bcopy's fall > into this range _except_ disk I/O block copies. I know this can be done bette >r > using other techniques (non-FP, see hackers mail from about 3 months ago). Don't know how much it would cost (in performance), but would it make sense to have a simple size-based cutoff test for the two different algorithms? jdl From owner-freebsd-current Fri Apr 5 09:15:58 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA26648 for current-outgoing; Fri, 5 Apr 1996 09:15:58 -0800 (PST) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA26639 for ; Fri, 5 Apr 1996 09:15:46 -0800 (PST) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id JAA08863; Fri, 5 Apr 1996 09:15:27 -0800 From: "Rodney W. Grimes" Message-Id: <199604051715.JAA08863@GndRsh.aac.dev.com> Subject: Re: tty-level buffer overflows - what to do? To: bde@zeta.org.au (Bruce Evans) Date: Fri, 5 Apr 1996 09:15:27 -0800 (PST) Cc: bde@zeta.org.au, current@freebsd.org, jgreco@brasil.moneng.mei.com, nate@sri.MT.net, root@deadline.snafu.de In-Reply-To: <199604051551.BAA12866@godzilla.zeta.org.au> from Bruce Evans at "Apr 6, 96 01:51:01 am" X-Mailer: ELM [version 2.4ME+ PL11 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >> >This is not quite correct, IRQ 7 is signal when someone asserts an IRQ singal > >> >then removes that signal _before_ the CPU runs the interrupt acknowledge > >> >cycle to the 8259 PIC. > >> > >> This is not quite correct :-). IRQ7 is signaled when an IRQ signal is > >> removed _during_ the interrupt acknowledge cycle for that IRQ. It isn't > >> signaled if the cycle never begins. > > >You had better go read the data book again, and look at the schematics to > >the real 8259A if you have access to them. > > Of course I checked before posting, and it has to work like I said or > there would be a stray interrupt every time a debugger disables clock > interrupts for more than one clock tick (since interrupts are edge > sensitive the edge trigger latch would hold any acknowledged interrupt > until it is EOI'ed). The ISR latch holds an interrupt until it is EOI'ed. There are three latches in there. The ``edge sense latch'', the ``request latch (aka IRR)'', and the ``in-service latch (ISR)''. ... > >In both the edge and level triggered modes the IR inputs > >must remain high until after the falling edge of the first > ^^^^^ > >INTA. If the IR input goes low before this time a DEFAULT > ^^^^ ^^^^^^^^^^^^^^^^^^^^ > >IR7 will occur when the CPU acknowledges the interrupt. > > When there's no INTA, there's no first INTA, so it doesn't matter > what the IR inputs do. Well, if there is no INTA I would say FreeBSD is pretty dead in the water. Sooner or later you going to run that INTA cycle that is going to cause the stray int 7. Remeber, the IRR is still set even though IRx has gone away. [It is this later fact that causes the logic in the resolver to default to a 7]. > >> The cause has to be a signal on one of the IRQ lines enabled by FreeBSD > >> (because masked lines are completely ignored). The signal can then interfere > >> with the signal from the enabled board. > > >Mostly true, ``(because masked lines are completely ignored)'' in not > >technically accurate, the mask register and AND gate are after the IRR latch, > >but they can't cause the priority resolver to trigger an INT request at > >step 2 above, so they should be out of the picture from a software point. > > Oops. Yes, they are only ignored for the purpose of generating interrupts. > > >Do we ever use the value of the IRR to dispatch an interrupt? As the IRR > >can be set even though the mask bit is turned on. > > We only use it to determine if a clock interrupt has just occurred in > microtime(). It's too expensive to read it on the chance that it might > be set becuse the chance isn't high (except possibly after interrupts > have been masked for a long time) and it takes too long to read (about 1 > usec). It is only of much use for examining the state of unacknowledged > (necessarily masked) interrupts - then it follows the real-time IRQ > signals. For acknowledged interrupts, it suffers from edge triggering > braindamage - it is 0 from when you send EOI until the next rising edge > on the IRQ, so reading it doesn't tell you if the IRQ is still there. > > Bruce > -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Fri Apr 5 09:22:07 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA27151 for current-outgoing; Fri, 5 Apr 1996 09:22:07 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA27145 for ; Fri, 5 Apr 1996 09:22:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by rover.village.org (8.6.12/8.6.6) with SMTP id KAA16235; Fri, 5 Apr 1996 10:20:17 -0700 Message-Id: <199604051720.KAA16235@rover.village.org> To: Joe Greco Subject: Re: tty-level buffer overflows - what to do? Cc: nate@sri.MT.net, root@deadline.snafu.de, current@FreeBSD.org In-reply-to: Your message of Fri, 05 Apr 1996 10:59:11 CST Date: Fri, 05 Apr 1996 10:20:16 -0700 From: Warner Losh Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk : firewall ruleset and the 386/40 will start to huff and puff under serious : load with 3 or 4 lines active with a dozen or two IPFW rules. I forgot to mention that we run a locally hacked IPFILT as well on our gateway and have about two dozen rules or so in our rule base. We still get about 2500-3000cps for binary data on our 28.8k modems depending more on line quality that day than on anything else.... We're so happy with this that we're thinking about putting a couple of ISDN modems on fast serial (or SYNC) cards and upgrading to 128Kbps service to our members. At least as they can afford it. Right now it seems like we have plenty of CPU to spare... Does anyone anticipate that this will be a problem? Would a SYNC card (ala Denis' company) put a smaller load on the machine than a bunch of 16550A's? Right now the load average is about 0.01 most of the time (most of that is the gated load: 35 seconds per day. We do about 450k packets to our ISP a day and about 1/10 that to the member's SLIP connections. We do about 550k packets a day on the etherent. We have about 45M interrupts on our main serial card (or about 500/s) per day. Our other connections have a more modest rate of 5-10/. Likewise, our ethernet is at about 10/s as well. These numbers are averaged over a 10 day period. Warner From owner-freebsd-current Fri Apr 5 09:36:52 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA28233 for current-outgoing; Fri, 5 Apr 1996 09:36:52 -0800 (PST) Received: from cenotaph.snafu.de (root@deadline.berlin.netSurf.DE [194.64.158.25]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA28228 for ; Fri, 5 Apr 1996 09:36:48 -0800 (PST) Received: by cenotaph.snafu.de from deadline.snafu.de using smtp id m0u5FQI-0002erC; Fri, 5 Apr 96 19:35:46 +0200 (MET DST) (/\##/\ Smail3.1.30.13 #30.1) Received: by deadline.snafu.de id m0u5FSm-000A2wC; Fri, 5 Apr 96 19:38:20 +0200 (MET DST) (/\##/\ Smail3.1.30.13 #30.1) Message-Id: From: root@deadline.snafu.de (Andreas S. Wetzel) Subject: Re: tty-level buffer overflows - what to do? To: roberto@keltia.freenix.fr (Ollivier Robert) Date: Fri, 5 Apr 1996 19:38:20 +0200 (MET DST) Cc: current@freebsd.org In-Reply-To: <199604050555.HAA17188@keltia.freenix.fr> from Ollivier Robert at "Apr 5, 96 07:55:04 am" Organization: A world stranger than you have ever imagined. X-Mailer: ELM [version 2.4ME+ PL13] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi! --- Ollivier Robert writes: ] It seems that Andreas S. Wetzel said: ] > I tried to install another Meg on 256k simms but didn't suceed cause the ] > motherboard only recognizes one meg of memory when I put in the 256k simms ] > additionally to the 4 meg. ] ] Try to swap the memory banks (e.g. bank#0 with 4x 256 and bank#1 with 4x ] 1M). I remember trying this when I upgraded to 20 MB a while ago and the 4 ] additional MB weren't recognized till I swapped the banks... I already did this, cause I had the same problem as you metioned when updating my other box to 20 Mb, but the effect was still the same: The machine only recognized the 256k simms with a total capacity of 1 Mb. I think this is simply a problem of the motherboard, since I had these 256k simms installed on another machine (dx2/66) and this machine recognized the total of 5 Mb. Anyway... I wont bother about 1 Meg of additional memory :-> Regards, mickey -- (__) (@@) Andreas S. Wetzel E-mail: mickey@deadline.snafu.de /-------\/ Utrechter Strasse 41 Web: http://deadline.snafu.de/ / | || 13347 Berlin Voice: <+4930> 456 81 68 * ||----|| Germany Fax/Data: <+4930> 455 19 57 ~~ ~~ From owner-freebsd-current Fri Apr 5 09:57:13 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA29337 for current-outgoing; Fri, 5 Apr 1996 09:57:13 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id JAA29330 for ; Fri, 5 Apr 1996 09:57:10 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id LAA04875; Fri, 5 Apr 1996 11:56:18 -0600 From: Joe Greco Message-Id: <199604051756.LAA04875@brasil.moneng.mei.com> Subject: Re: tty-level buffer overflows - what to do? To: bde@zeta.org.au (Bruce Evans) Date: Fri, 5 Apr 1996 11:56:18 -0600 (CST) Cc: jgreco@brasil.moneng.mei.com, root@deadline.snafu.de, current@FreeBSD.ORG In-Reply-To: <199604050309.NAA13560@godzilla.zeta.org.au> from "Bruce Evans" at Apr 5, 96 01:09:00 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >What kind of drives? IDE drives bite, particularly if they are being used > >at the same time as the serial port... etc, etc. > > IDE drives have no affect on the operation of the serial unless they > are so slow that the system spends too much of its time in the kernel. > Bus-hogging SCSI controllers bite. It has been my observation that IDE drives DO tend to affect the operation of serial I/O, at least during heavy I/O periods. Small-memory systems tend to spend much more time doing "heavy I/O" (swapping), in my experience, this is just one reason I put 8MB in even my smallest machines these days. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/546-7968 From owner-freebsd-current Fri Apr 5 10:00:29 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA29519 for current-outgoing; Fri, 5 Apr 1996 10:00:29 -0800 (PST) Received: from cenotaph.snafu.de (root@deadline.berlin.netSurf.DE [194.64.158.25]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA29496 for ; Fri, 5 Apr 1996 10:00:09 -0800 (PST) Received: by cenotaph.snafu.de from deadline.snafu.de using smtp id m0u5FmW-0002erC; Fri, 5 Apr 96 19:58:44 +0200 (MET DST) (/\##/\ Smail3.1.30.13 #30.1) Received: by deadline.snafu.de id m0u5Fp0-000A2wC; Fri, 5 Apr 96 20:01:18 +0200 (MET DST) (/\##/\ Smail3.1.30.13 #30.1) Message-Id: From: root@deadline.snafu.de (Andreas S. Wetzel) Subject: Re: tty-level buffer overflows - what to do? To: jgreco@brasil.moneng.mei.com (Joe Greco) Date: Fri, 5 Apr 1996 20:01:18 +0200 (MET DST) Cc: bde@zeta.org.au, jgreco@brasil.moneng.mei.com, current@FreeBSD.ORG In-Reply-To: <199604051756.LAA04875@brasil.moneng.mei.com> from Joe Greco at "Apr 5, 96 11:56:18 am" Organization: A world stranger than you have ever imagined. X-Mailer: ELM [version 2.4ME+ PL13] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi! --- Joe Greco writes: ] > >What kind of drives? IDE drives bite, particularly if they are being used ] > >at the same time as the serial port... etc, etc. ] > ] > IDE drives have no affect on the operation of the serial unless they ] > are so slow that the system spends too much of its time in the kernel. ] > Bus-hogging SCSI controllers bite. ] ] It has been my observation that IDE drives DO tend to affect the operation ] of serial I/O, at least during heavy I/O periods. Small-memory systems tend ] to spend much more time doing "heavy I/O" (swapping), in my experience, this ] is just one reason I put 8MB in even my smallest machines these days. By the way... can anybody tell me more about those new IDE/EIDE controllers that do such things linke other pio modes? Are they usable under FreeBSD, do they have any advantage over normal rotten old IDE controllers? Regards, Mickey -- (__) (@@) Andreas S. Wetzel E-mail: mickey@deadline.snafu.de /-------\/ Utrechter Strasse 41 Web: http://deadline.snafu.de/ / | || 13347 Berlin Voice: <+4930> 456 81 68 * ||----|| Germany Fax/Data: <+4930> 455 19 57 ~~ ~~ From owner-freebsd-current Fri Apr 5 10:11:26 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA29949 for current-outgoing; Fri, 5 Apr 1996 10:11:26 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA29944 for ; Fri, 5 Apr 1996 10:11:23 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id EAA17652; Sat, 6 Apr 1996 04:09:20 +1000 Date: Sat, 6 Apr 1996 04:09:20 +1000 From: Bruce Evans Message-Id: <199604051809.EAA17652@godzilla.zeta.org.au> To: bde@zeta.org.au, rgrimes@GndRsh.aac.dev.com Subject: Re: tty-level buffer overflows - what to do? Cc: current@freebsd.org, jgreco@brasil.moneng.mei.com, nate@sri.MT.net, root@deadline.snafu.de Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> Of course I checked before posting, and it has to work like I said or >> there would be a stray interrupt every time a debugger disables clock >> interrupts for more than one clock tick (since interrupts are edge >> sensitive the edge trigger latch would hold any acknowledged interrupt >> until it is EOI'ed). >The ISR latch holds an interrupt until it is EOI'ed. There are three >latches in there. The ``edge sense latch'', the ``request latch (aka IRR)'', >and the ``in-service latch (ISR)''. >... More completely: - the ISR latch is set when the interrupt is acknowledged and cleared when the interrupt is EOI'ed. - the `edge sense latch' (ESL) is set (negative logic) when the interrupt is acknowledged (after the ISR is set) and cleared when the interrupt goes away AND the ISR is clear. - the IRR latch is quite different. "Be sure top notice that the request latch is a transparent D type latch". If the ESL is clear, then the IRR follows the IRQ signal. If the ESL is set, then the IRR is in braindamaged mode: it is held low by ESL. >> >In both the edge and level triggered modes the IR inputs >> >must remain high until after the falling edge of the first >> ^^^^^ >> >INTA. If the IR input goes low before this time a DEFAULT >> ^^^^ > ^^^^^^^^^^^^^^^^^^^^ >> >IR7 will occur when the CPU acknowledges the interrupt. >> >> When there's no INTA, there's no first INTA, so it doesn't matter >> what the IR inputs do. >Well, if there is no INTA I would say FreeBSD is pretty dead in the >water. Sooner or later you going to run that INTA cycle that is >going to cause the stray int 7. Remeber, the IRR is still set even >though IRx has gone away. [It is this later fact that causes the >logic in the resolver to default to a 7]. No, the IRR isn't set. Only the ESL remembers the IRQ state, and it isn't active because there's no INTA. Bruce From owner-freebsd-current Fri Apr 5 10:31:21 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA00811 for current-outgoing; Fri, 5 Apr 1996 10:31:21 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA00806 for ; Fri, 5 Apr 1996 10:31:18 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id EAA18166; Sat, 6 Apr 1996 04:26:33 +1000 Date: Sat, 6 Apr 1996 04:26:33 +1000 From: Bruce Evans Message-Id: <199604051826.EAA18166@godzilla.zeta.org.au> To: bde@zeta.org.au, jgreco@brasil.moneng.mei.com Subject: Re: tty-level buffer overflows - what to do? Cc: current@FreeBSD.ORG, root@deadline.snafu.de Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> >What kind of drives? IDE drives bite, particularly if they are being used >> >at the same time as the serial port... etc, etc. >> >> IDE drives have no affect on the operation of the serial unless they >> are so slow that the system spends too much of its time in the kernel. >> Bus-hogging SCSI controllers bite. >It has been my observation that IDE drives DO tend to affect the operation >of serial I/O, at least during heavy I/O periods. Small-memory systems tend >to spend much more time doing "heavy I/O" (swapping), in my experience, this >is just one reason I put 8MB in even my smallest machines these days. It's an indirect effect. Small-memory systems are more likely to have slow IDE drives that make the swapping slower. You probably can't afford to swap the applications doing serial i/o at all if you don't use flow control - the kernel buffers are only large enough for 100 msec of input at 115200 bps. Bruce From owner-freebsd-current Fri Apr 5 10:41:51 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA01384 for current-outgoing; Fri, 5 Apr 1996 10:41:51 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id KAA01374 for ; Fri, 5 Apr 1996 10:41:47 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id MAA05100; Fri, 5 Apr 1996 12:40:52 -0600 From: Joe Greco Message-Id: <199604051840.MAA05100@brasil.moneng.mei.com> Subject: Re: tty-level buffer overflows - what to do? To: bde@zeta.org.au (Bruce Evans) Date: Fri, 5 Apr 1996 12:40:51 -0600 (CST) Cc: bde@zeta.org.au, jgreco@brasil.moneng.mei.com, current@FreeBSD.ORG, root@deadline.snafu.de In-Reply-To: <199604051826.EAA18166@godzilla.zeta.org.au> from "Bruce Evans" at Apr 6, 96 04:26:33 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >> >What kind of drives? IDE drives bite, particularly if they are being used > >> >at the same time as the serial port... etc, etc. > >> > >> IDE drives have no affect on the operation of the serial unless they > >> are so slow that the system spends too much of its time in the kernel. > >> Bus-hogging SCSI controllers bite. > > >It has been my observation that IDE drives DO tend to affect the operation > >of serial I/O, at least during heavy I/O periods. Small-memory systems tend > >to spend much more time doing "heavy I/O" (swapping), in my experience, this > >is just one reason I put 8MB in even my smallest machines these days. > > It's an indirect effect. Small-memory systems are more likely to have > slow IDE drives that make the swapping slower. You probably can't > afford to swap the applications doing serial i/o at all if you don't use > flow control - the kernel buffers are only large enough for 100 msec of > input at 115200 bps. Well, even with drives like the WDC Caviar's (the most common IDE drive around here)... and with flow control... you can see some lossage. _My_ recommendation is to build the systems so you don't use the disk much. And it works for me. :-) YMMV ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/546-7968 From owner-freebsd-current Fri Apr 5 10:44:17 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA01534 for current-outgoing; Fri, 5 Apr 1996 10:44:17 -0800 (PST) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA01460 for ; Fri, 5 Apr 1996 10:43:58 -0800 (PST) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id KAA09197; Fri, 5 Apr 1996 10:43:36 -0800 From: "Rodney W. Grimes" Message-Id: <199604051843.KAA09197@GndRsh.aac.dev.com> Subject: Re: tty-level buffer overflows - what to do? To: bde@zeta.org.au (Bruce Evans) Date: Fri, 5 Apr 1996 10:43:36 -0800 (PST) Cc: bde@zeta.org.au, current@freebsd.org, jgreco@brasil.moneng.mei.com, nate@sri.MT.net, root@deadline.snafu.de In-Reply-To: <199604051809.EAA17652@godzilla.zeta.org.au> from Bruce Evans at "Apr 6, 96 04:09:20 am" X-Mailer: ELM [version 2.4ME+ PL11 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >> Of course I checked before posting, and it has to work like I said or > >> there would be a stray interrupt every time a debugger disables clock > >> interrupts for more than one clock tick (since interrupts are edge > >> sensitive the edge trigger latch would hold any acknowledged interrupt > >> until it is EOI'ed). > > >The ISR latch holds an interrupt until it is EOI'ed. There are three > >latches in there. The ``edge sense latch'', the ``request latch (aka IRR)'', > >and the ``in-service latch (ISR)''. > >... > > More completely: > - the ISR latch is set when the interrupt is acknowledged and cleared when > the interrupt is EOI'ed. > - the `edge sense latch' (ESL) is set (negative logic) when the interrupt > is acknowledged (after the ISR is set) and cleared when the interrupt > goes away AND the ISR is clear. That event is way way after the DEFAULT IR7 occurs... - the ESL is reset (negative logic) when the IRx signal goes from low to high. [Needed to add this since you failed to mention how it gets set in the first place] > - the IRR latch is quite different. "Be sure top notice that the request > latch is a transparent D type latch". If the ESL is clear, then the IRR > follows the IRQ signal. If the ESL is set, then the IRR is in > braindamaged mode: it is held low by ESL. > > >> >In both the edge and level triggered modes the IR inputs > >> >must remain high until after the falling edge of the first > >> ^^^^^ > >> >INTA. If the IR input goes low before this time a DEFAULT > >> ^^^^ > > ^^^^^^^^^^^^^^^^^^^^ > >> >IR7 will occur when the CPU acknowledges the interrupt. > >> > >> When there's no INTA, there's no first INTA, so it doesn't matter > >> what the IR inputs do. > > >Well, if there is no INTA I would say FreeBSD is pretty dead in the > >water. Sooner or later you going to run that INTA cycle that is > >going to cause the stray int 7. Remeber, the IRR is still set even ^ESL oopsss... > >though IRx has gone away. [It is this later fact that causes the > >logic in the resolver to default to a 7]. > > No, the IRR isn't set. Only the ESL remembers the IRQ state, and > it isn't active because there's no INTA. Like I said bruce if there ain't no INTA this whole discussion is pointless! FreeBSD has DIED if INTA does not occur at some time. I think we need to end this, it is going no place, we both understand how the 8259A works, hell, we both probably have detailed logic diagrams of the damn thing. Simple fact of the mater is if someone asserts an IRx signal, then removes that signal before an INTA cycle completes with 8259 will signal this as an IRQ7 interrupt. Don't tell me again that INTA is not going to occur, because if it is not going to occur FreeBSD has stopped running.... -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Fri Apr 5 11:15:43 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA03395 for current-outgoing; Fri, 5 Apr 1996 11:15:43 -0800 (PST) Received: from mramirez.sy.yale.edu (mramirez.sy.yale.edu [130.132.57.207]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA03387 for ; Fri, 5 Apr 1996 11:15:29 -0800 (PST) Received: (from mrami@localhost) by mramirez.sy.yale.edu (8.6.12/8.6.9) id OAA06266; Fri, 5 Apr 1996 14:13:11 -0500 Date: Fri, 5 Apr 1996 14:13:11 -0500 (EST) From: Marc Ramirez Reply-To: mrami@minerva.cis.yale.edu To: Satoshi Asami cc: current@freebsd.org, nisha@cs.berkeley.edu, tege@matematik.su.se, hasty@rah.star-gate.com Subject: Re: fast memory copy for large data sizes In-Reply-To: <199604050935.BAA24263@silvia.HIP.Berkeley.EDU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 5 Apr 1996, Satoshi Asami wrote: > We've put together a fast memory copy that uses floating point > registers to speed up large transfers. The original idea was taken > from Amancio Hasty's old post to use floating point registers to move > 8 bytes at a time. (We tried using integer registers too but with our > wits we could only get 10MB/s less than the FP case.) P5's and up only, please. :) AMD 486/66: mrami[~/bcopy]$ make >> running tests sh runtests size libc ours 32 7.629395 MB/s 7.629395 MB/s 64 12.207031 MB/s 4.695012 MB/s 128 12.207031 MB/s 3.487723 MB/s 256 12.207031 MB/s 6.424753 MB/s 512 12.520032 MB/s 7.076540 MB/s 1024 12.682630 MB/s 7.454676 MB/s 2048 12.682630 MB/s 7.570252 MB/s 4096 10.146104 MB/s 7.629395 MB/s 8192 12.682630 MB/s 7.666830 MB/s 16384 12.703252 MB/s 7.689469 MB/s 32768 12.682630 MB/s 7.517440 MB/s 65536 12.183236 MB/s 7.472501 MB/s 131072 12.090144 MB/s 7.526040 MB/s 262144 12.569762 MB/s 7.717717 MB/s 524288 12.419583 MB/s 7.534773 MB/s 1048576 11.838803 MB/s 7.718551 MB/s 2097152 12.164192 MB/s 7.725020 MB/s 4194304 12.290410 MB/s 7.719504 MB/s mrami[~/bcopy]$ Marc. -- Every four seconds a woman has a baby. Our problem is to find this woman and stop her. From owner-freebsd-current Fri Apr 5 11:50:57 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA06064 for current-outgoing; Fri, 5 Apr 1996 11:50:57 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA06046 Fri, 5 Apr 1996 11:50:51 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id VAA28050; Fri, 5 Apr 1996 21:50:48 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id VAA08998; Fri, 5 Apr 1996 21:50:48 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id VAA01030; Fri, 5 Apr 1996 21:49:48 +0200 (MET DST) From: J Wunsch Message-Id: <199604051949.VAA01030@uriah.heep.sax.de> Subject: DM: CVSROOT/Emptydir exists. To: freebsd-current@FreeBSD.org (FreeBSD-current users), phk@FreeBSD.org (Poul-Henning Kamp) Date: Fri, 5 Apr 1996 21:49:47 +0200 (MET DST) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Is it just me only? Delta number 1845 is already applied; ignoring. Delta number 1846 is already applied; ignoring. Delta number 1847 is already applied; ignoring. Delta number 1848 is already applied; ignoring. Delta number 1849 is already applied; ignoring. DM: CVSROOT/Emptydir exists. Exit(80) This is from the nightly CTM run. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Fri Apr 5 12:27:49 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA09244 for current-outgoing; Fri, 5 Apr 1996 12:27:49 -0800 (PST) Received: from ki.net (root@ki.net [205.150.102.1]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id MAA09233 for ; Fri, 5 Apr 1996 12:27:40 -0800 (PST) Received: from freebsd.ki.net (freebsd.ki.net [205.150.102.2]) by ki.net (8.7.4/8.7.4) with ESMTP id PAA03394 for ; Fri, 5 Apr 1996 15:28:00 -0500 (EST) Received: from localhost (scrappy@localhost) by freebsd.ki.net (8.7.5/8.7.5) with SMTP id PAA01235 for ; Fri, 5 Apr 1996 15:28:31 -0500 (EST) X-Authentication-Warning: freebsd.ki.net: scrappy owned process doing -bs Date: Fri, 5 Apr 1996 15:28:29 -0500 (EST) From: "Marc G. Fournier" To: current@freebsd.org Subject: Can we upgrade ncurses? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi... Is there any underlying reason why we can't upgrade Ncurses from 1.8.4 (circa 1994) to 1.9.9e (circa current)? Included at the bottom of this is the NEWS file from 1.9.9e listing changes since 1.8.4... If its a matter of someone integrating...I raise my hand... for me it means that its one less thing I have to remember not to install when I do a make world, so its worth my time commiting an upgrade and maintaining the library :) Marc G. Fournier scrappy@ki.net Systems Administrator @ ki.net scrappy@freebsd.org This is a log of changes that ncurses has gone through since I started working with Pavel Curtis' original work, pcurses, in 1992: ### ncurses-1.9.8a -> 1.9.9 * fixed broken wsyncup()/wysncdown(), as a result wnoutrefresh() now has copy-changed-lines behavior. * added and documented wresize() function. * more fixes to LOWER-RIGHT corner handling. * changed the line-breakout optimization code to allow some lines to be emitted before the first check. # added option for tic to use symbolic instead of hard links (for AFS) * fix to restore auto-wrap mode. * trace level can be controlled by environment variable. * better handling of NULs in terminal descriptions. * improved compatibility with observed SVR4 behavior. * the refresh behavior of over-lapping windows is now more efficient and behaves like SVR4. * use autoconf 2.7, which results in a working setup for SCO 5.0. * support for ESCDELAY. * small fixes for menu/form code. * the test directory has its own configure. * fixes to pads when optimizing scrolling. * fixed several off-by-one bugs. * fixes for termcap->terminfo translation; less restrictions more correct behavior. ### ncurses-1.9.7 -> 1.9.8a * teach infocmp -i to recognize ECMA highlight sequences * infocmp now dumps all SVr4 termcaps (not just the SVr4 ones) on -C * support infocmp -RBSD. * satisfy XSI Curses requirement that every macro be available as a function. * This represents the last big change to the public interface of ncurses. The ABI_VERSION has now been set at 3.0 and should stay there barring any great catastrophies or acts of God. * The C++ has been cleaned up in reaction to the changes to satisfy XSI's requirements. * libncurses now gets linked to libcurses to help seemless emulation (replacement) of a vendor's curses. --disable-overwrite turns this behavior off. ### ncurses-1.9.6 -> 1.9.7 * corrected return values of setupterm() * Fixed some bugs in tput (it does padding now) * fixed a bug in tic that made it do the wrong thing on entries with more than one `use' capability. * corrected the screen-size calculation at startup time to alter the numeric capabilities as per SVr4, not just LINES and COLS. * toe(1) introduced; does what infocmp -T used to. * tic(1) can now translate AIX box1 and font[0123] capabilities. * tic uses much less core, the dotic.sh kluge can go away now. * fix read_entry() and write_entry() to pass through cancelled capabilities OK. * Add $HOME/.terminfo as source/target directory for terminfo entries. * termcap compilation now automatically dumps an entry to $HOME/.terminfo. * added -h option to toe(1). * added -R option to tic(1) and infocmp(1). * added fallback-entry-list feature. * added -i option to infocmp(1). * do a better job at detecting if we're on SCO. ### ncurses-1.9.5 -> 1.9.6 * handling of TERMCAP environment variables now works correctly. * various changes to shorten termcap translations to less that 1024 chars. * tset(1) added * mouse support for xterm. * most data tables are now const and accordingly live in shareable text space. * Obey the XPG4/SVr4 practice that echo() is initally off. * tic is much better at translating XENIX and AIX termcap entries now. * tic can interpret ko capabilities now. * integrated Juergen Pfeifer's forms library. * taught write_entry() how not to write more than it needs to; this change reduces the size of the terminfo tree by a full 26%! * infocmp -T option added. * better warnings about historical tic quirks from tic. ### ncurses 1.9.4 -> 1.9.5 * menus library is now included with documentation. * lib_mvcur has been carefully profiled and tuned. * Fixed a ^Z-handling bug that was tanking lynx(1). * HJ Lu's patches for ELF shared libraries under Linux * terminfo.src 9.8.2 * tweaks for compiling in seperate directories. * Thomas Dickey's patches to support NeXT's brain-dead linker * Eric Raymond's patches to fix problems with long termcap entries. * more support for shared libraries under SunOS and IRIX. ### ncurses 1.9.3 -> 1.9.4 * fixed an undefined-order-of-evaluation bug in lib_acs.c * systematically gave non-API public functions and data an _nc_ prefix. * integrated Juergen Pfeifer's menu code into the distribution. * totally rewrote the knight test game's interface ### ncurses 1.9.2c -> 1.9.3 * fixed the TERMCAP_FILE Support. * fixed off-by-one errors in scrolling code * added tracemunch to the test tools * took steps to cut the running time of make install.data ### ncurses 1.9.2c -> 1.9.2d * revised 'configure' script to produce libraries for normal, debug, profile and shared object models. ### ncurses 1.9.1 -> 1.9.2 * use 'autoconf' to implement 'configure' script. * panels support added * tic now checks for excessively long termcap entries when doing translation * first cut at eliminating namespace pollution. ### ncurses 1.8.9 -> 1.9 * cleanup gcc warnings for the following: use size_t where 'int' is not appropriate, fixed some shadowed variables, change attr_t to compatible with chtype, use attr_t in some places where it was confused with 'int'. * use chtype/attr_t casts as appropriate to ensure portability of masking operations. * added-back waddchnstr() to lib_addstr.c (it had been deleted). * supplied missing prototypes in curses.h * include in lib_termcap.c to ensure that the prototypes are consistent (they weren't). * corrected prototype of tputs in * rewrote varargs parsing in lib_tparm.c (to avoid referencing memory that may be out of bounds on the stack) -- Purify found this. * ensure that TRACE is defined in lib_trace.c (to solve prototype warnings from gcc). * corrected scrolling-region size in 'mvcur_wrap()' * more spelling fixes * use 'calloc()' to allocate WINDOW struct in lib_newwin.c (Purify). * set default value for SP->_ofp in lib_set_term.c (otherwise SunOS dumps core in init_acs()). * include in write_entry.c (most "braindead" includes declare errno in that file). ### ncurses 1.8.8 -> 1.8.9 * compile (mostly) clean with gcc 2.5.8 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wconversion and using __attribute__ to flush out non-portable use of "%x" for pointers, or for chtype data (which is declared as a long). * modified doupdate to ensure that typahead was turned on before attempting select-call (otherwise, some implementations hang). * added trace mask TRACE_FIFO, use this in lib_getch.c to allow finer resolution of traces. * improved bounds checking on several critical functions. * the data directory has been replaced by the new master terminfo file. * -F file-comparison option added to infocmp. * compatibility with XSI Curses is now documented in the man bages. * wsyncup/wsyncdown functions are reliable now; subwindow code in general is much less flaky. * capabilities ~msgr, tilde_glitch, insert_padding, generic_type, no_pad_char, memory_above, memory_below, and hard_copy are now used properly. * cursor-movement optimization has been completely rewritten. * vertical-movement optimization now uses hardware scrolling, il, dl. ### ncurses 1.8.7 -> 1.8.8 * untic no longer exists, infocmp replaces it. * tic can understand termcap now, especially if it is called captoinfo. * The Linux Standard Console terminfo entry is called linux insead of console. It also uses the kernel's new method of changing charsets. * initscr() will EXIT upon error (as the docs say) This wil mostly happen if you try to run on an undefined terminal. * I can get things running on AIX but tic can't compile terminfo. I have to compile entries on another machine. Volunteers to hunt this bug are welcome. * wbkgd() and wbkgdset() can be used to set a windows background to color. wclear()/werase() DO NOT use the current attribute to clear the screen. This is the way SVR4 curses works. PDCurses 2.1 is broken in this respect, though PDCurses 2.2 has been fixed. * cleaned up the test/ directory. * test/worm will segfault after quite a while. * many spelling corrections courtesy of Thomas E. Dickey ### ncurses 1.8.6 -> 1.8.7 * cleaned up programs in test/ directory. * fixed wbkgdset() macro. * modified getstr() to stop it from advancing cursor in noecho mode. * modified linux terminfo entry to work with the latest kernel to get the correct alternate character set. * also added a linux-mono entry for those running on monochrome screens. * changed initscr() so that it behaves like the man page says it does. this fixes the problem with programs in test/ crashing with SIGSEV if a terminal is undefined. * modified addch() to avoid using any term.h #define's * removed duplicate tgoto() in lib_tparm.c * modified dump_entry.c so that infocmp deals correctly with ',' in acsc * modified delwin() to correctly handle deleting subwindows. * fixed Makefile.dist to stop installing an empty curses.h * fixed a couple of out-of-date notes in man pages. ### ncurses 1.8.5 -> 1.8.6 * Implemented wbkgd(), bkgd(), bkgdset(), and wbkgdset(). * The handling of attributes has been improved and now does not turn off color if other attributes are turned off. * scrolling code is improved. Scrolling in subwindows is still broken. * Fixes to several bugs that manifest them on platforms other than Linux. * The default to meta now depends on the status of the terminal when ncurses is started. * The interface to the tracing facility has changed. Instead of the pair of functions traceon() and traceoff(), there is just one function trace() which takes a trace mask argument. The trace masks, defined in curses.h, are as follows: #define TRACE_DISABLE 0x00 /* turn off tracing */ #define TRACE_ORDINARY 0x01 /* ordinary trace mode */ #define TRACE_CHARPUT 0x02 /* also trace all character outputs */ #define TRACE_MAXIMUM 0x0f /* maximum trace level */ More trace masks may be added, or these may be changed, in future releases. * The pad code has been improved and the pad test code in test/ncurses.c has been improved. * The prototype ansi entry has been changed to work with a wider variety of emulators. * Fix to the prototype ansi entry that enables it to work with PC emulators that treat trailing ";m" in a highlight sequence as ";0m"; this doesn't break operation with any emulators. * There are now working infocmp, captoinfo, tput, and tclear utilities. * tic can now compile entries in termcap syntax. * Core-dump bug in pnoutrefresh fixed. * We now recognize and compile all the nonstandard capabilities in Ross Ridge's mytinfo package (rendering it obsolete). * General cleanup and documentation improvements. * Fixes and additions to the installation-documentation files. * Take cursor to normal mode on endwin. ### ncurses 1.8.4 -> 1.8.5 * serious bugs in updating screen which caused erratic non-display, fixed. * fixed initialization for getch() related variable which cause unpredictable results. * fixed another doupdate bug which only appeared if you have parm_char. * implemented redrawln() and redrawwin(). * implemented winsnstr() and related functions. * cleaned up insertln() and deleteln() and implemented (w)insdeln(). * changed Makefile.dist so that installation of man pages will take note of the terminfo directory. * fixed Configure (removed the mysterious 'X'). * Eric S. Raymond fixed the script.* files so that they work with stock awk. From owner-freebsd-current Fri Apr 5 12:33:52 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA09705 for current-outgoing; Fri, 5 Apr 1996 12:33:52 -0800 (PST) Received: from mramirez.sy.yale.edu (mramirez.sy.yale.edu [130.132.57.207]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA09696 for ; Fri, 5 Apr 1996 12:33:46 -0800 (PST) Received: (from mrami@localhost) by mramirez.sy.yale.edu (8.6.12/8.6.9) id PAA08637; Fri, 5 Apr 1996 15:31:15 -0500 Date: Fri, 5 Apr 1996 15:31:11 -0500 (EST) From: Marc Ramirez Reply-To: mrami@minerva.cis.yale.edu To: JULIAN Elischer cc: asami@cs.berkeley.edu, current@freebsd.org, nisha@cs.berkeley.edu, tege@matematik.su.se, hasty@rah.star-gate.com Subject: Re: fast memory copy for large data sizes In-Reply-To: <199604052011.MAA13929@ref.tfs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 5 Apr 1996, JULIAN Elischer wrote: > > sh runtests > > size libc ours > > 32 7.629395 MB/s 7.629395 MB/s > > 64 12.207031 MB/s 4.695012 MB/s > [...] > > 2097152 12.164192 MB/s 7.725020 MB/s > > 4194304 12.290410 MB/s 7.719504 MB/s > > mrami[~/bcopy]$ > > these tests SEEM to be indicating that the bcopy in libc > is already better! or am I misreading something? Well, remember, my chip isn't even an Intel part! But you must be careful which chips you activate it with; I can imagine the FPbcopy really sucking on a NexGen 586 with emulated FP... Marc. -- Encyclopedia Salesmen: Invite them all in. Nip out the back door. Phone the police and tell them your house is being burgled. -- Mike Harding, "The Armchair Anarchist's Almanac" From owner-freebsd-current Fri Apr 5 12:40:14 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA10194 for current-outgoing; Fri, 5 Apr 1996 12:40:14 -0800 (PST) Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id MAA10186 for ; Fri, 5 Apr 1996 12:40:10 -0800 (PST) Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.7.5/8.6.9) id MAA25813; Fri, 5 Apr 1996 12:39:49 -0800 (PST) Date: Fri, 5 Apr 1996 12:39:49 -0800 (PST) Message-Id: <199604052039.MAA25813@silvia.HIP.Berkeley.EDU> To: julian@ref.tfs.com CC: mrami@minerva.cis.yale.edu, current@freebsd.org, nisha@cs.berkeley.edu, tege@matematik.su.se, hasty@rah.star-gate.com In-reply-to: <199604052011.MAA13929@ref.tfs.com> (julian@ref.tfs.com) Subject: Re: fast memory copy for large data sizes From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Marc, thanks for running the test. * > sh runtests * > size libc ours * > 32 7.629395 MB/s 7.629395 MB/s * > 64 12.207031 MB/s 4.695012 MB/s * [...] * > 2097152 12.164192 MB/s 7.725020 MB/s * > 4194304 12.290410 MB/s 7.719504 MB/s * > mrami[~/bcopy]$ * * these tests SEEM to be indicating that the bcopy in libc * is already better! or am I misreading something? No, it only shows the libc version is faster on a 486. We expected that, as the FP unit on a 486 is much slower than a Pentium. (Even a straight int -> FP conversion takes a lot of time I guess.) Any other Pentium owners? :) Satoshi From owner-freebsd-current Fri Apr 5 12:56:51 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA10806 for current-outgoing; Fri, 5 Apr 1996 12:56:51 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA10801 for ; Fri, 5 Apr 1996 12:56:45 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id GAA23015; Sat, 6 Apr 1996 06:55:42 +1000 Date: Sat, 6 Apr 1996 06:55:42 +1000 From: Bruce Evans Message-Id: <199604052055.GAA23015@godzilla.zeta.org.au> To: asami@cs.berkeley.edu, current@FreeBSD.org Subject: Re: fast memory copy for large data sizes Cc: hasty@rah.star-gate.com, nisha@cs.berkeley.edu, tege@matematik.su.se Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >We've put together a fast memory copy that uses floating point >registers to speed up large transfers. The original idea was taken Oops. I put together 5 fast memory copies that don't use floating point registers. Speeds range from 40K/sec to 340K/sec. on a 133MHz Pentium (ASUS), Triton chipset, 512KB PB cache, 60ns non-EDO main memory. This is after attempting to minimize the differences caused by the cache state. Details in other mail. The speed differences are so large and the cache state is so variable that it is easy to create benchmarks showing that all methods are the best :-). We seemed to have fooled ourselves with the optimized kernel bzeros already. On the above i586 system, the i586-optimized bzero is the slowest for compiling the kernel; for fork-exec of small processes it is significantly the slowest. >from Amancio Hasty's old post to use floating point registers to move >8 bytes at a time. (We tried using integer registers too but with our >wits we could only get 10MB/s less than the FP case.) This seemed like a bad idea. I added a test using it (just 8 fldl's followed by 8 fstpl's, storing in reverse order - this works for at least all-zero data) and got good results, but I still think it is a bad idea. Perhaps it can the duplicated by copying via integer registers through the L1 cache. >133MHz Pentium (sunrise), Triton chipset, 512KB (pipeline burst) cache: new columns vvvvvvvvv vvvvvvvvv vvvvvvvv > size libc ours mine-libc mine-best(int) mine-fp > 32 N/A 30.517578 MB/s 51493147 98069887 > 64 61.035156 MB/s 30.517578 MB/s 65049070 196997754 > 128 40.690104 MB/s 40.690104 MB/s 74971005 254666769 > 256 40.690104 MB/s 40.690104 MB/s 80998485 327390112 > 512 40.690104 MB/s 48.828125 MB/s 84416182 376524453 > 1024 40.690104 MB/s 51.398026 MB/s 85214370 379715593 > 2048 39.859694 MB/s 51.398026 MB/s 86936111 350385424 > 4096 39.859694 MB/s 52.083333 MB/s 87266431 326943762 > 8192 39.457071 MB/s 52.787162 MB/s 84805486 97567163 > 16384 39.556962 MB/s 52.966102 MB/s 65103489 97472157 > 32768 39.506953 MB/s 53.146259 MB/s 66593990 99217964 93604474 > 65536 39.457071 MB/s 53.282182 MB/s 61407673 79866591 93721503 > 131072 39.457071 MB/s 53.327645 MB/s 65457449 68011573 79960595 > 262144 39.345294 MB/s 53.350405 MB/s 51273532 53702491 75576993 > 524288 39.044198 MB/s 53.430220 MB/s 49370136 50029142 67400433 > 1048576 38.086533 MB/s 53.447354 MB/s 44054746 44095308 58624791 > 2097152 37.706680 MB/s 53.387433 MB/s 42742240 42770154 56946700 > 4194304 37.628643 MB/s 53.280763 MB/s 43381238 43381238 57727588 >As you can see, from a certain size and onwards, it is much faster >than the libc version. ("size" is in bytes.) >The program allocates two 4MB buffers and calls libc's bcopy (which is >essentially a string move using rep/movsl; see below for more on this) My tests are obviously not equivalent for small copies - the libc times are about twice as high. This is because I keep copying the same data. I want to do this to test in-cache copies. Not-in-cache copies get tested as a side effect when the buffer is much larger that the cache (L1 or L2). Your test gives similar times on my system. It tests the speed of copying data that isn't in the cache. This seems to be the usual case for kernel bzeros - that's why the i586 optimizations are pessimizations. >operation. (You can't use fld and fst because they will trap on >illegal (as a floating point number) bit patterns -- by the way, the Only if traps are enabled. Rounding may be a problem. >Pentium FP regs are 80 bits with a 64-bit mantissa so there's no loss >of data by using the integer load/store.) Useing 64-bit precision may be enough to avoid rounding problems. fldl is much faster than fildl if the data is in the cache. >Please type "make" and it will compile & run the tests. The output It didn't :-). It assumes that "." is in the $PATH. Bruce From owner-freebsd-current Fri Apr 5 13:02:54 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA11070 for current-outgoing; Fri, 5 Apr 1996 13:02:54 -0800 (PST) Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id NAA11041 Fri, 5 Apr 1996 13:02:42 -0800 (PST) Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.7.5/8.6.9) id NAA25847; Fri, 5 Apr 1996 13:02:30 -0800 (PST) Date: Fri, 5 Apr 1996 13:02:30 -0800 (PST) Message-Id: <199604052102.NAA25847@silvia.HIP.Berkeley.EDU> To: andreas@knobel.gun.de CC: ports@freebsd.org, current@freebsd.org In-reply-to: <199604051143.NAA21078@knobel.gun.de> (message from Andreas Klemm on Fri, 5 Apr 1996 13:43:06 +0200 (MET DST)) Subject: Re: make clean should remove README.html in ports collection From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk * a) check the README.html files in into the source repository ? Yes, this is what we are eventually going to do, as I wrote on my original mail. Otherwise we'll have a chicken-and-egg problem, having to ask users to type "make readmes" before they have any idea what the hell the "ports collection" is! :) Satoshi From owner-freebsd-current Fri Apr 5 13:20:34 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA12260 for current-outgoing; Fri, 5 Apr 1996 13:20:34 -0800 (PST) Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id NAA12244 for ; Fri, 5 Apr 1996 13:20:21 -0800 (PST) Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.7.5/8.6.9) id NAA25877; Fri, 5 Apr 1996 13:19:19 -0800 (PST) Date: Fri, 5 Apr 1996 13:19:19 -0800 (PST) Message-Id: <199604052119.NAA25877@silvia.HIP.Berkeley.EDU> To: bde@zeta.org.au CC: current@FreeBSD.org, hasty@star-gate.com, nisha@cs.berkeley.edu, tege@matematik.su.se In-reply-to: <199604052055.GAA23015@godzilla.zeta.org.au> (message from Bruce Evans on Sat, 6 Apr 1996 06:55:42 +1000) Subject: Re: fast memory copy for large data sizes From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk * Oops. I put together 5 fast memory copies that don't use floating point * registers. Speeds range from 40K/sec to 340K/sec. on a 133MHz Pentium * (ASUS), Triton chipset, 512KB PB cache, 60ns non-EDO main memory. This * is after attempting to minimize the differences caused by the cache * state. Details in other mail. Cool cool. This is the kind of response I was waiting for! Oh by the way, the 133MHz Pentium system we tested has 60ns EDO memory. * The speed differences are so large and the cache state is so variable * that it is easy to create benchmarks showing that all methods are the * best :-). We seemed to have fooled ourselves with the optimized kernel :) * This seemed like a bad idea. I added a test using it (just 8 fldl's * followed by 8 fstpl's, storing in reverse order - this works for at * least all-zero data) and got good results, but I still think it is a bad * idea. Well, from the numbers below, it certainly seems faster than yours for larger sizes even if things are in the L2 cache! Note that the speed of fldls depend on the actual data. All-zero data is faster than random data (to avoid traps, try ((double *)src[i] = random())), probably because the all-zero bit pattern can be converted to floating point (ok, no conversion necesarry in this case :) in a snap. * Perhaps it can the duplicated by copying via integer registers * through the L1 cache. This is what I don't understand, people keep saying that we can do it using integer regesters but we simply can't get it to work as fast. If we can get it to work as fast as our FP copy, I won't utter "fildq" for the rest of my life, I swear! * >133MHz Pentium (sunrise), Triton chipset, 512KB (pipeline burst) cache: * * new columns * vvvvvvvvv vvvvvvvvv vvvvvvvv * > size libc ours mine-libc mine-best(int) mine-fp * > 32 N/A 30.517578 MB/s 51493147 98069887 * > 1024 40.690104 MB/s 51.398026 MB/s 85214370 379715593 ^^^^^^^^^ wow * > 16384 39.556962 MB/s 52.966102 MB/s 65103489 97472157 * > 32768 39.506953 MB/s 53.146259 MB/s 66593990 99217964 93604474 * > 65536 39.457071 MB/s 53.282182 MB/s 61407673 79866591 93721503 * > 131072 39.457071 MB/s 53.327645 MB/s 65457449 68011573 79960595 * > 262144 39.345294 MB/s 53.350405 MB/s 51273532 53702491 75576993 * > 524288 39.044198 MB/s 53.430220 MB/s 49370136 50029142 67400433 * > 1048576 38.086533 MB/s 53.447354 MB/s 44054746 44095308 58624791 * > 2097152 37.706680 MB/s 53.387433 MB/s 42742240 42770154 56946700 * > 4194304 37.628643 MB/s 53.280763 MB/s 43381238 43381238 57727588 * My tests are obviously not equivalent for small copies - the libc * times are about twice as high. This is because I keep copying the * same data. I want to do this to test in-cache copies. Not-in-cache * copies get tested as a side effect when the buffer is much larger * that the cache (L1 or L2). Ok. By the way, why is your data lacking smaller sizes for your FP copy? * Your test gives similar times on my system. It tests the speed of * copying data that isn't in the cache. This seems to be the usual Yeah, lmbench's mem_cp was giving me ungodly numbers for small-sized copies until I realized that it's copying the same things over and over. Since we were interested in optimizing filesystem troughput (large sequentian read/writes), that wasn't what we wanted, and I changed it to walk through a larger buffer. * Only if traps are enabled. Rounding may be a problem. : * Useing 64-bit precision may be enough to avoid rounding problems. * fldl is much faster than fildl if the data is in the cache. Well, we tried disabling the traps too, and got our data mangled. ;) * >Please type "make" and it will compile & run the tests. The output * * It didn't :-). It assumes that "." is in the $PATH. Duuh, sorry. Next time I send out a test script, I'll make sure to put "./" in front of all our programs! Satoshi From owner-freebsd-current Fri Apr 5 13:41:31 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA13988 for current-outgoing; Fri, 5 Apr 1996 13:41:31 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA13955 for ; Fri, 5 Apr 1996 13:41:26 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id HAA24517; Sat, 6 Apr 1996 07:39:27 +1000 Date: Sat, 6 Apr 1996 07:39:27 +1000 From: Bruce Evans Message-Id: <199604052139.HAA24517@godzilla.zeta.org.au> To: bde@zeta.org.au, rgrimes@GndRsh.aac.dev.com Subject: Re: tty-level buffer overflows - what to do? Cc: current@freebsd.org, jgreco@brasil.moneng.mei.com, nate@sri.MT.net, root@deadline.snafu.de Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> No, the IRR isn't set. Only the ESL remembers the IRQ state, and >> it isn't active because there's no INTA. >Like I said bruce if there ain't no INTA this whole discussion is >pointless! FreeBSD has DIED if INTA does not occur at some time. INTA occurs when all the conditions for it are satisfied: 1) the edge sensitive latch isn't set. 2) there is at least one active unmasked IRQ. 3) cpu interrupts are enabled. >Simple fact of the mater is if someone asserts an IRx signal, then removes >that signal before an INTA cycle completes with 8259 will signal this as >an IRQ7 interrupt. Don't tell me again that INTA is not going to occur, >because if it is not going to occur FreeBSD has stopped running.... I'll tell you again. Try this lkm. The clock IRQ goes up and down several and isn't latched. There may be an INTA one instruction after interrupts are reenabled, but only if condition (2) is satisfied (it depends where the clock duty cycle is; IRQ0 is certainly unmasked). No IRQ7's are generated. This is easier to test in square wave mode. Then inb(0x20) & 1 is on precisely half the time. Bruce --- Makefile: --- BINDIR= /tmp SRCS= mycall.c KMOD= newsyscall_mod NOMAN= none CLEANFILES+= ${KMOD} .include --- mycall.c --- #include #include #include #include #include static int mycall(struct proc *p, void *uap, int *retval); static struct sysent newent = { 0, mycall, }; MOD_SYSCALL("newsyscall_mod", -1, &newent); extern int newsyscall_mod(struct lkm_table *lkmtp, int cmd, int ver); int newsyscall_mod(struct lkm_table *lkmtp, int cmd, int ver) { DISPATCH(lkmtp, cmd, ver, lkm_nullcmd, lkm_nullcmd, lkm_nullcmd) } static int mycall(struct proc *p, void *uap, int *retval) { int i; disable_intr(); /* Wait about 50-100 msec (lose 5-10 clock ticks). */ for (i = 0; i < 100 * 1000; i++) inb(0x20); enable_intr(); return 0; } --- From owner-freebsd-current Fri Apr 5 14:02:18 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA15438 for current-outgoing; Fri, 5 Apr 1996 14:02:18 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA15430 for ; Fri, 5 Apr 1996 14:02:12 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id HAA25295; Sat, 6 Apr 1996 07:57:31 +1000 Date: Sat, 6 Apr 1996 07:57:31 +1000 From: Bruce Evans Message-Id: <199604052157.HAA25295@godzilla.zeta.org.au> To: asami@cs.berkeley.edu, bde@zeta.org.au Subject: Re: fast memory copy for large data sizes Cc: current@FreeBSD.org, hasty@star-gate.com, nisha@cs.berkeley.edu, tege@matematik.su.se Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > * This seemed like a bad idea. I added a test using it (just 8 fldl's > * followed by 8 fstpl's, storing in reverse order - this works for at > * least all-zero data) and got good results, but I still think it is a bad > * idea. >Well, from the numbers below, it certainly seems faster than yours for >larger sizes even if things are in the L2 cache! They aren't in the L2 cache (256K is a tie and yours are faster for 512K but 2*512K isn't in the cache). I get similar results with fildl. Now trying reading and pushing then popping and writing 32 bytes at a time. This might work better if there were more registers so the stack doesn't have to have to be used. However, the stack is very fast if it's in the L1 cache (I get 800 MB/s read and 750 MB/s write). >Note that the speed of fldls depend on the actual data. All-zero data >is faster than random data (to avoid traps, try ((double *)src[i] = >random())), probably because the all-zero bit pattern can be converted >to floating point (ok, no conversion necesarry in this case :) in a >snap. Have you tried using fldt? No conversion for that. >Ok. By the way, why is your data lacking smaller sizes for your FP >copy? I didn't run them all and they weren't interesting (nowhere near 350K/s). Bruce From owner-freebsd-current Fri Apr 5 14:14:55 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA16288 for current-outgoing; Fri, 5 Apr 1996 14:14:55 -0800 (PST) Received: from sunrise.cs.berkeley.edu (sunrise.CS.Berkeley.EDU [128.32.38.121]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA16282 for ; Fri, 5 Apr 1996 14:14:52 -0800 (PST) Received: (from asami@localhost) by sunrise.cs.berkeley.edu (8.6.12/8.6.12) id OAA08351; Fri, 5 Apr 1996 14:15:32 -0800 Date: Fri, 5 Apr 1996 14:15:32 -0800 Message-Id: <199604052215.OAA08351@sunrise.cs.berkeley.edu> To: bde@zeta.org.au CC: bde@zeta.org.au, current@FreeBSD.org, hasty@star-gate.com, nisha@cs.berkeley.edu, tege@matematik.su.se In-reply-to: <199604052157.HAA25295@godzilla.zeta.org.au> (message from Bruce Evans on Sat, 6 Apr 1996 07:57:31 +1000) Subject: Re: fast memory copy for large data sizes From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk * >Well, from the numbers below, it certainly seems faster than yours for * >larger sizes even if things are in the L2 cache! * * They aren't in the L2 cache (256K is a tie and yours are faster for 512K * but 2*512K isn't in the cache). I was commenting on the two rightmost columns, the "it" was your version of FP copy. (You can't compare your int copy and our original FP numbers, because we always started with everything out of the cache! ;) * I get similar results with fildl. Now * trying reading and pushing then popping and writing 32 bytes at a time. * This might work better if there were more registers so the stack doesn't * have to have to be used. Can you elaborate? Can I use FP registers without using the stack? I thought all the FP registers are in the stack! * However, the stack is very fast if it's in the * L1 cache (I get 800 MB/s read and 750 MB/s write). Wow. * Have you tried using fldt? No conversion for that. What's fldt? My assembler doesn't know about that instruction.... * >Ok. By the way, why is your data lacking smaller sizes for your FP * >copy? * * I didn't run them all and they weren't interesting (nowhere near 350K/s). Well, it might be worthwhile to put them side by side and see how they compare. By the way, may we have a copy of your routine? Is it beerware? :) Satoshi From owner-freebsd-current Fri Apr 5 14:36:06 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA18076 for current-outgoing; Fri, 5 Apr 1996 14:36:06 -0800 (PST) Received: from ki.net (root@ki.net [205.150.102.1]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id OAA17961 for ; Fri, 5 Apr 1996 14:35:58 -0800 (PST) Received: from freebsd.ki.net (root@freebsd.ki.net [205.150.102.2]) by ki.net (8.7.4/8.7.4) with ESMTP id RAA06516 for ; Fri, 5 Apr 1996 17:36:22 -0500 (EST) Received: from localhost (scrappy@localhost) by freebsd.ki.net (8.7.5/8.7.5) with SMTP id RAA00886 for ; Fri, 5 Apr 1996 17:36:48 -0500 (EST) X-Authentication-Warning: freebsd.ki.net: scrappy owned process doing -bs Date: Fri, 5 Apr 1996 17:36:48 -0500 (EST) From: "Marc G. Fournier" To: current@freebsd.org Subject: panic: rlist_free: free end overlaps already freed area Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This problem report relates to a panic I experienced this afternoon while shutting down the system in order to install a new kernel. ----[ CUT HERE ]---- SEND-PR: -*- send-pr -*- SEND-PR: Lines starting with `SEND-PR' will be removed automatically, as SEND-PR: will all comments (text enclosed in `<' and `>'). SEND-PR: SEND-PR: Please consult the send-pr man page `send-pr(1)' or the Texinfo SEND-PR: manual if you are not sure how to fill out a problem report. SEND-PR: SEND-PR: Choose from the following categories: SEND-PR: SEND-PR: bin conf docs gnu i386 kern misc ports SEND-PR: To: FreeBSD-gnats-submit@freebsd.org Subject: From: scrappy Reply-To: scrappy X-send-pr-version: 3.2 >Submitter-Id: current-users >Originator: Marc G. Fournier >Organization: >Confidential: no >Synopsis: panic: rlist_free: free end overlaps already freed area >Severity: critical >Priority: high >Category: kern >Release: FreeBSD 2.2-CURRENT i386 >Class: sw-bug >Environment: FreeBSD 2.2-CURRENT #35: Tue Apr 2 01:38:50 EST 1996 scrappy@freebsd.ki.net:/usr/src/sys/compile/freebsd CPU: i486DX (486-class CPU) real memory = 16777216 (16384K bytes) avail memory = 14716928 (14372K bytes) DEVFS: ready for devices Probing for devices on the ISA bus: vt0 at 0x60-0x6f irq 1 on motherboard vt0: mda, mono, 8 scr, mf2-kbd, [R3.20-b24] ed0 at 0x280-0x29f irq 5 maddr 0xd8000 msize 16384 on isa ed0: address 00:00:c0:b7:91:71, type WD8013EPC (16 bit) aha0 at 0x330-0x333 irq 11 drq 5 on isa (aha0:0:0): "UNISYS U0531 ST3600N 8374" type 0 fixed SCSI 2 sd0(aha0:0:0): Direct-Access 500MB (1025920 512 byte sectors) (aha0:3:0): "CONNER CFA540S 13B0" type 0 fixed SCSI 2 sd1(aha0:3:0): Direct-Access 515MB (1056708 512 byte sectors) 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 sctarg0(noadapter::): Processor Target devfs ready to run >Description: After 2days, 16hrs uptime, in order to install a new -current kernel, I typed 'reboot' as root at the prompt, at which point she panic'd (I swear, i was being gentle with her *grin*) I *think* I'm getting the hang of gdb, but if I'm missing some data that I could have gotten out of gdb, please let me know and I'll add that in :) DDB Output: panic: rlist_free: free end overlaps already freed area rlist_free+0x9d swap_pager_freeswapspace+0x1b swap_pager_free_swap+0xbb swap_pager_dealloc+0x9c vm_pager_deallocate+0x16 vm_object_terminate+0x13b vm_object_deallocate+0x1a3 vm_map_entry_delete+0x50 vm_map_delete+0x0x13e vm_map_remove+0x60 exit1+0xc5 exit+0x14 syscall+0x129 Xsyscall+0x35 --- syscall 1, eip = 0x8159a5d, ebp = 0xefbfdb40 --- GDB Output: Script started on Fri Apr 5 17:24:24 1996 gdbfreebsd# gdb -k /usr/debug/kernel-sym.35 vmcore.5 GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.13 (i386-unknown-freebsd), Copyright 1994 Free Software Foundation, Inc... IdlePTD 20d000 current pcb at 1dabc8 panic: rlist_free: free end overlaps already freed area #0 boot (howto=260) at ../../i386/i386/machdep.c:942 Source file is more recent than executable. 942 dumppcb.pcb_ptd = rcr3(); (kgdb) where #0 boot (howto=260) at ../../i386/i386/machdep.c:942 #1 0xf0113727 in panic (fmt=0xf01011f8 "from debugger") at ../../kern/subr_prf.c:133 #2 0xf0101215 in db_panic (dummy1=-266739549, dummy2=0, dummy3=-1, dummy4=0xefbffcb0 "") at ../../ddb/db_command.c:395 #3 0xf01010fe in db_command (last_cmdp=0xf01cab34, cmd_table=0xf01ca994) at ../../ddb/db_command.c:288 #4 0xf010127d in db_command_loop () at ../../ddb/db_command.c:417 #5 0xf01035e8 in db_trap (type=3, code=0) at ../../ddb/db_trap.c:73 #6 0xf019de7a in kdb_trap (type=3, code=0, regs=0xefbffdac) at ../../i386/i386/db_interface.c:136 #7 0xf01a59ec in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = -191131724, tf_esi = -267302978, tf_ebp = -272630288, tf_isp = -272630316, tf_ebx = 256, tf_edx = -266739595, tf_ecx = 1920, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -266739549, tf_cs = -272695288, tf_eflags = 582, tf_esp = -266739611, tf_ss = -267307330}) at ../../i386/i386/trap.c:399 #8 0xf019e6f1 in calltrap () #9 0xf011371e in panic ( fmt=0xf01147be "rlist_free: free end overlaps already freed area") at ../../kern/subr_prf.c:129 #10 0xf0114901 in rlist_free (rlh=0xf01e5ed0, start=8912, end=8935) at ../../kern/subr_rlist.c:157 #11 0xf018bf77 in swap_pager_freeswapspace (object=0xf0935880, from=8912, to=8935) at ../../vm/swap_pager.c:408 #12 0xf018c167 in swap_pager_free_swap (object=0xf0935880) at ../../vm/swap_pager.c:485 #13 0xf018c6b8 in swap_pager_dealloc (object=0xf0935880) at ../../vm/swap_pager.c:721 #14 0xf019861a in vm_pager_deallocate (object=0xf0935880) at ../../vm/vm_pager.c:178 #15 0xf01942b7 in vm_object_terminate (object=0xf0935880) at ../../vm/vm_object.c:416 #16 0xf019410b in vm_object_deallocate (object=0xf0935880) at ../../vm/vm_object.c:356 #17 0xf019227c in vm_map_entry_delete (map=0xf0937300, entry=0xf0924740) at ../../vm/vm_map.c:1620 #18 0xf01923ce in vm_map_delete (map=0xf0937300, start=0, end=4022329344) at ../../vm/vm_map.c:1715 #19 0xf019244c in vm_map_remove (map=0xf0937300, start=0, end=4022329344) at ../../vm/vm_map.c:1740 #20 0xf0108c89 in exit1 (p=0xf0937400, rv=0) at ../../kern/kern_exit.c:161 #21 0xf0108b84 in exit (p=0xf0937400, uap=0xefbfff94, retval=0xefbfff84) at ../../kern/kern_exit.c:97 #22 0xf01a646d in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = 0, tf_esi = -1, tf_ebp = -272639168, tf_isp = -272629788, tf_ebx = 135680096, tf_edx = 0, tf_ecx = 1, tf_eax = 1, tf_trapno = 7, tf_err = 7, tf_eip = 135633501, tf_cs = 31, tf_eflags = 658, tf_esp = -272639188, tf_ss = 39}) at ../../i386/i386/trap.c:904 ---Type to continue, or q to quit---qQuit (kgdb) up 10 #10 0xf0114901 in rlist_free (rlh=0xf01e5ed0, start=8912, end=8935) at ../../kern/subr_rlist.c:157 157 panic("rlist_free: free end overlaps already freed area"); (kgdb) list 152 } 153 154 if (cur_rlp != NULL) { 155 156 if (end >= cur_rlp->rl_start) 157 panic("rlist_free: free end overlaps already freed area"); 158 159 if (prev_rlp) { 160 if (start <= prev_rlp->rl_end) 161 panic("rlist_free: free start overlaps already freed area"); (kgdb) print end $1 = 8935 (kgdb) print cur_rlp->rl_start $2 = 8920 (kgdb) print cur_rlp $3 = (struct rlist *) 0xf49ba450 (kgdb) print prev_rlp $4 = (struct rlist *) 0xf49b8fb4 (kgdb) print start $5 = 8912 (kgdb) print prev_rlp->rl_end $6 = 8911 (kgdb) quit freebsd# exit exit Script done on Fri Apr 5 17:25:50 1996 >How-To-Repeat: >Fix: Marc G. Fournier | POP Mail Telnet Acct DNS Hosting System | WWW Services Database Services | Knowledge, Administrator | | Information and scrappy@ki.net | WWW: http://www.ki.net | Communications, Inc From owner-freebsd-current Fri Apr 5 14:59:07 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA19449 for current-outgoing; Fri, 5 Apr 1996 14:59:07 -0800 (PST) Received: (from mpp@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA19443 for freebsd-current; Fri, 5 Apr 1996 14:59:05 -0800 (PST) From: Mike Pritchard Message-Id: <199604052259.OAA19443@freefall.freebsd.org> Subject: sup/cvs tags To: freebsd-current Date: Fri, 5 Apr 1996 14:59:05 -0800 (PST) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In the future can we try and avoid tagging the kernel source tree except at release time? The wollman_polling tag is causing anyone who sups the cvs files to receive every file in /usr/src/sys just because of the new tag. This looks to be about 33 megabytes of data, which is quite painful over a slow link. -- Mike Pritchard mpp@freebsd.org "Go that way. Really fast. If something gets in your way, turn" From owner-freebsd-current Fri Apr 5 15:02:44 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA19737 for current-outgoing; Fri, 5 Apr 1996 15:02:44 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA19728 for ; Fri, 5 Apr 1996 15:02:33 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id JAA28284; Sat, 6 Apr 1996 09:00:26 +1000 Date: Sat, 6 Apr 1996 09:00:26 +1000 From: Bruce Evans Message-Id: <199604052300.JAA28284@godzilla.zeta.org.au> To: asami@cs.berkeley.edu, bde@zeta.org.au Subject: Re: fast memory copy for large data sizes Cc: current@freebsd.org, hasty@star-gate.com, nisha@cs.berkeley.edu, tege@matematik.su.se Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > * I get similar results with fildl. Now > * trying reading and pushing then popping and writing 32 bytes at a time. > * This might work better if there were more registers so the stack doesn't > * have to have to be used. >Can you elaborate? Can I use FP registers without using the stack? I >thought all the FP registers are in the stack! The FP registers are just registers organized as a stack for inconvenient access. I'm trying the usual stack. > * Have you tried using fldt? No conversion for that. >What's fldt? My assembler doesn't know about that instruction.... fld a ten-byte (80 bit) number. Gas knows about it. >By the way, may we have a copy of your routine? Is it beerware? :) Throwawayare. Here is the current version. The output file in it doesn't cover some new functions. The copy6 function (through the stack) is very poor. A version of it with less unrolling was only slightly slower than libc. Bruce --- I cleaned up my write and read memory bandwidth brenchmarks and added i586 optimizations and copy benchmarks. The zero[12] and read[12] benchmarks are more or less compatible with the old benchmarks. (The initialization for the old benchmarks was sloppy. Use the -p flag to almost duplicate it.) The times are for a P133 on an ASUS P55TP4XE rev.2.4 with a 512KB PB cache and 32MB 60ns non-EDO RAM with all the memory timings reduced to the minimums supported by the BIOS setup. getrusage() is used in the hope of getting more accurate times but perhaps the real times were more relevant. E.g., the 16MB copy benchmarks took "forever" to run due to swapping, but the copy speed was reported to be slightly faster than for the 8MB benchmarks. The i586 optimizations seem to be pessimizations in practice. I benchmarked the kernel's generic_bzero, i486_bzero and i586_bzero for compiling kernels and for a few thousand fork-exec's of small processes on. On the above i586 and on an i486, i486 was best and i586_bzero was worst in all cases, significantly worse for fork-exec. This is presumably because read-before-write is a pessimization if the data isn't in the L1 or L2 cache, and kernel data being bzero'ed usually isn't in the cache. Reducing the memory timings in the BIOS setup significantly reduced the pessimization to the ones shown in the output. E.g., for zeroing 2MB: 88287436 bytes/sec zero3: (now, was 87 MB/s) 68917465 bytes/sec zero4: (now, was 58 MB/s) Of course, perfect pairing isn't a pessimization and is harmless on i486's unless it involves extra nops. i586_bzero was only (:-) slightly slower when the read-before-write was replaced by a pairable read. The slowness is presumably caused by extra setup overheads or a wasted cycle for Adress Generation Interlock (AGI) in the main loop. Why is copying in the cache slightly slower than 1/2 the average speed of reading and writing? `perfmon' shows perfect pairing and no AGI for the loops in the i586-optimization benchmarks, but the tsc's and real times contain cycles (sometimes fractional cycles) that I can't account for. --- #! /bin/sh # This is a shell archive. Remove anything before this line, then unpack # it by saving it into a file and typing "sh file". To overwrite existing # files, type "sh file -c". You can also feed this as standard input via # unshar, or by typing "sh 'c.c' <<'END_OF_FILE' X#include X#include X#include X X#include X X#include X#include X#include X Xtypedef void func_t(void *dst, const void *src, size_t len); X Xstruct func X{ X func_t *fn; X char *name; X char *description; X}; X Xstatic func_t copy0, copy1, copy2, copy3, copy4, copy5, copy6, copy7; Xstatic void usage(void); X Xstatic char const *progname; X Xstatic struct func funcs[] = X{ X copy0, "copy0", "movsl", X copy1, "copy1", "unroll 16", X copy2, "copy2", "unroll 16 prefetch", X copy3, "copy3", "unroll 64 i586-opt", X copy4, "copy4", "unroll 64 i586-opt prefetch", X copy5, "copy5", "unroll 64 i586-opx prefetch", X copy6, "copy6", "unroll 64 stack", X copy7, "copy7", "unroll 64 fp", X memcpy,"copy8", "memcpy (movsl)", X}; X#define NFUNC (sizeof funcs / sizeof funcs[0]) X Xint main(int argc, char **argv) X{ X int ch; X unsigned char *dst; X int funcn; X int funcnspecified; X int i586; X size_t len; X size_t max; X int precache; X int quiet; X unsigned char *src; X size_t thrashbufsize; X unsigned long long tot; X X progname = argv[0]; X funcnspecified = -1; X i586 = 0; X len = 4096; X precache = 0; X quiet = 0; X tot = 100000000; X while ((ch = getopt(argc, argv, "5f:l:pqt:")) != EOF) X { X switch (ch) X { X case '5': X i586 = 1; X break; X case 'f': X funcnspecified = strtoul(optarg, (char **) NULL, 0); X if (funcnspecified < 0 || funcnspecified >= NFUNC) X usage(); X break; X case 'l': X len = strtoul(optarg, (char **) NULL, 0); X break; X case 'p': X precache = 1; X break; X case 'q': X quiet = 1; X break; X case 't': X tot = strtouq(optarg, (char **) NULL, 0); X break; X default: X usage(); X } X } X if (optind != argc) X usage(); X dst = malloc(len + 64); X src = malloc(len + 64); X if (dst == NULL || src == NULL) X { X fprintf(stderr, "%s: malloc failed\n", progname); X exit(1); X } X max = tot / len; X X for (funcn = 0; funcn < NFUNC; ++funcn) X { X func_t *funcp; X struct rusage finish; X size_t i; X struct rusage start; X unsigned long long tsc; X long usec; X X if (funcnspecified != -1 && funcnspecified != funcn) X continue; X X /* X * Check the function. As side effects, make sure that the buffers X * aren't a constant zero page, and leave as much of the buffers as X * possible in the cache to set up the `precache' case. X */ X memset(dst, 1, len); X memset(src, 2, len); X funcp = funcs[funcn].fn; X funcp(dst, src, len); X if (memcmp(dst, src, len) != 0) X { X fprintf(stderr, "%s: %s failed\n", progname, funcs[funcn].name); X exit(1); X } X X if (!precache) X /* X * Attempt to uncache the buffer so as to provide the same X * uncached environnment for all the functions. X */ X for (thrashbufsize = 2 * 1024 * 1024; thrashbufsize != 0; X thrashbufsize /= 2) X { X unsigned char *thrashbuf1; X unsigned char *thrashbuf2; X X thrashbuf1 = malloc(thrashbufsize); X thrashbuf2 = malloc(thrashbufsize); X if (thrashbuf1 != NULL && thrashbuf2 != NULL) X { X memcpy(thrashbuf2, thrashbuf1, thrashbufsize); X memcpy(thrashbuf1, thrashbuf2, thrashbufsize); X } X free(thrashbuf1); X free(thrashbuf2); X } X X tsc = 0; X getrusage(RUSAGE_SELF, &start); X if (i586) X tsc = rdtsc(); X for (i = 0; i < max; ++i) X funcp(dst, src, len); X if (i586) X tsc = rdtsc() - tsc; X getrusage(RUSAGE_SELF, &finish); X usec = 1000000 * (finish.ru_utime.tv_sec - start.ru_utime.tv_sec) X + finish.ru_utime.tv_usec - start.ru_utime.tv_usec; X if (usec < 0) X usec = 1; X printf("%s: %10.0f B/s", funcs[funcn].name, tot * 1e6 / usec); X if (!quiet) X { X printf(" (%7ld us)", usec); X if (i586) X printf(" (%9qd tsc)", tsc); X printf(" (%s)", funcs[funcn].description); X } X printf("\n"); X } X return 0; X} X Xstatic void copy0(void *dst, const void *src, size_t len) X{ X asm volatile(" X .align 4,0x90 X cld X shrl $2,%2 X rep; movsl" X : "=D" (dst), "=S" (src), "=c" (len) X : "0" (dst), "1" (src), "2" (len) X : "memory"); X} X Xstatic void copy1(void *dst, const void *src, size_t len) X{ X unsigned tmp; X X asm volatile(" X .align 4,0x90 X 1: X movl 0(%1),%3 X movl %3,0(%0) X movl 4(%1),%3 X movl %3,4(%0) X movl 8(%1),%3 X movl %3,8(%0) X movl 12(%1),%3 X movl %3,12(%0) X addl $16,%0 X addl $16,%1 X subl $16,%2 X ja 1b" X : "=r" (dst), "=r" (src), "=r" (len), "=&r" (tmp) X : "0" (dst), "1" (src), "2" (len) X : "memory"); X} X Xstatic void copy2(void *dst, const void *src, size_t len) X{ X unsigned prefetch; X unsigned tmp; X X asm volatile(" X .align 4,0x90 X 1: X movl 0(%0),%4 X movl 0(%1),%3 X movl %3,0(%0) X movl 4(%1),%3 X movl %3,4(%0) X movl 8(%1),%3 X movl %3,8(%0) X movl 12(%1),%3 X movl %3,12(%0) X addl $16,%0 X addl $16,%1 X subl $16,%2 X ja 1b" X : "=r" (dst), "=r" (src), "=r" (len), "=&r" (tmp), "=&r" (prefetch) X : "0" (dst), "1" (src), "2" (len) X : "memory"); X} X Xstatic void copy3(void *dst, const void *src, size_t len) X{ X unsigned tmp1; X unsigned tmp2; X X asm volatile(" X .align 4,0x90 X 1: X movl 0(%1),%3 X movl 4(%1),%4 X movl %3,0(%0) X movl %4,4(%0) X movl 8(%1),%3 X movl 12(%1),%4 X movl %3,8(%0) X movl %4,12(%0) X movl 16(%1),%3 X movl 20(%1),%4 X movl %3,16(%0) X movl %4,20(%0) X movl 24(%1),%3 X movl 28(%1),%4 X movl %3,24(%0) X movl %4,28(%0) X movl 32(%1),%3 X movl 36(%1),%4 X movl %3,32(%0) X movl %4,36(%0) X movl 40(%1),%3 X movl 44(%1),%4 X movl %3,40(%0) X movl %4,44(%0) X movl 48(%1),%3 X movl 52(%1),%4 X movl %3,48(%0) X movl %4,52(%0) X movl 56(%1),%3 X movl 60(%1),%4 X movl %3,56(%0) X movl %4,60(%0) X addl $64,%0 X addl $64,%1 X subl $64,%2 X ja 1b" X : "=r" (dst), "=r" (src), "=r" (len), "=&r" (tmp1), "=&r" (tmp2) X : "0" (dst), "1" (src), "2" (len) X : "memory"); X} X Xstatic void copy4(void *dst, const void *src, size_t len) X{ X unsigned tmp1; X unsigned tmp2; X X asm volatile(" X .align 4,0x90 X 1: X movl 0(%0),%3 X movl 36(%0),%4 X movl 0(%1),%3 X movl 4(%1),%4 X movl %3,0(%0) X movl %4,4(%0) X movl 8(%1),%3 X movl 12(%1),%4 X movl %3,8(%0) X movl %4,12(%0) X movl 16(%1),%3 X movl 20(%1),%4 X movl %3,16(%0) X movl %4,20(%0) X movl 24(%1),%3 X movl 28(%1),%4 X movl %3,24(%0) X movl %4,28(%0) X movl 32(%1),%3 X movl 36(%1),%4 X movl %3,32(%0) X movl %4,36(%0) X movl 40(%1),%3 X movl 44(%1),%4 X movl %3,40(%0) X movl %4,44(%0) X movl 48(%1),%3 X movl 52(%1),%4 X movl %3,48(%0) X movl %4,52(%0) X movl 56(%1),%3 X movl 60(%1),%4 X movl %3,56(%0) X movl %4,60(%0) X addl $64,%0 X addl $64,%1 X subl $64,%2 X ja 1b" X : "=r" (dst), "=r" (src), "=r" (len), "=&r" (tmp1), "=&r" (tmp2) X : "0" (dst), "1" (src), "2" (len) X : "memory"); X} X Xstatic void copy5(void *dst, const void *src, size_t len) X{ X void *junk; X unsigned tmp1; X unsigned tmp2; X X asm volatile(" X .align 4,0x90 X 1: X movl 0(%0),%3 X movl 36(%0),%4 X movl 0(%1),%3 X movl 4(%1),%4 X movl %3,0(%0) X movl %4,4(%0) X movl 8(%1),%3 X movl 12(%1),%4 X movl %3,8(%0) X movl %4,12(%0) X movl 16(%1),%3 X movl 20(%1),%4 X movl %3,16(%0) X movl %4,20(%0) X movl 24(%1),%3 X movl 28(%1),%4 X movl %3,24(%0) X movl %4,28(%0) X movl 32(%1),%3 X movl 36(%1),%4 X movl %3,32(%0) X movl %4,36(%0) X movl 40(%1),%3 X movl 44(%1),%4 X movl %3,40(%0) X movl %4,44(%0) X movl 48(%1),%3 X movl 52(%1),%4 X movl %3,48(%0) X movl %4,52(%0) X movl 56(%1),%3 X movl 60(%1),%4 X movl %3,56(%0) X movl %4,60(%0) X addl $64,%0 X addl $64,%1 X cmpl %2,%0 X jb 1b" X : "=r" (dst), "=r" (src), "=r" (junk), "=&r" (tmp1), "=&r" (tmp2) X : "0" (dst), "1" (src), "2" ((char *) dst + len) X : "memory"); X} X Xstatic void copy6(void *dst, const void *src, size_t len) X{ X void *junk; X unsigned tmp1; X unsigned tmp2; X unsigned tmp3; X unsigned tmp4; X X asm volatile(" X .align 4,0x90 X subl $64,%%esp X andl $0xffffff80,%%esp X 1: X movl 0(%1),%3 X movl 4(%1),%4 X movl %3,0(%%esp) X movl %4,4(%%esp) X movl 8(%1),%3 X movl 12(%1),%4 X movl %3,8(%%esp) X movl %4,12(%%esp) X movl 16(%1),%3 X movl 20(%1),%4 X movl %3,16(%%esp) X movl %4,20(%%esp) X movl 24(%1),%3 X movl 28(%1),%4 X movl %3,24(%%esp) X movl %4,28(%%esp) X movl 32(%1),%3 X movl 36(%1),%4 X movl %3,32(%%esp) X movl %4,36(%%esp) X movl 40(%1),%3 X movl 44(%1),%4 X movl %3,40(%%esp) X movl %4,44(%%esp) X movl 48(%1),%3 X movl 52(%1),%4 X movl %3,48(%%esp) X movl %4,52(%%esp) X movl 56(%1),%3 X movl 60(%1),%4 X movl %3,56(%%esp) X movl %4,60(%%esp) X movl 0(%%esp),%3 X movl 4(%%esp),%4 X movl %3,0(%0) X movl %4,4(%0) X movl 8(%%esp),%3 X movl 12(%%esp),%4 X movl %3,8(%0) X movl %4,12(%0) X movl 16(%%esp),%3 X movl 20(%%esp),%4 X movl %3,16(%0) X movl %4,20(%0) X movl 24(%%esp),%3 X movl 28(%%esp),%4 X movl %3,24(%0) X movl %4,28(%0) X movl 32(%%esp),%3 X movl 36(%%esp),%4 X movl %3,32(%0) X movl %4,36(%0) X movl 40(%%esp),%3 X movl 44(%%esp),%4 X movl %3,40(%0) X movl %4,44(%0) X movl 48(%%esp),%3 X movl 52(%%esp),%4 X movl %3,48(%0) X movl %4,52(%0) X movl 56(%%esp),%3 X movl 60(%%esp),%4 X movl %3,56(%0) X movl %4,60(%0) X addl $32,%0 X addl $32,%1 X cmpl %0,%2 X ja 1b" X : "=r" (dst), "=r" (src), "=r" (junk), "=&r" (tmp1), "=&r" (tmp2) X : "0" (dst), "1" (src), "2" ((char *) dst + len) X : "memory"); X} X Xstatic void copy7(void *dst, const void *src, size_t len) X{ X void *junk; X X asm volatile(" X .align 4,0x90 X 1: X fildq 0(%1) X fildq 8(%1) X fildq 16(%1) X fildq 24(%1) X fildq 32(%1) X fildq 40(%1) X fildq 48(%1) X fildq 56(%1) X fistpq 56(%0) X fistpq 48(%0) X fistpq 40(%0) X fistpq 32(%0) X fistpq 24(%0) X fistpq 16(%0) X fistpq 8(%0) X fistpq 0(%0) X addl $64,%0 X addl $64,%1 X cmpl %0,%2 X ja 1b" X : "=r" (dst), "=r" (src), "=r" (junk) X : "0" (dst), "1" (src), "2" ((char *) dst + len) X : "memory"); X} Xstatic void usage(void) X{ X fprintf(stderr, "%s: [-5cpq] [-f function] [-l length] [-t tot]\n", X progname); X exit(1); X} END_OF_FILE if test 9577 -ne `wc -c <'c.c'`; then echo shar: \"'c.c'\" unpacked with wrong size! fi # end of 'c.c' fi if test -f 'r.c' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'r.c'\" else echo shar: Extracting \"'r.c'\" \(5120 characters\) sed "s/^X//" >'r.c' <<'END_OF_FILE' X#include X#include X#include X X#include X X#include X#include X#include X Xtypedef void func_t(const void *buf, size_t len); X Xstruct func X{ X func_t *fn; X char *name; X char *description; X}; X Xstatic func_t read0, read1, read2, read3, read4; Xstatic void usage(void); X Xstatic char const *progname; X Xstatic struct func funcs[] = X{ X read0, "read0", "lodsl", X read1, "read1", "unroll 16", X read2, "read2", "unroll 16 prefetch", X read3, "read3", "unroll 32 i586-opt", X read4, "read4", "unroll 64 i586-opt", X}; X#define NFUNC (sizeof funcs / sizeof funcs[0]) X Xint main(int argc, char **argv) X{ X unsigned char *buf; X int ch; X int funcn; X int funcnspecified; X int i586; X size_t len; X size_t max; X int precache; X int quiet; X size_t thrashbufsize; X unsigned long long tot; X X progname = argv[0]; X funcnspecified = -1; X i586 = 0; X len = 4096; X precache = 0; X quiet = 0; X tot = 100000000; X while ((ch = getopt(argc, argv, "5f:l:pqt:")) != EOF) X { X switch (ch) X { X case '5': X i586 = 1; X break; X case 'f': X funcnspecified = strtoul(optarg, (char **) NULL, 0); X if (funcnspecified < 0 || funcnspecified >= NFUNC) X usage(); X break; X case 'l': X len = strtoul(optarg, (char **) NULL, 0); X break; X case 'p': X precache = 1; X break; X case 'q': X quiet = 1; X break; X case 't': X tot = strtouq(optarg, (char **) NULL, 0); X break; X default: X usage(); X } X } X if (optind != argc) X usage(); X buf = malloc(len + 64); X if (buf == NULL) X { X fprintf(stderr, "%s: malloc failed\n", progname); X exit(1); X } X max = tot / len; X X for (funcn = 0; funcn < NFUNC; ++funcn) X { X func_t *funcp; X struct rusage finish; X size_t i; X struct rusage start; X unsigned long long tsc; X long usec; X X if (funcnspecified != -1 && funcnspecified != funcn) X continue; X X /* X * Make sure that the buffer isn't a constant zero page, and leave X * as much of the buffer as possible in the cache to set up the X * `precache' case. X */ X memset(buf, 1, len); X funcp = funcs[funcn].fn; X funcp(buf, len); X X if (!precache) X /* X * Attempt to uncache the buffer so as to provide the same X * uncached environnment for all the functions. X */ X for (thrashbufsize = 2 * 1024 * 1024; thrashbufsize != 0; X thrashbufsize /= 2) X { X unsigned char *thrashbuf1; X unsigned char *thrashbuf2; X X thrashbuf1 = malloc(thrashbufsize); X thrashbuf2 = malloc(thrashbufsize); X if (thrashbuf1 != NULL && thrashbuf2 != NULL) X { X memcpy(thrashbuf2, thrashbuf1, thrashbufsize); X memcpy(thrashbuf1, thrashbuf2, thrashbufsize); X } X free(thrashbuf1); X free(thrashbuf2); X } X X tsc = 0; X getrusage(RUSAGE_SELF, &start); X if (i586) X tsc = rdtsc(); X for (i = 0; i < max; ++i) X funcp(buf, len); X if (i586) X tsc = rdtsc() - tsc; X getrusage(RUSAGE_SELF, &finish); X usec = 1000000 * (finish.ru_utime.tv_sec - start.ru_utime.tv_sec) X + finish.ru_utime.tv_usec - start.ru_utime.tv_usec; X if (usec < 0) X usec = 1; X printf("%s: %10.0f B/s", funcs[funcn].name, tot * 1e6 / usec); X if (!quiet) X { X printf(" (%7ld us)", usec); X if (i586) X printf(" (%9qd tsc)", tsc); X printf(" (%s)", funcs[funcn].description); X } X printf("\n"); X } X return 0; X} X Xstatic void read0(const void *buf, size_t len) X{ X asm volatile(" X .align 4,0x90 X cld X shrl $2,%1 X rep; lodsl" X : "=S" (buf), "=c" (len) X : "0" (buf), "1" (len)); X} X Xstatic void read1(const void *buf, size_t len) X{ X unsigned junk; X X asm volatile(" X .align 4,0x90 X 1: X movl 0(%0),%2 X movl 4(%0),%2 X movl 8(%0),%2 X movl 12(%0),%2 X addl $16,%0 X subl $16,%1 X ja 1b" X : "=r" (buf), "=r" (len), "=&r" (junk) X : "0" (buf), "1" (len)); X} X Xstatic void read2(const void *buf, size_t len) X{ X unsigned junk; X X asm volatile(" X .align 4,0x90 X 1: X movl 0(%0),%2 X movl 4(%0),%2 X movl 8(%0),%2 X movl 16(%0),%2 X movl 12(%0),%2 X addl $16,%0 X subl $16,%1 X ja 1b" X : "=r" (buf), "=r" (len), "=&r" (junk) X : "0" (buf), "1" (len)); X} X Xstatic void read3(const void *buf, size_t len) X{ X unsigned junk1; X unsigned junk2; X X asm volatile(" X .align 4,0x90 X 1: X movl 0(%0),%1 X movl 4(%0),%2 X movl 8(%0),%1 X movl 12(%0),%2 X movl 16(%0),%1 X movl 20(%0),%2 X movl 24(%0),%1 X movl 28(%0),%2 X addl $32,%0 X cmpl %4,%0 X jb 1b" X : "=r" (buf), "=&r" (junk1), "=&r" (junk2) X : "0" (buf), "r" ((char *) buf + len)); X} X Xstatic void read4(const void *buf, size_t len) X{ X unsigned junk1; X unsigned junk2; X X asm volatile(" X .align 4,0x90 X 1: X movl 0(%0),%1 X movl 4(%0),%2 X movl 8(%0),%1 X movl 12(%0),%2 X movl 16(%0),%1 X movl 20(%0),%2 X movl 24(%0),%1 X movl 28(%0),%2 X movl 32(%0),%2 X movl 36(%0),%1 X movl 40(%0),%2 X movl 44(%0),%1 X movl 48(%0),%2 X movl 52(%0),%2 X movl 56(%0),%1 X movl 60(%0),%2 X addl $64,%0 X cmpl %4,%0 X jb 1b" X : "=r" (buf), "=&r" (junk1), "=&r" (junk2) X : "0" (buf), "r" ((char *) buf + len)); X} X Xstatic void usage(void) X{ X fprintf(stderr, "%s: [-5cpq] [-f function] [-l length] [-t tot]\n", X progname); X exit(1); X} END_OF_FILE if test 5120 -ne `wc -c <'r.c'`; then echo shar: \"'r.c'\" unpacked with wrong size! fi # end of 'r.c' fi if test -f 'w.c' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'w.c'\" else echo shar: Extracting \"'w.c'\" \(6940 characters\) sed "s/^X//" >'w.c' <<'END_OF_FILE' X#include X#include X#include X X#include X X#include X#include X#include X Xtypedef void func_t(void *buf, size_t len); X Xstruct func X{ X func_t *fn; X char *name; X char *description; X}; X Xstatic func_t zero0, zero1, zero2, zero3, zero4, zero5; Xstatic void usage(void); X Xstatic char const *progname; X Xstatic struct func funcs[] = X{ X zero0, "zero0", "stosl", X zero1, "zero1", "unroll 16", X zero2, "zero2", "unroll 16 prefetch", X zero3, "zero3", "unroll 64 i586-opt", X zero4, "zero4", "unroll 64 i586-opt prefetch", X zero5, "zero5", "unroll 64 i586-opx prefetch", X bzero, "zero6", "bzero (stosl)", X}; X#define NFUNC (sizeof funcs / sizeof funcs[0]) X Xint main(int argc, char **argv) X{ X unsigned char *buf; X int ch; X int funcn; X int funcnspecified; X int i586; X size_t len; X size_t max; X int precache; X int quiet; X size_t thrashbufsize; X unsigned long long tot; X X progname = argv[0]; X funcnspecified = -1; X i586 = 0; X len = 4096; X precache = 0; X quiet = 0; X tot = 100000000; X while ((ch = getopt(argc, argv, "5f:l:pqt:")) != EOF) X { X switch (ch) X { X case '5': X i586 = 1; X break; X case 'f': X funcnspecified = strtoul(optarg, (char **) NULL, 0); X if (funcnspecified < 0 || funcnspecified >= NFUNC) X usage(); X break; X case 'l': X len = strtoul(optarg, (char **) NULL, 0); X break; X case 'p': X precache = 1; X break; X case 'q': X quiet = 1; X break; X case 't': X tot = strtouq(optarg, (char **) NULL, 0); X break; X default: X usage(); X } X } X if (optind != argc) X usage(); X buf = malloc(len + 64); X if (buf == NULL) X { X fprintf(stderr, "%s: malloc failed\n", progname); X exit(1); X } X max = tot / len; X X for (funcn = 0; funcn < NFUNC; ++funcn) X { X func_t *funcp; X struct rusage finish; X size_t i; X struct rusage start; X unsigned long long tsc; X long usec; X X if (funcnspecified != -1 && funcnspecified != funcn) X continue; X X /* X * Check the function. As side effects, make sure that the buffer X * isn't a constant zero page, and leave as much of the buffer as X * possible in the cache to set up the `precache' case. X */ X memset(buf, 1, len); X funcp = funcs[funcn].fn; X funcp(buf, len); X for (i = 0; i < len; ++i) X if (buf[i] != '\0') X { X fprintf(stderr, "%s: %s failed\n", progname, funcs[funcn].name); X exit(1); X } X X if (!precache) X /* X * Attempt to uncache the buffer so as to provide the same X * uncached environnment for all the functions. X */ X for (thrashbufsize = 2 * 1024 * 1024; thrashbufsize != 0; X thrashbufsize /= 2) X { X unsigned char *thrashbuf1; X unsigned char *thrashbuf2; X X thrashbuf1 = malloc(thrashbufsize); X thrashbuf2 = malloc(thrashbufsize); X if (thrashbuf1 != NULL && thrashbuf2 != NULL) X { X memcpy(thrashbuf2, thrashbuf1, thrashbufsize); X memcpy(thrashbuf1, thrashbuf2, thrashbufsize); X } X free(thrashbuf1); X free(thrashbuf2); X } X X tsc = 0; X getrusage(RUSAGE_SELF, &start); X if (i586) X tsc = rdtsc(); X for (i = 0; i < max; ++i) X funcp(buf, len); X if (i586) X tsc = rdtsc() - tsc; X getrusage(RUSAGE_SELF, &finish); X usec = 1000000 * (finish.ru_utime.tv_sec - start.ru_utime.tv_sec) X + finish.ru_utime.tv_usec - start.ru_utime.tv_usec; X if (usec < 0) X usec = 1; X printf("%s: %10.0f B/s", funcs[funcn].name, tot * 1e6 / usec); X if (!quiet) X { X printf(" (%7ld us)", usec); X if (i586) X printf(" (%9qd tsc)", tsc); X printf(" (%s)", funcs[funcn].description); X } X printf("\n"); X } X return 0; X} X Xstatic void zero0(void *buf, size_t len) X{ X asm volatile(" X .align 4,0x90 X cld X shrl $2,%1 X rep; stosl" X : "=D" (buf), "=c" (len) X : "0" (buf), "1" (len), "a" (0) X : "memory"); X} X Xstatic void zero1(void *buf, size_t len) X{ X asm volatile(" X .align 4,0x90 X 1: X movl %4,0(%0) X movl %4,4(%0) X movl %4,8(%0) X movl %4,12(%0) X addl $16,%0 X subl $16,%1 X ja 1b" X : "=r" (buf), "=r" (len) X : "0" (buf), "1" (len), "r" (0) X : "memory"); X} X Xstatic void zero2(void *buf, size_t len) X{ X unsigned prefetch; X X asm volatile(" X .align 4,0x90 X 1: X movl (%0),%2 X movl %5,0(%0) X movl %5,4(%0) X movl %5,8(%0) X movl %5,12(%0) X addl $16,%0 X subl $16,%1 X ja 1b" X : "=r" (buf), "=r" (len), "=&r" (prefetch) X : "0" (buf), "1" (len), "r" (0) X : "memory"); X} X Xstatic void zero3(void *buf, size_t len) X{ X asm volatile(" X .align 4,0x90 X 1: X movl %3,0(%0) X movl %3,4(%0) X movl %3,8(%0) X movl %3,12(%0) X movl %3,16(%0) X movl %3,20(%0) X movl %3,24(%0) X movl %3,28(%0) X movl %3,32(%0) X movl %3,36(%0) X movl %3,40(%0) X movl %3,44(%0) X movl %3,48(%0) X movl %3,52(%0) X movl %3,56(%0) X movl %3,60(%0) X addl $64,%0 X cmpl %2,%0 X jb 1b" X : "=r" (buf) X : "0" (buf), "r" ((char *) buf + len), "r" (0) X : "memory"); X} X Xstatic void zero4(void *buf, size_t len) X{ X void *buf2; X unsigned prefetch; X X /* X * The main loop has 11 pairs of i586 instructions with no AGI so that X * it takes 11 cycles on i586's if all the data is in the L1 cache. X * X * On an ASUS P55TP4XE P133 the speeds are approx: X * data in L1 cache: 740,000,000 B/s X * data in L2 cache only: 90,000,000 B/s (highly variant) X * data not in any cache: 60,000,000 B/s X * and without prefetching (function zero3) they are: X * data in L1 cache: 87,000,000 B/s X * data in L2 cache only: 87,000,000 B/s X * data not in any cache: 90,000,000 B/s X * X * Thus the intruction selection and ordering optimizations have an X * insignificant effect if the data isn't in the L1 cache or the L2 X * cache, and prefetching is a pessimization if the data isn't in the X * L2 cache. X */ X asm volatile(" X .align 4,0x90 X 1: X movl (%0),%3 X leal 32(%0),%2 X movl %6,0(%0) X movl %6,4(%0) X movl %6,8(%0) X movl %6,12(%0) X movl %6,16(%0) X movl %6,20(%0) X movl %6,24(%0) X movl %6,28(%0) X movl (%2),%3 X addl $64,%0 X movl %6,0(%2) X movl %6,4(%2) X movl %6,8(%2) X movl %6,12(%2) X movl %6,16(%2) X movl %6,20(%2) X movl %6,24(%2) X movl %6,28(%2) X subl $64,%1 X ja 1b" X : "=r" (buf), "=r" (len), "=&r" (buf2), "=&r" (prefetch) X : "0" (buf), "1" (len), "r" (0) X : "memory"); X} X Xstatic void zero5(void *buf, size_t len) X{ X void *buf2; X unsigned prefetch; X X asm volatile(" X .align 4,0x90 X 1: X movl (%0),%2 X leal 32(%0),%1 X movl %5,0(%0) X movl %5,4(%0) X movl %5,8(%0) X movl %5,12(%0) X movl %5,16(%0) X movl %5,20(%0) X movl %5,24(%0) X movl %5,28(%0) X movl (%1),%2 X addl $64,%0 X movl %5,0(%1) X movl %5,4(%1) X movl %5,8(%1) X movl %5,12(%1) X movl %5,16(%1) X movl %5,20(%1) X movl %5,24(%1) X movl %5,28(%1) X cmpl %4,%0 X jb 1b" X : "=r" (buf), "=&r" (buf2), "=&r" (prefetch) X : "0" (buf), "r" ((char *) buf + len), "r" (0) X : "memory"); X} X Xstatic void usage(void) X{ X fprintf(stderr, "%s: [-5cpq] [-f function] [-l length] [-t tot]\n", X progname); X exit(1); X} END_OF_FILE if test 6940 -ne `wc -c <'w.c'`; then echo shar: \"'w.c'\" unpacked with wrong size! fi # end of 'w.c' fi if test -f 'wrc' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'wrc'\" else echo shar: Extracting \"'wrc'\" \(479 characters\) sed "s/^X//" >'wrc' <<'END_OF_FILE' Xi=1024 Xwhile : Xdo X for b in 0 1 2 3 4 5 6 X do X (echo -n $i' '; ./w -f $b -l $i -q) | X awk '{ printf("%8s: %10.0f bytes/sec %s\n", $1, $3, $2) }' X done X for b in 0 1 2 3 4 X do X (echo -n $i' '; ./r -f $b -l $i -q) | X awk '{ printf("%8s: %10.0f bytes/sec %s\n", $1, $3, $2) }' X done X for b in 0 1 2 3 4 5 6 7 8 X do X (echo -n $i' '; ./c -f $b -l $i -q) | X awk '{ printf("%8s: %10.0f bytes/sec %s\n", $1, $3, $2) }' X done X i=`expr $i + $i` Xdone END_OF_FILE if test 479 -ne `wc -c <'wrc'`; then echo shar: \"'wrc'\" unpacked with wrong size! fi # end of 'wrc' fi if test -f 'wrc.out' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'wrc.out'\" else echo shar: Extracting \"'wrc.out'\" \(9576 characters\) sed "s/^X//" >'wrc.out' <<'END_OF_FILE' X 1024: 86444769 bytes/sec zero0: X 1024: 87023795 bytes/sec zero1: X 1024: 383464990 bytes/sec zero2: X 1024: 87020993 bytes/sec zero3: X 1024: 638255775 bytes/sec zero4: X 1024: 638528830 bytes/sec zero5: X 1024: 168742196 bytes/sec read0: X 1024: 385585280 bytes/sec read1: X 1024: 326719443 bytes/sec read2: X 1024: 605462483 bytes/sec read3: X 1024: 716404224 bytes/sec read4: X 1024: 86265646 bytes/sec copy0: X 1024: 86545993 bytes/sec copy1: X 1024: 248412643 bytes/sec copy2: X 1024: 86715829 bytes/sec copy3: X 1024: 403417755 bytes/sec copy4: X 1024: 398523868 bytes/sec copy5: X 2048: 86907853 bytes/sec zero0: X 2048: 87022129 bytes/sec zero1: X 2048: 399996800 bytes/sec zero2: X 2048: 86737491 bytes/sec zero3: X 2048: 705024711 bytes/sec zero4: X 2048: 690197811 bytes/sec zero5: X 2048: 172957117 bytes/sec read0: X 2048: 408336600 bytes/sec read1: X 2048: 338657022 bytes/sec read2: X 2048: 647240812 bytes/sec read3: X 2048: 787730313 bytes/sec read4: X 2048: 87124710 bytes/sec copy0: X 2048: 87003428 bytes/sec copy1: X 2048: 215849389 bytes/sec copy2: X 2048: 86859692 bytes/sec copy3: X 2048: 344827586 bytes/sec copy4: X 2048: 340708537 bytes/sec copy5: X 4096: 86660970 bytes/sec zero0: X 4096: 86803822 bytes/sec zero1: X 4096: 413086583 bytes/sec zero2: X 4096: 87588990 bytes/sec zero3: X 4096: 760994468 bytes/sec zero4: X 4096: 724716455 bytes/sec zero5: X 4096: 174118958 bytes/sec read0: X 4096: 414447645 bytes/sec read1: X 4096: 343425463 bytes/sec read2: X 4096: 668619034 bytes/sec read3: X 4096: 807324044 bytes/sec read4: X 4096: 86945635 bytes/sec copy0: X 4096: 86956144 bytes/sec copy1: X 4096: 214172662 bytes/sec copy2: X 4096: 86677646 bytes/sec copy3: X 4096: 337507172 bytes/sec copy4: X 4096: 337204440 bytes/sec copy5: X 8192: 86985794 bytes/sec zero0: X 8192: 86898866 bytes/sec zero1: X 8192: 359670829 bytes/sec zero2: X 8192: 86931349 bytes/sec zero3: X 8192: 561722015 bytes/sec zero4: X 8192: 565892526 bytes/sec zero5: X 8192: 166822089 bytes/sec read0: X 8192: 368969652 bytes/sec read1: X 8192: 313836748 bytes/sec read2: X 8192: 563815452 bytes/sec read3: X 8192: 667017963 bytes/sec read4: X 8192: 84435213 bytes/sec copy0: X 8192: 85045367 bytes/sec copy1: X 8192: 81536141 bytes/sec copy2: X 8192: 84545505 bytes/sec copy3: X 8192: 61797899 bytes/sec copy4: X 8192: 97250060 bytes/sec copy5: X 16384: 86577163 bytes/sec zero0: X 16384: 86511701 bytes/sec zero1: X 16384: 91782021 bytes/sec zero2: X 16384: 86879841 bytes/sec zero3: X 16384: 131223435 bytes/sec zero4: X 16384: 130990009 bytes/sec zero5: X 16384: 110540965 bytes/sec read0: X 16384: 161218814 bytes/sec read1: X 16384: 161114656 bytes/sec read2: X 16384: 190427223 bytes/sec read3: X 16384: 197610103 bytes/sec read4: X 16384: 65619295 bytes/sec copy0: X 16384: 65469492 bytes/sec copy1: X 16384: 66021156 bytes/sec copy2: X 16384: 63431009 bytes/sec copy3: X 16384: 97963150 bytes/sec copy4: X 16384: 97608971 bytes/sec copy5: X 32768: 86671636 bytes/sec zero0: X 32768: 86648280 bytes/sec zero1: X 32768: 129736686 bytes/sec zero2: X 32768: 86801411 bytes/sec zero3: X 32768: 106576631 bytes/sec zero4: X 32768: 131485351 bytes/sec zero5: X 32768: 95844471 bytes/sec read0: X 32768: 161903205 bytes/sec read1: X 32768: 131358921 bytes/sec read2: X 32768: 190906366 bytes/sec read3: X 32768: 195968535 bytes/sec read4: X 32768: 65916363 bytes/sec copy0: X 32768: 65692663 bytes/sec copy1: X 32768: 81768489 bytes/sec copy2: X 32768: 64470792 bytes/sec copy3: X 32768: 99775406 bytes/sec copy4: X 32768: 99771523 bytes/sec copy5: X 65536: 87012285 bytes/sec zero0: X 65536: 87014405 bytes/sec zero1: X 65536: 116457683 bytes/sec zero2: X 65536: 86789810 bytes/sec zero3: X 65536: 118404569 bytes/sec zero4: X 65536: 133328356 bytes/sec zero5: X 65536: 111068905 bytes/sec read0: X 65536: 162809970 bytes/sec read1: X 65536: 145247291 bytes/sec read2: X 65536: 169225354 bytes/sec read3: X 65536: 175326326 bytes/sec read4: X 65536: 65905024 bytes/sec copy0: X 65536: 61498346 bytes/sec copy1: X 65536: 73303035 bytes/sec copy2: X 65536: 63758676 bytes/sec copy3: X 65536: 74987983 bytes/sec copy4: X 65536: 70467198 bytes/sec copy5: X 131072: 86827338 bytes/sec zero0: X 131072: 86796740 bytes/sec zero1: X 131072: 98350950 bytes/sec zero2: X 131072: 87126912 bytes/sec zero3: X 131072: 112326105 bytes/sec zero4: X 131072: 97081535 bytes/sec zero5: X 131072: 103272926 bytes/sec read0: X 131072: 126374640 bytes/sec read1: X 131072: 133852323 bytes/sec read2: X 131072: 158405302 bytes/sec read3: X 131072: 186528536 bytes/sec read4: X 131072: 57519462 bytes/sec copy0: X 131072: 63329899 bytes/sec copy1: X 131072: 57108462 bytes/sec copy2: X 131072: 57810786 bytes/sec copy3: X 131072: 65174136 bytes/sec copy4: X 131072: 61808746 bytes/sec copy5: X 262144: 86989956 bytes/sec zero0: X 262144: 86783408 bytes/sec zero1: X 262144: 96834012 bytes/sec zero2: X 262144: 86996994 bytes/sec zero3: X 262144: 89947713 bytes/sec zero4: X 262144: 94686658 bytes/sec zero5: X 262144: 89521267 bytes/sec read0: X 262144: 122771091 bytes/sec read1: X 262144: 122058542 bytes/sec read2: X 262144: 130217489 bytes/sec read3: X 262144: 136078490 bytes/sec read4: X 262144: 55315180 bytes/sec copy0: X 262144: 53134568 bytes/sec copy1: X 262144: 49456106 bytes/sec copy2: X 262144: 55849198 bytes/sec copy3: X 262144: 50385373 bytes/sec copy4: X 262144: 50291869 bytes/sec copy5: X 524288: 87288369 bytes/sec zero0: X 524288: 87189203 bytes/sec zero1: X 524288: 83525163 bytes/sec zero2: X 524288: 87196730 bytes/sec zero3: X 524288: 83545260 bytes/sec zero4: X 524288: 81666720 bytes/sec zero5: X 524288: 79887327 bytes/sec read0: X 524288: 99394686 bytes/sec read1: X 524288: 98545954 bytes/sec read2: X 524288: 119443204 bytes/sec read3: X 524288: 115947541 bytes/sec read4: X 524288: 48821665 bytes/sec copy0: X 524288: 46609855 bytes/sec copy1: X 524288: 40622945 bytes/sec copy2: X 524288: 47938225 bytes/sec copy3: X 524288: 43924033 bytes/sec copy4: X 524288: 43559357 bytes/sec copy5: X 1048576: 87285322 bytes/sec zero0: X 1048576: 87283950 bytes/sec zero1: X 1048576: 72887094 bytes/sec zero2: X 1048576: 87666698 bytes/sec zero3: X 1048576: 71178025 bytes/sec zero4: X 1048576: 71653666 bytes/sec zero5: X 1048576: 71103426 bytes/sec read0: X 1048576: 89790304 bytes/sec read1: X 1048576: 89479774 bytes/sec read2: X 1048576: 97097748 bytes/sec read3: X 1048576: 100427722 bytes/sec read4: X 1048576: 43895304 bytes/sec copy0: X 1048576: 44224540 bytes/sec copy1: X 1048576: 38171275 bytes/sec copy2: X 1048576: 43119302 bytes/sec copy3: X 1048576: 40846920 bytes/sec copy4: X 1048576: 41458081 bytes/sec copy5: X 2097152: 87974192 bytes/sec zero0: X 2097152: 88215783 bytes/sec zero1: X 2097152: 68610070 bytes/sec zero2: X 2097152: 88287436 bytes/sec zero3: X 2097152: 68917465 bytes/sec zero4: X 2097152: 67962716 bytes/sec zero5: X 2097152: 69144721 bytes/sec read0: X 2097152: 85944100 bytes/sec read1: X 2097152: 85587347 bytes/sec read2: X 2097152: 93399635 bytes/sec read3: X 2097152: 94968024 bytes/sec read4: X 2097152: 42594046 bytes/sec copy0: X 2097152: 42654601 bytes/sec copy1: X 2097152: 38098402 bytes/sec copy2: X 2097152: 41848656 bytes/sec copy3: X 2097152: 40400417 bytes/sec copy4: X 2097152: 40570256 bytes/sec copy5: X 4194304: 90166041 bytes/sec zero0: X 4194304: 89977416 bytes/sec zero1: X 4194304: 69796432 bytes/sec zero2: X 4194304: 90171569 bytes/sec zero3: X 4194304: 69706765 bytes/sec zero4: X 4194304: 69677283 bytes/sec zero5: X 4194304: 70125539 bytes/sec read0: X 4194304: 86942989 bytes/sec read1: X 4194304: 86395477 bytes/sec read2: X 4194304: 94129873 bytes/sec read3: X 4194304: 95756365 bytes/sec read4: X 4194304: 43384927 bytes/sec copy0: X 4194304: 43264366 bytes/sec copy1: X 4194304: 38952141 bytes/sec copy2: X 4194304: 43132451 bytes/sec copy3: X 4194304: 42045921 bytes/sec copy4: X 4194304: 41550170 bytes/sec copy5: X 8388608: 94921870 bytes/sec zero0: X 8388608: 94142988 bytes/sec zero1: X 8388608: 72916910 bytes/sec zero2: X 8388608: 94257459 bytes/sec zero3: X 8388608: 72880082 bytes/sec zero4: X 8388608: 72842709 bytes/sec zero5: X 8388608: 73575342 bytes/sec read0: X 8388608: 90701385 bytes/sec read1: X 8388608: 90326322 bytes/sec read2: X 8388608: 97226800 bytes/sec read3: X 8388608: 100359689 bytes/sec read4: X 8388608: 44787236 bytes/sec copy0: X 8388608: 45069204 bytes/sec copy1: X 8388608: 40680901 bytes/sec copy2: X 8388608: 44366812 bytes/sec copy3: X 8388608: 42067836 bytes/sec copy4: X 8388608: 41896241 bytes/sec copy5: X16777216: 98608729 bytes/sec zero0: X16777216: 98309760 bytes/sec zero1: X16777216: 78795128 bytes/sec zero2: X16777216: 99273812 bytes/sec zero3: X16777216: 77295522 bytes/sec zero4: X16777216: 78430757 bytes/sec zero5: X16777216: 78362414 bytes/sec read0: X16777216: 94250973 bytes/sec read1: X16777216: 96350252 bytes/sec read2: X16777216: 100450319 bytes/sec read3: X16777216: 110066095 bytes/sec read4: X16777216: 46661988 bytes/sec copy0: X16777216: 45378516 bytes/sec copy1: X16777216: 42331805 bytes/sec copy2: END_OF_FILE if test 9576 -ne `wc -c <'wrc.out'`; then echo shar: \"'wrc.out'\" unpacked with wrong size! fi # end of 'wrc.out' fi echo shar: End of shell archive. exit 0 From owner-freebsd-current Fri Apr 5 15:14:12 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA20430 for current-outgoing; Fri, 5 Apr 1996 15:14:12 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA20424 for ; Fri, 5 Apr 1996 15:14:09 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA25090; Fri, 5 Apr 1996 16:08:31 -0700 From: Terry Lambert Message-Id: <199604052308.QAA25090@phaeton.artisoft.com> Subject: Re: 2.2-960323 Panic in mount_msdos To: franky@pinewood.nl (Frank ten Wolde) Date: Fri, 5 Apr 1996 16:08:31 -0700 (MST) Cc: terry@lambert.org, freebsd-current@FreeBSD.org In-Reply-To: <9604050935.ZM9063@pwood1.pinewood.nl> from "Frank ten Wolde" at Apr 5, 96 09:35:25 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > Not bounds-checking dereferences isn't an error; it an optimization, > > and it's allowable because mount is not a user accessable command > > (you have to be root). > > I slightly disagree. Even as root I could make a typo and by mistake > specifiy the wrong partition/slice to mount, causing the entire system > to die. > > It would have been nice if some sanity checking would have been performed, > so that the kernel simply would abort the mount(2) system call with an > appropriate error (wrong FS type, or something similar). For instance, if you accidently type "/dev/kmem" instead of a disk device? Typo's are unlikely, since the "cannonically correct" way to do transient mounts that you expect to make is to put them as not mounted by default entries in the /etc/fstab. Then you mount them by device name, and typos get an error because they would need two device names. > I simply pointed out the panic. Maybe the code maintainer of the DOSFS > can use this info to make the system even more stable. Appreciated; but from what I understand, it is a *total* rewrite, so unless you get the developement code before it is released, any bug reports on the old system are bit-bucket fodder. I was explicit (possibly to the point of looking annoyed when I'm not) in the posting because of this. 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 Apr 5 15:17:20 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA20660 for current-outgoing; Fri, 5 Apr 1996 15:17:20 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA20648 for ; Fri, 5 Apr 1996 15:17:12 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id JAA28956; Sat, 6 Apr 1996 09:13:46 +1000 Date: Sat, 6 Apr 1996 09:13:46 +1000 From: Bruce Evans Message-Id: <199604052313.JAA28956@godzilla.zeta.org.au> To: asami@CS.Berkeley.EDU, current@freebsd.org Subject: Re: optimized bzeros found harmful (was: fast memory copy ...) Cc: hasty@rah.star-gate.com, mrami@minerva.cis.yale.edu, nisha@CS.Berkeley.EDU, tege@matematik.su.se Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Optimizing bzero is almost as difficult as optimizing bcopy. I benchmarked all the current kernel bzeros and found that the i586 is pessimization in all interesting cases on my ASUS p133 system: (tsc is the i586 timestamp counter). real user sys tsc for bzero time in bzero making a kernel (immediately after make clean; reboot): generic_bzero 492.43 377.86 31.03 1,219,568,103 9.195 i486_bzero 488.64 377.04 31.33 1,215,884,698 9.167 i586_bzero 492.96 378.79 32.27 1,617,865,274 12.198 10000 fork-execs of statically linked tiny processes: generic_bzero 25.29 0.30 10.04 0x225ca555 i486_bzero 25.39 0.28 10.02 0x2252d2df i586_bzero 28.58 0.34 12.00 0x304b123d i586_bzerox 25.88 0.34 10.17 0x22d93f47 2500 fork-execs of dynamically linked tiny processes: generic_bzero 24.74 8.43 16.15 0x16b85bde i486_bzero 24.83 8.26 16.39 0x16b6fc72 i586_bzero 26.65 7.59 18.80 0x1f28c253 i586_bzerox 24.81 8.31 16.29 0x16f8e380 i586_bzerox is i586_bzerox with the read-before-write (RBW) replaced by a 3-byte pairable instruction. The Time Stamp Counts were obtained by adding rdtsc's at the start and before the returns of all the bzero functions. This behaviour is consistent with the data being zeroed usually not being in the L2 cache. RBW is 33% slower in that case on my system. Other cases: if the data is in the L2 cache but not in the L1 cache, then RBW is between 0% and 33% faster; if data the data is in the L1 cache, then RBW is 8.5 times faster (740MB/s!). Bruce From owner-freebsd-current Fri Apr 5 15:21:33 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA20874 for current-outgoing; Fri, 5 Apr 1996 15:21:33 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA20861 for ; Fri, 5 Apr 1996 15:21:17 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA25117; Fri, 5 Apr 1996 16:14:00 -0700 From: Terry Lambert Message-Id: <199604052314.QAA25117@phaeton.artisoft.com> Subject: Re: fast memory copy for large data sizes To: paul@netcraft.co.uk Date: Fri, 5 Apr 1996 16:14:00 -0700 (MST) Cc: davidg@Root.COM, asami@cs.berkeley.edu, current@FreeBSD.org, nisha@cs.berkeley.edu, tege@matematik.su.se, hasty@rah.star-gate.com In-Reply-To: <199604051156.MAA00692@originat.demon.co.uk> from "Paul Richards" at Apr 5, 96 12:56:29 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-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > This would be a big lose in the kernel since just about all bcopy's fall > > into this range _except_ disk I/O block copies. I know this can be done better > > using other techniques (non-FP, see hackers mail from about 3 months ago). You > > should talk to John Dyson who's also working on this. > > A quick check of the size would probably help and use the original > method for small copies. Run a benchmark on such a scheme and see what > happens. > > Anyway, I had another thought, do we save the fp registers across > context switches? I seem to remember that we don't always and instead > save them when something tries to do FP operations, I might be imagining > this but if it's true increased use of the fp regs is going to impact > context switching. This is true. I also don't see the code seriously dealing with misalignment between wource and target, which need to be aligned on the same boundry for everything but the initial and final sub-increment sized moves. Otherwise the cache lines will still require multiple fetches and stores to make work (a design flaw in the P5/P6, which could easily have had special purpose registers for unaligned access if two increments could be in cache at the same time in a barrel shifter or similar hardware zero-clock cache line access rotor). Often it's better if the alignment isn't there to fallback to the old code. 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 Apr 5 16:14:36 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA22816 for current-outgoing; Fri, 5 Apr 1996 16:14:36 -0800 (PST) Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id QAA22802 for ; Fri, 5 Apr 1996 16:14:29 -0800 (PST) Received: by sequent.kiae.su id AA01238 (5.65.kiae-2 ); Sat, 6 Apr 1996 03:11:56 +0300 Received: by sequent.KIAE.su (UUMAIL/2.0); Sat, 6 Apr 96 03:11:55 +0300 Received: (from ache@localhost) by astral.msk.su (8.7.5/8.7.3) id EAA02916; Sat, 6 Apr 1996 04:09:53 +0400 (MSD) Message-Id: <199604060009.EAA02916@astral.msk.su> Subject: Re: Can we upgrade ncurses? To: scrappy@ki.net (Marc G. Fournier) Date: Sat, 6 Apr 1996 04:09:52 +0400 (MSD) Cc: current@FreeBSD.org In-Reply-To: from "Marc G. Fournier" at "Apr 5, 96 03:28:29 pm" From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast X-Mailer: ELM [version 2.4ME+ PL14 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Is there any underlying reason why we can't upgrade Ncurses > from 1.8.4 (circa 1994) to 1.9.9e (circa current)? There the reasons: Ncurses before 1.9.9 was too buggy. Righgt now I not yet find enough time to do that. > If its a matter of someone integrating...I raise my hand... > for me it means that its one less thing I have to remember not to > install when I do a make world, so its worth my time commiting an > upgrade and maintaining the library :) OK from me, but please keep in mind following things: It must be configured for termcap-only, no fallback to terminfo: one terminal database must exists in the system. BSD tputs glitch must be turned on. Mytinfo library must be replaced with empty library for a while (for compatibility). Next step will be replacing curses library with ncurses. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-current Fri Apr 5 17:04:39 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA25775 for current-outgoing; Fri, 5 Apr 1996 17:04:39 -0800 (PST) Received: from palmer.demon.co.uk (palmer.demon.co.uk [158.152.50.150]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id RAA25769 for ; Fri, 5 Apr 1996 17:04:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by palmer.demon.co.uk (sendmail/PALMER-1) with SMTP id BAA00989 ; Sat, 6 Apr 1996 01:14:45 +0100 (BST) To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) cc: freebsd-current@FreeBSD.ORG (FreeBSD-current users) From: "Gary Palmer" Subject: Re: DM: CVSROOT/Emptydir exists. In-reply-to: Your message of "Fri, 05 Apr 1996 21:49:47 +0200." <199604051949.VAA01030@uriah.heep.sax.de> Date: Sat, 06 Apr 1996 01:14:44 +0100 Message-ID: <987.828749684@palmer.demon.co.uk> Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk J Wunsch wrote in message ID <199604051949.VAA01030@uriah.heep.sax.de>: > Is it just me only? > > Delta number 1845 is already applied; ignoring. > Delta number 1846 is already applied; ignoring. > Delta number 1847 is already applied; ignoring. > Delta number 1848 is already applied; ignoring. > Delta number 1849 is already applied; ignoring. > DM: CVSROOT/Emptydir exists. > Exit(80) > This is from the nightly CTM run. Since I'm up to cvs-cur-1854 without problems... :-) Gary From owner-freebsd-current Fri Apr 5 18:48:09 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA29994 for current-outgoing; Fri, 5 Apr 1996 18:48:09 -0800 (PST) Received: from perki.connect.com.au (perki.connect.com.au [192.189.54.5]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id SAA29988 Fri, 5 Apr 1996 18:48:05 -0800 (PST) Received: (from Unemeton@localhost) by perki.connect.com.au id MAA23451 (8.7.4/IDA-1.6); Sat, 6 Apr 1996 12:47:40 +1000 (EST) X-Authentication-Warning: perki.connect.com.au: Unemeton set sender to giles@nemeton.com.au using -f >Received: from localhost (giles@localhost [127.0.0.1]) by nemeton.com.au (8.6.12/8.6.9) with SMTP id MAA08844; Sat, 6 Apr 1996 12:49:37 +1000 Message-Id: <199604060249.MAA08844@nemeton.com.au> To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Subject: Re: DM: CVSROOT/Emptydir exists. In-reply-to: <199604051949.VAA01030@uriah.heep.sax.de> Date: Sat, 06 Apr 1996 12:49:36 +1000 From: Giles Lean Content-Type: text Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 5 Apr 1996 21:49:47 +0200 (MET DST) J Wunsch wrote: > Is it just me only? You only, I think. Mine just applied OK. Giles Working on > DM CVSROOT/Emptydir > FS .ctm_status > FN CVSROOT/commitlogs/ports > FN CVSROOT/commitlogs/sbin > FN CVSROOT/commitlogs/share > FN CVSROOT/commitlogs/sys > FN CVSROOT/commitlogs/usrsbin > FN ports/www/kaffe/Makefile,v > FN ports/www/kaffe/files/md5,v > FN ports/www/kaffe/patches/patch-aa,v > FN ports/www/kaffe/pkg/DESCR,v > FN ports/www/kaffe/pkg/PLIST,v > FN ports/www/netscape3/pkg/DESCR,v > FN src/sbin/i386/mount_msdos/mount_msdos.8,v > FN src/share/man/man5/printcap.5,v > FN src/sys/msdosfs/msdosfs_vfsops.c,v > FN src/sys/sys/sysent.h,v > FN src/usr.sbin/lpr/common_source/common.c,v > FN src/usr.sbin/lpr/common_source/lp.h,v > FN src/usr.sbin/lpr/lpd/Makefile,v > FM src/usr.sbin/lpr/lpd/modes.c,v > FN src/usr.sbin/lpr/lpd/printjob.c,v All done ok From owner-freebsd-current Fri Apr 5 19:10:50 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id TAA00827 for current-outgoing; Fri, 5 Apr 1996 19:10:50 -0800 (PST) Received: from ki.net (root@ki.net [205.150.102.1]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id TAA00820 for ; Fri, 5 Apr 1996 19:10:46 -0800 (PST) Received: from freebsd.ki.net (root@freebsd.ki.net [205.150.102.2]) by ki.net (8.7.4/8.7.4) with ESMTP id WAA13866; Fri, 5 Apr 1996 22:11:15 -0500 (EST) Received: from localhost (scrappy@localhost) by freebsd.ki.net (8.7.5/8.7.5) with ESMTP id WAA01227; Fri, 5 Apr 1996 22:11:42 -0500 (EST) X-Authentication-Warning: freebsd.ki.net: scrappy owned process doing -bs Date: Fri, 5 Apr 1996 22:11:41 -0500 (EST) From: "Marc G. Fournier" To: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= cc: current@FreeBSD.org Subject: Re: Can we upgrade ncurses? In-Reply-To: <199604060009.EAA02916@astral.msk.su> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 6 Apr 1996, [KOI8-R] =E1=CE=C4=D2=C5=CA =FE=C5=D2=CE=CF=D7 wrote: > > =09Is there any underlying reason why we can't upgrade Ncurses > > from 1.8.4 (circa 1994) to 1.9.9e (circa current)? > > There the reasons: > Ncurses before 1.9.9 was too buggy. > Righgt now I not yet find enough time to do that. > > > =09If its a matter of someone integrating...I raise my hand... > > for me it means that its one less thing I have to remember not to > > install when I do a make world, so its worth my time commiting an > > upgrade and maintaining the library :) > > OK from me, but please keep in mind following things: > It must be configured for termcap-only, no fallback to terminfo: =09Oh...I was going to do it the opposite way *hang head* =09Just curious (I'll work on it as termcap-only), but what exactly is the difference between termcap and terminfo, and pros/cons of each? > one terminal database must exists in the system. > BSD tputs glitch must be turned on. > Mytinfo library must be replaced with empty library for a while (for > compatibility). > Next step will be replacing curses library with ncurses. > =09replace with or get rid of libcurses? I currently have ncurses installed on both my -stable and -current machines with the symlink from libncurses to libcurses. Marc G. Fournier | POP Mail Telnet Acct DNS Hosting System | WWW Services Database Services | Knowledge, Administrator | | Information and scrappy@ki.net | WWW: http://www.ki.net | Communications, Inc From owner-freebsd-current Fri Apr 5 22:09:53 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA07962 for current-outgoing; Fri, 5 Apr 1996 22:09:53 -0800 (PST) Received: from haywire.DIALix.COM (root@haywire.DIALix.COM [192.203.228.65]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id WAA07955 for ; Fri, 5 Apr 1996 22:09:47 -0800 (PST) Received: (from news@localhost) by haywire.DIALix.COM (8.7.5/8.7.3) id OAA22451 for freebsd-current@freebsd.org; Sat, 6 Apr 1996 14:09:54 +0800 (WST) X-Authentication-Warning: haywire.DIALix.COM: news set sender to usenet-request@haywire.dialix.com using -f Received: from GATEWAY by haywire.DIALix.COM with netnews for freebsd-current@freebsd.org (problems to: usenet@haywire.dialix.com) To: freebsd-current@freebsd.org Date: 6 Apr 96 06:04:14 GMT From: peter@jhome.DIALix.COM (Peter Wemm) Message-ID: Organization: DIALix Services, Perth, Australia. References: <199604052259.OAA19443@freefall.freebsd.org> Subject: Re: sup/cvs tags Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk mpp@freefall.freebsd.org (Mike Pritchard) writes: >In the future can we try and avoid tagging the kernel source tree >except at release time? The wollman_polling tag is causing anyone >who sups the cvs files to receive every file in /usr/src/sys just >because of the new tag. This looks to be about 33 megabytes of data, >which is quite painful over a slow link. If you dont have an ultra-fast link, you really should be using CTM as it only sends the changes for each file, not the whole blasted file each time there's a one-line change. -Peter >-- >Mike Pritchard >mpp@freebsd.org >"Go that way. Really fast. If something gets in your way, turn" From owner-freebsd-current Fri Apr 5 23:37:15 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA12235 for current-outgoing; Fri, 5 Apr 1996 23:37:15 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA12230 for ; Fri, 5 Apr 1996 23:37:12 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id RAA15566; Sat, 6 Apr 1996 17:34:30 +1000 Date: Sat, 6 Apr 1996 17:34:30 +1000 From: Bruce Evans Message-Id: <199604060734.RAA15566@godzilla.zeta.org.au> To: freebsd-current@FreeBSD.org, peter@jhome.DIALix.COM Subject: Re: sup/cvs tags Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >>In the future can we try and avoid tagging the kernel source tree >>except at release time? The wollman_polling tag is causing anyone >If you dont have an ultra-fast link, you really should be using CTM as it >only sends the changes for each file, not the whole blasted file each time >there's a one-line change. The CTM delta was about 70K for the last change IIRC. It's about 500K when the whole tree is tagged. This could be improved by specialized compression. BTW, what is the best way to look at the diffs in the wollman_polling branch? `cvs diff -r HEAD -r wollman_polling' gave too many current diffs just one or two days after the branch. How do I get the date of the branch in a form suitable for `cvs diff -D'? Bruce From owner-freebsd-current Fri Apr 5 23:45:11 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA12534 for current-outgoing; Fri, 5 Apr 1996 23:45:11 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id XAA12529 for ; Fri, 5 Apr 1996 23:45:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with SMTP id XAA00445 for ; Fri, 5 Apr 1996 23:44:41 -0800 (PST) To: current@freebsd.org Subject: pgcc and kernels.. Date: Fri, 05 Apr 1996 23:44:41 -0800 Message-ID: <443.828776681@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk After reading that provocative article about how awesome pgcc's pentium optimization is, I naturally had to try it with today's -current. I notice that the kernel compile perks along fairly nicely with `-O -pipe -mpentium' until one tries to compile kern_clock.c, at which point the following define in machine/clock.h is flagged as in error: #define I586_CYCLECTR(x) \ __asm __volatile(".byte 0x0f, 0x31" : "=A" (x)) I've never been all that comfortable with gcc's asm() syntax, seeing as I use it pretty much never, so I'm not sure who's "right" here - us or gcc? Jordan From owner-freebsd-current Sat Apr 6 00:21:12 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA14097 for current-outgoing; Sat, 6 Apr 1996 00:21:12 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id AAA14083 Sat, 6 Apr 1996 00:21:08 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id KAA09113; Sat, 6 Apr 1996 10:21:06 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id KAA16842; Sat, 6 Apr 1996 10:21:06 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id KAA06982; Sat, 6 Apr 1996 10:15:33 +0200 (MET DST) From: J Wunsch Message-Id: <199604060815.KAA06982@uriah.heep.sax.de> Subject: Re: sup/cvs tags To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sat, 6 Apr 1996 10:15:32 +0200 (MET DST) Cc: mpp@freefall.freebsd.org (Mike Pritchard) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199604052259.OAA19443@freefall.freebsd.org> from "Mike Pritchard" at Apr 5, 96 02:59:05 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Mike Pritchard wrote: > > In the future can we try and avoid tagging the kernel source tree > except at release time? The wollman_polling tag is causing anyone > who sups the cvs files to receive every file in /usr/src/sys just > because of the new tag. This looks to be about 33 megabytes of data, > which is quite painful over a slow link. Don't use sup if you've got a slow link. CTM handles this much more graceful (only the diff line with the tag is transferred per file). I think vendor branches are a good means to integrate things into the source tree that should for some reason not yet appear in the HEAD but be available for more than one developer. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sat Apr 6 00:30:31 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA14436 for current-outgoing; Sat, 6 Apr 1996 00:30:31 -0800 (PST) Received: from diablo.ppp.de (diablo.ppp.de [193.141.101.34]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id AAA14427 for ; Sat, 6 Apr 1996 00:30:24 -0800 (PST) Received: from allegro.lemis.de by diablo.ppp.de with smtp (Smail3.1.28.1 #1) id m0u5TO0-000QYLC; Sat, 6 Apr 96 10:30 MET DST From: grog@lemis.de (Greg Lehey) Organisation: LEMIS, Schellnhausen 2, 36325 Feldatal, Germany Phone: +49-6637-919123 Fax: +49-6637-919122 Received: (grog@localhost) by allegro.lemis.de (8.6.9/8.6.9) id KAA07652; Sat, 6 Apr 1996 10:19:17 +0200 Message-Id: <199604060819.KAA07652@allegro.lemis.de> Subject: Re: 2.2-960323 Panic in mount_msdos To: terry@lambert.org (Terry Lambert) Date: Sat, 6 Apr 1996 10:19:17 +0200 (MET DST) Cc: franky@pinewood.nl, freebsd-current@FreeBSD.org In-Reply-To: <199604042010.NAA22425@phaeton.artisoft.com> from "Terry Lambert" at Apr 4, 96 01:10:04 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Terry Lambert writes: > >> I know you cannot mount an NTFS under FreeBSD, but at least the system >> should not crash. Agreed. >> I just report this problem as I have too little knowledge of the internals >> of the kernel to fix the problem myself :-) > > A file system operates by copying on disk strucutures into memory > and then using the offsets in the coppy to access additional memory. > > It does not bounds-check these accesses. > > If there is a problem with this, it's that the DOSFS did not validate > that the device was in fact a DOS partition before going gung-ho into > dereferencing. > > Not bounds-checking dereferences isn't an error; it an optimization, > and it's allowable because mount is not a user accessable command > (you have to be root). If not bound-checking causes a crash, then in my book it's an error. Sure, you shouldn't be able to mount incorrect file systems, but even if the file system is correct, there's always the chance of data corruption. I agree that it's not a good idea to be paranoid about every pointer, but there should be a way to recover if the data is corrupted. Typically, that's done by bounds checking such pointers. Maybe it would be interesting to put drivers like this at IOPL1, where they could be recognized as such and, if found wanting, terminated rather than crashing the system. > The fix for inconsistent media is to run fsck (or equivalent) on it > before attempting a mount; the fix is procedural, in other words, > and doesn't require a change to the mount code. Yes, but this isn't sufficient. It also places the onus on the user. I still believe that the kernel should protect itself as much as possible from outside influences. Greg From owner-freebsd-current Sat Apr 6 01:38:47 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA17914 for current-outgoing; Sat, 6 Apr 1996 01:38:47 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id BAA17908 for ; Sat, 6 Apr 1996 01:38:43 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id TAA03574; Sat, 6 Apr 1996 19:34:05 +0930 From: Michael Smith Message-Id: <199604061004.TAA03574@genesis.atrad.adelaide.edu.au> Subject: Re: Clean reboot on current To: freebsd@hopf.math.purdue.edu (Clarence Wilkerson) Date: Sat, 6 Apr 1996 19:34:05 +0930 (CST) Cc: current@freefall.freebsd.org, freebsd@hopf.math.purdue.edu, wilker@hopf.math.purdue.edu In-Reply-To: <199604051606.LAA21264@hopf.math.purdue.edu> from "Clarence Wilkerson" at Apr 5, 96 11:06:53 am MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Clarence Wilkerson stands accused of saying: > When I do a few syncs and a "reboot" command, I get a string of > numbers like > > 3 3 3 3 3 3 "giving up" The '3' indicates the number of disk buffers that are waiting to be written. Do you get the same result with 'shutdown -r now'? If not, then you probably have an application that's unhappy about being nuked. > Clarence Wilkerson -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[ From owner-freebsd-current Sat Apr 6 01:51:56 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA18980 for current-outgoing; Sat, 6 Apr 1996 01:51:56 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id BAA18975 for ; Sat, 6 Apr 1996 01:51:53 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id TAA20678; Sat, 6 Apr 1996 19:51:00 +1000 Date: Sat, 6 Apr 1996 19:51:00 +1000 From: Bruce Evans Message-Id: <199604060951.TAA20678@godzilla.zeta.org.au> To: current@FreeBSD.ORG, jkh@time.cdrom.com Subject: Re: pgcc and kernels.. Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >at which point the following define in machine/clock.h is flagged >as in error: > >#define I586_CYCLECTR(x) \ > __asm __volatile(".byte 0x0f, 0x31" : "=A" (x)) >I've never been all that comfortable with gcc's asm() syntax, seeing >as I use it pretty much never, so I'm not sure who's "right" here - us >or gcc? gcc is always right. pgcc != gcc. The "A" regclass was added on 14 June 1994 and released in 2.6.0 according ChangeLog.9. Perhaps the relevant parts of pgcc are older than that? I think the Pentium parts are mostly the old Intel work which was done long before that. Bruce From owner-freebsd-current Sat Apr 6 01:58:53 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA19627 for current-outgoing; Sat, 6 Apr 1996 01:58:53 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id BAA19605 for ; Sat, 6 Apr 1996 01:58:49 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id LAA10423 for ; Sat, 6 Apr 1996 11:58:47 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id LAA17797 for freebsd-current@FreeBSD.org; Sat, 6 Apr 1996 11:58:46 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id LAA07603 for freebsd-current@FreeBSD.org; Sat, 6 Apr 1996 11:29:15 +0200 (MET DST) From: J Wunsch Message-Id: <199604060929.LAA07603@uriah.heep.sax.de> Subject: Re: Can we upgrade ncurses? To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sat, 6 Apr 1996 11:29:13 +0200 (MET DST) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from "Marc G. Fournier" at Apr 5, 96 10:11:41 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Marc G. Fournier wrote: > Just curious (I'll work on it as termcap-only), but what exactly > is the difference between termcap and terminfo, and pros/cons of each? Terminfo abuses the file system as a database. It introduces new capabilities (e.g. function keys > 9), but that's not to say you couldn't implement them in tercap either. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sat Apr 6 01:58:54 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA19636 for current-outgoing; Sat, 6 Apr 1996 01:58:54 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id BAA19595 for ; Sat, 6 Apr 1996 01:58:47 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id LAA10419 for ; Sat, 6 Apr 1996 11:58:45 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id LAA17796 for freebsd-current@FreeBSD.org; Sat, 6 Apr 1996 11:58:45 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id KAA07114 for freebsd-current@FreeBSD.org; Sat, 6 Apr 1996 10:31:08 +0200 (MET DST) From: J Wunsch Message-Id: <199604060831.KAA07114@uriah.heep.sax.de> Subject: Re: DM: CVSROOT/Emptydir exists. To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sat, 6 Apr 1996 10:31:08 +0200 (MET DST) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <987.828749684@palmer.demon.co.uk> from "Gary Palmer" at Apr 6, 96 01:14:44 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Gary Palmer wrote: > > Delta number 1849 is already applied; ignoring. > > DM: CVSROOT/Emptydir exists. > > Exit(80) > > > This is from the nightly CTM run. > > Since I'm up to cvs-cur-1854 without problems... :-) I wonder why the directory had been created before. I've removed it manually (as the name suggests, it was empty :), and everything worked fine afterwards. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sat Apr 6 02:19:16 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA20690 for current-outgoing; Sat, 6 Apr 1996 02:19:16 -0800 (PST) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id CAA20685 Sat, 6 Apr 1996 02:19:11 -0800 (PST) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) id MAA18709; Sat, 6 Apr 1996 12:00:35 +0200 (MET DST) Received: from localhost (localhost [127.0.0.1]) by knobel.gun.de (8.7.5/8.7.3) with SMTP id LAA04418; Sat, 6 Apr 1996 11:24:04 +0200 (MET DST) Date: Sat, 6 Apr 1996 11:24:03 +0200 (MET DST) From: Andreas Klemm To: Bill Fenner cc: Satoshi Asami , ports@freebsd.org, current@freebsd.org Subject: Re: make clean should remove README.html in ports collection In-Reply-To: <96Apr5.090201pst.177476@crevenia.parc.xerox.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Fri, 5 Apr 1996, Bill Fenner wrote: > In message <199604051143.NAA21078@knobel.gun.de> you write: > >? ports/lang/icon/README.html > >? ports/lang/itcl/README.html > >? ports/lang/logo/README.html > > How about "cvs -I README.html"? Or add README.html to CVSROOT/cvsignore? ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Well, that sounds great ... could someone commit it. please. I don't want to get out of sync with you... ;-) - -- andreas@knobel.gun.de /\/\___ Wiechers & Partner Datentechnik GmbH Andreas Klemm ___/\/\/ $$ Support Unix - aklemm@wup.de $$ pgp p-key http://www-swiss.ai.mit.edu/~bal/pks-toplev.html >>> powered by <<< ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz >>> FreeBSD <<< -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMWY4M/MLpmkD/U+FAQEM+gP+KLs6ok8gaoyPZh/Sw3SRTV0z9j8Wp/Tb /rMQpAmVqesSdA88W5I2BRuP4WbtlbG1fOT01SKCHR56P/7vWfCPUBqdssC1fuWy VLJinX9clGvrqsC6QxUyC6vpV7aqbmgHzS3NR6TrwiE6XGWal/wPilJtmRTDOb5S CjRHQBi9ni0= =ZaGs -----END PGP SIGNATURE----- From owner-freebsd-current Sat Apr 6 02:30:28 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA21281 for current-outgoing; Sat, 6 Apr 1996 02:30:28 -0800 (PST) Received: from diablo.ppp.de (diablo.ppp.de [193.141.101.34]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id CAA21275 for ; Sat, 6 Apr 1996 02:30:22 -0800 (PST) Received: from allegro.lemis.de by diablo.ppp.de with smtp (Smail3.1.28.1 #1) id m0u5VG7-000QYEC; Sat, 6 Apr 96 12:30 MET DST From: grog@lemis.de (Greg Lehey) Organisation: LEMIS, Schellnhausen 2, 36325 Feldatal, Germany Phone: +49-6637-919123 Fax: +49-6637-919122 Received: (grog@localhost) by allegro.lemis.de (8.6.9/8.6.9) id MAA11211 for current@freebsd.org; Sat, 6 Apr 1996 12:27:33 +0200 Message-Id: <199604061027.MAA11211@allegro.lemis.de> Subject: CVS: What am I doing wrong? To: current@freebsd.org Date: Sat, 6 Apr 1996 12:27:32 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've started to re-checkout my complete -current tree, and have run into some strange problems: I started in an empty directory called /src/2.2-CURRENT. With the command cvs -r co src I expect to get a complete, read-only source tree attached to the current directory. Instead, I get: + cvs checkout: Updating src + U src/COPYRIGHT + U src/Makefile + cvs checkout: Updating src/TODO-2.1 + cvs checkout: Updating src/bin + U src/bin/Makefile In addition, it bombs out on me in a number of directories, such as: + U src/sys/gnu/i386/fpemul/wm_shrx.s + U src/sys/gnu/i386/fpemul/wm_sqrt.s + cvs checkout: Updating src/sys/gnu/i386/isa + cvs checkout: cannot open CVS/Entries for reading: No such file or directory + cvs [checkout aborted]: cannot open CVS/Root: No such file or directory Since in each case the directory doesn't exist, I can't see why it should complain about this particular directory. Even curiouser, if I specify this directory specifically, it works: + $ cvs -r co src/sys/gnu/i386/isa + cvs checkout: Updating src/sys/gnu/i386/isa + U src/sys/gnu/i386/isa/dgb.c + U src/sys/gnu/i386/isa/dgbios.h + U src/sys/gnu/i386/isa/dgfep.h + U src/sys/gnu/i386/isa/dgreg.h + U src/sys/gnu/i386/isa/nic3008.c + U src/sys/gnu/i386/isa/nic3008.h + U src/sys/gnu/i386/isa/nic3009.c + U src/sys/gnu/i386/isa/nic3009.h + U src/sys/gnu/i386/isa/niccyreg.h I'm using the -current cvs of about a week ago. Is cvs broke? Is my checkout command screwed up? Or is it just an artifact of the phase of the moon? Greg From owner-freebsd-current Sat Apr 6 04:58:09 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA27723 for current-outgoing; Sat, 6 Apr 1996 04:58:09 -0800 (PST) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id EAA27718 Sat, 6 Apr 1996 04:58:05 -0800 (PST) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) id OAA20518; Sat, 6 Apr 1996 14:30:15 +0200 (MET DST) Received: from localhost (localhost [127.0.0.1]) by knobel.gun.de (8.7.5/8.7.3) with SMTP id MAA04689; Sat, 6 Apr 1996 12:13:29 +0200 (MET DST) Date: Sat, 6 Apr 1996 12:13:28 +0200 (MET DST) From: Andreas Klemm To: Joerg Wunsch cc: FreeBSD-current users , Poul-Henning Kamp Subject: Re: DM: CVSROOT/Emptydir exists. In-Reply-To: <199604051949.VAA01030@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Fri, 5 Apr 1996, J Wunsch wrote: > Is it just me only? > > Delta number 1845 is already applied; ignoring. > Delta number 1846 is already applied; ignoring. > Delta number 1847 is already applied; ignoring. > Delta number 1848 is already applied; ignoring. > Delta number 1849 is already applied; ignoring. > DM: CVSROOT/Emptydir exists. > Exit(80) > > This is from the nightly CTM run. After removing CVSROOT/Emptydir I was able to successfully apply the delta. No further problems after that action. Now I'm at level 'cvs-cur 1856'. - -- andreas@knobel.gun.de /\/\___ Wiechers & Partner Datentechnik GmbH Andreas Klemm ___/\/\/ $$ Support Unix - aklemm@wup.de $$ pgp p-key http://www-swiss.ai.mit.edu/~bal/pks-toplev.html >>> powered by <<< ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz >>> FreeBSD <<< -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMWZDyfMLpmkD/U+FAQFAfQQAqFexCMrAvJ8MAUDuTUqRf2ydWCrkxM0e 3DhzdDhvjuIoXWv8MCRDH8o/OHM8Bw3e39fnUNO3z72yi7kGdBF2k+x7mvllpTxf Y+B94OpqP1px2Zf81r/qWiyGbduDR4VEdb7gk8G2PrX3ZjFUAPRNTuNWRG33QkUo JS6/09zpGYs= =aeic -----END PGP SIGNATURE----- From owner-freebsd-current Sat Apr 6 05:35:36 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA28989 for current-outgoing; Sat, 6 Apr 1996 05:35:36 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id FAA28979 for ; Sat, 6 Apr 1996 05:35:33 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id PAA13231 for ; Sat, 6 Apr 1996 15:35:31 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id PAA19293 for freebsd-current@FreeBSD.org; Sat, 6 Apr 1996 15:35:30 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id PAA00612 for freebsd-current@FreeBSD.org; Sat, 6 Apr 1996 15:27:19 +0200 (MET DST) From: J Wunsch Message-Id: <199604061327.PAA00612@uriah.heep.sax.de> Subject: devfs questions To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sat, 6 Apr 1996 15:27:15 +0200 (MET DST) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk I've started playing with devfs. Find below a patch to init(8) that should allow the system to come up with an empty /dev directory as long as devfs is statically available in the kernel. It tries to mount /dev early in the game, before the first device node (/dev/console) is about to be accessed. I've at least been able to run the single-user shell with it. Alas, the next would be fsck'ing, and so the big question is: how are the slice and partition entries supposed to be created? I've also got a panic when trying to create a hardlink there, but have yet to reproduce it again ("vrele: negative reference cnt"). The previous core dump was unusable. How hard will it be to get symlinks implemented? Index: init/init.c =================================================================== RCS file: /home/ncvs/src/sbin/init/init.c,v retrieving revision 1.11 diff -u -u -r1.11 init.c --- init.c 1995/11/10 07:06:59 1.11 +++ init.c 1996/04/06 12:44:10 @@ -45,6 +45,7 @@ #endif /* not lint */ #include +#include #include #include @@ -125,6 +126,7 @@ state_t requested_transition = runcom; void setctty __P((char *)); +void check_console __P((void)); typedef struct init_session { int se_index; /* index of entry in ttys file */ @@ -546,6 +548,28 @@ } /* + * Check for the existance of _PATH_CONSOLE. Try mounting devfs if it + * doesn't exist. + */ +void +check_console() +{ + if (access(_PATH_CONSOLE, F_OK) == 0) + return; + + if (getvfsbytype(MOUNT_DEVFS) == NULL) { + stall("%s does not exist, and \"devfs\" is not available", + _PATH_CONSOLE); + _exit(1); + } + if (mount(MOUNT_DEVFS, _PATH_DEV_MNTPNT, 0, NULL) == -1) { + stall("cannot mount \"devfs\", errno = %d", + errno); + _exit(1); + } +} + +/* * Bring the system up single user. */ state_func_t @@ -583,6 +607,7 @@ /* * Start the single user session. */ + check_console(); setctty(_PATH_CONSOLE); #ifdef SECURE @@ -716,6 +741,7 @@ (void) sigaction(SIGTSTP, &sa, (struct sigaction *)0); (void) sigaction(SIGHUP, &sa, (struct sigaction *)0); + check_console(); setctty(_PATH_CONSOLE); argv[0] = "sh"; Index: init/pathnames.h =================================================================== RCS file: /home/ncvs/src/sbin/init/pathnames.h,v retrieving revision 1.1.1.1 diff -u -u -r1.1.1.1 pathnames.h --- pathnames.h 1994/05/26 06:34:19 1.1.1.1 +++ pathnames.h 1996/04/06 12:43:42 @@ -40,3 +40,4 @@ #define _PATH_SLOGGER "/sbin/session_logger" #define _PATH_RUNCOM "/etc/rc" +#define _PATH_DEV_MNTPNT "/dev" /* _PATH_DEV has a trailing slash */ -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sat Apr 6 05:45:10 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA29302 for current-outgoing; Sat, 6 Apr 1996 05:45:10 -0800 (PST) Received: from originat.demon.co.uk (originat.demon.co.uk [158.152.220.9]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id FAA29296 Sat, 6 Apr 1996 05:45:04 -0800 (PST) Received: (from paul@localhost) by originat.demon.co.uk (8.7.5/8.6.9) id OAA00485; Sat, 6 Apr 1996 14:46:15 +0100 (BST) From: Paul Richards Message-Id: <199604061346.OAA00485@originat.demon.co.uk> Subject: Re: sup/cvs tags To: mpp@freefall.freebsd.org (Mike Pritchard) Date: Sat, 6 Apr 1996 14:46:15 +0100 (BST) Cc: freebsd-current@freefall.freebsd.org In-Reply-To: <199604052259.OAA19443@freefall.freebsd.org> from "Mike Pritchard" at Apr 5, 96 02:59:05 pm Reply-to: paul@netcraft.co.uk X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In reply to Mike Pritchard who said > > In the future can we try and avoid tagging the kernel source tree > except at release time? The wollman_polling tag is causing anyone > who sups the cvs files to receive every file in /usr/src/sys just > because of the new tag. This looks to be about 33 megabytes of data, > which is quite painful over a slow link. I agree. The FreeBSD cvs tree isn't for personal development and I'm a bit miffed that Garret has been allowed to get away with putting in a personal tag. If it's not ready to go in the main development tree then it doesn't belong at all. We'll have a real mess if we all start creating personal branches. -- Paul Richards, Originative Solutions Ltd. Internet: paul@netcraft.co.uk, http://www.netcraft.co.uk Phone: 0370 462071 (Mobile), +44 1225 447500 (work) From owner-freebsd-current Sat Apr 6 06:20:47 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA00808 for current-outgoing; Sat, 6 Apr 1996 06:20:47 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id GAA00791 for ; Sat, 6 Apr 1996 06:20:44 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id QAA13773 for ; Sat, 6 Apr 1996 16:20:42 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id QAA19530 for freebsd-current@FreeBSD.org; Sat, 6 Apr 1996 16:20:41 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id PAA01108 for freebsd-current@FreeBSD.org; Sat, 6 Apr 1996 15:52:26 +0200 (MET DST) From: J Wunsch Message-Id: <199604061352.PAA01108@uriah.heep.sax.de> Subject: Re: DM: CVSROOT/Emptydir exists. To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sat, 6 Apr 1996 15:52:25 +0200 (MET DST) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from "Andreas Klemm" at Apr 6, 96 12:13:28 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Andreas Klemm wrote: > > DM: CVSROOT/Emptydir exists. > > Exit(80) > After removing CVSROOT/Emptydir I was able to successfully > apply the delta. No further problems after that action. Of course, and that's what i did, but i still wonder why it has been created in the first place. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sat Apr 6 06:21:05 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA00846 for current-outgoing; Sat, 6 Apr 1996 06:21:05 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id GAA00829 for ; Sat, 6 Apr 1996 06:20:55 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id QAA13791; Sat, 6 Apr 1996 16:20:50 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id QAA19536; Sat, 6 Apr 1996 16:20:50 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id QAA01190; Sat, 6 Apr 1996 16:09:02 +0200 (MET DST) From: J Wunsch Message-Id: <199604061409.QAA01190@uriah.heep.sax.de> Subject: Re: CVS: What am I doing wrong? To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sat, 6 Apr 1996 16:09:02 +0200 (MET DST) Cc: grog@lemis.de (Greg Lehey) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199604061027.MAA11211@allegro.lemis.de> from "Greg Lehey" at Apr 6, 96 12:27:32 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Greg Lehey wrote: > I started in an empty directory called /src/2.2-CURRENT. With the > command > > cvs -r co src > > I expect to get a complete, read-only source tree attached to the > current directory. Instead, I get: > > + cvs checkout: Updating src > + U src/COPYRIGHT cvs co uses the module name as its subdir by default. Override this with cvs -r co -d . src if you don't like it. > + cvs checkout: Updating src/sys/gnu/i386/isa > + cvs checkout: cannot open CVS/Entries for reading: No such file or directory > + cvs [checkout aborted]: cannot open CVS/Root: No such file or directory > I've never seen this though. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sat Apr 6 06:59:22 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA02003 for current-outgoing; Sat, 6 Apr 1996 06:59:22 -0800 (PST) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id GAA01998 for ; Sat, 6 Apr 1996 06:59:20 -0800 (PST) Received: by pcnet1.pcnet.com (4.1/SMI-4.1) id AA06406; Sat, 6 Apr 96 09:56:27 EST Date: Sat, 6 Apr 96 09:56:27 EST From: eischen@vigrid.com (Daniel Eischen) Message-Id: <9604061456.AA06406@pcnet1.pcnet.com> To: freebsd@hopf.math.purdue.edu, msmith@atrad.adelaide.edu.au Subject: Re: Clean reboot on current Cc: current@freefall.freebsd.org, wilker@hopf.math.purdue.edu Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Clarence Wilkerson stands accused of saying: > > When I do a few syncs and a "reboot" command, I get a string of > > numbers like > > > > 3 3 3 3 3 3 "giving up" > > The '3' indicates the number of disk buffers that are waiting to be > written. Do you get the same result with 'shutdown -r now'? > If not, then you probably have an application that's unhappy about being > nuked. Like a Linux partition that is still mounted at reboot time? That's what I get if I fail to umount the Linux partition before rebooting. Booting Linux (eek! I hate to admit it) then requires a file system check. Dan Eischen eischen@pcnet.com From owner-freebsd-current Sat Apr 6 07:04:32 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA02218 for current-outgoing; Sat, 6 Apr 1996 07:04:32 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id HAA02213 for ; Sat, 6 Apr 1996 07:04:27 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id AAA04291; Sun, 7 Apr 1996 00:59:49 +0930 From: Michael Smith Message-Id: <199604061529.AAA04291@genesis.atrad.adelaide.edu.au> Subject: Re: Clean reboot on current To: eischen@vigrid.com (Daniel Eischen) Date: Sun, 7 Apr 1996 00:59:49 +0930 (CST) Cc: freebsd@hopf.math.purdue.edu, msmith@atrad.adelaide.edu.au, current@freefall.freebsd.org, wilker@hopf.math.purdue.edu In-Reply-To: <9604061456.AA06406@pcnet1.pcnet.com> from "Daniel Eischen" at Apr 6, 96 09:56:27 am MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Daniel Eischen stands accused of saying: > > > > The '3' indicates the number of disk buffers that are waiting to be > > written. Do you get the same result with 'shutdown -r now'? > > If not, then you probably have an application that's unhappy about being > > nuked. > > Like a Linux partition that is still mounted at reboot time? That's what > I get if I fail to umount the Linux partition before rebooting. Booting > Linux (eek! I hate to admit it) then requires a file system check. Ah, that would probably be a bug in the e2fs, and should be reported so it can be fixed. Please file a pr on it! > Dan Eischen -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[ From owner-freebsd-current Sat Apr 6 07:17:31 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA02615 for current-outgoing; Sat, 6 Apr 1996 07:17:31 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA02608 Sat, 6 Apr 1996 07:17:28 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0u5Zjx-0003vqC; Sat, 6 Apr 96 07:17 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id PAA04245; Sat, 6 Apr 1996 15:17:23 GMT X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: paul@netcraft.co.uk cc: mpp@freefall.freebsd.org (Mike Pritchard), freebsd-current@freefall.freebsd.org Subject: Re: sup/cvs tags In-reply-to: Your message of "Sat, 06 Apr 1996 14:46:15 +0100." <199604061346.OAA00485@originat.demon.co.uk> Date: Sat, 06 Apr 1996 15:17:22 +0000 Message-ID: <4243.828803842@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > In reply to Mike Pritchard who said > > > > In the future can we try and avoid tagging the kernel source tree > > except at release time? The wollman_polling tag is causing anyone > > who sups the cvs files to receive every file in /usr/src/sys just > > because of the new tag. This looks to be about 33 megabytes of data, > > which is quite painful over a slow link. > > I agree. The FreeBSD cvs tree isn't for personal development and I'm > a bit miffed that Garret has been allowed to get away with putting in > a personal tag. If it's not ready to go in the main development tree then > it doesn't belong at all. We'll have a real mess if we all start creating > personal branches. "allowed" ?? He didn't make the mistake to ask if it were a good idea :-( -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Sat Apr 6 07:30:24 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA03215 for current-outgoing; Sat, 6 Apr 1996 07:30:24 -0800 (PST) Received: from diablo.ppp.de (diablo.ppp.de [193.141.101.34]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA03210 for ; Sat, 6 Apr 1996 07:30:20 -0800 (PST) Received: from allegro.lemis.de by diablo.ppp.de with smtp (Smail3.1.28.1 #1) id m0u5ZwQ-000QY4C; Sat, 6 Apr 96 17:30 MET DST From: grog@lemis.de (Greg Lehey) Organisation: LEMIS, Schellnhausen 2, 36325 Feldatal, Germany Phone: +49-6637-919123 Fax: +49-6637-919122 Received: (grog@localhost) by allegro.lemis.de (8.6.9/8.6.9) id RAA21824; Sat, 6 Apr 1996 17:24:12 +0200 Message-Id: <199604061524.RAA21824@allegro.lemis.de> Subject: Re: CVS: What am I doing wrong? To: joerg_wunsch@uriah.heep.sax.de Date: Sat, 6 Apr 1996 17:24:12 +0200 (MET DST) Cc: freebsd-current@FreeBSD.org, grog@lemis.de In-Reply-To: <199604061409.QAA01190@uriah.heep.sax.de> from "J Wunsch" at Apr 6, 96 04:09:02 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk J Wunsch writes: > > As Greg Lehey wrote: > >> I started in an empty directory called /src/2.2-CURRENT. With the >> command >> >> cvs -r co src >> >> I expect to get a complete, read-only source tree attached to the >> current directory. Instead, I get: >> >> + cvs checkout: Updating src >> + U src/COPYRIGHT > > cvs co uses the module name as its subdir by default. Override this > with > > cvs -r co -d . src > > if you don't like it. No, that wasn't the problem. Why is it saying "updating" and printing a U when there was nothing there before? >> + cvs checkout: Updating src/sys/gnu/i386/isa >> + cvs checkout: cannot open CVS/Entries for reading: No such file or directory >> + cvs [checkout aborted]: cannot open CVS/Root: No such file or directory >> > > I've never seen this though. I removed the whole directory hierarchy and started again. It still said "Updating", but it didn't trip over these directories (there was one other, but I didn't go through to the end of the hierarchy). The question is, have I done something the first time round that stopped it from happening again? I had a look in the repository (/src/cvs/src/sys/gnu/i386/isa/), but nothing changed status round that time. Greg From owner-freebsd-current Sat Apr 6 07:47:18 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA04140 for current-outgoing; Sat, 6 Apr 1996 07:47:18 -0800 (PST) Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id HAA04112 for ; Sat, 6 Apr 1996 07:47:15 -0800 (PST) Received: (from julian@localhost) by ref.tfs.com (8.7.3/8.6.9) id MAA13929; Fri, 5 Apr 1996 12:11:49 -0800 (PST) Message-Id: <199604052011.MAA13929@ref.tfs.com> Subject: Re: fast memory copy for large data sizes To: mrami@minerva.cis.yale.edu Date: Fri, 5 Apr 1996 12:11:49 -0800 (PST) From: "JULIAN Elischer" Cc: asami@cs.berkeley.edu, current@freebsd.org, nisha@cs.berkeley.edu, tege@matematik.su.se, hasty@rah.star-gate.com In-Reply-To: from "Marc Ramirez" at Apr 5, 96 02:13:11 pm X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > sh runtests > size libc ours > 32 7.629395 MB/s 7.629395 MB/s > 64 12.207031 MB/s 4.695012 MB/s [...] > 2097152 12.164192 MB/s 7.725020 MB/s > 4194304 12.290410 MB/s 7.719504 MB/s > mrami[~/bcopy]$ these tests SEEM to be indicating that the bcopy in libc is already better! or am I misreading something? julian From owner-freebsd-current Sat Apr 6 08:19:08 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA05662 for current-outgoing; Sat, 6 Apr 1996 08:19:08 -0800 (PST) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id IAA05655 for ; Sat, 6 Apr 1996 08:18:59 -0800 (PST) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) id SAA05605 for current@freebsd.org; Sat, 6 Apr 1996 18:00:46 +0200 (MET DST) Received: from localhost (localhost [127.0.0.1]) by knobel.gun.de (8.7.5/8.7.3) with SMTP id RAA01386 for ; Sat, 6 Apr 1996 17:41:50 +0200 (MET DST) Date: Sat, 6 Apr 1996 17:41:49 +0200 (MET DST) From: Andreas Klemm To: current@freebsd.org Subject: add rplay in /etc/services Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- If you like to add rplay into the list of known services ... here is the diff... Thanks Andreas /// diff -u -r1.21 services - --- services 1996/03/08 10:54:00 1.21 +++ services 1996/04/06 15:39:36 @@ -1594,6 +1594,7 @@ hacl-local 5304/udp hacl-test 5305/tcp hacl-test 5305/udp +rplay 5555/udp proshareaudio 5713/tcp #proshare conf audio proshareaudio 5713/udp #proshare conf audio prosharevideo 5714/tcp #proshare conf video andreas@knobel.gun.de /\/\___ Wiechers & Partner Datentechnik GmbH Andreas Klemm ___/\/\/ $$ Support Unix - aklemm@wup.de $$ pgp p-key http://www-swiss.ai.mit.edu/~bal/pks-toplev.html >>> powered by <<< ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz >>> FreeBSD <<< -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMWaQvfMLpmkD/U+FAQGXIwQAo25xYuRp/RcyLXIF0S4rAFor0xK5bY9o t8kWpbFbBXFbeYKnP2nWjv53NDvAsW70lHr4lX+HQgH+Pdpt14+fm2fITeRgCRsj nmNfzosSokXXuOzyQ+OUlT1DKZThjTGwANPG7PKwWKobBRiB80/LRS0Mwxe498yy fLQAasmd6RA= =hrQ0 -----END PGP SIGNATURE----- From owner-freebsd-current Sat Apr 6 08:21:36 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA05884 for current-outgoing; Sat, 6 Apr 1996 08:21:36 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id IAA05877 for ; Sat, 6 Apr 1996 08:21:32 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id SAA15461; Sat, 6 Apr 1996 18:20:40 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id SAA20295; Sat, 6 Apr 1996 18:20:40 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id SAA01686; Sat, 6 Apr 1996 18:07:38 +0200 (MET DST) From: J Wunsch Message-Id: <199604061607.SAA01686@uriah.heep.sax.de> Subject: Re: CVS: What am I doing wrong? To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sat, 6 Apr 1996 18:07:37 +0200 (MET DST) Cc: grog@lemis.de (Greg Lehey) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199604061524.RAA21824@allegro.lemis.de> from "Greg Lehey" at Apr 6, 96 05:24:12 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Greg Lehey wrote: > No, that wasn't the problem. Why is it saying "updating" and printing > a U when there was nothing there before? I updates the directory. :-) It always says ``updating''. Actually, you can often intermix cvs update and cvs checkout, they're doing mostly the same. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sat Apr 6 08:40:55 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA06946 for current-outgoing; Sat, 6 Apr 1996 08:40:55 -0800 (PST) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id IAA06931 for ; Sat, 6 Apr 1996 08:40:52 -0800 (PST) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id JAA21818; Sat, 6 Apr 1996 09:40:43 -0700 Date: Sat, 6 Apr 1996 09:40:43 -0700 From: Nate Williams Message-Id: <199604061640.JAA21818@rocky.sri.MT.net> To: paul@netcraft.co.uk Cc: freebsd-current@freefall.freebsd.org Subject: Re: sup/cvs tags In-Reply-To: <199604061346.OAA00485@originat.demon.co.uk> References: <199604052259.OAA19443@freefall.freebsd.org> <199604061346.OAA00485@originat.demon.co.uk> Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Paul Richards writes: > In reply to Mike Pritchard who said > > > > In the future can we try and avoid tagging the kernel source tree > > except at release time? The wollman_polling tag is causing anyone > > who sups the cvs files to receive every file in /usr/src/sys just > > because of the new tag. This looks to be about 33 megabytes of data, > > which is quite painful over a slow link. > > I agree. The FreeBSD cvs tree isn't for personal development and I'm > a bit miffed that Garret has been allowed to get away with putting in > a personal tag. I disagree. I think we don't use the full capabilities of CVS, and just because it might be painful for folks on slow links (and *NO* one has a slower link than me, so don't even try to argue that point), the benefits of being able to see the new code and possibility of getting newer code in the tree far outweighs the costs of increased transmission times. If it means we all switch to CTM (ugh, no offense Poul) then so be it. I'd *LOVE* to be able to apply the PC-CARD patches to a branch so that folks could get at them, and I could merge them into -current and -stable *AND* still allow folks to use them. As it stands now, they are dependant on me making a new (external) patch-set everytime I make significant changes to the code, which is a lot of work for me and a lot of work for them. With a branch on the tree much of this work would go away. Nate From owner-freebsd-current Sat Apr 6 09:01:39 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA07494 for current-outgoing; Sat, 6 Apr 1996 09:01:39 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA07489 for ; Sat, 6 Apr 1996 09:01:34 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id CAA02813; Sun, 7 Apr 1996 02:57:39 +1000 Date: Sun, 7 Apr 1996 02:57:39 +1000 From: Bruce Evans Message-Id: <199604061657.CAA02813@godzilla.zeta.org.au> To: freebsd-current@FreeBSD.ORG, j@uriah.heep.sax.de Subject: Re: devfs questions Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Alas, the next would be fsck'ing, and so the big question is: how are >the slice and partition entries supposed to be created? This doesn't work right yet. Initially there are only whole-disk device names. Opening these creates the slice device names. Opening the slices creates the partition device names. I think the root partition gets opened by number (dev_t) so all the slice names and all the partitions on the root slice get created. Opening everything at attach time would probably work OK for fixed media. It fails for removable media. Consider floppies. Due to your second-favourite PC design feature (:-), there is no good way to tell if there is a floppy in the drive. I've just fixed the floppy devfs names. The unit numbering was wrong (fd1 was type 8), the links to fd.xxxx were bogus, and most of the fd.xxxx's weren't created. There are now too many devices: fd0 fd0f fd1c rfd0.820 rfd1.360 fd0.1200 fd0g fd1d rfd0a rfd1.720 fd0.1440 fd0h fd1e rfd0b rfd1.800 fd0.1480 fd1 fd1f rfd0c rfd1.820 fd0.1720 fd1.1200 fd1g rfd0d rfd1a fd0.720 fd1.1440 fd1h rfd0e rfd1b fd0.800 fd1.1480 rfd0 rfd0f rfd1c fd0.820 fd1.360 rfd0.1200 rfd0g rfd1d fd0a fd1.720 rfd0.1440 rfd0h rfd1e fd0b fd1.800 rfd0.1480 rfd1 rfd1f fd0c fd1.820 rfd0.1720 rfd1.1200 rfd1g fd0d fd1a rfd0.720 rfd1.1440 rfd1h fd0e fd1b rfd0.800 rfd1.1480 Note that fd0.360 doesn't exist since fd0 is 1440K, and fd1.1720 doesn't exist since fd1 is 1200K. The devices [r]fd[0-1][a-h] are fairly useless links to [r]fd[0-1]. The 1480K and 1720K devices are actually 1476K and 1722K and should be renamed. I normally use a sliced version of this which only generates whole-disk devices except of course when there are real partitions. Slicing and partitioning of the fd.xxxx devices isn't supported. Bruce From owner-freebsd-current Sat Apr 6 09:04:05 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA07585 for current-outgoing; Sat, 6 Apr 1996 09:04:05 -0800 (PST) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id JAA07580 Sat, 6 Apr 1996 09:04:02 -0800 (PST) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) id SAA25995; Sat, 6 Apr 1996 18:45:23 +0200 (MET DST) Received: from localhost (localhost [127.0.0.1]) by knobel.gun.de (8.7.5/8.7.3) with SMTP id SAA00282; Sat, 6 Apr 1996 18:47:23 +0200 (MET DST) Date: Sat, 6 Apr 1996 18:47:22 +0200 (MET DST) From: Andreas Klemm To: phk@freebsd.org cc: current@freebsd.org Subject: syntax error in /etc/netstart Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hi Poul ! Was just updating my /etc/files and noticed during next reboot a syntax error somewhere in the startup scripts. Some set -x brought me to /etc/netstart. I think a -a makes most sense in this context :-). Here is the diff... Andreas /// RCS file: /cvs/src/etc/netstart,v retrieving revision 1.43 diff -u -r1.43 netstart - --- netstart 1996/04/03 17:13:58 1.43 +++ netstart 1996/04/06 16:41:13 @@ -24,7 +24,7 @@ fi # If IP filtering - -if [ -n "$firewall" -a "x$firewall" != "xNO" -f /etc/rc.firewall ] ; then +if [ -n "$firewall" -a "x$firewall" != "xNO" -a -f /etc/rc.firewall ] ; then sh /etc/rc.firewall fi - -- andreas@knobel.gun.de /\/\___ Wiechers & Partner Datentechnik GmbH Andreas Klemm ___/\/\/ $$ Support Unix - aklemm@wup.de $$ pgp p-key http://www-swiss.ai.mit.edu/~bal/pks-toplev.html >>> powered by <<< ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz >>> FreeBSD <<< -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMWagGvMLpmkD/U+FAQHb4gQAhZfluBwaPRyUaHghidKataGfUlMJOLHk 3f5FoKA2WVyWg4FLoAqDmiDrLQQuYrbRHciRUIo9UfWmfp7xGtW4pdFg3LjI9MSR sXEZCiUzBHVMhHiRv0VDZENN967LyUu76gtpkIx6U9xpx3jUeBs6gFarVJilokir 7Ofbwo+W/XU= =Dvwa -----END PGP SIGNATURE----- From owner-freebsd-current Sat Apr 6 09:32:43 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA08816 for current-outgoing; Sat, 6 Apr 1996 09:32:43 -0800 (PST) Received: from gauss.math.purdue.edu (gauss.math.purdue.edu [128.210.21.2]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id JAA08745 for ; Sat, 6 Apr 1996 09:32:26 -0800 (PST) Received: from hopf.math.purdue.edu (uucp@hopf.math.purdue.edu [128.210.3.18]) by gauss.math.purdue.edu (8.7.4/Purdue_Math) with ESMTP id MAA15208; Sat, 6 Apr 1996 12:32:19 -0500 (EST) Received: (from uucp@localhost) by hopf.math.purdue.edu (8.7.1/8.6.11) with UUCP id MAA23754; Sat, 6 Apr 1996 12:32:15 -0500 (EST) Received: from hopf2.math.purdue.edu (localhost [127.0.0.1]) by hopf2.cww.home.edu (8.6.11/8.6.11) with ESMTP id MAA01402; Sat, 6 Apr 1996 12:31:58 -0500 Message-Id: <199604061731.MAA01402@hopf2.cww.home.edu> To: Michael Smith cc: eischen@vigrid.com (Daniel Eischen), freebsd@hopf.math.purdue.edu, current@freefall.freebsd.org, wilker@math.purdue.edu Reply-To: wilker@math.purdue.edu Subject: Re: Clean reboot on current In-reply-to: Your message of "Sun, 07 Apr 1996 00:59:49 +0930." <199604061529.AAA04291@genesis.atrad.adelaide.edu.au> Date: Sat, 06 Apr 1996 12:31:55 -0500 From: "Clarence Wilkerson, " Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk You're right. I have a kinux ext2fs partition mounted. Unmounting it before reboot stopped the problem. How do I file a PR? Clarence From owner-freebsd-current Sat Apr 6 09:54:52 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA09343 for current-outgoing; Sat, 6 Apr 1996 09:54:52 -0800 (PST) Received: from insanus.matematik.su.se (insanus.matematik.su.se [130.237.198.12]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id JAA09336 for ; Sat, 6 Apr 1996 09:54:49 -0800 (PST) Received: from localhost (prudens.matematik.su.se [130.237.198.5]) by insanus.matematik.su.se (8.7.5/8.6.9) with ESMTP id TAA17355; Sat, 6 Apr 1996 19:54:30 +0200 (MET DST) Message-Id: <199604061754.TAA17355@insanus.matematik.su.se> X-Address: Department of Mathematics, Stockholm University S-106 91 Stockholm SWEDEN X-Phone: int+46 8 162000 X-Fax: int+46 8 6126717 X-Url: http://www.matematik.su.se To: Bruce Evans cc: asami@cs.berkeley.edu, current@freebsd.org, hasty@rah.star-gate.com, mrami@minerva.cis.yale.edu, nisha@cs.berkeley.edu, tege@matematik.su.se Subject: Re: optimized bzeros found harmful (was: fast memory copy ...) In-reply-to: Your message of "Sat, 06 Apr 1996 09:13:46 +1000." <199604052313.JAA28956@godzilla.zeta.org.au> Date: Sat, 06 Apr 1996 19:54:25 +0200 From: Torbjorn Granlund Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This behaviour is consistent with the data being zeroed usually not being in the L2 cache. RBW is 33% slower in that case on my system. Other cases: if the data is in the L2 cache but not in the L1 cache, then RBW is between 0% and 33% faster; if data the data is in the L1 cache, then RBW is 8.5 times faster (740MB/s!). This must be a misunderstanding! If the data is really in the L1 cache, the read-before-write is wasted and just contributes to the overhead. The read-before-write is effective if and only if the data is not in the L1 cache. In that case, it forces allocation of the cache line in the L1 cache, and thereby allows a 14x peak speedup. If other behaviours are observed, the timing framework confuses you. All other CPUs I know of have caches that do allocate-on-write. From owner-freebsd-current Sat Apr 6 10:23:11 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA10148 for current-outgoing; Sat, 6 Apr 1996 10:23:11 -0800 (PST) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA10142 for ; Sat, 6 Apr 1996 10:23:09 -0800 (PST) Received: by pcnet1.pcnet.com (4.1/SMI-4.1) id AA14775; Sat, 6 Apr 96 13:20:16 EST Date: Sat, 6 Apr 96 13:20:16 EST From: eischen@vigrid.com (Daniel Eischen) Message-Id: <9604061820.AA14775@pcnet1.pcnet.com> To: msmith@atrad.adelaide.edu.au, wilker@MATH.Purdue.EDU Subject: Re: Clean reboot on current Cc: current@freefall.freebsd.org, eischen@vigrid.com, freebsd@hopf.math.purdue.edu Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >You're right. I have a kinux ext2fs partition mounted. >Unmounting it before reboot stopped the problem. > >How do I file a PR? I just filed a PR, but if you need to file another one sometime, use send-pr(1). Dan Eischen eischen@vigrid.com From owner-freebsd-current Sat Apr 6 11:26:43 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA11764 for current-outgoing; Sat, 6 Apr 1996 11:26:43 -0800 (PST) Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA11759 for ; Sat, 6 Apr 1996 11:26:41 -0800 (PST) Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA07184; Sat, 6 Apr 1996 14:25:45 -0500 Date: Sat, 6 Apr 1996 14:25:45 -0500 From: Garrett Wollman Message-Id: <9604061925.AA07184@halloran-eldar.lcs.mit.edu> To: Bruce Evans Cc: freebsd-current@FreeBSD.org, peter@jhome.DIALix.COM Subject: Re: sup/cvs tags In-Reply-To: <199604060734.RAA15566@godzilla.zeta.org.au> References: <199604060734.RAA15566@godzilla.zeta.org.au> Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk < said: > BTW, what is the best way to look at the diffs in the wollman_polling > branch? `cvs diff -r HEAD -r wollman_polling' gave too many current > diffs just one or two days after the branch. How do I get the date > of the branch in a form suitable for `cvs diff -D'? It seems to me a bug that CVS won't take as input the date format that RCS outputs... In any event, you can say ``cvs diff -D '1 april' -r wollman_polling'' and get reasonable-looking diffs. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-current Sat Apr 6 12:06:49 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA12806 for current-outgoing; Sat, 6 Apr 1996 12:06:49 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA12801 for ; Sat, 6 Apr 1996 12:06:46 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id GAA08258; Sun, 7 Apr 1996 06:01:26 +1000 Date: Sun, 7 Apr 1996 06:01:26 +1000 From: Bruce Evans Message-Id: <199604062001.GAA08258@godzilla.zeta.org.au> To: bde@zeta.org.au, tege@matematik.su.se Subject: Re: optimized bzeros found harmful (was: fast memory copy ...) Cc: asami@cs.berkeley.edu, current@FreeBSD.org, hasty@rah.star-gate.com, mrami@minerva.cis.yale.edu, nisha@cs.berkeley.edu Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > This behaviour is consistent with the data being zeroed usually not being > in the L2 cache. RBW is 33% slower in that case on my system. Other > cases: if the data is in the L2 cache but not in the L1 cache, then RBW > is between 0% and 33% faster; if data the data is in the L1 cache, then > RBW is 8.5 times faster (740MB/s!). >This must be a misunderstanding! >If the data is really in the L1 cache, the read-before-write is wasted and >just contributes to the overhead. It must not be in the L1 cache. (Why not?) `perfmon' in -currrent shows much more bus activity for write test 3 than for write test 4. E.g., counter 25 (PMC5_WRITE_BACKUP_STALL) is about 117e6 events for test 3 and only 5e6 for test 4. This is for copying a total amount of 100e6 bytes. Let's see your output for `./w -5' and your explanation of it. >The read-before-write is effective if and only if the data is not in the L1 >cache. In that case, it forces allocation of the cache line in the L1 >cache, and thereby allows a 14x peak speedup. >If other behaviours are observed, the timing framework confuses you. Let's see you output for `./w -l 65536 -5'. 64K should fit in the L2 cache (512K). Why does read-before-write give only a 25% speedup? >All other CPUs I know of have caches that do allocate-on-write. Perhaps the Pentium behaviour is best. It seems to penalize writing to the same location without reading it, but this is abnormal behaviour. Bruce From owner-freebsd-current Sat Apr 6 12:47:24 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA15455 for current-outgoing; Sat, 6 Apr 1996 12:47:24 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA15440 for ; Sat, 6 Apr 1996 12:47:22 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0u5etB-0003wHC; Sat, 6 Apr 96 12:47 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id UAA04587; Sat, 6 Apr 1996 20:47:18 GMT X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: Nate Williams cc: paul@netcraft.co.uk, freebsd-current@freefall.freebsd.org Subject: Re: sup/cvs tags In-reply-to: Your message of "Sat, 06 Apr 1996 09:40:43 MST." <199604061640.JAA21818@rocky.sri.MT.net> Date: Sat, 06 Apr 1996 20:47:17 +0000 Message-ID: <4585.828823637@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I agree. The FreeBSD cvs tree isn't for personal development and I'm > > a bit miffed that Garret has been allowed to get away with putting in > > a personal tag. > > I disagree. I think we don't use the full capabilities of CVS, and just > because it might be painful for folks on slow links (and *NO* one has a Maybe the right thing to do would be to make a branch for all core-members (and other significant developers) once and for all... -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Sat Apr 6 16:21:09 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA25265 for current-outgoing; Sat, 6 Apr 1996 16:21:09 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id QAA25258 for ; Sat, 6 Apr 1996 16:21:06 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id CAA22793 for ; Sun, 7 Apr 1996 02:21:04 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id CAA26663 for freebsd-current@FreeBSD.org; Sun, 7 Apr 1996 02:21:04 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id BAA12440 for freebsd-current@FreeBSD.org; Sun, 7 Apr 1996 01:43:09 +0200 (MET DST) From: J Wunsch Message-Id: <199604062343.BAA12440@uriah.heep.sax.de> Subject: Re: devfs questions To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sun, 7 Apr 1996 01:43:03 +0200 (MET DST) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199604061657.CAA02813@godzilla.zeta.org.au> from "Bruce Evans" at Apr 7, 96 02:57:39 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Bruce Evans wrote: > > >Alas, the next would be fsck'ing, and so the big question is: how are > >the slice and partition entries supposed to be created? > > This doesn't work right yet. Initially there are only whole-disk device > names. Opening these creates the slice device names. Opening the You mean, fsck (or mount) would have to open /dev/rsd0 before trying to fsck/mount /dev/rsd0e? > I've just fixed the floppy devfs names. The unit numbering was wrong > (fd1 was type 8), the links to fd.xxxx were bogus, and most of the > fd.xxxx's weren't created. There are now too many devices: I don't really like the current way either. The fd0.foo entries should be symlinks to `generic' fd0a ... fd0z entries, created by the rc mechanism instead of by devfs. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sat Apr 6 16:39:25 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA26230 for current-outgoing; Sat, 6 Apr 1996 16:39:25 -0800 (PST) Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id QAA26225 for ; Sat, 6 Apr 1996 16:39:23 -0800 (PST) Received: from localhost.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.7.4/8.7.3) with SMTP id TAA15273 for ; Sat, 6 Apr 1996 19:39:21 -0500 (EST) Message-Id: <199604070039.TAA15273@whizzo.transsys.com> X-Authentication-Warning: whizzo.transsys.com: Host localhost.transsys.com [127.0.0.1] didn't use HELO protocol To: current@freebsd.org From: "Louis A. Mamakos" Subject: psm.c PS/2 mouse driver and devfs Date: Sat, 06 Apr 1996 19:39:21 -0500 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've noticed messages like this in syslog, and finally decided to go looking for the cause: Apr 1 17:15:03 whizzo /kernel: Device psm0: name slot allocation failed (E=17) Apr 1 17:15:03 whizzo /kernel: Device npsm0: name slot allocation failed (E=17) It seems that the code which calls devfs to instantiate the device actually happens in the open routing of the driver, rather than the attach. So, if you start up another X session, the next time the device is opened you'll get the messages above. Hopefully there's nothing that's not obvious behind this; the mse.c driver has the devfs invocation where you'd expect, in the attach routine. Further, with the current state of affairs, you'd never be able to open the mouse using a devfs /dev since it's not there yet.. louie From owner-freebsd-current Sat Apr 6 16:39:52 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA26267 for current-outgoing; Sat, 6 Apr 1996 16:39:52 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id QAA26262 for ; Sat, 6 Apr 1996 16:39:51 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA28746; Sat, 6 Apr 1996 17:34:20 -0700 From: Terry Lambert Message-Id: <199604070034.RAA28746@phaeton.artisoft.com> Subject: Re: devfs questions To: joerg_wunsch@uriah.heep.sax.de Date: Sat, 6 Apr 1996 17:34:19 -0700 (MST) Cc: freebsd-current@FreeBSD.ORG In-Reply-To: <199604061327.PAA00612@uriah.heep.sax.de> from "J Wunsch" at Apr 6, 96 03:27:15 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I've started playing with devfs. Find below a patch to init(8) that > should allow the system to come up with an empty /dev directory as > long as devfs is statically available in the kernel. It tries to > mount /dev early in the game, before the first device node > (/dev/console) is about to be accessed. I've at least been able to > run the single-user shell with it. I still think that devfs should export the root directory and a dev directory and be mounted in the kernel. I think it is a bad thing to chang init this way. 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 Sat Apr 6 16:51:14 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA26691 for current-outgoing; Sat, 6 Apr 1996 16:51:14 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id QAA26686 for ; Sat, 6 Apr 1996 16:51:12 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA28784; Sat, 6 Apr 1996 17:45:20 -0700 From: Terry Lambert Message-Id: <199604070045.RAA28784@phaeton.artisoft.com> Subject: Re: devfs questions To: bde@zeta.org.au (Bruce Evans) Date: Sat, 6 Apr 1996 17:45:20 -0700 (MST) Cc: freebsd-current@FreeBSD.ORG, j@uriah.heep.sax.de In-Reply-To: <199604061657.CAA02813@godzilla.zeta.org.au> from "Bruce Evans" at Apr 7, 96 02:57:39 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-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >Alas, the next would be fsck'ing, and so the big question is: how are > >the slice and partition entries supposed to be created? > > This doesn't work right yet. Initially there are only whole-disk device > names. Opening these creates the slice device names. Opening the > slices creates the partition device names. I think the root partition > gets opened by number (dev_t) so all the slice names and all the > partitions on the root slice get created. > > Opening everything at attach time would probably work OK for fixed > media. It fails for removable media. Consider floppies. Due to > your second-favourite PC design feature (:-), there is no good way > to tell if there is a floppy in the drive. This is why you need "device arrival notification" of some kind, and the sub devices, if any, should be created as a result of callback recognition as a result of that event. A floppy device which probes true would "arrive", but subslices, if any, would not arrive without a "diskchange" notification. This could either be implicit in a mount request (in which case we should limit ourselves toa single "slice" per floppy" to get rid of the requirement for other sub-devices), or as a reult of a specific "diskchange" event. A "diskchange" program would only need to successfully cause aread for an inserted floppy to trigger the callback process. Devices created from callback registration need to self-verify (per the conversation about crashes and the current DOSFS code) on any attempt to access a created subdevices. This could be implied in the mount without a great deal of difficulty. Obviously, using this scheme, there would be a top level device for removable media at all times. Most 3.5" floppies support change notificatio, if we fix what Bruce noted the other day regarding IDE/EIDE controller port address conflicts and handling IDE/EIDE controller problems. > I've just fixed the floppy devfs names. The unit numbering was wrong > (fd1 was type 8), the links to fd.xxxx were bogus, and most of the > fd.xxxx's weren't created. There are now too many devices: > > fd0 fd0f fd1c rfd0.820 rfd1.360 > fd0.1200 fd0g fd1d rfd0a rfd1.720 > fd0.1440 fd0h fd1e rfd0b rfd1.800 > fd0.1480 fd1 fd1f rfd0c rfd1.820 > fd0.1720 fd1.1200 fd1g rfd0d rfd1a > fd0.720 fd1.1440 fd1h rfd0e rfd1b > fd0.800 fd1.1480 rfd0 rfd0f rfd1c > fd0.820 fd1.360 rfd0.1200 rfd0g rfd1d > fd0a fd1.720 rfd0.1440 rfd0h rfd1e > fd0b fd1.800 rfd0.1480 rfd1 rfd1f > fd0c fd1.820 rfd0.1720 rfd1.1200 rfd1g > fd0d fd1a rfd0.720 rfd1.1440 rfd1h > fd0e fd1b rfd0.800 rfd1.1480 > > Note that fd0.360 doesn't exist since fd0 is 1440K, and fd1.1720 > doesn't exist since fd1 is 1200K. The devices [r]fd[0-1][a-h] > are fairly useless links to [r]fd[0-1]. The 1480K and 1720K devices > are actually 1476K and 1722K and should be renamed. > > I normally use a sliced version of this which only generates whole-disk > devices except of course when there are real partitions. Slicing and > partitioning of the fd.xxxx devices isn't supported. Slicing floppies is obnoxious anyway. I would be tempted to reduce the name space clutter by imposing hierarchy on the device. Frankly, other than formatting (which can damn well take a parameter for it), there is really no need to have media density encoded in device names. If DOS can deal with format detection, we can damn well do the same. There is no such thing as "A:" and "A.1440:", etc.. 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 Sat Apr 6 17:06:19 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA27716 for current-outgoing; Sat, 6 Apr 1996 17:06:19 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id RAA27710 for ; Sat, 6 Apr 1996 17:06:17 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id SAA28828; Sat, 6 Apr 1996 18:00:08 -0700 From: Terry Lambert Message-Id: <199604070100.SAA28828@phaeton.artisoft.com> Subject: Re: sup/cvs tags To: phk@critter.tfs.com (Poul-Henning Kamp) Date: Sat, 6 Apr 1996 18:00:08 -0700 (MST) Cc: nate@sri.MT.net, paul@netcraft.co.uk, freebsd-current@freefall.freebsd.org In-Reply-To: <4585.828823637@critter.tfs.com> from "Poul-Henning Kamp" at Apr 6, 96 08:47: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-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > I agree. The FreeBSD cvs tree isn't for personal development and I'm > > > a bit miffed that Garret has been allowed to get away with putting in > > > a personal tag. > > > > I disagree. I think we don't use the full capabilities of CVS, and just > > because it might be painful for folks on slow links (and *NO* one has a > > Maybe the right thing to do would be to make a branch for all core-members > (and other significant developers) once and for all... What's needed is the ability to locally branch so that you can continue to recieve changes on the main source branch and still use local version control. This means that people like me can run under local source control with multiple seperately committable projects and still end up with combined sources for our own local builds. The problem here is the transport mechanism would need to be able to be flagged to list the branches to be transported. Neither SUP nor CTM are up to this job. Specifically, Garrett adding his tag would not affect you because unless you asked for his tagged branch, you'd only get the common source base in any case. THis would allow using the CVS tree for multiple combined projects that don't impact non-participants. If you aren't willing to fix the CVS, then you need to do what I do: lump it. I currently keep a difficult-to-maintain environment and my patches are submitted in difficult-to-piece-out form because I can't maintain local seperate and combined trees based on branch tags and branch merge on checkout. If you get large updates when a necessary tag goes in, live with it or fix CVS so you don't have to suffer as a result. But don't try and say "the tag should not go in because it is not convenient". Life is inconvenient. Deal with it. As to the idea of creating a branch for each core member and other significant developers, it doesn't deal with: 1) people without commit priviledges 2) developers with commit priveledges with multiple irons in the fire. I don't think the idea will result what you obviously intend: taking a large hit once to avoid taking future hits. Garrett's tag is not "garrett"... it is descriptive of the subproject. You could not reliably predict the names of all future subprojects and precreate them to save taking the hits. Say "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 Sat Apr 6 17:10:15 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA27961 for current-outgoing; Sat, 6 Apr 1996 17:10:15 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id RAA27953 for ; Sat, 6 Apr 1996 17:10:11 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id SAA28843; Sat, 6 Apr 1996 18:04:36 -0700 From: Terry Lambert Message-Id: <199604070104.SAA28843@phaeton.artisoft.com> Subject: Re: devfs questions To: joerg_wunsch@uriah.heep.sax.de Date: Sat, 6 Apr 1996 18:04:36 -0700 (MST) Cc: freebsd-current@freebsd.org In-Reply-To: <199604062343.BAA12440@uriah.heep.sax.de> from "J Wunsch" at Apr 7, 96 01:43:03 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-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > >Alas, the next would be fsck'ing, and so the big question is: how are > > >the slice and partition entries supposed to be created? > > > > This doesn't work right yet. Initially there are only whole-disk device > > names. Opening these creates the slice device names. Opening the > > You mean, fsck (or mount) would have to open /dev/rsd0 before trying > to fsck/mount /dev/rsd0e? That is how I read it too. This is a bad thing(tm). It is an acceptable penalty(tm) for removable media without change notification. > I don't really like the current way either. The fd0.foo entries > should be symlinks to `generic' fd0a ... fd0z entries, created by > the rc mechanism instead of by devfs. Bletch. The slices should not be there. You are imposing a naming convention that isn't very flexible an which we would then have to live with forever. Better to force "changedisk" and suggest people buy good floppy drives if they don't want to rely on explicit calls to the utility or implicit calls to the utility as a result of mount attempts, fsck attempts, etc.... on the basis that an access is an implicit request to verify "no change has occured" for removable media without notification. The first thing to do is to cause 0x370 referencing code to be added to the floppy driver so that this is not a problem for 95% of all 3.5" disks. 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 Sat Apr 6 17:16:27 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA28536 for current-outgoing; Sat, 6 Apr 1996 17:16:27 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id RAA28531 for ; Sat, 6 Apr 1996 17:16:25 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id SAA28868; Sat, 6 Apr 1996 18:10:25 -0700 From: Terry Lambert Message-Id: <199604070110.SAA28868@phaeton.artisoft.com> Subject: Re: psm.c PS/2 mouse driver and devfs To: louie@TransSys.COM (Louis A. Mamakos) Date: Sat, 6 Apr 1996 18:10:25 -0700 (MST) Cc: current@freebsd.org In-Reply-To: <199604070039.TAA15273@whizzo.transsys.com> from "Louis A. Mamakos" at Apr 6, 96 07:39:21 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-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I've noticed messages like this in syslog, and finally decided to go > looking for the cause: > > Apr 1 17:15:03 whizzo /kernel: Device psm0: name slot allocation failed (E=17) > Apr 1 17:15:03 whizzo /kernel: Device npsm0: name slot allocation failed (E=17) > > It seems that the code which calls devfs to instantiate the device > actually happens in the open routing of the driver, rather than the > attach. So, if you start up another X session, the next time the > device is opened you'll get the messages above. > > Hopefully there's nothing that's not obvious behind this; the mse.c > driver has the devfs invocation where you'd expect, in the attach > routine. Further, with the current state of affairs, you'd never be > able to open the mouse using a devfs /dev since it's not there yet.. Mice are insufficiently virtualized to allow this to work at the present time. In reality, mice should be bound through the console code, and then virtualized along with the screen and keyboard instances as a result. The Microsoft Windows95 DDK has sample code that probes serial ports for mice and assigns them as class devices based on whether the device probes true or not. This type of code should probably go into the serial port probes to tell the system that a serial port with a mouse is not a serial port. There is still the issue of dealing with busmouse polling, and abstracting the mouse protocol, as well as all the other well known failings of the console code and X doing direct port I/O to set modes of which the console code has no knowledge. This is not abug which can be simply fixed if it is to be fixed completely. 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 Sat Apr 6 17:19:25 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA28905 for current-outgoing; Sat, 6 Apr 1996 17:19:25 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id RAA28878 for ; Sat, 6 Apr 1996 17:19:21 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id DAA23684 for ; Sun, 7 Apr 1996 03:19:18 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id DAA27226 for freebsd-current@FreeBSD.org; Sun, 7 Apr 1996 03:19:18 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id DAA15010 for freebsd-current@FreeBSD.org; Sun, 7 Apr 1996 03:01:37 +0200 (MET DST) From: J Wunsch Message-Id: <199604070101.DAA15010@uriah.heep.sax.de> Subject: Re: devfs questions To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sun, 7 Apr 1996 03:01:37 +0200 (MET DST) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199604070034.RAA28746@phaeton.artisoft.com> from "Terry Lambert" at Apr 6, 96 05:34:19 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Terry Lambert wrote: > I still think that devfs should export the root directory and a dev > directory and be mounted in the kernel. Why? And what's devfs' job wrt. the root dir? > I think it is a bad thing to chang init this way. What's the basical difference? (Despite, it's perhaps not much harder either, but i'm curious about your reasons.) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sat Apr 6 17:19:26 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA28906 for current-outgoing; Sat, 6 Apr 1996 17:19:26 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id RAA28883 for ; Sat, 6 Apr 1996 17:19:22 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id DAA23688 for ; Sun, 7 Apr 1996 03:19:20 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id DAA27228 for freebsd-current@FreeBSD.org; Sun, 7 Apr 1996 03:19:19 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id DAA15087 for freebsd-current@FreeBSD.org; Sun, 7 Apr 1996 03:03:02 +0200 (MET DST) From: J Wunsch Message-Id: <199604070103.DAA15087@uriah.heep.sax.de> Subject: Re: add rplay in /etc/services To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sun, 7 Apr 1996 03:03:01 +0200 (MET DST) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from "Andreas Klemm" at Apr 6, 96 05:41:49 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Andreas Klemm wrote: > If you like to add rplay into the list of known services ... > here is the diff... Thanks! -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sat Apr 6 17:51:44 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA00627 for current-outgoing; Sat, 6 Apr 1996 17:51:44 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id RAA00602 for ; Sat, 6 Apr 1996 17:51:40 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id DAA24081 for ; Sun, 7 Apr 1996 03:51:27 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id DAA27461 for freebsd-current@FreeBSD.org; Sun, 7 Apr 1996 03:51:27 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id DAA15356 for freebsd-current@FreeBSD.org; Sun, 7 Apr 1996 03:23:33 +0200 (MET DST) From: J Wunsch Message-Id: <199604070123.DAA15356@uriah.heep.sax.de> Subject: Re: devfs questions To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sun, 7 Apr 1996 03:23:33 +0200 (MET DST) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199604070045.RAA28784@phaeton.artisoft.com> from "Terry Lambert" at Apr 6, 96 05:45:20 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Terry Lambert wrote: > Frankly, other than formatting (which can damn well take a parameter > for it), there is really no need to have media density encoded in device > names. If DOS can deal with format detection, we can damn well do the > same. There is no such thing as "A:" and "A.1440:", etc.. DOS cannot really deal with format detection. It uses its superblock to decide about the media properties. It totally ignores non-DOS media. This is no excuse for not trying to automagically detect the floppy format, of course. I had it back in my CP/M floppy BIOS as well. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sat Apr 6 17:51:45 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA00634 for current-outgoing; Sat, 6 Apr 1996 17:51:45 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id RAA00598 for ; Sat, 6 Apr 1996 17:51:38 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id DAA24085 for ; Sun, 7 Apr 1996 03:51:29 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id DAA27462 for freebsd-current@FreeBSD.org; Sun, 7 Apr 1996 03:51:28 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id DAA15372 for freebsd-current@FreeBSD.org; Sun, 7 Apr 1996 03:28:50 +0200 (MET DST) From: J Wunsch Message-Id: <199604070128.DAA15372@uriah.heep.sax.de> Subject: Re: devfs questions To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sun, 7 Apr 1996 03:28:49 +0200 (MET DST) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199604070104.SAA28843@phaeton.artisoft.com> from "Terry Lambert" at Apr 6, 96 06:04:36 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Terry Lambert wrote: > > I don't really like the current way either. The fd0.foo entries > > should be symlinks to `generic' fd0a ... fd0z entries, created by > > the rc mechanism instead of by devfs. > > Bletch. The slices should not be there. You are imposing a naming > convention that isn't very flexible an which we would then have > to live with forever. Which slices? I'm simply implying some form of subdevices. The actual meaning of them is run-time selectable. It is already now, there's a mostly unused utility fdcontrol(8), you can use it to make your fd0.1720 device node accept 184 KB floppies instead. :-) All i want is generic names, and leave it to userland to find convenient names for it. Format autodetection will never work for all 5E+23 different floppy formats that are available in the world. > Better to force "changedisk" and suggest people buy good floppy > drives This is unrelated. Changelin support is unavailable for exotic drives, and i think it's also unavailable for drives 2 and 3. I agree that it should be used if it is there. (Didn't i say the floppy driver needs a rewrite? :-) > The first thing to do is to cause 0x370 referencing code to be added > to the floppy driver so that this is not a problem for 95% of all 3.5" > disks. There's not much different between modern 3.5in and 5.25in drives. All AT drives are supposed to support changeline logic, and systems like OS/2 do break if the drives are broken. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sat Apr 6 18:09:34 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA01724 for current-outgoing; Sat, 6 Apr 1996 18:09:34 -0800 (PST) Received: from spooky.apana.org.au (spooky.apana.org.au [203.3.126.200]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id SAA01713 for ; Sat, 6 Apr 1996 18:09:06 -0800 (PST) Received: (from ernie@localhost) by spooky.apana.org.au (8.7.5/8.6.12) id MAA05209 for freebsd-current@freebsd.org; Sun, 7 Apr 1996 12:23:54 +1000 (EST) Message-Id: <199604070223.MAA05209@spooky.apana.org.au> Subject: Make world failed To: freebsd-current@freebsd.org Date: Sun, 7 Apr 1996 12:23:53 +1000 (EST) From: "Ernie Elu" X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I tried a make world this morning with the following error" building special pic c library ld.so failed: open failed for "libc.so.3.0" : No such file or directory *** Error code 1 All was fine last weekend. I do a make world almost every weekend out of interst sake. - Ernie. From owner-freebsd-current Sat Apr 6 18:30:56 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA02701 for current-outgoing; Sat, 6 Apr 1996 18:30:56 -0800 (PST) Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id SAA02696 for ; Sat, 6 Apr 1996 18:30:53 -0800 (PST) Received: by sequent.kiae.su id AA19257 (5.65.kiae-2 for current@freebsd.org); Sun, 7 Apr 1996 05:19:18 +0300 Received: by sequent.KIAE.su (UUMAIL/2.0); Sun, 7 Apr 96 05:19:17 +0300 Received: (from ache@localhost) by astral.msk.su (8.7.5/8.7.3) id GAA00630 for current@freebsd.org; Sun, 7 Apr 1996 06:18:27 +0400 (MSD) Message-Id: <199604070218.GAA00630@astral.msk.su> Subject: routed delete my PPP default: how to fight it? To: current@freebsd.org (FreeBSD-current) Date: Sun, 7 Apr 1996 06:18:26 +0400 (MSD) From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast X-Mailer: ELM [version 2.4ME+ PL15 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I got very often: Apr 7 05:57:24 astral routed[51]: deleting route to interface tun0 (timed out) Apr 7 05:58:52 astral routed[51]: re-installing interface tun0 when carrier dropped. And sometimes "re-installing" not happens: it means that route died and no one package can cause on-demand redialing. How I can instruct routed NEVER delete route to tun0? -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-current Sat Apr 6 19:23:33 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id TAA06053 for current-outgoing; Sat, 6 Apr 1996 19:23:33 -0800 (PST) Received: from jhome.DIALix.COM (root@jhome.DIALix.COM [192.203.228.69]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id TAA06038 for ; Sat, 6 Apr 1996 19:23:24 -0800 (PST) Received: from localhost.DIALix.oz.au (peter@localhost.DIALix.oz.au [127.0.0.1]) by jhome.DIALix.COM (8.7.5/8.7.3) with SMTP id LAA03025; Sun, 7 Apr 1996 11:22:28 +0800 (WST) Message-Id: <199604070322.LAA03025@jhome.DIALix.COM> X-Authentication-Warning: jhome.DIALix.COM: Host peter@localhost.DIALix.oz.au [127.0.0.1] didn't use HELO protocol To: Garrett Wollman cc: Bruce Evans , freebsd-current@FreeBSD.org Subject: Re: sup/cvs tags In-reply-to: Your message of "Sat, 06 Apr 1996 14:25:45 EST." <9604061925.AA07184@halloran-eldar.lcs.mit.edu> Date: Sun, 07 Apr 1996 11:22:27 +0800 From: Peter Wemm Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >< said: > >> BTW, what is the best way to look at the diffs in the wollman_polling >> branch? `cvs diff -r HEAD -r wollman_polling' gave too many current >> diffs just one or two days after the branch. How do I get the date >> of the branch in a form suitable for `cvs diff -D'? > >It seems to me a bug that CVS won't take as input the date format that >RCS outputs... In any event, you can say ``cvs diff -D '1 april' -r >wollman_polling'' and get reasonable-looking diffs. > >-GAWollman That's why branch point tags are used.. to eliminate this ambiguity. What _should_ have happened when this was tagged was: cvs rtag wollman_pending_bp sys cvs rtag -r wollman_pending_bp -b wollman_pending sys cvs checkout -r wollman_pending sys And later, we could all do a: cvs [r]diff -r wollman_pending_bp -r wollman_pending and clearly see what you are working on. re: cvs's parsedate.y.. If anybody wants to fix it to understand all rcs's forms of date coding, be my guest. :-) I'm sure either Nate or I can take it back to the cvs developers and check it into the current source. Since CVS uses local time by default and RCS uses GMT, one has to be careful. I usually use something like: "3/31/96 10:00:07 GMT", but again one has to reverse the month and date into the "backwards" system the americans use. :-) Remember, to cvs, "april 1" covers a 24 hour time span, depending on where you are in the world. Cheers, -Peter From owner-freebsd-current Sat Apr 6 22:51:27 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA19668 for current-outgoing; Sat, 6 Apr 1996 22:51:27 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id WAA19658 for ; Sat, 6 Apr 1996 22:51:19 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id QAA31787; Sun, 7 Apr 1996 16:49:31 +1000 Date: Sun, 7 Apr 1996 16:49:31 +1000 From: Bruce Evans Message-Id: <199604070649.QAA31787@godzilla.zeta.org.au> To: freebsd-current@FreeBSD.org, j@uriah.heep.sax.de Subject: Re: devfs questions Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >> Better to force "changedisk" and suggest people buy good floppy >> drives >This is unrelated. Changelin support is unavailable for exotic >drives, and i think it's also unavailable for drives 2 and 3. I agree >that it should be used if it is there. (Didn't i say the floppy >driver needs a rewrite? :-) The change line is only valid while the motor is on, so it is almost useless for automatic slice building. Consider the following setup: - fd0 motor off. - all devices on fd0 closed. - drive was previously opened, and it had slices fd0s1..fd0s4 on it, and the slice driver has left these (possibly stale) devices in the devfs tree for convenience (this is what it does now). What happens an attempt is made to open /dev/fd0s4 and /dev/fd0s4 has gone away? Currently, the slice table is read and the open fails because fd0s4 no longer exists, and fd0s4 disappears from the devfs tree. This behaviour is right and wouldn't be significantly different if the disk change line was supported - the slice table would be read because the disk has changed instead of always like it is now. The case where fd0s4 doesn't exist in the devfs tree but exists on the disk after a disk change is more interesting/broken. Then there is no way to reference /dev/fd0s4 without first opening /dev/fd0 or some other existent slice or partition on fd0. Disk change line support wouldn't be much used for fixing this because disk changes aren't reported until you look. >> The first thing to do is to cause 0x370 referencing code to be added >> to the floppy driver so that this is not a problem for 95% of all 3.5" >> disks. >There's not much different between modern 3.5in and 5.25in drives. >All AT drives are supposed to support changeline logic, and systems >like OS/2 do break if the drives are broken. I have 2 out of 3 3.5in drives with broken change lines and 1 out of 3 much older but less fragile 5.25in drives with broken change lines :-(. This causes problems under DOS when I forget to hit ^C to tell it to reset the disk. It used to cause problems under Linux. Linux now has ioctls to disable the change line support. Installing new drives is not an acceptable fix because I break things at install time :-). Bruce From owner-freebsd-current Sat Apr 6 23:37:18 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA21587 for current-outgoing; Sat, 6 Apr 1996 23:37:18 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA21582 for ; Sat, 6 Apr 1996 23:37:14 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id RAA00643; Sun, 7 Apr 1996 17:34:58 +1000 Date: Sun, 7 Apr 1996 17:34:58 +1000 From: Bruce Evans Message-Id: <199604070734.RAA00643@godzilla.zeta.org.au> To: bde@zeta.org.au, terry@lambert.org Subject: Re: devfs questions Cc: freebsd-current@FreeBSD.ORG, j@uriah.heep.sax.de Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Most 3.5" floppies support change notificatio, if we fix what Bruce >noted the other day regarding IDE/EIDE controller port address >conflicts and handling IDE/EIDE controller problems. It's not a problem because splbio() locking is coarse-grained. >Slicing floppies is obnoxious anyway. It's good for debugging. Many forms of hardware braindamage are represented in the floppy device. Bruce