From owner-freebsd-current Sun Apr 14 00:00:44 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA01449 for current-outgoing; Sun, 14 Apr 1996 00:00:44 -0700 (PDT) Received: from bunyip.cc.uq.oz.au (pp@bunyip.cc.uq.oz.au [130.102.2.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id AAA01441 for ; Sun, 14 Apr 1996 00:00:42 -0700 (PDT) Received: from bunyip.cc.uq.oz.au by bunyip.cc.uq.oz.au id <00456-0@bunyip.cc.uq.oz.au>; Sun, 14 Apr 1996 17:00:19 +1000 Received: from netfl15a.devetir.qld.gov.au by pandora.devetir.qld.gov.au (8.6.10/DEVETIR-E0.3a) with ESMTP id QAA07382 for ; Sun, 14 Apr 1996 16:59:18 +1000 Received: from localhost by netfl15a.devetir.qld.gov.au (8.6.8.1/DEVETIR-0.1) id HAA01707 for ; Sun, 14 Apr 1996 07:05:21 GMT Message-Id: <199604140705.HAA01707@netfl15a.devetir.qld.gov.au> X-Mailer: exmh version 1.6.5 12/11/95 To: current@freebsd.org Subject: Something very odd... X-Face: 3}heU+2?b->-GSF-G4T4>jEB9~FR(V9lo&o>kAy=Pj&;oVOc<|pr%I/VSG"ZD32J>5gGC0N 7gj]^GI@M:LlqNd]|(2OxOxy@$6@/!,";-!OlucF^=jq8s57$%qXd/ieC8DhWmIy@J1AcnvSGV\|*! >Bvu7+0h4zCY^]{AxXKsDTlgA2m]fX$W@'8ev-Qi+-;%L'CcZ'NBL!@n?}q!M&Em3*eW7,093nOeV8 M)(u+6D;%B7j\XA/9j4!Gj~&jYzflG[#)E9sI&Xe9~y~Gn%fA7>F:YKr"Wx4cZU*6{^2ocZ!YyR Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 14 Apr 1996 17:05:20 +1000 From: Stephen Hocking Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'm doing a make all at the moment in /usr/src, and it's happily compiling away but not displaying any link commands for each command. What gives? Stephen -- The views expressed above are not those of the Worker's Compensation Board of Queensland, Australia. From owner-freebsd-current Sun Apr 14 01:35:40 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA08577 for current-outgoing; Sun, 14 Apr 1996 01:35:40 -0700 (PDT) Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id BAA08565 for ; Sun, 14 Apr 1996 01:35:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by Root.COM (8.7.5/8.6.5) with SMTP id BAA03267; Sun, 14 Apr 1996 01:35:17 -0700 (PDT) Message-Id: <199604140835.BAA03267@Root.COM> X-Authentication-Warning: implode.Root.COM: Host localhost [127.0.0.1] didn't use HELO protocol To: "Marc G. Fournier" cc: current@FreeBSD.org Subject: Re: File System Corruption *sigh* In-reply-to: Your message of "Sun, 14 Apr 1996 02:24:40 EDT." From: David Greenman Reply-To: davidg@Root.COM Date: Sun, 14 Apr 1996 01:35:17 -0700 Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > All of a sudden, I started getting: > >cc -c -O2 -m486 -pipe -W -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Winline -g -nostdinc -I. -I../.. -I../../sys -I../../../include -DI486_CPU -DCOMPAT_43 -DDEVFS -DNFS -DFFS -DINET -D >DODUMP -DKERNEL ../../kern/tty.c >In file included from ../../sys/types.h:46, > from ../../sys/param.h:54, > from ../../kern/tty.c:73: >./machine/ansi.h:52: warning: `/*' within comment > > For warnings under /usr/src/sys/compile/freebsd. Figuring them >for mere warnings, I kind of ignored them, but then got curious, since I've >never seen that warning before, so checked out the file, and found this >at line 52: > >#define _BSD_SIZE_T_ unsigned int /* sizeof ) * >#d`fin` _BSD_SSIZE_T_ int /* byte count or error */ >#define _BSD_TIME_T_ long /* time() */ > > Notice, as well, the corruption at the end of the BSD_SIZE_T >define... Try rebooting the machine and see if the data errors are only in the cache. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-current Sun Apr 14 01:43:10 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA09029 for current-outgoing; Sun, 14 Apr 1996 01:43:10 -0700 (PDT) Received: from ki.net (root@ki.net [205.150.102.1]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id BAA09021 for ; Sun, 14 Apr 1996 01:43:06 -0700 (PDT) Received: from freebsd.ki.net (root@freebsd.ki.net [205.150.102.51]) by ki.net (8.7.4/8.7.4) with ESMTP id EAA12265; Sun, 14 Apr 1996 04:43:12 -0400 (EDT) Received: from localhost (scrappy@localhost) by freebsd.ki.net (8.7.5/8.7.5) with SMTP id EAA00328; Sun, 14 Apr 1996 04:43:06 -0400 (EDT) X-Authentication-Warning: freebsd.ki.net: scrappy owned process doing -bs Date: Sun, 14 Apr 1996 04:43:05 -0400 (EDT) From: "Marc G. Fournier" To: David Greenman cc: current@FreeBSD.org Subject: Re: File System Corruption *sigh* In-Reply-To: <199604140835.BAA03267@Root.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 Sun, 14 Apr 1996, David Greenman wrote: > Try rebooting the machine and see if the data errors are only in the cache. > Next time I notice it happen, I will try that. In fact, when i come in tomorrow (well, later today, as its 5am here now) I'll try to pound it again and see if I come up with something similar. I manually edit'd the "corrupt" files this time in order that I could get my kernel compiled...hadn't thought of cache ;( Marc G. Fournier scrappy@ki.net Systems Administrator @ ki.net scrappy@freebsd.org From owner-freebsd-current Sun Apr 14 02:46:23 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA12117 for current-outgoing; Sun, 14 Apr 1996 02:46:23 -0700 (PDT) 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 CAA12112 for ; Sun, 14 Apr 1996 02:46:19 -0700 (PDT) Received: from gilberto.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de) by mail.rwth-aachen.de (PMDF V5.0-4 #13110) id <01I3J42KWX1S0013FO@mail.rwth-aachen.de>; Sun, 14 Apr 1996 11:45:07 +0100 Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.6.11/8.6.9) id LAA24933; Sun, 14 Apr 1996 11:50:48 +0200 Date: Sun, 14 Apr 1996 11:50:47 +0200 (MET DST) From: "Christoph P. Kukulies" Subject: Re: File System Corruption *sigh* In-reply-to: To: scrappy@ki.net (Marc G. Fournier) Cc: current@freebsd.org Reply-to: Christoph Kukulies Message-id: <199604140950.LAA24933@gilberto.physik.rwth-aachen.de> MIME-version: 1.0 X-Mailer: ELM [version 2.4 PL25 ME8b] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [stripped] > ./machine/ansi.h:52: warning: `/*' within comment I'd be interested to know what ./machine/ansi.h actually looks like. I have seen this some time ago in -current with a P150 IDE system. Didn't check though if the file was corrupt after a reboot. errno.h was corrupt with many charcters having some bits flipped. > > Marc G. Fournier scrappy@ki.net > Systems Administrator @ ki.net scrappy@freebsd.org > > --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-current Sun Apr 14 03:08:14 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA12790 for current-outgoing; Sun, 14 Apr 1996 03:08:14 -0700 (PDT) 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 DAA12783 Sun, 14 Apr 1996 03:08:11 -0700 (PDT) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) id LAA26150; Sun, 14 Apr 1996 11:45:39 +0200 (MET DST) Received: from localhost (localhost [127.0.0.1]) by knobel.gun.de (8.7.5/8.7.3) with SMTP id LAA04164; Sun, 14 Apr 1996 11:30:09 +0200 (MET DST) Date: Sun, 14 Apr 1996 11:30:08 +0200 (MET DST) From: Andreas Klemm To: Joerg Wunsch cc: FreeBSD-current users , Gary Clark II Subject: Re: Just how stable is current In-Reply-To: <199604131826.UAA21414@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 Sat, 13 Apr 1996, J Wunsch wrote: > As Gary Clark II wrote: > > > Yes, I know that this is a bad question to ask, but.... > > Mine's from the Easter weekend, and i can't complain. Yes, it's fine. - -- 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 iQCVAwUBMXDFoPMLpmkD/U+FAQHCPQP9EilMuf+UbZ0ejg2BE9BCYODFlnkilII0 ypvrzPxK4EQcKkLG30E/48ITXAV55DjSoOuzx7jjR0YkmXJPSgHRTptTNcVLm7l3 ZNS+3yrIRExjySrGVaM8nsJjYfUN+EfVNney0rkXEaAMD32Ym5G4Oxs4+WbyPCWA emrPMRKaYIA= =AXCP -----END PGP SIGNATURE----- From owner-freebsd-current Sun Apr 14 09:15:45 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA11808 for current-outgoing; Sun, 14 Apr 1996 09:15:45 -0700 (PDT) Received: from centauro.isr.uc.pt (centauro.isr.uc.pt [193.136.205.5]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA11491 for ; Sun, 14 Apr 1996 09:15:08 -0700 (PDT) Received: by centauro.isr.uc.pt (4.1/SMI-4.1) id AA14155; Sun, 14 Apr 96 17:14:42 +0100 Date: Sun, 14 Apr 1996 17:14:41 +0100 (WET DST) From: Paulo Menezes To: current@freebsd.org Subject: Another problem with Adaptec 2940 and S3TRIO64 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 I installed 2.1R in a HP Vectra VL 5/100. I have noticed that the system hangs during periods of heavy disk activity, with or without X86_S3 running. After the second hang I rebooted the machine and started to compile knews just to see if there was any message and ..... ahc0: target 0, lun 0 (sd0) timed out sd0(ahc0:0:0): BUS DEVICE RESET message queued. sd0(ahc0:0:0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted , retries:4 Can anyone tell me if this is related with my new hardware :-( ? Thanks Paulo ====================================================== FreeBSD 2.1.0-RELEASE #0: Sun Apr 14 03:55:07 1996 root@ener1000.dee.uc.pt:/usr/src/sys/compile/LOCAL CPU: 99-MHz Pentium 735\\90 or 815\\100 (Pentium-class CPU) Origin = "GenuineIntel" Id = 0x525 Stepping=5 Features=0x1bf real memory = 16777216 (16384K bytes) avail memory = 14827520 (14480K 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 not found at 0x280 ed1 at 0x300-0x31f irq 3 on isa ed1: address 00:80:c8:2b:86:be, type NE2000 (16 bit) sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1: disabled, not probed. lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface mse0: wrong signature ff mse0 not found at 0x23c psm0 at 0x60-0x63 irq 12 on motherboard fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 72065B fd0: 1.44MB 3.5in wdc0 not found at 0x1f0 wdc1 not found at 0x170 bt0 not found at 0x330 uha0 not found at 0x330 ahc1 not found ahb0 not found aha0 not found at 0x330 aic0 not found at 0x340 nca0 not found at 0x1f88 nca1 not found at 0x350 sea0 not found wt0 not probed due to I/O address conflict with ed1 at 0x300 mcd0 not probed due to I/O address conflict with ed1 at 0x300 mcd1: timeout getting status mcd1 not found at 0x340 matcdc0 not found at 0x230 scd0 not found at 0x230 ep0 not probed due to I/O address conflict with ed1 at 0x300 npx0 on motherboard npx0: INT 16 interface pcibus_setup(1): mode1res=0x80000000 (0x80000000), mode2res=0xff (0x0e) pcibus_setup(2): mode1res=0x80000000 (0x80000000) pcibus_check: device 0 is there (id=122d8086) Probing for devices on the PCI bus: configuration mode 1 allows 32 devices. chip0 rev 2 on pci0:0 ahc0 rev 3 int a irq 9 on pci0:6 mapreg[10] type=1 addr=0000fc00 size=0100. mapreg[14] type=0 addr=fedff000 size=1000. ahc0: reading board settings ahc0: Reading SEEPROM...done. ahc0: 2940 Single Channel, SCSI Id=7, aic7870, 255 SCBs ahc0: Downloading Sequencer Program...Done ahc0: Probing channel A ahc0 waiting for scsi devices to settle ahc0: target 0 synchronous at 10.0MB/s, offset = 0xf (ahc0:0:0): "MICROP 4221-09SC21020AV TN05" type 0 fixed SCSI 2 sd0(ahc0:0:0): Direct-Access 1955MB (4004219 512 byte sectors) sd0(ahc0:0:0): with 4049 cyls, 9 heads, and an average 109 sectors/track vga0 rev 0 int a irq 255 on pci0:13 mapreg[10] type=0 addr=fe000000 size=800000. chip1 rev 2 on pci0:15 pci0: uses 8392704 bytes of memory from fe000000 upto fedfffff. pci0: uses 256 bytes of I/O space from fc00 upto fcff. changing root device to sd0a BIOS Geometries: 0:03fe3f20 0..1022=1023 cylinders, 0..63=64 heads, 1..32=32 sectors 0 accounted for sd0s1: type 0xa5, start 32, end = 4003839, size 4003808 : OK WARNING: / was not properly dismounted. ahc0: target 0, lun 0 (sd0) timed out sd0(ahc0:0:0): BUS DEVICE RESET message queued. sd0(ahc0:0:0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted , retries:4 From owner-freebsd-current Sun Apr 14 09:25:27 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA16161 for current-outgoing; Sun, 14 Apr 1996 09:25:27 -0700 (PDT) Received: from DeepCore.dk (aalb10.pip.dknet.dk [194.192.0.170]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id JAA16114 for ; Sun, 14 Apr 1996 09:25:21 -0700 (PDT) Received: (from sos@localhost) by DeepCore.dk (8.7.5/8.7.3) id JAA03788; Sun, 14 Apr 1996 09:57:39 +0200 (MET DST) Message-Id: <199604140757.JAA03788@DeepCore.dk> Subject: Re: File System Corruption *sigh* To: scrappy@ki.net (Marc G. Fournier) Date: Sun, 14 Apr 1996 09:57:39 +0200 (MET DST) From: "Søren Schmidt" Cc: current@FreeBSD.org In-Reply-To: from "Marc G. Fournier" at Apr 14, 96 02:24:40 am From: sos@FreeBSD.org Reply-to: sos@FreeBSD.org X-Mailer: ELM [version 2.4 PL25 ME8b] 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 In reply to Marc G. Fournier who wrote: > > > I'm not having much luck with this -current machine, hardware > or software yet to be determined... :( ----- > For warnings under /usr/src/sys/compile/freebsd. Figuring them > for mere warnings, I kind of ignored them, but then got curious, since I've > never seen that warning before, so checked out the file, and found this > at line 52: > > #define _BSD_SIZE_T_ unsigned int /* sizeof ) * > #d`fin` _BSD_SSIZE_T_ int /* byte count or error */ > #define _BSD_TIME_T_ long /* time() */ > > Notice, as well, the corruption at the end of the BSD_SIZE_T > define... > > I am using nfs mounts for various things, but my /usr, /usr/src > and /usr/include directories are all local, so I would presume that the > nfs mounts wouldn't affect this. > > Other then the memory being in question, this machine is a > 486DX2-66 w/ 16Meg of RAM, an Adaptec 1542CF SCSI controller and a > SCSI hard drive: > > (aha0:0:0): "UNISYS U0531 ST3600N 8374" type 0 fixed SCSI 2 > sd0(aha0:0:0): Direct-Access 500MB (1025920 512 byte sectors) I've seen this type of error MANY times over the last half year on many different hw setups, the only common factor is that they all uses SCSI disk, but I think that is coincidence. A surefire way for me to reproduce this is to checkout a complete src-tree while a kernel-build is running, that way I get 2-3 files corrupted like this in the whole tree :( Oh, and none of the systems I see failing uses nfs.... I have searched high and low for explanations to this, but havn't been able to come up with any hard evidence. My gut feeling though is that its VM related, some buffer mess up of sorts.... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-current Sun Apr 14 09:34:30 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA19007 for current-outgoing; Sun, 14 Apr 1996 09:34:30 -0700 (PDT) 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 JAA18995 Sun, 14 Apr 1996 09:34:27 -0700 (PDT) Message-Id: <199604141634.JAA18995@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: Host localhost.cdrom.com [127.0.0.1] didn't use HELO protocol To: Paulo Menezes cc: current@freebsd.org Subject: Re: Another problem with Adaptec 2940 and S3TRIO64 In-reply-to: Your message of "Sun, 14 Apr 1996 17:14:41 BST." Date: Sun, 14 Apr 1996 09:34:27 -0700 From: "Justin T. Gibbs" Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk The aic7xxx driver in 2.1R has problems. Upgrade to 2.1-STABLE and see if your problems go away. >Thanks > >Paulo -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Sun Apr 14 09:41:21 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA21299 for current-outgoing; Sun, 14 Apr 1996 09:41:21 -0700 (PDT) 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 JAA21281 Sun, 14 Apr 1996 09:41:18 -0700 (PDT) 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 SAA19338 ; Sun, 14 Apr 1996 18:41:08 +0200 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id SAA23991 ; Sun, 14 Apr 1996 18:41:31 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.7.5/keltia-uucp-2.7) id OAA20535; Sun, 14 Apr 1996 14:17:58 +0200 (MET DST) From: Ollivier Robert Message-Id: <199604141217.OAA20535@keltia.freenix.fr> Subject: Re: Just how stable is current To: joerg_wunsch@uriah.heep.sax.de Date: Sun, 14 Apr 1996 14:17:57 +0200 (MET DST) Cc: freebsd-current@FreeBSD.org, gclarkii@freefall.freebsd.org In-Reply-To: <199604131826.UAA21414@uriah.heep.sax.de> from J Wunsch at "Apr 13, 96 08:26:55 pm" X-Operating-System: FreeBSD 2.2-CURRENT ctm#1872 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 J Wunsch said: > > Yes, I know that this is a bad question to ask, but.... > > Mine's from the Easter weekend, and i can't complain. Mine is from tuesday is running fine. -CURRENT has been very stable for me for at least 3 weeks (if not more). -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 2.2-CURRENT #11: Tue Apr 9 20:14:48 MET DST 1996 From owner-freebsd-current Sun Apr 14 10:19:56 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA01572 for current-outgoing; Sun, 14 Apr 1996 10:19:56 -0700 (PDT) Received: from cabri.obs-besancon.fr (cabri.obs-besancon.fr [193.52.184.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA01565 for ; Sun, 14 Apr 1996 10:19:53 -0700 (PDT) Received: by cabri.obs-besancon.fr (5.57/Ultrix3.0-C) id AA28469; Sun, 14 Apr 96 19:22:30 +0100 Date: Sun, 14 Apr 96 19:22:30 +0100 Message-Id: <9604141822.AA28469@cabri.obs-besancon.fr> From: Jean-Marc Zucconi To: current@freebsd.org Subject: Panic during boot X-Mailer: Emacs Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk With a kernel from yesterdays's sources: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xeffffffc fault code = supervisor read, page not present instruction pointer = 0x8:0xf0188f3e This is in ncr.c: f0188ef8 t _ncr_scatter f01890a4 t _ncr_regtest current process = 0 interrupt mask = bio Jean-Marc _____________________________________________________________________________ Jean-Marc Zucconi Observatoire de Besancon F 25010 Besancon cedex PGP Key: finger jmz@cabri.obs-besancon.fr ============================================================================= From owner-freebsd-current Sun Apr 14 10:55:30 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA03727 for current-outgoing; Sun, 14 Apr 1996 10:55:30 -0700 (PDT) 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 KAA03712 for ; Sun, 14 Apr 1996 10:55:22 -0700 (PDT) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id KAA23202; Sun, 14 Apr 1996 10:55:10 -0700 From: "Rodney W. Grimes" Message-Id: <199604141755.KAA23202@GndRsh.aac.dev.com> Subject: Re: Can someone explain why... To: scrappy@ki.net (Marc G. Fournier) Date: Sun, 14 Apr 1996 10:55:10 -0700 (PDT) Cc: davidg@Root.COM, current@freebsd.org In-Reply-To: from "Marc G. Fournier" at "Apr 14, 96 01:18:24 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 > On Sat, 13 Apr 1996, David Greenman wrote: > > > Simple - you have a memory problem and the part of memory that is caching > > gcc is wrong. It just happens that the code involved is only exercised when > > you use -O. It's easy to test this: just reboot your computer and see if the > > problem goes away. If it persists, then you might have a corrupt gcc binary. > > > Okay, that works for me...is there anything I can do to a SIMM to > test it *before* I change it? Or to test the new one before I even put it > in? Trial and Error doesn't seem to be an effective way of fixing this > problem :( Find a memory supplier that has a SIMM tester, that is the only true and accurate way to rule a SIMM good or bad, sans replacing it. I know these folks are not easy to find, but check with your local PC distributors (not retailers), they sometimes have one around. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Sun Apr 14 10:59:30 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA04060 for current-outgoing; Sun, 14 Apr 1996 10:59:30 -0700 (PDT) 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 KAA04052 for ; Sun, 14 Apr 1996 10:59:27 -0700 (PDT) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id KAA23212; Sun, 14 Apr 1996 10:59:16 -0700 From: "Rodney W. Grimes" Message-Id: <199604141759.KAA23212@GndRsh.aac.dev.com> Subject: Re: Can someone explain why... To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Sun, 14 Apr 1996 10:59:15 -0700 (PDT) Cc: current@freebsd.org In-Reply-To: <199604140641.QAA12291@genesis.atrad.adelaide.edu.au> from Michael Smith at "Apr 14, 96 04:11:24 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 > Marc G. Fournier stands accused of saying: > > Okay, that works for me...is there anything I can do to a SIMM to > > test it *before* I change it? Or to test the new one before I even put it > > in? Trial and Error doesn't seem to be an effective way of fixing this > > problem :( > > Spend several thousand dollars on a _real_ SIMM tester. Or find a supplier > and brand of SIMM that you're happy with and stick with it. Even that won't protect you from the occasion batch of bad simms... trust me, I get hit about twice a year by it :-(. > We're having a good run with Panasonic parts in Triton motherboards at > the moment. Humm... last time I got Panasonic I had to RMA them 3 times (total of 48 sticks all showing the same problem, very simmiliar to what Marc is experiencing) before the vendor gave up and shipped me another brand, YMMV... -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Sun Apr 14 11:01:54 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA04371 for current-outgoing; Sun, 14 Apr 1996 11:01:54 -0700 (PDT) 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 LAA04364 for ; Sun, 14 Apr 1996 11:01:51 -0700 (PDT) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id LAA23221; Sun, 14 Apr 1996 11:01:45 -0700 From: "Rodney W. Grimes" Message-Id: <199604141801.LAA23221@GndRsh.aac.dev.com> Subject: Re: File System Corruption *sigh* To: scrappy@ki.net (Marc G. Fournier) Date: Sun, 14 Apr 1996 11:01:45 -0700 (PDT) Cc: current@FreeBSD.org In-Reply-To: from "Marc G. Fournier" at "Apr 14, 96 02:24:40 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 > > Morning all... > > I'm not having much luck with this -current machine, hardware > or software yet to be determined... :( > > In attempting to beat the hell out of this machine (got it > up to using 57% of its 51Meg swap space, with 16Meg of RAM), I > started up 5 make processes: > > make on /usr/src/sys/compile/freebsd > 4 makes under /usr/src/lib > > All of a sudden, I started getting: ... This is really starting to smell of a broken memory subsystem... -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Sun Apr 14 11:29:49 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA06828 for current-outgoing; Sun, 14 Apr 1996 11:29:49 -0700 (PDT) Received: from FileServ1.MI.Uni-Koeln.DE (FileServ1.MI.Uni-Koeln.DE [134.95.212.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA06823 for ; Sun, 14 Apr 1996 11:29:45 -0700 (PDT) Received: by FileServ1.MI.Uni-Koeln.DE id AA08854 (5.67b/IDA-1.5 for current@freebsd.org); Sun, 14 Apr 1996 20:29:32 +0200 Message-Id: <199604141829.AA08854@FileServ1.MI.Uni-Koeln.DE> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Sun, 14 Apr 1996 20:29:32 +0200 In-Reply-To: Jean-Marc Zucconi "Panic during boot" (Apr 14, 19:22) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: Jean-Marc Zucconi Subject: Re: Panic during boot Cc: current@freebsd.org Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Apr 14, 19:22, Jean-Marc Zucconi wrote: } Subject: Panic during boot } With a kernel from yesterdays's sources: } } Fatal trap 12: page fault while in kernel mode } fault virtual address = 0xeffffffc } fault code = supervisor read, page not present } instruction pointer = 0x8:0xf0188f3e } This is in ncr.c: } f0188ef8 t _ncr_scatter } f01890a4 t _ncr_regtest } current process = 0 } interrupt mask = bio The ncr_scatter code works mostly on local variables, besides the scatter/gather list that is part of the command control block. Could this be a VM problem, i.e. a non-resident page being referenced in the vtophys() macro ? Regards, STefan -- Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160 ============================================================================== http://www.zpr.uni-koeln.de/~se From owner-freebsd-current Sun Apr 14 13:15:08 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA11273 for current-outgoing; Sun, 14 Apr 1996 13:15:08 -0700 (PDT) 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 NAA11267 for ; Sun, 14 Apr 1996 13:15:05 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA07351; Sun, 14 Apr 1996 13:12:14 -0700 From: Terry Lambert Message-Id: <199604142012.NAA07351@phaeton.artisoft.com> Subject: Re: ed_start() panic revisited To: scrappy@ki.net (Marc G. Fournier) Date: Sun, 14 Apr 1996 13:12:13 -0700 (MST) Cc: terry@lambert.org, current@FreeBSD.org In-Reply-To: from "Marc G. Fournier" at Apr 13, 96 08:05:26 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > volatile frame? type? > > > > Ignorantly, he inquires...Huh? Prevent loop unlrolling and register optimization of the variables that could be screwing up by declaring them volatile. 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 Apr 14 14:29:50 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA16050 for current-outgoing; Sun, 14 Apr 1996 14:29:50 -0700 (PDT) Received: from horst.bfd.com ([204.160.242.10]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id OAA16010 Sun, 14 Apr 1996 14:29:35 -0700 (PDT) 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 OAA29159; Sun, 14 Apr 1996 14:34:52 -0700 (PDT) Date: Sun, 14 Apr 1996 14:31:57 -0700 (PDT) From: "Eric J. Schwertfeger" To: current@freebsd.org, hackers@freebsd.org, questions@freebsd.org Subject: Need help setting up user ppp and dial-on demand Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk First of all, sorry for sending this to three lists, but I got no response the first time to just questions. Please delete all but the appropriate list, or just reply directly to me. Basically, I have a small lan in my house, and I'm converting from Linux over to FreeBSD (2.1R). I have a static IP address from my provider, and wanted to set up on-demand PPP so my wife can get on the net any time without having to start anything herself. The problem seems to be that the system insists on having the PPP link up before it will allow any traffic. Even "telnet 127.0.0.1" blocks until the PPP link is established. My first attempt followed the examples in the /etc/ppp directory. This resulted in the behavior above. After trying with no success to tweek that configuration (the closest I got was that it would work normally until the first time it connected), I went by the configuration in the handbook. After tweeking the second configuration for a while I got to the point where no traffic was blocking, but it would bring up the link for no apparent reason. So, I started blocking services for dialing, and when I blocked everything I thought could be happening, it still dialed. So I blocked everything, and it still dialed. I suspect my filters aren't set up properly :-) Anyway, is anyone successfully using dial-on-demand PPP on a machine also attached to a local network? From owner-freebsd-current Sun Apr 14 15:18:10 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA17812 for current-outgoing; Sun, 14 Apr 1996 15:18:10 -0700 (PDT) Received: from cabri.obs-besancon.fr (cabri.obs-besancon.fr [193.52.184.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA17807 for ; Sun, 14 Apr 1996 15:18:07 -0700 (PDT) Received: by cabri.obs-besancon.fr (5.57/Ultrix3.0-C) id AA02719; Mon, 15 Apr 96 00:20:42 +0100 Date: Mon, 15 Apr 96 00:20:42 +0100 Message-Id: <9604142320.AA02719@cabri.obs-besancon.fr> From: Jean-Marc Zucconi To: se@zpr.uni-koeln.de Cc: current@freebsd.org In-Reply-To: <199604141829.AA08854@FileServ1.MI.Uni-Koeln.DE> (se@zpr.uni-koeln.de) Subject: Re: Panic during boot X-Mailer: Emacs Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>>>> Stefan Esser writes: > On Apr 14, 19:22, Jean-Marc Zucconi wrote: > } Subject: Panic during boot > } With a kernel from yesterdays's sources: > } > } Fatal trap 12: page fault while in kernel mode > } fault virtual address = 0xeffffffc > } fault code = supervisor read, page not present > } instruction pointer = 0x8:0xf0188f3e > } This is in ncr.c: > } f0188ef8 t _ncr_scatter > } f01890a4 t _ncr_regtest > } current process = 0 > } interrupt mask = bio > The ncr_scatter code works mostly on local variables, > besides the scatter/gather list that is part of the > command control block. > Could this be a VM problem, i.e. a non-resident page > being referenced in the vtophys() macro ? I have identified my problem: using the -n flag with config is not a good idea :-/ After recompiling a kernel from scratch, my system runs fine. Sorry for the false alarm. Jean-Marc > Regards, STefan > -- > Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 > Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160 > ============================================================================== > http://www.zpr.uni-koeln.de/~se _____________________________________________________________________________ Jean-Marc Zucconi Observatoire de Besancon F 25010 Besancon cedex PGP Key: finger jmz@cabri.obs-besancon.fr ============================================================================= From owner-freebsd-current Sun Apr 14 15:29:41 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA18307 for current-outgoing; Sun, 14 Apr 1996 15:29:41 -0700 (PDT) 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 PAA18302 Sun, 14 Apr 1996 15:29:40 -0700 (PDT) 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 PAA00856; Sun, 14 Apr 1996 15:29:03 -0700 (PDT) Message-Id: <199604142229.PAA00856@precipice.shockwave.com> cc: freebsd-hubs@freefall.freebsd.org, freebsd-current@freefall.freebsd.org Subject: Re: SUP2 down for 24-48 hours In-reply-to: Your message of "Thu, 11 Apr 1996 22:01:32 PDT." <199604120501.WAA20156@freefall.freebsd.org> Date: Sun, 14 Apr 1996 15:29:02 -0700 From: Paul Traina Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Sup2 is back up (was back in operation friday evening). From: Paul Traina Subject: SUP2 down for 24-48 hours sup2.freebsd.org will be down effective immediately for 24 to 48 hours for a software and hardware upgrade. Sorry for the short notice, it was "supposed" to be a quickie, but I managed to fry an IDE drive's internal code pages while playing around with the install code. Paul p.s. anyone who is a guru at WD IDE drive hacking, feel free to drop me a line... this one's really weird. (god I hate IDE) From owner-freebsd-current Sun Apr 14 16:44:29 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA22649 for current-outgoing; Sun, 14 Apr 1996 16:44:29 -0700 (PDT) Received: from mubo.augusta.de (mubo.augusta.de [193.175.25.25]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id QAA22640 for ; Sun, 14 Apr 1996 16:44:21 -0700 (PDT) Received: from rabbit by mubo.augusta.de with uucp (Smail3.1.28.1 #1) id m0u8bSf-0008hBC; Mon, 15 Apr 96 01:44 MESZ Received: by rabbit.augusta.de (Smail3.1.29.1 #1) id m0u8b2m-0009zaC; Mon, 15 Apr 96 01:17 MET DST Message-Id: Date: Mon, 15 Apr 96 01:17 MET DST X-Newsreader: knews 0.9.3 References: <199604100852.KAA28320@grumble.grondar.za> From: shanee@rabbit.augusta.de (Andreas Kohout) Subject: Re: /var/mail default permissions?? X-Original-Newsgroups: muc.lists.freebsd.current In-Reply-To: <199604100852.KAA28320@grumble.grondar.za> To: current@freebsd.org Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199604100852.KAA28320@grumble.grondar.za>, mark@grondar.za (Mark Murray) writes: >> I thought /var/mail was supposed to be mode 1777 on BSD systems?? >God forbid! ok, but which permission is correct and how will I tell it smail (from the ports collection)? SMail works only with 1777 on /var/mail ... -- Gruß, Andy ------------------------------------------------------------------------- Berge von unten, Kirchen von außen und Kneipen von innen ... shanee@rabbit.augusta.de Zirbelnußtown ------------------------------------------------------------------------- From owner-freebsd-current Sun Apr 14 17:23:38 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA26160 for current-outgoing; Sun, 14 Apr 1996 17:23:38 -0700 (PDT) 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 RAA26155 for ; Sun, 14 Apr 1996 17:23:34 -0700 (PDT) Received: from localhost (lyndon@localhost) by multivac.orthanc.com (8.7.3/8.7.3) with SMTP id RAA12285; Sun, 14 Apr 1996 17:22:13 -0700 (PDT) Message-Id: <199604150022.RAA12285@multivac.orthanc.com> From: Lyndon Nerenberg VE7TCP To: shanee@rabbit.augusta.de (Andreas Kohout) cc: current@freebsd.org Subject: Re: /var/mail default permissions?? In-reply-to: Your message of "Mon, 15 Apr 1996 01:17:00 +0700." Date: Sun, 14 Apr 1996 17:22:13 -0700 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >ok, but which permission is correct and how will I tell it smail (from the >ports collection)? >SMail works only with 1777 on /var/mail ... There should be a README- in the smail source tree that documents the changes necessary for 4.4BSD systems. You have to change the delivery agent for "local" to invoke /usr/libexec/mail.local, rather than having it attempt direct delivery to the recipients mailbox. The modification goes into the smail directors file. You can use the "local" mailer definition in /etc/sendmail.cf to see how mail.local needs to be invoked. The "port" should be applying this fix. I'll take a look at it later today and see about submitting a patch. --lyndon From owner-freebsd-current Sun Apr 14 18:03:00 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA28807 for current-outgoing; Sun, 14 Apr 1996 18:03:00 -0700 (PDT) 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 SAA28802 for ; Sun, 14 Apr 1996 18:02:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with SMTP id SAA16049; Sun, 14 Apr 1996 18:01:33 -0700 (PDT) To: Jean-Marc Zucconi cc: se@zpr.uni-koeln.de, current@FreeBSD.ORG Subject: Re: Panic during boot In-reply-to: Your message of "Mon, 15 Apr 1996 00:20:42 BST." <9604142320.AA02719@cabri.obs-besancon.fr> Date: Sun, 14 Apr 1996 18:01:33 -0700 Message-ID: <16047.829530093@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I have identified my problem: using the -n flag with config is not a > good idea :-/ Tell this to Garrett - he still beats me up over the default behavior! :-) Jordan From owner-freebsd-current Sun Apr 14 18:20:12 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA00352 for current-outgoing; Sun, 14 Apr 1996 18:20:12 -0700 (PDT) Received: from ki.net (root@ki.net [205.150.102.1]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id SAA00334 for ; Sun, 14 Apr 1996 18:20:06 -0700 (PDT) Received: from localhost (scrappy@localhost) by ki.net (8.7.4/8.7.4) with SMTP id VAA28584; Sun, 14 Apr 1996 21:19:51 -0400 (EDT) Date: Sun, 14 Apr 1996 21:19:46 -0400 (EDT) From: "Marc G. Fournier" To: "Jordan K. Hubbard" cc: Jean-Marc Zucconi , se@zpr.uni-koeln.de, current@FreeBSD.ORG Subject: Re: Panic during boot In-Reply-To: <16047.829530093@time.cdrom.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 Sun, 14 Apr 1996, Jordan K. Hubbard wrote: > > I have identified my problem: using the -n flag with config is not a > > good idea :-/ > > Tell this to Garrett - he still beats me up over the default behavior! :-) > Wait, what's wrong with -n?? Except for the other day, I always use -gn when I reconfig the sources before compiling, so that I don't lose my version #. Marc G. Fournier scrappy@ki.net Systems Administrator @ ki.net scrappy@freebsd.org From owner-freebsd-current Sun Apr 14 18:46:27 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA03298 for current-outgoing; Sun, 14 Apr 1996 18:46:27 -0700 (PDT) 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 SAA03239 Sun, 14 Apr 1996 18:46:11 -0700 (PDT) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id LAA14971; Mon, 15 Apr 1996 11:46:42 +0930 From: Michael Smith Message-Id: <199604150216.LAA14971@genesis.atrad.adelaide.edu.au> Subject: Re: Need help setting up user ppp and dial-on demand To: ejs@bfd.com (Eric J. Schwertfeger) Date: Mon, 15 Apr 1996 11:46:41 +0930 (CST) Cc: current@freebsd.org, hackers@freebsd.org, questions@freebsd.org In-Reply-To: from "Eric J. Schwertfeger" at Apr 14, 96 02:31:57 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 Eric J. Schwertfeger stands accused of saying: > > The problem seems to be that the system insists on having the PPP link up > before it will allow any traffic. Even "telnet 127.0.0.1" blocks until > the PPP link is established. Your name resolution setup is wrong. Make sure you have 'hosts' listed before 'bind' in /etc/host.conf, and that all of your hosts and all their aliases are named in /etc/hosts. You might also want to configure a caching-only nameserver. Consult the 'named' manpage and the O'Reilly "DNS and Bind" book for details on this. -- ]] 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 Sun Apr 14 19:57:01 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id TAA11376 for current-outgoing; Sun, 14 Apr 1996 19:57:01 -0700 (PDT) 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 TAA11371 for ; Sun, 14 Apr 1996 19:56:58 -0700 (PDT) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id MAA15368; Mon, 15 Apr 1996 12:56:25 +0930 From: Michael Smith Message-Id: <199604150326.MAA15368@genesis.atrad.adelaide.edu.au> Subject: Re: Panic during boot To: scrappy@ki.net (Marc G. Fournier) Date: Mon, 15 Apr 1996 12:56:25 +0930 (CST) Cc: jkh@time.cdrom.com, jmz@cabri.obs-besancon.fr, se@zpr.uni-koeln.de, current@FreeBSD.ORG In-Reply-To: from "Marc G. Fournier" at Apr 14, 96 09:19:46 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 Marc G. Fournier stands accused of saying: > > > > I have identified my problem: using the -n flag with config is not a > > > good idea :-/ > > > > Tell this to Garrett - he still beats me up over the default behavior! :-) > > > > Wait, what's wrong with -n?? Except for the other day, I always > use -gn when I reconfig the sources before compiling, so that I don't lose > my version #. It would have been nice if you mentioned this back when you were talking about other problems you were having. -n is _evil_. If any changes have been made to your kernel sources that you are not _intimately_ familiar with, (ie. you have resupped), then you _must_must_must_ not use -n. Dependencies aren't enough to protect you from losing like this. I suspect this _may_ be part of your problem. > Marc G. Fournier scrappy@ki.net -- ]] 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 Sun Apr 14 20:33:48 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id UAA13489 for current-outgoing; Sun, 14 Apr 1996 20:33:48 -0700 (PDT) Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id UAA13482 for ; Sun, 14 Apr 1996 20:33:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by Root.COM (8.7.5/8.6.5) with SMTP id UAA04584; Sun, 14 Apr 1996 20:32:58 -0700 (PDT) Message-Id: <199604150332.UAA04584@Root.COM> X-Authentication-Warning: implode.Root.COM: Host localhost [127.0.0.1] didn't use HELO protocol To: Michael Smith cc: scrappy@ki.net (Marc G. Fournier), jkh@time.cdrom.com, jmz@cabri.obs-besancon.fr, se@ZPR.Uni-Koeln.DE, current@FreeBSD.ORG Subject: Re: Panic during boot In-reply-to: Your message of "Mon, 15 Apr 1996 12:56:25 +0930." <199604150326.MAA15368@genesis.atrad.adelaide.edu.au> From: David Greenman Reply-To: davidg@Root.COM Date: Sun, 14 Apr 1996 20:32:58 -0700 Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> Wait, what's wrong with -n?? Except for the other day, I always >> use -gn when I reconfig the sources before compiling, so that I don't lose >> my version #. > >It would have been nice if you mentioned this back when you were talking >about other problems you were having. > >-n is _evil_. If any changes have been made to your kernel sources that >you are not _intimately_ familiar with, (ie. you have resupped), then >you _must_must_must_ not use -n. Dependencies aren't enough to protect >you from losing like this. I suspect this _may_ be part of your problem. Indeed. Even the dependencies themselves don't always work as expected so some things don't get rebuilt when they need to be. The whole reason why Jordan made the change to config to blow away the compile directory was because we kept getting weird bug reports that later turned out to be caused by a stale .o's. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-current Sun Apr 14 22:54:35 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA29873 for current-outgoing; Sun, 14 Apr 1996 22:54:35 -0700 (PDT) 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 WAA29864 for ; Sun, 14 Apr 1996 22:54:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by rover.village.org (8.6.12/8.6.6) with SMTP id XAA29699 for ; Sun, 14 Apr 1996 23:54:24 -0600 Message-Id: <199604150554.XAA29699@rover.village.org> To: current@freebsd.org Subject: make world question Date: Sun, 14 Apr 1996 23:54:23 -0600 From: Warner Losh Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Why is a make depend done as part of make world? Unless I'm missing something, all of the binaries would be rebuilt anyway due to the .o's not being there, it is a waste of time. Can one safely omit it for "clean" builds on "virgin" /usr/src trees? The order that is there now should cause the includes to be installed first, and then the libraries built and installed and then all the binaries build and installed. In this case, what does depend buy you? What subtle thing, if any, am I missing? Warner From owner-freebsd-current Sun Apr 14 23:56:39 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA06687 for current-outgoing; Sun, 14 Apr 1996 23:56:39 -0700 (PDT) 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 XAA06682 for ; Sun, 14 Apr 1996 23:56:35 -0700 (PDT) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id XAA23803; Sun, 14 Apr 1996 23:56:28 -0700 From: "Rodney W. Grimes" Message-Id: <199604150656.XAA23803@GndRsh.aac.dev.com> Subject: Re: make world question To: imp@village.org (Warner Losh) Date: Sun, 14 Apr 1996 23:56:28 -0700 (PDT) Cc: current@freebsd.org In-Reply-To: <199604150554.XAA29699@rover.village.org> from Warner Losh at "Apr 14, 96 11:54:23 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 > Why is a make depend done as part of make world? Unless I'm missing > something, all of the binaries would be rebuilt anyway due to the .o's > not being there, it is a waste of time. Can one safely omit it for > "clean" builds on "virgin" /usr/src trees? Yes, one can safely ommit it (unless more cruft has slipped in, as in the past certain .c files created from other files occured during the depend phase only, these have been cleaned up last time I checked [right around 2.1R time].) > The order that is there now should cause the includes to be installed > first, and then the libraries built and installed and then all the > binaries build and installed. In this case, what does depend buy you? Nothing, _if_ that is where you stop... > What subtle thing, if any, am I missing? After a make world it is easy to go in and work on things and just type ``make'', unless you modify something that effects the dependencies, then you'll have to rebuild the .depend file. I added the depend phase way way back in the 386BSD Patch kit days when ``make world'' use to be a shell script. At that time it was an absoulte requirement to get the system to build properly. Since then many many many things have changed, and the depend phase can most likely be safely removed (or made optional) for those who are just running make worlds all the time. You do need the .depend stuff around if you like to short circuit make world and do you own things (I don't very often run make world on my personal systems, mostly just make all install.) -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Mon Apr 15 01:00:53 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA16551 for current-outgoing; Mon, 15 Apr 1996 01:00:53 -0700 (PDT) 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 BAA16534 for ; Mon, 15 Apr 1996 01:00:50 -0700 (PDT) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id SAA17472 for current@freebsd.org; Mon, 15 Apr 1996 18:01:49 +0930 From: Michael Smith Message-Id: <199604150831.SAA17472@genesis.atrad.adelaide.edu.au> Subject: Apr-14 sup panics at startup To: current@freebsd.org Date: Mon, 15 Apr 1996 18:01:48 +0930 (CST) 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 Possibly a broken sup, possibly just a month-old userland (I can't update the userland binaries on this box at the moment), but I get a panic at vm_page_free+0x8e during startup. 'ps' under DDB pagefaults too 8) Known, want more info, go away? 8) (will resup to be sure) -- ]] 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 15 01:21:07 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA20002 for current-outgoing; Mon, 15 Apr 1996 01:21:07 -0700 (PDT) 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 BAA19955 Mon, 15 Apr 1996 01:20:55 -0700 (PDT) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id KAA15525; Mon, 15 Apr 1996 10:20:48 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id KAA14323; Mon, 15 Apr 1996 10:20:48 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id JAA11351; Mon, 15 Apr 1996 09:53:15 +0200 (MET DST) From: J Wunsch Message-Id: <199604150753.JAA11351@uriah.heep.sax.de> Subject: Re: Interesting bash bug - anyone else see this? To: ports@FreeBSD.org Date: Mon, 15 Apr 1996 09:53:13 +0200 (MET DST) Cc: freebsd-current@FreeBSD.org (FreeBSD-current users) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199604150138.SAA16211@time.cdrom.com> from "Jordan K. Hubbard" at Apr 14, 96 06:38:25 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 Jordan K. Hubbard wrote: > > I just noticed it, myself. It doesn't happen in sh or csh, so it's > definitely one for -bash and -current (if not also -stable; I dunno!). > > > root@reason-> ls -lt | more > ^Z > [2]+ Done ls -lt | more > root@reason-> fg > ls -lt | more > Broken pipe > > Bug #1: Upon suspending, bash erroneously reports the background job's status > as "Done", not "Suspended" > > Bug #2: Upon resuming, we're hosed - the pipe breaks. I can reproduce it. Depending upon how quickly i pressed ^Z, i could even get bash into a totally hosed state, the ^Z has been displayed, but ``nichts geht mehr''. Only a SIGCONT from a different window helped. It seems that bash sends the SIGSTOP to each process in turn instead of the entire process group of the pipeline: 107 11252 270 0 10 0 628 884 wait S p3 0:00.30 bash 107 11261 11252 0 28 0 352 152 - T+ p3 0:00.03 ls -lt 107 11262 11252 1 -6 0 204 512 piperd S+ p3 0:00.08 more You'll note that `more' hasn't got a stop signal, it's running and waiting for input from the pipe. This is your case: 107 11252 270 1 10 0 628 700 wait S p3 0:00.43 bash 107 11267 11252 1 28 0 384 232 - T p3 0:00.07 ls -lt The `ls' has been stopped, but `more' is already dead. (That's why bash is reporting it as `Done'.) I could reproduce the deadlock situation with /bin/sh as well. The symptoms are identical (ls is in the `T' state, more is `S'). To the contrary, this is how tcsh arranges for it: j 270 269 270 7fdaa0 0 Ss p3 0:12.53 -tcsh (tcsh) j 11330 270 11330 7fdaa0 2 T p3 0:00.02 -tcsh (tcsh) j 11331 270 11330 7fdaa0 2 T p3 0:00.03 more j 11332 11330 11330 7fdaa0 2 T p3 0:00.02 ls -CF -lt PID 270 is my interactive shell, PID (and PGID) 11330 is the pipeline. Unlike with the Bourne-alike shells, tcsh spent an entire subshell to the pipeline, and this one has got the stop signal. -- 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 15 01:21:38 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA20104 for current-outgoing; Mon, 15 Apr 1996 01:21:38 -0700 (PDT) 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 BAA20083 for ; Mon, 15 Apr 1996 01:21:30 -0700 (PDT) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id KAA15543 for ; Mon, 15 Apr 1996 10:20:57 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id KAA14328 for freebsd-current@FreeBSD.org; Mon, 15 Apr 1996 10:20:57 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id KAA11461 for freebsd-current@FreeBSD.org; Mon, 15 Apr 1996 10:08:39 +0200 (MET DST) From: J Wunsch Message-Id: <199604150808.KAA11461@uriah.heep.sax.de> Subject: Re: Panic during boot To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Mon, 15 Apr 1996 10:08:38 +0200 (MET DST) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199604150332.UAA04584@Root.COM> from "David Greenman" at Apr 14, 96 08:32: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 David Greenman wrote: > The whole reason why > Jordan made the change to config to blow away the compile directory was > because we kept getting weird bug reports that later turned out to be caused > by a stale .o's. I thought it was rather due to the poor traditional option handling? For me, this is quite a difference. If it's only been for the option handling, -n could go away again once all major (i.e., supported) options have been turned into `new style', since the dependencies on opt_foo.h will work again. People who are using unsupported options, or people who upgrade their machines frequently to newer sources are expected to know what they're doing. We should only protect ``ordinary customers'' against (from their point of view) unforseeable accidents. (I always prevent config from clobbering my compile directory, however, i remove it manually if i think too many things have changed, or if something doesn't work as expected and i cannot figure it out.) -- 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 15 01:21:45 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA20127 for current-outgoing; Mon, 15 Apr 1996 01:21:45 -0700 (PDT) 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 BAA20088 for ; Mon, 15 Apr 1996 01:21:33 -0700 (PDT) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id KAA15552; Mon, 15 Apr 1996 10:21:00 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id KAA14330; Mon, 15 Apr 1996 10:21:00 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id KAA11427; Mon, 15 Apr 1996 10:01:46 +0200 (MET DST) From: J Wunsch Message-Id: <199604150801.KAA11427@uriah.heep.sax.de> Subject: Re: /var/mail default permissions?? To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Mon, 15 Apr 1996 10:01:46 +0200 (MET DST) Cc: shanee@rabbit.augusta.de Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199604150022.RAA12285@multivac.orthanc.com> from "Lyndon Nerenberg VE7TCP" at Apr 14, 96 05:22:13 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 Lyndon Nerenberg VE7TCP wrote: > You can use the "local" mailer definition in > /etc/sendmail.cf to see how mail.local needs to be invoked. Actually, don't really use the `-d' option. This was legacy code inherited from the default pattern in sendmail, i've overridden it for 4.4BSD recently in our sources. mail.local only needs the recipient as argument. -- 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 15 02:17:11 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA00425 for current-outgoing; Mon, 15 Apr 1996 02:17:11 -0700 (PDT) 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 CAA00396 for ; Mon, 15 Apr 1996 02:17:04 -0700 (PDT) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id TAA17813; Mon, 15 Apr 1996 19:18:08 +0930 From: Michael Smith Message-Id: <199604150948.TAA17813@genesis.atrad.adelaide.edu.au> Subject: Re: Apr-14 sup panics at startup To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Mon, 15 Apr 1996 19:18:07 +0930 (CST) Cc: current@FreeBSD.ORG In-Reply-To: <199604150831.SAA17472@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Apr 15, 96 06:01:48 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 Michael Smith stands accused of saying: > > Possibly a broken sup, possibly just a month-old userland (I can't update > the userland binaries on this box at the moment), but I get a panic at > vm_page_free+0x8e during startup. 'ps' under DDB pagefaults too 8) Definitely a broken sup. *sigh* Not to worry. -- ]] 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 15 03:00:48 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA05149 for current-outgoing; Mon, 15 Apr 1996 03:00:48 -0700 (PDT) Received: from bunyip.cc.uq.oz.au (pp@bunyip.cc.uq.oz.au [130.102.2.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id DAA05124 for ; Mon, 15 Apr 1996 03:00:27 -0700 (PDT) Received: from bunyip.cc.uq.oz.au by bunyip.cc.uq.oz.au id <23176-0@bunyip.cc.uq.oz.au>; Mon, 15 Apr 1996 20:00:21 +1000 Received: from orion.devetir.qld.gov.au by pandora.devetir.qld.gov.au (8.6.10/DEVETIR-E0.3a) with ESMTP id SAA00868 for ; Mon, 15 Apr 1996 18:54:25 +1000 Received: from localhost by orion.devetir.qld.gov.au (8.6.10/DEVETIR-0.3) id SAA14153; Mon, 15 Apr 1996 18:56:00 +1000 Message-Id: <199604150856.SAA14153@orion.devetir.qld.gov.au> To: freebsd-current@freebsd.org cc: syssgm@devetir.qld.gov.au Subject: Re: Just how stable is current Date: Mon, 15 Apr 1996 18:55:59 +1000 From: Stephen McKay Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Ollivier Robert thinks: >It seems that J Wunsch said: >> > Yes, I know that this is a bad question to ask, but.... >> >> Mine's from the Easter weekend, and i can't complain. > >Mine is from tuesday is running fine. -CURRENT has been very stable for me >for at least 3 weeks (if not more). Not all of us are happy campers. I have a -current kernel from January 9 which works well for me, and have had various problems with all kernels built since. My hardware is modest: 16Mhz 386sx with 4Mb ram, NFS for all source and object files, vnconfig swap + real swap totals 16Mb. I have 3 problems: 1) NFS problem: My January 9 kernel will work properly as a client with any server using 8Kb max size UDP connections. More recent kernels won't. I get severe performance degradation that I assume is from lots of retries and timeouts, even though I can't find them in nfsstat. Many processes hang for long periods in sbwait, nfsrcvlk and similar network states. Ok, overruns are a common problem with PC network cards, especially in slow machines. However, setting the maximum size to 1Kb does not cure the problem (or maybe moves the problem elsewhere). Switching to TCP transport produced a total cure, but is not available on all servers. 2) Processes with negative resident size: Friday, I started a make all of -current and snapped this: (some boring processes deleted) UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND 0 0 0 0 -18 0 0 0 sched DLs ?? 0:03.33 (swapper) 0 1 0 12 10 0 392 0 wait IWs ?? 0:00.33 /sbin/init -- 0 2 0 75 -18 0 0 12 psleep DL ?? 11:54.65 (pagedaemon) 0 3 0 32 28 0 0 12 psleep DL ?? 2:52.65 (vmdaemon) 0 4 0 5 29 0 0 12 update DL ?? 0:14.13 (update) ... 0 2177 2176 9 10 5 340 -4 wait IWN p0 0:02.70 make 0 2179 2177 38 10 5 452 0 wait IWN p0 0:00.36 /bin/sh -ec for entry in include lib bin games gnu libexec sbin 0 2190 2179 75 10 5 308 -4 wait IWN p0 0:02.29 make all DIRPRFX 0 2192 2190 107 10 5 452 -4 wait IWN p0 0:00.33 /bin/sh -ec for entry in csu/i386 libc libcompat libcom_err libc 0 2195 2192 32 10 5 2840 8 wait IWN p0 1:12.30 make all DIRPRFX 0 2233 2195 135 10 5 216 16 wait IWN p0 0:00.99 cc -O2 -DLIBC_RCS -DSYSLIBC_RCS -D__DBINTERFACE_PRIVATE -DPOSIX_ 0 2238 2233 109 65 5 848 1004 - RN p0 0:17.92 /usr/libexec/cc1 /tmp/cc002233.i -quiet -dumpbase bt_open.c -O2 0 147 1 48 3 0 156 -4 ttyin IWs+ v0 0:00.49 /usr/libexec/getty Pc ttyv0 RSS < 0 may be a cosmetic flaw, or it may be seriously buggering the VM system. I don't know yet, but I'm valiantly struggling through the VM code. :-) 3) Madly spinning processes: This morning the scene was: UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND 0 4796 4399 131 10 5 308 -4 wait IWN ?? 0:01.85 make all DIRPRFX 0 4798 4796 87 10 5 452 -4 wait IWN ?? 0:00.72 /bin/sh -ec for entry in as awk bc cc cpio cvs dc dialog diff di 0 4990 4798 135 10 5 312 -4 wait IWN ?? 0:01.98 make all DIRPRFX 0 4992 4990 149 10 5 452 -4 wait IWN ?? 0:00.39 /bin/sh -ec for entry in libgroff libdriver libbib groff troff n 0 5011 4992 210 90 5 344 20 - RN ?? 3509:56.22 make all DIR All but one process had reasonable amounts of time accrued. Some even had normal resident memory. :-) vmstat -s revealed: (sorry, I don't know what's irrelevant here) 3010564 cpu context switches 69486232 device interrupts 2658782 software interrupts 371029200 traps 1002815 system calls 86889 swap pager pageins 195866 swap pager pages paged in 57630 swap pager pageouts 82118 swap pager pages paged out 115789 vnode pager pageins 238148 vnode pager pages paged in 0 vnode pager pageouts 0 vnode pager pages paged out 41415 page daemon wakeups 27543608 pages examined by the page daemon 15642 pages reactivated 158113 copy-on-write faults 262888 zero fill pages zeroed 253 intransit blocking page faults 367919662 total VM faults taken 514357 pages freed 39851 pages freed by daemon 368305 pages freed by exiting processes 286 pages active 68 pages inactive 9 pages in VM cache 313 pages wired down 13 pages free 4096 bytes per page 550001 total name lookups cache hits (77% pos + 2% neg) system 2% per-directory deletions 0%, falsehits 4%, toolong 0% 367919662 VM faults over 2.5 days equates to 1700 per second. This is far in excess of what the machine can fetch from disk, so it can only be "soft" faults (where pages really are there, but the VM system was hoping you didn't need them any more and was going to free them soon), or some total failure to provide the needed page at all, causing make to fault again immediately on returning to user mode. That make process has only 5 resident pages (or is it 6 :-)), but lots of memory was available for my shell, telnetd, etc when I logged in. It isn't lack of real memory that caused this. Now, for the final twist before the audience can return to the comfortable normalcy of their own lives: I stopped the whole process group with SIGSTOP, and noted that all processes went from RSS -4 to 8, presumably because the u area had faulted in. I waited all day (just because I had real work :-)), and found that the problem make process was eventually reduced to 8Kb, like the others. Then I restarted them with SIGCONT, and blow me down if they didn't just up and carry on like nothing had happened. The problem make exited (presumably after finishing successfully), and the compilation is proceeding normally as I write. Thanks to all who have bothered to read this far. I shall be consulting the special texts of the masters (sys/vm/*.[hc]) for enlightenment, but expect to be beaten to the answer by more knowledgeable persons. Stephen. From owner-freebsd-current Mon Apr 15 04:49:01 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA11375 for current-outgoing; Mon, 15 Apr 1996 04:49:01 -0700 (PDT) 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 EAA11367 Mon, 15 Apr 1996 04:48:59 -0700 (PDT) Received: (from jkh@localhost) by time.cdrom.com (8.7.5/8.6.9) id EAA19676; Mon, 15 Apr 1996 04:48:10 -0700 (PDT) Date: Mon, 15 Apr 1996 04:48:10 -0700 (PDT) From: "Jordan K. Hubbard" Message-Id: <199604151148.EAA19676@time.cdrom.com> To: markm@freebsd.org Subject: Most recent eBones changes break -current Cc: current@freebsd.org Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This is just a straight make world from yesterday's sources: rm -f .depend mkdep -f .depend -a -I. -I/a/src-current/eBones/lib/libkadm -I/a/src-current/eB ones/lib/libkadm/../../lib/libkrb/obj -DPOSIX -I/a/src-current/eBones/lib/libkad m/../../../secure/lib/libdes -I/a/src-current/eBones/lib/libkadm/../../include - I/a/src-current/eBones/lib/libkadm/../../../secure/lib/libdes -I/a/src-current/e Bones/lib/libkadm/../../include kadm_err.c /a/src-current/eBones/lib/libkadm/ka dm_stream.c /a/src-current/eBones/lib/libkadm/kadm_supp.c /a/src-current/eBones/ lib/libkadm/kadm_cli_wrap.c /a/src-current/eBones/lib/libkadm/kadm_cli_wrap.c:32: krb_err.h: No such file or directory mkdep: compile failed. *** Error code 1 Stop. Missing dependency? Bogus tree on my part? Anyone else verify this? Jordan From owner-freebsd-current Mon Apr 15 06:29:34 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA16929 for current-outgoing; Mon, 15 Apr 1996 06:29:34 -0700 (PDT) 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 GAA16924 for ; Mon, 15 Apr 1996 06:29:32 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.7.5/8.6.9) id IAA08884; Mon, 15 Apr 1996 08:29:20 -0500 (EST) From: "John S. Dyson" Message-Id: <199604151329.IAA08884@dyson.iquest.net> Subject: Re: Just how stable is current To: syssgm@devetir.qld.gov.au (Stephen McKay) Date: Mon, 15 Apr 1996 08:29:19 -0500 (EST) Cc: freebsd-current@freebsd.org, syssgm@devetir.qld.gov.au In-Reply-To: <199604150856.SAA14153@orion.devetir.qld.gov.au> from "Stephen McKay" at Apr 15, 96 06:55:59 pm Reply-To: dyson@freebsd.org 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 > > RSS < 0 may be a cosmetic flaw, or it may be seriously buggering the VM system. > I don't know yet, but I'm valiantly struggling through the VM code. :-) > Cosmetic. > > 3) Madly spinning processes: This morning the scene was: > Pagetable paging has changed. Might be the problem, will look at it. John From owner-freebsd-current Mon Apr 15 09:22:41 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA01255 for current-outgoing; Mon, 15 Apr 1996 09:22:41 -0700 (PDT) Received: from grumble.grondar.za (root@grumble.grondar.za [196.7.18.130]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id JAA01250 for ; Mon, 15 Apr 1996 09:22:37 -0700 (PDT) Received: from grumble.grondar.za (mark@localhost [127.0.0.1]) by grumble.grondar.za (8.7.5/8.7.3) with ESMTP id SAA02235; Mon, 15 Apr 1996 18:21:52 +0200 (SAT) Message-Id: <199604151621.SAA02235@grumble.grondar.za> To: "Jordan K. Hubbard" cc: current@freebsd.org Subject: Re: Most recent eBones changes break -current Date: Mon, 15 Apr 1996 18:21:52 +0200 From: Mark Murray Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk "Jordan K. Hubbard" wrote: > This is just a straight make world from yesterday's sources: > > rm -f .depend I did a fix to fix specifically this. What does your eBones/lib/Makefile look like? M > mkdep -f .depend -a -I. -I/a/src-current/eBones/lib/libkadm -I/a/src-current /eB > ones/lib/libkadm/../../lib/libkrb/obj -DPOSIX -I/a/src-current/eBones/lib/lib kad > m/../../../secure/lib/libdes -I/a/src-current/eBones/lib/libkadm/../../includ e - > I/a/src-current/eBones/lib/libkadm/../../../secure/lib/libdes -I/a/src-curren t/e > Bones/lib/libkadm/../../include kadm_err.c /a/src-current/eBones/lib/libkadm /ka > dm_stream.c /a/src-current/eBones/lib/libkadm/kadm_supp.c /a/src-current/eBon es/ > lib/libkadm/kadm_cli_wrap.c > /a/src-current/eBones/lib/libkadm/kadm_cli_wrap.c:32: krb_err.h: No such file or > directory > mkdep: compile failed. > *** Error code 1 > > Stop. > > Missing dependency? Bogus tree on my part? Anyone else verify this? > > Jordan -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grondar.za for PGP key From owner-freebsd-current Mon Apr 15 09:55:15 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA05492 for current-outgoing; Mon, 15 Apr 1996 09:55:15 -0700 (PDT) Received: from ki.net (root@ki.net [205.150.102.1]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id JAA05429 for ; Mon, 15 Apr 1996 09:55:01 -0700 (PDT) Received: from localhost (scrappy@localhost) by ki.net (8.7.4/8.7.4) with SMTP id MAA10634 for ; Mon, 15 Apr 1996 12:54:54 -0400 (EDT) Date: Mon, 15 Apr 1996 12:54:52 -0400 (EDT) From: "Marc G. Fournier" To: current@freebsd.org Subject: Really stupid question of the day 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 just found out that the machine I'm running -current on is, in fact, a 486DX4-100, not a 486DX2-66 as I was earlier led to believe. The motherboard jumper settings are set as being a DX2, not a DX4...could that, in any way, cause the problems that I've recently been experiencing on that machine, or would this be totally irrelevant? Thanks...*sigh* Marc G. Fournier scrappy@ki.net Systems Administrator @ ki.net scrappy@freebsd.org From owner-freebsd-current Mon Apr 15 10:14:28 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA08780 for current-outgoing; Mon, 15 Apr 1996 10:14:28 -0700 (PDT) Received: from vector.jhs.no_domain (slip139-92-18-159.pt.uk.ibm.net [139.92.18.159]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id KAA08666 Mon, 15 Apr 1996 10:13:55 -0700 (PDT) Received: (from jhs@localhost) by vector.jhs.no_domain (8.7.3/8.6.9) id QAA03317; Mon, 15 Apr 1996 16:33:50 +0200 (MET DST) Date: Mon, 15 Apr 1996 16:33:50 +0200 (MET DST) Message-Id: <199604151433.QAA03317@vector.jhs.no_domain> To: current@freebsd.org cc: rgrimes@freebsd.org Subject: share/mk/bsd.README 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 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I suggest in share/mk/bsd.README, (notwithstanding the ] XXX This document is seriously out of date, it is currenly being revised. ) that ] Each ".mk" file has a ] corresponding ".rd" file which is an explanation of the ".mk" file. be removed, as it is false & misleading. I wouldn't care if it just said "future intention is that ... blah blah", (or was changed to say that), but current info is false. Julian -- Julian H. Stacey jhs@freebsd.org http://www.freebsd.org/~jhs/ (PGP available) -- "Every 2 or 3 centuries there is a volcanic eruption so big that it fouls up the atmosphere for a couple of years. There are just no harvests. According to current estimates, the world's grain stocks are only 45 days." ... James Lovlock, quoted by Newsweek's Ken Shulman 15th April 1996. From owner-freebsd-current Mon Apr 15 10:27:21 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA10900 for current-outgoing; Mon, 15 Apr 1996 10:27:21 -0700 (PDT) Received: from ki.net (root@ki.net [205.150.102.1]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id KAA10891 for ; Mon, 15 Apr 1996 10:27:17 -0700 (PDT) Received: from localhost (scrappy@localhost) by ki.net (8.7.4/8.7.4) with SMTP id NAA11456; Mon, 15 Apr 1996 13:26:43 -0400 (EDT) Date: Mon, 15 Apr 1996 13:26:41 -0400 (EDT) From: "Marc G. Fournier" To: David Greenman cc: current@FreeBSD.ORG Subject: Re: Panic during boot In-Reply-To: <199604150332.UAA04584@Root.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 Sun, 14 Apr 1996, David Greenman wrote: > >> Wait, what's wrong with -n?? Except for the other day, I always > >> use -gn when I reconfig the sources before compiling, so that I don't lose > >> my version #. > > > >It would have been nice if you mentioned this back when you were talking > >about other problems you were having. > > > >-n is _evil_. If any changes have been made to your kernel sources that > >you are not _intimately_ familiar with, (ie. you have resupped), then > >you _must_must_must_ not use -n. Dependencies aren't enough to protect > >you from losing like this. I suspect this _may_ be part of your problem. > > Indeed. Even the dependencies themselves don't always work as expected so > some things don't get rebuilt when they need to be. The whole reason why > Jordan made the change to config to blow away the compile directory was > because we kept getting weird bug reports that later turned out to be caused > by a stale .o's. > As I sent back to Jordan...*groan* I only wanted to keep my version numbers straight :( actually, when I think back on it, it wasn't until I started asking about the version numbers that someone mentioned the -n switch...can we get rid of it altogether? :) Recompiling my kernel now and I'll see if that fixes the problem :( Marc G. Fournier scrappy@ki.net Systems Administrator @ ki.net scrappy@freebsd.org From owner-freebsd-current Mon Apr 15 10:29:13 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA11292 for current-outgoing; Mon, 15 Apr 1996 10:29:13 -0700 (PDT) Received: from ki.net (root@ki.net [205.150.102.1]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id KAA11271 for ; Mon, 15 Apr 1996 10:29:04 -0700 (PDT) Received: from localhost (scrappy@localhost) by ki.net (8.7.4/8.7.4) with SMTP id NAA11853; Mon, 15 Apr 1996 13:28:47 -0400 (EDT) Date: Mon, 15 Apr 1996 13:28:46 -0400 (EDT) From: "Marc G. Fournier" To: Joerg Wunsch cc: FreeBSD-current users Subject: Re: Panic during boot In-Reply-To: <199604150808.KAA11461@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 Mon, 15 Apr 1996, J Wunsch wrote: > People who are using unsupported options, or people who upgrade their > machines frequently to newer sources are expected to know what they're > doing. Well, now I at least know better... Marc G. Fournier scrappy@ki.net Systems Administrator @ ki.net scrappy@freebsd.org From owner-freebsd-current Mon Apr 15 10:34:16 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA11969 for current-outgoing; Mon, 15 Apr 1996 10:34:16 -0700 (PDT) Received: from robin.mcnc.org.mcnc.org (robin.mcnc.org [128.109.130.29]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA11932 Mon, 15 Apr 1996 10:34:06 -0700 (PDT) Received: by robin.mcnc.org.mcnc.org (8.6.9/MCNC/8-10-92) id NAA26450; Mon, 15 Apr 1996 13:34:00 -0400 for Date: Mon, 15 Apr 1996 13:34:00 -0400 From: "Frank E. Terhaar-Yonkers" Message-Id: <199604151734.NAA26450@robin.mcnc.org.mcnc.org> To: stable@freebsd.org, current@freebsd.org Subject: anyone have patches for Cy 6x86 processors? X-Face: ,fjtWiMPydUaSQl%8[eTg`u:^BXt&T)Sny(6w\*U"5D9H[Z$kG%Q/z;Z=NwrPiXf-aMF3R) Rsand$,]26-8>5@HD(A3A79gN|0%NHsdek4mT8E,>j+\w!~d2#nH;~NV!5a0"`5$Cj8d\or(Jy/JQ_ |uc;C[filmZ(~#lre*l:|O%d/PJFy`.5w8)sMZ-)QI3TaV"j'k Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk It boots, it runs. Only it thinks it's a 486 not a 586. Has anyone done this yet, or do I get to go first? - Frank (BTW - the motherboard is the new Tyan Tomcat - Triton II) \\\\////\\\\////\\\\\////\\\\\////\\\\////\\\\////\\\\////\\\\////\\\\////\\\\ Frank Terhaar-Yonkers, Manager High Performance Computing and Communications Research MCNC PO Box 12889 3021 Cornwallis Road Research Triangle Park, North Carolina 27709-2889 fty@mcnc.org voice (919)248-1417 FAX (919)248-1455 http://www.mcnc.org/hpcc.html From owner-freebsd-current Mon Apr 15 11:31:03 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA18881 for current-outgoing; Mon, 15 Apr 1996 11:31:03 -0700 (PDT) Received: from phoenix.csie.nctu.edu.tw (root@phoenix.csie.nctu.edu.tw [140.113.17.171]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA18874 for ; Mon, 15 Apr 1996 11:30:59 -0700 (PDT) Received: from FreeBSD.csie.NCTU.edu.tw (root@freebsd.csie.nctu.edu.tw [140.113.235.250]) by phoenix.csie.nctu.edu.tw (8.6.11/8.6.4) with ESMTP id CAA08841 for ; Tue, 16 Apr 1996 02:31:16 +0800 Received: (from jdli@localhost) by FreeBSD.csie.NCTU.edu.tw (8.7.5/8.7.3) id CAA15009 for freebsd-current@freebsd.org; Tue, 16 Apr 1996 02:30:38 +0800 (CST) From: Jian-Da Li Message-Id: <199604151830.CAA15009@FreeBSD.csie.NCTU.edu.tw> Subject: xpaint broken in 2.2-Apr-15 To: freebsd-current@freebsd.org Date: Tue, 16 Apr 1996 02:30:38 +0800 (CST) X-Mailer: ELM [version 2.4ME+ PL11 (25)] 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 Hi : My xpaint (packages-current) worked fine in 2.2-0323-SNAP, but it sig-11 in 0415-current while i load any xpm file. -- §õ «Ø ¹F (Jian-Da Li) ¥æ¤j¸ê¤u E-Mail : jdli@csie.nctu.edu.tw From owner-freebsd-current Mon Apr 15 11:32:05 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA19108 for current-outgoing; Mon, 15 Apr 1996 11:32:05 -0700 (PDT) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id LAA19054 for ; Mon, 15 Apr 1996 11:32:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by rover.village.org (8.7.5/8.6.6) with SMTP id MAA01152 for ; Mon, 15 Apr 1996 12:31:47 -0600 (MDT) Message-Id: <199604151831.MAA01152@rover.village.org> To: current@freebsd.org Subject: Which one is faster Date: Mon, 15 Apr 1996 12:31:47 -0600 From: Warner Losh Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'm looking for a fairly easy way to tell if my UltraStore 34F is faster than a BT-545S or the other way around. Since I don't have raw disks to test performance with, can someone recommend a good disk benchmark. For the tape, I was going to do a level 0 and see which one is faster... Warner From owner-freebsd-current Mon Apr 15 12:01:05 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA23166 for current-outgoing; Mon, 15 Apr 1996 12:01:05 -0700 (PDT) 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 MAA23149 for ; Mon, 15 Apr 1996 12:01:00 -0700 (PDT) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id MAA24413; Mon, 15 Apr 1996 12:00:44 -0700 From: "Rodney W. Grimes" Message-Id: <199604151900.MAA24413@GndRsh.aac.dev.com> Subject: Re: Really stupid question of the day To: scrappy@ki.net (Marc G. Fournier) Date: Mon, 15 Apr 1996 12:00:43 -0700 (PDT) Cc: current@FreeBSD.org In-Reply-To: from "Marc G. Fournier" at "Apr 15, 96 12:54:52 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... > > I just found out that the machine I'm running -current on is, > in fact, a 486DX4-100, not a 486DX2-66 as I was earlier led to believe. ^^^^^^^^^^ Intel? Amd? If Intel, is it a DX4100ODPR or ODP? If Amd is it an NV8T or SV8B? > > The motherboard jumper settings are set as being a DX2, not a > DX4...could that, in any way, cause the problems that I've recently > been experiencing on that machine, or would this be totally irrelevant? It could, especially if the motherboard has decided that you need 5V for that chip. (Yes, the chip will run, but it will run very very hot, and very likely have really strange problems, if set for 5V when infact it is a 3V chip). > > Thanks...*sigh* > > Marc G. Fournier scrappy@ki.net > Systems Administrator @ ki.net scrappy@freebsd.org > > -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Mon Apr 15 12:35:52 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA27320 for current-outgoing; Mon, 15 Apr 1996 12:35:52 -0700 (PDT) Received: from babba.cu-online.com (somebody@babba.cu-online.com [205.198.248.21]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id MAA27315 for ; Mon, 15 Apr 1996 12:35:50 -0700 (PDT) Received: from localhost (somebody@localhost) by babba.cu-online.com (8.7.5/8.7.3) with SMTP id OAA12573 for ; Mon, 15 Apr 1996 14:35:35 -0500 (CDT) Date: Mon, 15 Apr 1996 14:35:35 -0500 (CDT) From: Somebody To: current@freebsd.org Subject: Suggestions? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have a news server built and I am in the process of deciding what version of FreeBSD I want to use. I am think of going with BSD-STABLE but I am not sure if this the best decision. This machine is a P133 with 48M of ram and Buslogic 946C and a 4.2G Atlas Pro and 1G EIDE Drive for the base OS and it will be running INN1.4unoff3 or unoff2. This machine will at first act as a newsfeeder for my other locations and other news exchangers. Thank You Carlos Carlos Ramirez (217) 356 - 4009 Voice CU-Online System Administrator (217) 356 - 3600 Data Offerings Circuits Upto T1/E1 Speeds at affordable rates. "Your one stop Internet Provider" From owner-freebsd-current Mon Apr 15 12:54:09 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA29194 for current-outgoing; Mon, 15 Apr 1996 12:54:09 -0700 (PDT) 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 MAA29189 for ; Mon, 15 Apr 1996 12:54:00 -0700 (PDT) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id VAA12272 for ; Mon, 15 Apr 1996 21:53:47 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id VAA21247 for freebsd-current@FreeBSD.org; Mon, 15 Apr 1996 21:53:47 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id UAA12685 for freebsd-current@FreeBSD.org; Mon, 15 Apr 1996 20:59:52 +0200 (MET DST) From: J Wunsch Message-Id: <199604151859.UAA12685@uriah.heep.sax.de> Subject: Re: NFS timing (Was: Just how stable is current) To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Mon, 15 Apr 1996 20:59:52 +0200 (MET DST) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199604150856.SAA14153@orion.devetir.qld.gov.au> from "Stephen McKay" at Apr 15, 96 06:55: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 Stephen McKay wrote: > 1) NFS problem: My January 9 kernel will work properly as a client with any > server using 8Kb max size UDP connections. More recent kernels won't. I > get severe performance degradation that I assume is from lots of retries and > timeouts, even though I can't find them in nfsstat. Many processes hang > for long periods in sbwait, nfsrcvlk and similar network states. > > Ok, overruns are a common problem with PC network cards, especially in slow > machines. However, setting the maximum size to 1Kb does not cure the > problem (or maybe moves the problem elsewhere). Switching to TCP transport > produced a total cure, but is not available on all servers. This seems to be identical with the observation that all recent SNAPs have increased timing problems (up to totally unusable) when installing over NFS. For me, it required me to revert to 1 KB blocksize (even though the NFS server is also only a lame 8-bit 3c503), and we've got at least one installation problem report where the installation totally starved at the first lengthy file, even _with_ the ``NFS slow'' option. I really wonder what might have caused this 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 Mon Apr 15 15:36:39 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA13400 for current-outgoing; Mon, 15 Apr 1996 15:36:39 -0700 (PDT) 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 PAA13394 for ; Mon, 15 Apr 1996 15:36:34 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.7.5/8.6.9) id RAA09839; Mon, 15 Apr 1996 17:35:22 -0500 (EST) From: "John S. Dyson" Message-Id: <199604152235.RAA09839@dyson.iquest.net> Subject: Re: NFS timing (Was: Just how stable is current) To: joerg_wunsch@uriah.heep.sax.de Date: Mon, 15 Apr 1996 17:35:22 -0500 (EST) Cc: freebsd-current@FreeBSD.org In-Reply-To: <199604151859.UAA12685@uriah.heep.sax.de> from "J Wunsch" at Apr 15, 96 08:59:52 pm Reply-To: dyson@FreeBSD.org 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 > For me, it required me to revert to 1 KB blocksize (even though the > NFS server is also only a lame 8-bit 3c503), and we've got at least > one installation problem report where the installation totally starved > at the first lengthy file, even _with_ the ``NFS slow'' option. > > I really wonder what might have caused this change. > Try adding an spl0(); at the beginning of vm_daemon in vm_pageout.c. This was causing some unpleasant interrupt latencies. BDE figured this one out. Might work, might not. John From owner-freebsd-current Mon Apr 15 20:59:40 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id UAA05244 for current-outgoing; Mon, 15 Apr 1996 20:59:40 -0700 (PDT) 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 UAA05237 for ; Mon, 15 Apr 1996 20:59:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with SMTP id UAA22884; Mon, 15 Apr 1996 20:58:18 -0700 (PDT) To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) cc: freebsd-current@FreeBSD.org (FreeBSD-current users) Subject: Re: NFS timing (Was: Just how stable is current) In-reply-to: Your message of "Mon, 15 Apr 1996 20:59:52 +0200." <199604151859.UAA12685@uriah.heep.sax.de> Date: Mon, 15 Apr 1996 20:58:18 -0700 Message-ID: <22882.829627098@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > This seems to be identical with the observation that all recent SNAPs > have increased timing problems (up to totally unusable) when > installing over NFS. Yes, I hate to admit it but I just managed to reproduce it myself - NFS installs are pretty broken in -current. Sigh. Any clues from the kernel gurus? Jordan From owner-freebsd-current Mon Apr 15 21:19:21 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA06768 for current-outgoing; Mon, 15 Apr 1996 21:19:21 -0700 (PDT) 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 VAA06760 for ; Mon, 15 Apr 1996 21:19:16 -0700 (PDT) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id OAA22276; Tue, 16 Apr 1996 14:20:06 +0930 From: Michael Smith Message-Id: <199604160450.OAA22276@genesis.atrad.adelaide.edu.au> Subject: Re: NFS timing (Was: Just how stable is current) To: joerg_wunsch@uriah.heep.sax.de Date: Tue, 16 Apr 1996 14:20:06 +0930 (CST) Cc: freebsd-current@FreeBSD.ORG In-Reply-To: <199604151859.UAA12685@uriah.heep.sax.de> from "J Wunsch" at Apr 15, 96 08:59:52 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 J Wunsch stands accused of saying: > This seems to be identical with the observation that all recent SNAPs > have increased timing problems (up to totally unusable) when > installing over NFS. > > For me, it required me to revert to 1 KB blocksize (even though the > NFS server is also only a lame 8-bit 3c503), and we've got at least > one installation problem report where the installation totally starved > at the first lengthy file, even _with_ the ``NFS slow'' option. Hmm. I thought it was just me, but maybe not. I have a machine at home at the most recent -SNAP level that NFS-mounts /usr/src. A 'make world' will eventually 'sieze up' - it's still possible to log in, providing you don't do anything NFS related. (Even on another mount). If you do, your process again just stops. The server is -stable from around the beginning of April. > I really wonder what might have caused this change. Indeed. > 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 Tue Apr 16 00:51:14 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA21039 for current-outgoing; Tue, 16 Apr 1996 00:51:14 -0700 (PDT) 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 AAA21032 for ; Tue, 16 Apr 1996 00:51:04 -0700 (PDT) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id JAA29417 for ; Tue, 16 Apr 1996 09:51:00 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id JAA01385 for freebsd-current@FreeBSD.org; Tue, 16 Apr 1996 09:51:00 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id JAA16501 for freebsd-current@FreeBSD.org; Tue, 16 Apr 1996 09:04:40 +0200 (MET DST) From: J Wunsch Message-Id: <199604160704.JAA16501@uriah.heep.sax.de> Subject: Re: NFS timing (Was: Just how stable is current) To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Tue, 16 Apr 1996 09:04:39 +0200 (MET DST) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199604152235.RAA09839@dyson.iquest.net> from "John S. Dyson" at Apr 15, 96 05:35:22 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 John S. Dyson wrote: > > For me, it required me to revert to 1 KB blocksize (even though the > > NFS server is also only a lame 8-bit 3c503), and we've got at least > > one installation problem report where the installation totally starved > > at the first lengthy file, even _with_ the ``NFS slow'' option. > Try adding an spl0(); at the beginning of vm_daemon in vm_pageout.c. This > was causing some unpleasant interrupt latencies. BDE figured this one out. > Might work, might not. I doubt, all SNAPs i've test-installed have been compiled before Bruce was changing this. So i guess it's something else. The deadline seems to be mid January. -- 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 16 05:23:08 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA07655 for current-outgoing; Tue, 16 Apr 1996 05:23:08 -0700 (PDT) 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 FAA07650 for ; Tue, 16 Apr 1996 05:23:06 -0700 (PDT) Received: by ghost.uunet.ca id <61431-2>; Tue, 16 Apr 1996 08:22:55 -0400 Date: Tue, 16 Apr 1996 08:22:48 -0400 From: Cat Okita To: "Rodney W. Grimes" cc: "Marc G. Fournier" , current@FreeBSD.org Subject: Re: Really stupid question of the day In-Reply-To: <199604151900.MAA24413@GndRsh.aac.dev.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, 15 Apr 1996, Rodney W. Grimes wrote: Marc Fournier wrote: > > I just found out that the machine I'm running -current on is, > > in fact, a 486DX4-100, not a 486DX2-66 as I was earlier led to believe. > ^^^^^^^^^^ > Intel? Amd? If Intel, is it a DX4100ODPR or ODP? If Amd is it an NV8T > or SV8B? It's an AMD chip, and should be 3.3V Cat From owner-freebsd-current Tue Apr 16 08:50:26 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA20445 for current-outgoing; Tue, 16 Apr 1996 08:50:26 -0700 (PDT) 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 IAA20438 for ; Tue, 16 Apr 1996 08:50:24 -0700 (PDT) Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA17258; Tue, 16 Apr 1996 11:49:40 -0400 Date: Tue, 16 Apr 1996 11:49:40 -0400 From: Garrett Wollman Message-Id: <9604161549.AA17258@halloran-eldar.lcs.mit.edu> To: Mike Grupenhoff Cc: current@freebsd.org Subject: Re: rfork() changes In-Reply-To: References: <199604161003.SAA04157@jhome.DIALix.COM> Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk < said: > IMO, considering that the point of vfork() was as a faster fork() for > exec()ing a new program, and not for address space sharing, programs that > abuse the address sharing bogusness present in old implementations deserve > to die. I can't imagine too many of them exist anyway. I would have no problem with implementing vfork() in libc as a call for fork(). Then, we can redeclare vfork() as LIBCOMPAT in syscalls.master, using fork() as the function, and eliminate all the kernel cruft completely. -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 16 09:07:38 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA21359 for current-outgoing; Tue, 16 Apr 1996 09:07:38 -0700 (PDT) Received: from knecht.Oxford.Reference.COM (root@knecht.oxford.reference.com [204.247.98.2]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id JAA21349 for ; Tue, 16 Apr 1996 09:07:06 -0700 (PDT) Received: from knecht.Oxford.Reference.COM (eric@localhost [127.0.0.1]) by knecht.Oxford.Reference.COM (8.7.4/8.8.Alpha.0) with ESMTP id IAA26112; Tue, 16 Apr 1996 08:49:03 -0700 (PDT) Message-Id: <199604161549.IAA26112@knecht.Oxford.Reference.COM> X-Mailer: exmh version 1.6.5 12/11/95 To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) From: Eric Allman X-URL: http://WWW.Reference.COM/~eric cc: freebsd-current@freebsd.org (FreeBSD-current users) Subject: Re: The Biff service In-reply-to: Mail from J Wunsch dated Mon, 08 Apr 1996 11:56:44 +0200 <199604080956.LAA04555@uriah.heep.sax.de> Date: Tue, 16 Apr 1996 08:48:59 -0700 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Sorry for not answering earlier -- I've been on jury duty, and between that and my job haven't had much free time. The intent of mail.local is that it be as simple as possible. I'm reluctant to start adding options. This one doesn't seem terribly dangerous on the surface, but it's a dangerous precedent. An alternative would be to add a "discard" entry to inetd.conf for this service. This would require no code changes and would have the same effect. eric ============= In Reply To: =========================================== : From: J Wunsch : Subject: The Biff service : Date: Mon, 8 Apr 1996 11:56:44 +0200 (MET DST) : Would people kill me for introducing a `-b' option to mail.local(8) to : stop it from attempting to use the ``biff'' service? : : (To Eric: recent FreeBSD kernels can log failed connection attempts to : TCP or UDP ports. So the `biff' attempts clutter the logs. However, : /etc/services is normally being used as a ``list of known services'' : as opposed to a ``list of installed services'', so checking with : getservbyname() alone isn't really an option.) : : Index: sendmail/mail.local/mail.local.8 : =================================================================== : RCS file: /home/ncvs/src/usr.sbin/sendmail/mail.local/mail.local.8,v : retrieving revision 1.1.1.1 : diff -u -u -r1.1.1.1 mail.local.8 : --- mail.local.8 1995/12/02 17:30:22 1.1.1.1 : +++ mail.local.8 1996/04/08 09:47:16 : @@ -40,6 +40,7 @@ : .Sh SYNOPSIS : .Nm mail.local : .Op Fl f Ar from : +.Op Fl b : .Ar user ... : .Sh DESCRIPTION : .Nm Mail.local : @@ -55,6 +56,10 @@ : .Bl -tag -width xxxfrom : .It Fl f Ar from : Specify the sender's name. : +.It Fl b : +Turn off the attempts to notify the : +.Dq biff : +service. : .El : .Pp : Individual mail messages in the mailbox are delimited by an empty : Index: sendmail/mail.local/mail.local.c : =================================================================== : RCS file: /home/ncvs/src/usr.sbin/sendmail/mail.local/mail.local.c,v : retrieving revision 1.1.1.1 : diff -u -u -r1.1.1.1 mail.local.c : --- mail.local.c 1995/12/02 17:30:22 1.1.1.1 : +++ mail.local.c 1996/04/08 09:55:44 : @@ -127,7 +127,7 @@ : : int eval = EX_OK; /* sysexits.h error value. */ : : -void deliver __P((int, char *)); : +void deliver __P((int, char *, int)); : void e_to_sys __P((int)); : __dead void err __P((const char *, ...)); : void notifybiff __P((char *)); : @@ -142,7 +142,7 @@ : char *argv[]; : { : struct passwd *pw; : - int ch, fd; : + int ch, fd, nobiff; : uid_t uid; : char *from; : extern char *optarg; : @@ -162,8 +162,12 @@ : #endif : : from = NULL; : - while ((ch = getopt(argc, argv, "df:r:")) != EOF) : + nobiff = 0; : + while ((ch = getopt(argc, argv, "bdf:r:")) != EOF) : switch(ch) { : + case 'b': : + nobiff++; : + break; : case 'd': /* Backward compatible. */ : break; : case 'f': : @@ -204,7 +208,7 @@ : * at the expense of repeated failures and multiple deliveries. : */ : for (fd = store(from); *argv; ++argv) : - deliver(fd, *argv); : + deliver(fd, *argv, nobiff); : exit(eval); : } : : @@ -259,8 +263,8 @@ : } : : void : -deliver(fd, name) : - int fd; : +deliver(fd, name, nobiff) : + int fd, nobiff; : char *name; : { : struct stat fsb, sb; : @@ -368,11 +372,14 @@ : goto err1; : } : : - /* Get the starting offset of the new message for biff. */ : - curoff = lseek(mbfd, (off_t)0, SEEK_END); : - (void)snprintf(biffmsg, sizeof(biffmsg), : - sizeof curoff > sizeof(long) ? "%s@%qd\n" : "%s@%ld\n", : - name, curoff); : + if (!nobiff) { : + /* Get the starting offset of the new message for biff. */ : + curoff = lseek(mbfd, (off_t)0, SEEK_END); : + (void)snprintf(biffmsg, sizeof(biffmsg), : + sizeof curoff > sizeof(long) ? : + "%s@%qd\n" : "%s@%ld\n", : + name, curoff); : + } : : /* Copy the message into the file. */ : if (lseek(fd, (off_t)0, SEEK_SET) == (off_t)-1) { : @@ -436,7 +443,8 @@ : printf("reset euid = %d\n", geteuid()); : #endif : unlockmbox(); : - notifybiff(biffmsg); : + if (!nobiff) : + notifybiff(biffmsg); : } : : /* : @@ -525,7 +533,7 @@ : usage() : { : eval = EX_USAGE; : - err("usage: mail.local [-f from] user ..."); : + err("usage: mail.local [-b] [-f from] user ..."); : } : : #if __STDC__ : : -- : 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 16 09:43:11 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA23386 for current-outgoing; Tue, 16 Apr 1996 09:43:11 -0700 (PDT) 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 JAA23355 for ; Tue, 16 Apr 1996 09:42:52 -0700 (PDT) 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 SAA05431 ; Tue, 16 Apr 1996 18:42:12 +0200 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id SAA03713 ; Tue, 16 Apr 1996 18:42:37 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.7.5/keltia-uucp-2.7) id IAA07110; Tue, 16 Apr 1996 08:34:18 +0200 (MET DST) From: Ollivier Robert Message-Id: <199604160634.IAA07110@keltia.freenix.fr> Subject: Re: Suggestions? To: somebody@cu-online.com (Somebody) Date: Tue, 16 Apr 1996 08:34:17 +0200 (MET DST) Cc: current@FreeBSD.ORG In-Reply-To: from Somebody at "Apr 15, 96 02:35:35 pm" X-Operating-System: FreeBSD 2.2-CURRENT ctm#1889 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 Somebody said: > what version of FreeBSD I want to use. I am think of going with BSD-STABLE > but I am not sure if this the best decision. This machine is a P133 with ^^^^^ You don't really need a P133 for this. > 48M of ram and Buslogic 946C and a 4.2G Atlas Pro and 1G EIDE Drive for ^^^ Maybe not enough if you have a big enough feed. I'd suggest bying 2x 2.2 GB disk or 4x 1 GB disks and spread the spool & news dir & overview data over all the disks (maybe with ccd). Get rid of the IDE disk. Go all SCSI. IDE is evil. > the base OS and it will be running INN1.4unoff3 or unoff2. Take unoff4 and innfeed (see into news.software.nntp for details). > This machine will at first act as a newsfeeder for my other > locations and other news exchangers. Better take a P90 with 64 MB than a P133 with 48... Memory is more important than CPU power. My 2 ECUS^H^H^H^HEUROS. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 2.2-CURRENT #12: Sun Apr 14 16:01:04 MET DST 1996 From owner-freebsd-current Tue Apr 16 09:50:32 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA23962 for current-outgoing; Tue, 16 Apr 1996 09:50:32 -0700 (PDT) Received: from babba.cu-online.com (somebody@babba.cu-online.com [205.198.248.21]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id JAA23955 for ; Tue, 16 Apr 1996 09:50:29 -0700 (PDT) Received: from localhost (somebody@localhost) by babba.cu-online.com (8.7.5/8.7.3) with SMTP id LAA04698; Tue, 16 Apr 1996 11:50:10 -0500 (CDT) Date: Tue, 16 Apr 1996 11:50:09 -0500 (CDT) From: Somebody To: Ollivier Robert cc: current@FreeBSD.ORG Subject: Re: Suggestions? In-Reply-To: <199604160634.IAA07110@keltia.freenix.fr> 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, 16 Apr 1996, Ollivier Robert wrote: > It seems that Somebody said: > > what version of FreeBSD I want to use. I am think of going with BSD-STABLE > > but I am not sure if this the best decision. This machine is a P133 with > ^^^^^ > You don't really need a P133 for this. > > > 48M of ram and Buslogic 946C and a 4.2G Atlas Pro and 1G EIDE Drive for > ^^^ > Maybe not enough if you have a big enough feed. > > I'd suggest bying 2x 2.2 GB disk or 4x 1 GB disks and spread the spool & > news dir & overview data over all the disks (maybe with ccd). Get rid of > the IDE disk. Go all SCSI. IDE is evil. > > > the base OS and it will be running INN1.4unoff3 or unoff2. > > Take unoff4 and innfeed (see into news.software.nntp for details). > > > This machine will at first act as a newsfeeder for my other > > locations and other news exchangers. > > Better take a P90 with 64 MB than a P133 with 48... Memory is more > important than CPU power. Oh it doesn't matter actually memory and ram I will add more as need it. Yeah I heard good stuff about innfeed parrallel feeding and such sounds very cool. BTW I got another question I installed 2.1.0 how do I get the thing to upgrade tho to FreeBSD-stable. Carlosx Carlos Ramirez (217) 356 - 4009 Voice CU-Online System Administrator (217) 356 - 3600 Data Offerings Circuits Upto T1/E1 Speeds at affordable rates. "Your one stop Internet Provider" From owner-freebsd-current Tue Apr 16 10:46:27 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA27390 for current-outgoing; Tue, 16 Apr 1996 10:46:27 -0700 (PDT) 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 KAA27385 for ; Tue, 16 Apr 1996 10:46:24 -0700 (PDT) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id KAA25667; Tue, 16 Apr 1996 10:45:29 -0700 From: "Rodney W. Grimes" Message-Id: <199604161745.KAA25667@GndRsh.aac.dev.com> Subject: Re: Really stupid question of the day To: cat@ghost.uunet.ca (Cat Okita) Date: Tue, 16 Apr 1996 10:45:28 -0700 (PDT) Cc: scrappy@ki.net, current@FreeBSD.org In-Reply-To: from Cat Okita at "Apr 16, 96 08:22:48 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 > On Mon, 15 Apr 1996, Rodney W. Grimes wrote: > Marc Fournier wrote: > > > I just found out that the machine I'm running -current on is, > > > in fact, a 486DX4-100, not a 486DX2-66 as I was earlier led to believe. > > ^^^^^^^^^^ > > Intel? Amd? If Intel, is it a DX4100ODPR or ODP? If Amd is it an NV8T > > or SV8B? > > It's an AMD chip, and should be 3.3V Now the real question, was the motherboard setting for DX2/66 supplying the chip with 5V. If it was, it could explain a _lot_ of your problems :-) -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Tue Apr 16 11:02:36 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA28330 for current-outgoing; Tue, 16 Apr 1996 11:02:36 -0700 (PDT) Received: from ki.net (root@ki.net [205.150.102.1]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id LAA28325 for ; Tue, 16 Apr 1996 11:02:30 -0700 (PDT) Received: from localhost (scrappy@localhost) by ki.net (8.7.4/8.7.4) with SMTP id OAA07357; Tue, 16 Apr 1996 14:01:32 -0400 (EDT) Date: Tue, 16 Apr 1996 14:01:29 -0400 (EDT) From: "Marc G. Fournier" To: "Rodney W. Grimes" cc: Cat Okita , current@FreeBSD.org Subject: Re: Really stupid question of the day In-Reply-To: <199604161745.KAA25667@GndRsh.aac.dev.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, 16 Apr 1996, Rodney W. Grimes wrote: > > On Mon, 15 Apr 1996, Rodney W. Grimes wrote: > > Marc Fournier wrote: > > > > I just found out that the machine I'm running -current on is, > > > > in fact, a 486DX4-100, not a 486DX2-66 as I was earlier led to believe. > > > ^^^^^^^^^^ > > > Intel? Amd? If Intel, is it a DX4100ODPR or ODP? If Amd is it an NV8T > > > or SV8B? > > > > It's an AMD chip, and should be 3.3V > > Now the real question, was the motherboard setting for DX2/66 supplying > the chip with 5V. If it was, it could explain a _lot_ of your problems :-) > I ripped apart the board and all he setting actually look okay... what *I* had screwed up was looking at the setting for the DX4 instead of the AMD :( Back to memory problems.. :( Marc G. Fournier scrappy@ki.net Systems Administrator @ ki.net scrappy@freebsd.org From owner-freebsd-current Tue Apr 16 11:19:49 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA29250 for current-outgoing; Tue, 16 Apr 1996 11:19:49 -0700 (PDT) Received: from babba.cu-online.com (jayk@babba.cu-online.com [205.198.248.21]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id LAA29241 for ; Tue, 16 Apr 1996 11:19:44 -0700 (PDT) Received: from localhost (jayk@localhost) by babba.cu-online.com (8.7.5/8.7.3) with SMTP id NAA08475 for ; Tue, 16 Apr 1996 13:19:29 -0500 (CDT) Date: Tue, 16 Apr 1996 13:19:28 -0500 (CDT) From: Jeremy Koski To: freebsd-current@freebsd.org Subject: /proc Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk When I did a system wide find for setuid programs, I noticed something weird in /proc. It said something like: /proc/1466/file This "file" program was setuid root, but disappeared within seconds, so I don't know what it's purpose was. Can anyone explain this? I'm somewhat worried that it may be a possible security hole. Thanks. From owner-freebsd-current Tue Apr 16 12:22:34 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA01535 for current-outgoing; Tue, 16 Apr 1996 12:22:34 -0700 (PDT) Received: from grumble.grondar.za (root@grumble.grondar.za [196.7.18.130]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id MAA01530 for ; Tue, 16 Apr 1996 12:22:22 -0700 (PDT) Received: from grumble.grondar.za (mark@localhost [127.0.0.1]) by grumble.grondar.za (8.7.5/8.7.3) with ESMTP id VAA18610 for ; Tue, 16 Apr 1996 21:20:49 +0200 (SAT) Message-Id: <199604161920.VAA18610@grumble.grondar.za> To: current@freebsd.org Subject: SNAP CDROM -> CURRENT via CTM? Date: Tue, 16 Apr 1996 21:20:47 +0200 From: Mark Murray Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello All Would anyone be interested in a CTM delta that is a diff between the recently released (23 March) SNAP CDROM and CURRENT for cvs-cur? It would probably make a good starting point for anyone wanting to get going on CTM, or it could allow you to trash your collection of CTM deltas, and use the CDROM + this as your ultimate backup... I have just got a script going that will do this, and am testing it at the moment. If it works, I will generate a diff for cvs-cur.1900 when I am up to that level myself (in +- 12 hours?) M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grondar.za for PGP key From owner-freebsd-current Tue Apr 16 13:06:22 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA04262 for current-outgoing; Tue, 16 Apr 1996 13:06:22 -0700 (PDT) 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 NAA04238 for ; Tue, 16 Apr 1996 13:06:08 -0700 (PDT) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) id VAA21097; Tue, 16 Apr 1996 21:45:20 +0200 (MET DST) Received: from localhost (localhost [127.0.0.1]) by knobel.gun.de (8.7.5/8.7.3) with SMTP id IAA00666; Tue, 16 Apr 1996 08:04:16 +0200 (MET DST) Date: Tue, 16 Apr 1996 08:04:15 +0200 (MET DST) From: Andreas Klemm To: Warner Losh cc: current@FreeBSD.org Subject: Re: Which one is faster In-Reply-To: <199604151831.MAA01152@rover.village.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 Mon, 15 Apr 1996, Warner Losh wrote: > I'm looking for a fairly easy way to tell if my UltraStore 34F is > faster than a BT-545S or the other way around. > > Since I don't have raw disks to test performance with, can someone > recommend a good disk benchmark. For the tape, I was going to do a > level 0 and see which one is faster... Bonnie and large file sizes for the test file. 100M minimum. See ports collection. Avoid iozone. - -- 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 iQCVAwUBMXM4YPMLpmkD/U+FAQHM5gQAsMfAMIc5UPJ4YGoptPfKJPA+nah474ME LXvULMva6yk/bNYSWlyY+el3KMiIw2WBqI3ixTvNd2LSQktGb9qaCqybrylt0E5g no2Ui00fYm4Ggd3EnbO9NBy08SUn/ZA5V5e3+YleI1ugzsiWQBRbdM+6QFeMbCUz qiZj/jtAwtM= =tolQ -----END PGP SIGNATURE----- From owner-freebsd-current Tue Apr 16 16:38:09 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA18046 for current-outgoing; Tue, 16 Apr 1996 16:38:09 -0700 (PDT) Received: from xi.dorm.umd.edu (root@xi.dorm.umd.edu [129.2.152.45]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id QAA18040 for ; Tue, 16 Apr 1996 16:38:06 -0700 (PDT) Received: from localhost (smpatel@localhost [127.0.0.1]) by xi.dorm.umd.edu (8.7.5/8.6.12) with SMTP id TAA06929; Tue, 16 Apr 1996 19:37:56 -0400 (EDT) Date: Tue, 16 Apr 1996 19:37:56 -0400 (EDT) From: Sujal Patel X-Sender: smpatel@xi.dorm.umd.edu To: Garrett Wollman cc: current@freebsd.org Subject: Re: rfork() changes In-Reply-To: <9604161549.AA17258@halloran-eldar.lcs.mit.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 Tue, 16 Apr 1996, Garrett Wollman wrote: > I would have no problem with implementing vfork() in libc as a call > for fork(). Then, we can redeclare vfork() as LIBCOMPAT in > syscalls.master, using fork() as the function, and eliminate all the > kernel cruft completely. I think this would be the best way to go about it. Looking over the entire source tree, it doesn't look like anything will break if vfork() is actually fork(). Also, we should declare vfork() as ``obsolete'' in the man page. At this point, there is no advantage at all to using the vfork() syscall instead of fork(). Any dissent? Sujal From owner-freebsd-current Tue Apr 16 17:55:41 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA21733 for current-outgoing; Tue, 16 Apr 1996 17:55:41 -0700 (PDT) Received: from forgery.CS.Berkeley.EDU (forgery.CS.Berkeley.EDU [128.32.33.75]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id RAA21728 for ; Tue, 16 Apr 1996 17:55:38 -0700 (PDT) Received: (from asami@localhost) by forgery.CS.Berkeley.EDU (8.6.11/8.6.9) id RAA23297; Tue, 16 Apr 1996 17:55:27 -0700 Date: Tue, 16 Apr 1996 17:55:27 -0700 Message-Id: <199604170055.RAA23297@forgery.CS.Berkeley.EDU> To: current@freebsd.org Subject: -current kernel crashes under heavy load From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've got yesterday's -current crash repeatedly (well, three times) under heavy load. We had an array (ccd) of 12 disks and were running 16 random read tests simultaneously. They are all in the same place: === ## gdb -k kernel.4 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...(no debugging symbols found)... IdlePTD 1f0000 current pcb at 1e5230 panic: page fault #0 0xf01ad6bf in boot () (kgdb) bt #0 0xf01ad6bf in boot () #1 0xf0117316 in panic () #2 0xf01b5516 in trap_fatal () #3 0xf01b5008 in trap_pfault () #4 0xf01b4ceb in trap () #5 0xf01aaf01 in calltrap () #6 0xf01a2c3a in vm_map_delete () <========== #7 0xf01a2cc4 in vm_map_remove () #8 0xf010cd16 in exit1 () #9 0xf0113086 in sigexit () #10 0xf0112e98 in postsig () #11 0xf01b5870 in syscall () #12 0xf01aaf55 in Xsyscall () Cannot access memory at address 0xefbfca70. === Satoshi From owner-freebsd-current Tue Apr 16 19:17:45 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id TAA26183 for current-outgoing; Tue, 16 Apr 1996 19:17:45 -0700 (PDT) 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 TAA26168 for ; Tue, 16 Apr 1996 19:17:30 -0700 (PDT) Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id TAA00280 for ; Tue, 16 Apr 1996 19:17:29 -0700 Received: from localhost.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.7.5/8.7.3) with SMTP id WAA12045; Tue, 16 Apr 1996 22:15:34 -0400 (EDT) Message-Id: <199604170215.WAA12045@whizzo.transsys.com> X-Authentication-Warning: whizzo.transsys.com: Host localhost.transsys.com [127.0.0.1] didn't use HELO protocol To: Eric Allman cc: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch), freebsd-current@FreeBSD.org (FreeBSD-current users) From: "Louis A. Mamakos" Subject: Re: The Biff service References: <199604161549.IAA26112@knecht.Oxford.Reference.COM> In-reply-to: Your message of "Tue, 16 Apr 1996 08:48:59 PDT." <199604161549.IAA26112@knecht.Oxford.Reference.COM> Date: Tue, 16 Apr 1996 22:15:34 -0400 Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > An alternative would be to add a "discard" entry to inetd.conf for > this service. This would require no code changes and would have > the same effect. Or for no code changes at all, have 'biff' be an alias for the discard 9/udp sink null line in /etc/services... Assuming that mail.local uses getservbyname() this ought to be all that's required. louie From owner-freebsd-current Tue Apr 16 20:07:38 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id UAA28874 for current-outgoing; Tue, 16 Apr 1996 20:07:38 -0700 (PDT) Received: from phoenix.csie.nctu.edu.tw (root@phoenix.csie.nctu.edu.tw [140.113.17.171]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id UAA28861 for ; Tue, 16 Apr 1996 20:07:30 -0700 (PDT) Received: from FreeBSD.csie.NCTU.edu.tw (root@freebsd.csie.nctu.edu.tw [140.113.235.250]) by phoenix.csie.nctu.edu.tw (8.6.11/8.6.4) with ESMTP id LAA23622 for ; Wed, 17 Apr 1996 11:07:50 +0800 Received: (from jdli@localhost) by FreeBSD.csie.NCTU.edu.tw (8.7.5/8.7.3) id LAA27406 for freebsd-current@FreeBSD.ORG; Wed, 17 Apr 1996 11:07:09 +0800 (CST) Date: Wed, 17 Apr 1996 11:07:09 +0800 (CST) From: Jian-Da Li Message-Id: <199604170307.LAA27406@FreeBSD.csie.NCTU.edu.tw> To: freebsd-current@FreeBSD.ORG Subject: nfsstat is broken Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 2.2-960416-CURRENT nfsstat: sysctl: No such file or directory Please check it, thanks. :) From owner-freebsd-current Wed Apr 17 06:49:07 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA07754 for current-outgoing; Wed, 17 Apr 1996 06:49:07 -0700 (PDT) Received: from robin.mcnc.org.mcnc.org (robin.mcnc.org [128.109.130.29]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id GAA07744 Wed, 17 Apr 1996 06:49:04 -0700 (PDT) Received: by robin.mcnc.org.mcnc.org (8.6.9/MCNC/8-10-92) id JAA05386; Wed, 17 Apr 1996 09:48:47 -0400 for Date: Wed, 17 Apr 1996 09:48:47 -0400 From: "Frank E. Terhaar-Yonkers" Message-Id: <199604171348.JAA05386@robin.mcnc.org.mcnc.org> To: freebsd-stable@FreeBSD.ORG Subject: -stable still weird Cc: current@FreeBSD.ORG, freebsd-current@FreeBSD.ORG X-Face: ,fjtWiMPydUaSQl%8[eTg`u:^BXt&T)Sny(6w\*U"5D9H[Z$kG%Q/z;Z=NwrPiXf-aMF3R) Rsand$,]26-8>5@HD(A3A79gN|0%NHsdek4mT8E,>j+\w!~d2#nH;~NV!5a0"`5$Cj8d\or(Jy/JQ_ |uc;C[filmZ(~#lre*l:|O%d/PJFy`.5w8)sMZ-)QI3TaV"j'k Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I reported a couple of weeks ago that I had the console "lock up". What is locking up, appears to be only the keyboard - vid, mouse, the system in general all appear to be okay. I backed up to an earlier kernel (late March) and have been running fine. Since then I've upgraded the system (CPU & motherboard) - which also worked fine. So yesterday, I did a make world on the latest sup from freefall and the keyboard lockup is back. After booting the system, and logging in (via xlogin/xdm) the keyboard will work for no more than a few minutes ... Has there been a change as to make XFree 3.1.2 broken? Any other ideas? - Frank \\\\////\\\\////\\\\\////\\\\\////\\\\////\\\\////\\\\////\\\\////\\\\////\\\\ Frank Terhaar-Yonkers, Manager High Performance Computing and Communications Research MCNC PO Box 12889 3021 Cornwallis Road Research Triangle Park, North Carolina 27709-2889 fty@mcnc.org voice (919)248-1417 FAX (919)248-1455 http://www.mcnc.org/hpcc.html From owner-freebsd-current Wed Apr 17 09:11:04 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA17356 for current-outgoing; Wed, 17 Apr 1996 09:11:04 -0700 (PDT) Received: from rocky.sri.MT.net ([204.182.243.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA17350 for ; Wed, 17 Apr 1996 09:11:01 -0700 (PDT) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id KAA03171; Wed, 17 Apr 1996 10:10:19 -0600 Date: Wed, 17 Apr 1996 10:10:19 -0600 From: Nate Williams Message-Id: <199604171610.KAA03171@rocky.sri.MT.net> To: current@FreeBSD.org Subject: Adding commented out PS/2 driver line to GENERIC? Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Would anyone mind if I did this? I've seen quite a few 'where do I find the PS/2 mouse driver' questions, and until we get the all singing/dancing video/mouse driver working, it would clutter up GENERIC a bit while making it easier for folks to add it to their systems. If no-one objects, I'll add it in a couple days. Nate From owner-freebsd-current Wed Apr 17 09:29:29 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA17991 for current-outgoing; Wed, 17 Apr 1996 09:29:29 -0700 (PDT) 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 JAA17982 for ; Wed, 17 Apr 1996 09:29:24 -0700 (PDT) Received: from Early-Bird-1.Think.COM by mail.think.com; Wed, 17 Apr 96 12:29:06 -0400 Received: from compound.Think.COM ([206.10.99.151]) by Early-Bird.Think.COM; Wed, 17 Apr 96 12:29:02 EDT Received: (from alk@localhost) by compound.Think.COM (8.7.5/8.7.3) id MAA24785; Wed, 17 Apr 1996 12:28:57 -0500 (CDT) Date: Wed, 17 Apr 1996 12:28:57 -0500 (CDT) Message-Id: <199604171728.MAA24785@compound.Think.COM> From: Tony Kimball To: current@freefall.freebsd.org Subject: EtherExpress16 problems Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Recently, I began getting /kernel: ix0: device timeout messages on my main box. I also (although not invariably) get ixintr without being inited!! at boot time (q.v. dmesg log attached below). Is it possible Also, I was setting up a lame router, and as soon as I ifconfig ix0, I start getting ix.cx.busy messages. The interface does not operate for outgoing packets. In ixintr_cx I read: if (cb->status & CB_BUSY) { IXCOUNTER(ifp->if_busy++;) printf("ix.cx.busy"); /* This should never occur */ } so something is wrong. This box passes the EE16 diagnostics from Intel and was routing correctly running dos software in the current physical configuration. Suggestions of any sort with regard to either problem are solicited. Thanks, //alk FreeBSD 2.2-CURRENT #0: Tue Apr 16 21:02:06 CDT 1996 root@:/alt/src/sys/compile/COMPOUND CPU: Pentium (99.53-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x525 Stepping=5 Features=0x1bf real memory = 33554432 (32768K bytes) avail memory = 30400512 (29688K bytes) DEVFS: ready for devices Probing for devices on PCI bus 0: chip0 rev 1 on pci0:0 chip1 rev 2 on pci0:7:0 piix0 rev 2 on pci0:7:1 vga0 rev 0 int a irq 12 on pci0:19 Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> 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 mse0 at 0x23c irq 5 on isa fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 765 fd0: 1.44MB 3.5in wdc0 at 0x1f0-0x1f7 irq 14 on isa wdc0: unit 0 (wd0): wd0: 1033MB (2116800 sectors), 2100 cyls, 16 heads, 63 S/T, 512 B/S aha0 at 0x130-0x133 irq 11 drq 6 on isa aha0 waiting for scsi devices to settle (aha0:0:0): "CONNER CFP1060S 1.05GB 245F" type 0 fixed SCSI 2 sd0(aha0:0:0): Direct-Access 1010MB (2070400 512 byte sectors) (aha0:1:0): "WANGTEK 6200-HS 4B18" type 1 removable SCSI 2 st0(aha0:1:0): Sequential-Access density code 0x13, drive empty (aha0:2:0): "MICROP 4110-09NB_Nov18F TN0F" type 0 fixed SCSI 2 sd1(aha0:2:0): Direct-Access 1002MB (2053880 512 byte sectors) (aha0:3:0): "CHINON CD-ROM CDS-535 Q20" type 5 removable SCSI 2 cd0(aha0:3:0): CD-ROM cd0(aha0:3:0): NOT READY can't get the size ix0 at 0x210-0x21f irq 4 maddr 0xd0000 msize 32768 on isa ix0: address 00:aa:00:37:06:87 npx0 on motherboard npx0: INT 16 interface sb0 at 0x220 irq 10 drq 1 on isa sb0: sbmidi0 at 0x330 on isa sbxvi0 at 0x0 drq 5 on isa sbxvo0: opl0 at 0x200 on isa opl0: ixintr without being inited!! From owner-freebsd-current Wed Apr 17 10:39:18 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA21690 for current-outgoing; Wed, 17 Apr 1996 10:39:18 -0700 (PDT) Received: from riley-net170-164.uoregon.edu (riley-net170-164.uoregon.edu [128.223.170.164]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA21674 for ; Wed, 17 Apr 1996 10:39:11 -0700 (PDT) Received: (from dwhite@localhost) by riley-net170-164.uoregon.edu (8.6.12/8.6.12) id KAA05218; Wed, 17 Apr 1996 10:39:32 -0700 Date: Wed, 17 Apr 1996 10:39:31 -0700 (PDT) From: Doug White Reply-To: dwhite@resnet.uoregon.edu To: Tony Kimball cc: current@freefall.freebsd.org Subject: Re: EtherExpress16 problems In-Reply-To: <199604171728.MAA24785@compound.Think.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, 17 Apr 1996, Tony Kimball wrote: > > Recently, I began getting > /kernel: ix0: device timeout > messages on my main box. I also (although not invariably) > get > ixintr without being inited!! > at boot time (q.v. dmesg log attached below). Is it possible Hm. I don't like this line: > ix0 at 0x210-0x21f irq 4 maddr 0xd0000 msize 32768 on isa > ix0: address 00:aa:00:37:06:87 IRQ 4?!? I've never used that. Try 5 instead. 4 is probably being used by something else. > ixintr without being inited!! That should solve this too. 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 Wed Apr 17 10:44:20 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA22063 for current-outgoing; Wed, 17 Apr 1996 10:44:20 -0700 (PDT) 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 KAA22052 for ; Wed, 17 Apr 1996 10:44:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with SMTP id KAA01989; Wed, 17 Apr 1996 10:44:04 -0700 (PDT) To: Nate Williams cc: current@FreeBSD.org Subject: Re: Adding commented out PS/2 driver line to GENERIC? In-reply-to: Your message of "Wed, 17 Apr 1996 10:10:19 MDT." <199604171610.KAA03171@rocky.sri.MT.net> Date: Wed, 17 Apr 1996 10:44:04 -0700 Message-ID: <1987.829763044@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk I've heard it hangs a few keyboards out there completely, which is why it's not been added up to this point. Jordan > Would anyone mind if I did this? I've seen quite a few 'where do I find > the PS/2 mouse driver' questions, and until we get the all > singing/dancing video/mouse driver working, it would clutter up GENERIC > a bit while making it easier for folks to add it to their systems. > > If no-one objects, I'll add it in a couple days. > > > > Nate From owner-freebsd-current Wed Apr 17 10:44:22 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA22070 for current-outgoing; Wed, 17 Apr 1996 10:44:22 -0700 (PDT) Received: from caldas.rgi.br (root@caldas.rgi.br [200.18.160.5]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA22015 for ; Wed, 17 Apr 1996 10:44:00 -0700 (PDT) Received: (from e@localhost) by caldas.rgi.br (8.6.12/8.6.9) id OAA03833; Wed, 17 Apr 1996 14:30:23 -0300 Date: Wed, 17 Apr 1996 14:30:22 -0300 (EST) From: "Ernesto S. Arruda /POPGO" To: freebsd-current@freebsd.org Subject: upgarde 2.1 to ext2fs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello, I'd like to know if there is any way to upgrade my 2.1 for it to mount ext2 filsystems. What else, apart from changing the kernel, do I need to do? I'm trying to avoid installing a "current" version. Please send replies to my mailbox, I'm not a freebsd-current subscriber. TIA, E -----------------------------+----------------------------- Ernesto S. Arruda | Bolsista CNPq-RNP Ponto de Presenca Goias | E-mail: e@rgi.br Telegoias/Goiaspac 4. andar | postmast@rgi.br Rua 3, c/7 Centro | Fax: +55 62 244 2129 74000 - Goiania - GO | Voice: +55 62 244 2101 -----------------------------+----------------------------- From owner-freebsd-current Wed Apr 17 10:47:43 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA22236 for current-outgoing; Wed, 17 Apr 1996 10:47:43 -0700 (PDT) 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 KAA22226 for ; Wed, 17 Apr 1996 10:47:40 -0700 (PDT) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id LAA03436; Wed, 17 Apr 1996 11:46:57 -0600 Date: Wed, 17 Apr 1996 11:46:57 -0600 From: Nate Williams Message-Id: <199604171746.LAA03436@rocky.sri.MT.net> To: "Jordan K. Hubbard" Cc: Nate Williams , current@FreeBSD.org Subject: Re: Adding commented out PS/2 driver line to GENERIC? In-Reply-To: <1987.829763044@time.cdrom.com> References: <199604171610.KAA03171@rocky.sri.MT.net> <1987.829763044@time.cdrom.com> Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > I've heard it hangs a few keyboards out there completely, which is why > it's not been added up to this point. I agree, and have had it lockup a couple boxes I was responsible for. I simply want to added a commented out entry to GENERIC. It won't be enabled, but it will be easier to find. Nate From owner-freebsd-current Wed Apr 17 10:49:44 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA22455 for current-outgoing; Wed, 17 Apr 1996 10:49:44 -0700 (PDT) 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 KAA22440 for ; Wed, 17 Apr 1996 10:49:32 -0700 (PDT) Received: from Early-Bird-1.Think.COM by mail.think.com; Wed, 17 Apr 96 13:49:13 -0400 Received: from compound.Think.COM ([206.10.99.151]) by Early-Bird.Think.COM; Wed, 17 Apr 96 13:49:08 EDT Received: (from alk@localhost) by compound.Think.COM (8.7.5/8.7.3) id NAA25424; Wed, 17 Apr 1996 13:49:04 -0500 (CDT) Date: Wed, 17 Apr 1996 13:49:04 -0500 (CDT) Message-Id: <199604171849.NAA25424@compound.Think.COM> From: Tony Kimball To: dwhite@resnet.uoregon.edu Cc: current@freefall.freebsd.org In-Reply-To: (message from Doug White on Wed, 17 Apr 1996 10:39:31 -0700 (PDT)) Subject: Re: EtherExpress16 problems Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Date: Wed, 17 Apr 1996 10:39:31 -0700 (PDT) From: Doug White > Recently, I began getting > /kernel: ix0: device timeout > messages on my main box. I also (although not invariably) > get > ixintr without being inited!! > at boot time (q.v. dmesg log attached below). Is it possible Hm. I don't like this line: > ix0 at 0x210-0x21f irq 4 maddr 0xd0000 msize 32768 on isa > ix0: address 00:aa:00:37:06:87 IRQ 4?!? I've never used that. Try 5 instead. 4 is probably being used by something else. > ixintr without being inited!! That should solve this too. I was using irq 10, but moved things around because I was experiencing the symptoms already described. I know that 4 is free because I have disabled com1 in the bios in order to free an interrupt. ix0 is now up, but essentially quiescent: ; vmstat -i interrupt total rate clk0 irq0 4670267 100 rtc0 irq8 5976524 127 fdc0 irq6 1 0 aha0 irq11 45919 0 sc0 irq1 42722 0 sio1 irq3 1986304 42 mse0 irq5 2935141 62 ix0 irq4 9430 0 sb0 irq10 1 0 Total 15666309 335 These problems began within the last week (running current). I intend eventually to resolve them by working through the kernel source changes, but I was hoping someone might have short-cut info... (Incidentally, I do not understand about IRQs 2 and 9. Is there a document I might read? Are they available for assignment to devices, generally?) //alk From owner-freebsd-current Wed Apr 17 11:11:19 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA24187 for current-outgoing; Wed, 17 Apr 1996 11:11:19 -0700 (PDT) Received: from riley-net170-164.uoregon.edu (riley-net170-164.uoregon.edu [128.223.170.164]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA24171 for ; Wed, 17 Apr 1996 11:11:14 -0700 (PDT) Received: (from dwhite@localhost) by riley-net170-164.uoregon.edu (8.6.12/8.6.12) id LAA05491; Wed, 17 Apr 1996 11:11:35 -0700 Date: Wed, 17 Apr 1996 11:11:34 -0700 (PDT) From: Doug White Reply-To: dwhite@resnet.uoregon.edu To: Tony Kimball cc: current@freefall.freebsd.org Subject: Re: EtherExpress16 problems In-Reply-To: <199604171849.NAA25424@compound.Think.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, 17 Apr 1996, Tony Kimball wrote: > > ix0 at 0x210-0x21f irq 4 maddr 0xd0000 msize 32768 on isa > > ix0: address 00:aa:00:37:06:87 > > I was using irq 10, but moved things around because I was experiencing > the symptoms already described. I know that 4 is free because I have > disabled com1 in the bios in order to free an interrupt. ix0 is now > up, but essentially quiescent: Hm. My next question is if you have a broken card. > > ; vmstat -i > interrupt total rate > clk0 irq0 4670267 100 > rtc0 irq8 5976524 127 > fdc0 irq6 1 0 > aha0 irq11 45919 0 > sc0 irq1 42722 0 > sio1 irq3 1986304 42 > mse0 irq5 2935141 62 > ix0 irq4 9430 0 > sb0 irq10 1 0 > Total 15666309 335 > > These problems began within the last week (running current). I intend > eventually to resolve them by working through the kernel source > changes, but I was hoping someone might have short-cut info... I threw out a basic answer, and forgot this is current :-) I think I'll leave you to that, then. > > (Incidentally, I do not understand about IRQs 2 and 9. Is there a > document I might read? Are they available for assignment to devices, > generally?) The book "Running FreeBSD" has a good discussion on it. The 2/9 is a hack to support 16 bit interrupts. Back in the old days of XTs they only had 8 bit interrupts, and when 16 bit came they decided to cascase IRQ 2 to 9. Don't ask me why. :) 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 Wed Apr 17 13:04:57 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA02059 for current-outgoing; Wed, 17 Apr 1996 13:04:57 -0700 (PDT) Received: from grumble.grondar.za (root@grumble.grondar.za [196.7.18.130]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id NAA01941 Wed, 17 Apr 1996 13:03:24 -0700 (PDT) Received: from grumble.grondar.za (mark@localhost [127.0.0.1]) by grumble.grondar.za (8.7.5/8.7.3) with ESMTP id WAA01354; Wed, 17 Apr 1996 22:03:09 +0200 (SAT) Message-Id: <199604172003.WAA01354@grumble.grondar.za> To: phk@freebsd.org, current@freebsd.org, stable@freebsd.org Subject: CTM Delta cvs-cur.1900S.gz Date: Wed, 17 Apr 1996 22:03:09 +0200 From: Mark Murray Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi I have built this delta (cvs-cur.1900S.gz) which is a "starter" delta against the 23 March SNAP CDROM's CVS snapshot. If anyone wants it, it in my home directory on freefall:~/markm. Poul-Henning, could you please put it into the anonymous ftp area and announce it if that is OK? Thanks! Enjoy! M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grondar.za for PGP key From owner-freebsd-current Wed Apr 17 15:16:36 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA16530 for current-outgoing; Wed, 17 Apr 1996 15:16:36 -0700 (PDT) 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 PAA16521 for ; Wed, 17 Apr 1996 15:16:32 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id IAA13920; Thu, 18 Apr 1996 08:11:58 +1000 Date: Thu, 18 Apr 1996 08:11:58 +1000 From: Bruce Evans Message-Id: <199604172211.IAA13920@godzilla.zeta.org.au> To: current@freebsd.org, nate@sri.MT.net Subject: Re: Adding commented out PS/2 driver line to GENERIC? Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Would anyone mind if I did this? I've seen quite a few 'where do I find >the PS/2 mouse driver' questions, and until we get the all >singing/dancing video/mouse driver working, it would clutter up GENERIC >a bit while making it easier for folks to add it to their systems. You can now configure it but disable it. Bruce From owner-freebsd-current Wed Apr 17 15:18:32 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA16607 for current-outgoing; Wed, 17 Apr 1996 15:18:32 -0700 (PDT) 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 PAA16602 for ; Wed, 17 Apr 1996 15:18:29 -0700 (PDT) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id QAA04476; Wed, 17 Apr 1996 16:18:13 -0600 Date: Wed, 17 Apr 1996 16:18:13 -0600 From: Nate Williams Message-Id: <199604172218.QAA04476@rocky.sri.MT.net> To: Bruce Evans Cc: current@freebsd.org, nate@sri.MT.net Subject: Re: Adding commented out PS/2 driver line to GENERIC? In-Reply-To: <199604172211.IAA13920@godzilla.zeta.org.au> References: <199604172211.IAA13920@godzilla.zeta.org.au> Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >Would anyone mind if I did this? I've seen quite a few 'where do I find > >the PS/2 mouse driver' questions, and until we get the all > >singing/dancing video/mouse driver working, it would clutter up GENERIC > >a bit while making it easier for folks to add it to their systems. > > You can now configure it but disable it. Cool! Do you have an example config line of a configured but disabled device? Nate From owner-freebsd-current Wed Apr 17 15:36:00 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA18398 for current-outgoing; Wed, 17 Apr 1996 15:36:00 -0700 (PDT) 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 PAA18389 for ; Wed, 17 Apr 1996 15:35:56 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id IAA14828; Thu, 18 Apr 1996 08:31:58 +1000 Date: Thu, 18 Apr 1996 08:31:58 +1000 From: Bruce Evans Message-Id: <199604172231.IAA14828@godzilla.zeta.org.au> To: bde@zeta.org.au, nate@sri.MT.net Subject: Re: Adding commented out PS/2 driver line to GENERIC? Cc: current@freebsd.org Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Do you have an example config line of a configured but disabled device? *** GENERIC~ Fri Apr 12 03:21:46 1996 --- GENERIC Sun Apr 14 05:15:07 1996 *************** *** 97,99 **** device sio2 at isa? port "IO_COM3" tty irq 5 vector siointr ! #device sio3 at isa? port "IO_COM4" tty irq 9 vector siointr --- 97,99 ---- device sio2 at isa? port "IO_COM3" tty irq 5 vector siointr ! device sio3 at isa? disable port "IO_COM4" tty irq 9 vector siointr Bruce From owner-freebsd-current Wed Apr 17 16:23:09 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA23385 for current-outgoing; Wed, 17 Apr 1996 16:23:09 -0700 (PDT) Received: from vector.jhs.no_domain (slip139-92-42-148.ut.nl.ibm.net [139.92.42.148]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id QAA23371 Wed, 17 Apr 1996 16:23:02 -0700 (PDT) Received: (from jhs@localhost) by vector.jhs.no_domain (8.7.3/8.6.9) id VAA00660; Wed, 17 Apr 1996 21:58:11 +0200 (MET DST) Date: Wed, 17 Apr 1996 21:58:11 +0200 (MET DST) From: "Julian Stacey jhs@freebsd.org" Message-Id: <199604171958.VAA00660@vector.jhs.no_domain> To: current@freebsd.org, current@netbsd.org Subject: Free pizza & beer for GCC Guru in or near Berlin Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Warning: Cross posted to current@ freebsd.org & netbsd.org ... Shock Horror ;-) Is there a GCC guru in or near Berlin, who wants to visit for the weekend, bed pizza & board provided ? The guy below phoned me ('cos my name's in the FSF lists ) to say he has a GCC porting problem with his 2 personal Siemens MX300 (32532 machines), & he'd be willing to buy pizza & beer (I told him to say that :-) & provide accomodation if you can be a visiting gcc guru for a weekend. He'll show you round Berlin too. Ronald LISICKA Marchand Str 3a 12249 Berlin Home 030 767 031 88 20:00 - 22:00 Office 030 86526130 (if redirected ask for Abteilung 11.0.3) Reason I posted this here is that a cross porting machine will be needed, & I know NetBSD (& thus GCC) runs on the PC532 (ie NSC 32532) but none of those are in Berlin. However the same GCC could be be cross hosted from an ix86 Net or Free BSD too. If someone wants to copy this to the Linux lists, do, (but _please_ don't cc current@ freebsd.org or netbsd.org :-) ) If he can't get GCC up he'll dispose of the machines, so you might cut a deal, by porting & retaing one box :-) Flame me privately for the free & net cross post if you want :-) But please dont waste time mailing me technical questions, I don't know more than this, & he doesnt have email, so phone him direct. (I'm not about to become an email to long distance (Munich-Berlin) phone relay). PS Apparently he can speak some English, but I spoke to him in German. Julian -- Julian H. Stacey jhs@freebsd.org http://www.freebsd.org/~jhs/ (PGP available) -- "Every 2 or 3 centuries there is a volcanic eruption so big that it fouls up the atmosphere for a couple of years. There are just no harvests. According to current estimates, the world's grain stocks are only 45 days." ... James Lovlock, quoted by Newsweek's Ken Shulman 15th April 1996. From owner-freebsd-current Wed Apr 17 20:26:54 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id UAA09166 for current-outgoing; Wed, 17 Apr 1996 20:26:54 -0700 (PDT) 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 UAA09161 for ; Wed, 17 Apr 1996 20:26:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with SMTP id UAA04944; Wed, 17 Apr 1996 20:26:30 -0700 (PDT) To: Nate Williams cc: current@FreeBSD.org Subject: Re: Adding commented out PS/2 driver line to GENERIC? In-reply-to: Your message of "Wed, 17 Apr 1996 11:46:57 MDT." <199604171746.LAA03436@rocky.sri.MT.net> Date: Wed, 17 Apr 1996 20:26:30 -0700 Message-ID: <4942.829797990@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > I've heard it hangs a few keyboards out there completely, which is why > > it's not been added up to this point. > > I agree, and have had it lockup a couple boxes I was responsible for. > > I simply want to added a commented out entry to GENERIC. It won't be > enabled, but it will be easier to find. Ah, OK. I must have misread your message. That's fine by me! Jordan From owner-freebsd-current Wed Apr 17 20:27:12 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id UAA09190 for current-outgoing; Wed, 17 Apr 1996 20:27:12 -0700 (PDT) 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 UAA09184 for ; Wed, 17 Apr 1996 20:27:08 -0700 (PDT) Received: (from mbartley@localhost) by lear35.cytex.com (8.7.5/8.7.3) id UAA02026 for freebsd-current@freebsd.org; Wed, 17 Apr 1996 20:27:06 -0700 (PDT) From: Matt Bartley Message-Id: <199604180327.UAA02026@lear35.cytex.com> Subject: netinet/in_proto.c warnings To: freebsd-current@freebsd.org Date: Wed, 17 Apr 1996 20:27:05 -0700 (PDT) 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 While compiling the -current kernel (last sup from sup2 at 1996/04/18 01:54 UTC) I get the following warning messages. I think this has been happening for a long time; I just thought I'd stop ignoring it. (reformatted to < 80 character line lengths) cc -c -O -W -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Winline -nostdinc -I. -I../.. -I../../sys -I../../../include -DI586_CPU -DEXT2FS -DFAILSAFE -DCOMPAT_43 -DCD9660 -DMSDOSFS -DNFS -DFFS -DINET -DKERNEL ../../netinet/in_proto.c ../../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:166: warning: initialization from incompatible pointer type It then goes on to compile the kernel with no apparent harm done. Should I go back to ignoring it? I couldn't find any mention of this in the list archive. md5 /usr/src/sys/netinet/in_proto.c MD5 (/usr/src/sys/netinet/in_proto.c) = 504c74a82d6596a537bc25492d8eb4f0 ls -l /usr/src/sys/netinet/in_proto.c -rw-rw-r-- 1 root bin 6534 Mar 26 13:49 /usr/src/sys/netinet/in_proto.c From owner-freebsd-current Wed Apr 17 23:23:56 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA17067 for current-outgoing; Wed, 17 Apr 1996 23:23:56 -0700 (PDT) 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 XAA17062 for ; Wed, 17 Apr 1996 23:23:47 -0700 (PDT) Received: (from nerv@localhost) by nixpbe.pdb.sni.de (8.6.12/8.6.12) id IAA20609 for current@freefall.freebsd.org; Thu, 18 Apr 1996 08:24:07 +0200 Message-Id: <199604180624.IAA20609@nixpbe.pdb.sni.de> Subject: Re: EtherExpress16 problems To: dwhite@resnet.uoregon.edu Date: Thu, 18 Apr 96 8:23:30 MDT From: Greg Lehey Cc: alk@Think.COM, current@freefall.freebsd.org, questions@freebsd.org In-Reply-To: ; from "Doug White" at Apr 17, 96 11:11 am X-Mailer: xmail 2.4 (based on ELM 2.2 PL16) Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > On Wed, 17 Apr 1996, Tony Kimball wrote: >> (Incidentally, I do not understand about IRQs 2 and 9. Is there a >> document I might read? Are they available for assignment to devices, >> generally?) > > The book "Running FreeBSD" has a good discussion on it. Thank you. > The 2/9 is a > hack to support 16 bit interrupts. Back in the old days of XTs they only > had 8 bit interrupts, and when 16 bit came they decided to cascase IRQ 2 > to 9. Don't ask me why. :) The interrupt controller chip used in the XT and AT was the Intel 8259A. It handled 8 interrupts, but had a so-called "cascade mode", where you could designate each of the primary interrupts as representing another group of 8. This is what they did in the AT: they took IRQ2, which up to this point had hardly been used, and used it for the interrupt input from the second 8259A. The *real* IRQ2 thus represents all of the IRQs from 8 to 15. This is (almost) completely transparent to the software, the only exception being the interrupt controller initialisation routines. There is also an ISA bus line called IRQ2 (B4: on the rear of the connector, 4th from left when you have the connector pointing down) It used to be connected to IRQ2 on the XT, but it now homeless, since it couldn't be connected to IRQ2. Instead, they connected it to IRQ9. Unfortunately, the line is (AFAIK) still called IRQ2. Thus the confusion. Bottom line: it's really IRQ9, but it's the only one of the IRQs 8-15 which you can use with an 8 bit board. Is this clear? Is it interesting? Shall I put it in the next edition of the book? Greg From owner-freebsd-current Thu Apr 18 03:56:52 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA28724 for current-outgoing; Thu, 18 Apr 1996 03:56:52 -0700 (PDT) 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 DAA28719 for ; Thu, 18 Apr 1996 03:56:29 -0700 (PDT) Received: by sovcom.kiae.su id AA07019 (5.65.kiae-1 for current@freebsd.org); Thu, 18 Apr 1996 13:53:36 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Thu, 18 Apr 96 13:53:35 +0300 Received: (from ache@localhost) by astral.msk.su (8.7.5/8.7.3) id OAA04016 for current@freebsd.org; Thu, 18 Apr 1996 14:53:25 +0400 (MSD) Message-Id: <199604181053.OAA04016@astral.msk.su> Subject: WARNING: /etc/security ontput first time after SUP To: current@freebsd.org (FreeBSD-current) Date: Thu, 18 Apr 1996 14:53:25 +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 Since /etc/security now check devices too, when it will be running first time after SUP you'll get all device entries as diff in your daily report. Ignore them, it will happen only once. -- 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 18 08:25:51 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA10887 for current-outgoing; Thu, 18 Apr 1996 08:25:51 -0700 (PDT) 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 IAA10878 for ; Thu, 18 Apr 1996 08:25:43 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id BAA00627 for current@freebsd.org; Fri, 19 Apr 1996 01:25:09 +1000 Date: Fri, 19 Apr 1996 01:25:09 +1000 From: Bruce Evans Message-Id: <199604181525.BAA00627@godzilla.zeta.org.au> To: current@freebsd.org Subject: #include bloat Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Long ago, I introduced the #include of in to make all the machine-dependent inline functions visible without changing many files. The list of inlines has now grown so large that compiling them now takes about 10% of the kernel build time: Times to build a -current GENERIC from a freshly configured directory immediately after booting: 485.41 real 380.97 user 27.83 sys Times to do the same thing with all the inlines in cpufunc.h replaced by prototypes: 446.99 real 346.64 user 26.44 sys Times to build GENERICBT in 1.1.5 (on the same hardware with the same compiler, but on a different file system and not immediately after booting): 213.92 real 163.58 user 16.50 sys I guess that it would take 150-180 seconds on the same hardware under 1.1.5, mainly because gcc was faster. Sigh. I think only about 50% of the extra time is justified by features. Bruce From owner-freebsd-current Thu Apr 18 08:27:27 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA10948 for current-outgoing; Thu, 18 Apr 1996 08:27:27 -0700 (PDT) Received: from xi.dorm.umd.edu (root@xi.dorm.umd.edu [129.2.152.45]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id IAA10943 for ; Thu, 18 Apr 1996 08:27:24 -0700 (PDT) Received: from localhost (smpatel@localhost [127.0.0.1]) by xi.dorm.umd.edu (8.7.5/8.6.12) with SMTP id LAA16101 for ; Thu, 18 Apr 1996 11:27:15 -0400 (EDT) Date: Thu, 18 Apr 1996 11:27:14 -0400 (EDT) From: Sujal Patel X-Sender: smpatel@xi.dorm.umd.edu To: current@freebsd.org Subject: Changes for vfork() Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In the recent thread about rfork(), we talked about the no longer useful vfork() syscall. According to the manpage for vfork(): This system call will be eliminated when proper system sharing mechanisms are implemented. Users should not depend on the memory sharing semantics of vfork(2) as it will, in that case, be made synonymous to fork(2). Since FreeBSD uses copy-on-write for the pages of processes that are forked, there is little or no purpose in having the vfork() syscall (and the man page even says it will be made synonymous to fork some day). As we sort of talked about, I think it's time to declare this an obsolete syscall and perhaps move the vfork() call in libc to libcompat, libc/compat-43, or libc/???? (I really don't know where it should go). Also, vfork() can now just point to fork(), which will clean up some cruft in kern_fork.c Comments please? Sujal From owner-freebsd-current Thu Apr 18 09:07:35 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA13738 for current-outgoing; Thu, 18 Apr 1996 09:07:35 -0700 (PDT) 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 JAA13723 for ; Thu, 18 Apr 1996 09:07:30 -0700 (PDT) Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA06704; Thu, 18 Apr 1996 12:07:28 -0400 Date: Thu, 18 Apr 1996 12:07:28 -0400 From: Garrett Wollman Message-Id: <9604181607.AA06704@halloran-eldar.lcs.mit.edu> To: Sujal Patel Cc: current@freebsd.org Subject: Changes for vfork() In-Reply-To: References: Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk < said: > we sort of talked about, I think it's time to declare this an obsolete > syscall and perhaps move the vfork() call in libc to libcompat, > libc/compat-43, or libc/???? (I really don't know where it should go). There is no reason to move it at this point. Certainly it needs to be part of libc for the forseeable future. Just declare it as COMPAT in syscalls.master, change the kernel code, and document vfork as being an obsolete synonym for fork. Then create libc/compat-43/vfork.c: ------------------------------------ /* This code is in the public domain. */ #include int vfork(void) { return fork(); } ------------------------------------ and everything should Just Work. (Make sure to do all of these steps before recompiling the world, though.) -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 Thu Apr 18 09:27:22 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA15808 for current-outgoing; Thu, 18 Apr 1996 09:27:22 -0700 (PDT) Received: from xi.dorm.umd.edu (root@xi.dorm.umd.edu [129.2.152.45]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id JAA15800 for ; Thu, 18 Apr 1996 09:27:20 -0700 (PDT) Received: from localhost (smpatel@localhost [127.0.0.1]) by xi.dorm.umd.edu (8.7.5/8.6.12) with SMTP id MAA16398; Thu, 18 Apr 1996 12:27:10 -0400 (EDT) Date: Thu, 18 Apr 1996 12:27:08 -0400 (EDT) From: Sujal Patel X-Sender: smpatel@xi.dorm.umd.edu To: Garrett Wollman cc: current@freebsd.org Subject: Re: Changes for vfork() In-Reply-To: <9604181607.AA06704@halloran-eldar.lcs.mit.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 Thu, 18 Apr 1996, Garrett Wollman wrote: > and everything should Just Work. (Make sure to do all of these steps > before recompiling the world, though.) We should briefly look over the source tree too. Some brain-dead programs may rely on vfork() behavior (such as sleeping on the child, or altering the parent's address space)... Other then that, What you posted is exactly what I was thinking-- Unless there are any objections, I'll take care of it in the next few days. Sujal From owner-freebsd-current Thu Apr 18 10:52:58 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA24976 for current-outgoing; Thu, 18 Apr 1996 10:52:58 -0700 (PDT) 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 KAA24967 for ; Thu, 18 Apr 1996 10:52:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by palmer.demon.co.uk (sendmail/PALMER-1) with SMTP id SAA00937 ; Thu, 18 Apr 1996 18:52:15 +0100 (BST) To: Matt Bartley cc: freebsd-current@FreeBSD.ORG From: "Gary Palmer" Subject: Re: netinet/in_proto.c warnings In-reply-to: Your message of "Wed, 17 Apr 1996 20:27:05 PDT." <199604180327.UAA02026@lear35.cytex.com> Date: Thu, 18 Apr 1996 18:52:15 +0100 Message-ID: <935.829849935@palmer.demon.co.uk> Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Matt Bartley wrote in message ID <199604180327.UAA02026@lear35.cytex.com>: > It then goes on to compile the kernel with no apparent harm done. > Should I go back to ignoring it? I couldn't find any mention of this > in the list archive. Ignore it. I'm probably going to try cleaning this up soon. Garrett will probably kill me in the process :-) Gary From owner-freebsd-current Thu Apr 18 11:05:33 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA25656 for current-outgoing; Thu, 18 Apr 1996 11:05:33 -0700 (PDT) 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 LAA25607 Thu, 18 Apr 1996 11:04:57 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id EAA06384; Fri, 19 Apr 1996 04:00:51 +1000 Date: Fri, 19 Apr 1996 04:00:51 +1000 From: Bruce Evans Message-Id: <199604181800.EAA06384@godzilla.zeta.org.au> To: j@uriah.heep.sax.de, ports@freebsd.org Subject: Re: Interesting bash bug - anyone else see this? Cc: freebsd-current@freebsd.org Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> I just noticed it, myself. It doesn't happen in sh or csh, so it's >> definitely one for -bash and -current (if not also -stable; I dunno!). >> >> >> root@reason-> ls -lt | more >> ^Z >> [2]+ Done ls -lt | more >> root@reason-> fg >> ls -lt | more >> Broken pipe >> >> Bug #1: Upon suspending, bash erroneously reports the background job's status >> as "Done", not "Suspended" >> >> Bug #2: Upon resuming, we're hosed - the pipe breaks. This works fine here because my `more' is aliased to `less' like it should be :-). `/bin/ls -lt /usr/src/lib/libc/obj/ | /usr/bin/more' fails in much the under bash, sh and csh. bash gives better error messages but the pipe always breaks. I don't have tcsh installed. >I can reproduce it. Depending upon how quickly i pressed ^Z, i could >even get bash into a totally hosed state, the ^Z has been displayed, >but ``nichts geht mehr''. Only a SIGCONT from a different window >helped. I can't reproduce this. Perhaps it is like the bug that causes bash to hang when starting up (type su and hit ^C; the su often gets stuck in a loop doing a longjmp to nowhere from a signal handler). >... This is your case: > 107 11252 270 1 10 0 628 700 wait S p3 0:00.43 bash > 107 11267 11252 1 28 0 384 232 - T p3 0:00.07 ls -lt >The `ls' has been stopped, but `more' is already dead. (That's why >bash is reporting it as `Done'.) This seems to be a bug in `more'. It goes to a lot of trouble to receive the SIGTSP but seems to always exit if the signal interrupts a read. Try stopping: (sleep 2; cat /etc/passwd) | ktrace /usr/bin/more `kdump' shows `more' receiving the signal and exiting without retrying the read. Bruce From owner-freebsd-current Thu Apr 18 14:53:12 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA11584 for current-outgoing; Thu, 18 Apr 1996 14:53:12 -0700 (PDT) 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 OAA11562 Thu, 18 Apr 1996 14:52:43 -0700 (PDT) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id XAA26853; Thu, 18 Apr 1996 23:52:31 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id XAA23017; Thu, 18 Apr 1996 23:52:31 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id XAA02879; Thu, 18 Apr 1996 23:42:08 +0200 (MET DST) From: J Wunsch Message-Id: <199604182142.XAA02879@uriah.heep.sax.de> Subject: Re: Interesting bash bug - anyone else see this? To: bde@zeta.org.au (Bruce Evans) Date: Thu, 18 Apr 1996 23:42:07 +0200 (MET DST) Cc: ports@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199604181800.EAA06384@godzilla.zeta.org.au> from "Bruce Evans" at Apr 19, 96 04:00:51 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: > This works fine here because my `more' is aliased to `less' like it should > be :-). `/bin/ls -lt /usr/src/lib/libc/obj/ | /usr/bin/more' fails in much > the under bash, sh and csh. bash gives better error messages but the pipe > always breaks. I don't have tcsh installed. Our more is basically a less. I can reproduce the problem for less, too. (Not surprising.) I can also reproduce the problem for /bin/sh, but not for tcsh. I can't seem to reproduce the problem for ``sh && less''. :-) weird... -- 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 18 19:18:22 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id TAA23766 for current-outgoing; Thu, 18 Apr 1996 19:18:22 -0700 (PDT) Received: from riley-net170-164.uoregon.edu (riley-net170-164.uoregon.edu [128.223.170.164]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id TAA23755 Thu, 18 Apr 1996 19:18:08 -0700 (PDT) Received: (from dwhite@localhost) by riley-net170-164.uoregon.edu (8.6.12/8.6.12) id TAA19296; Thu, 18 Apr 1996 19:19:11 -0700 Date: Thu, 18 Apr 1996 19:19:11 -0700 (PDT) From: Doug White Reply-To: dwhite@resnet.uoregon.edu To: Greg Lehey cc: alk@Think.COM, current@freefall.freebsd.org, questions@freebsd.org Subject: Re: EtherExpress16 problems In-Reply-To: <199604180624.IAA20593@nixpbe.pdb.sni.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 Thu, 18 Apr 1996, Greg Lehey wrote: > > On Wed, 17 Apr 1996, Tony Kimball wrote: > >> (Incidentally, I do not understand about IRQs 2 and 9. Is there a > >> document I might read? Are they available for assignment to devices, > >> generally?) > > > > The book "Running FreeBSD" has a good discussion on it. > > Thank you. :-) The "discussion" isn't as long as I remember it, but I was trying to recall the information from memory, and it must have gotten mixed in there. Hey, I've gotten two questions on how to get the book from that response :-) > > The 2/9 is a > > hack to support 16 bit interrupts. Back in the old days of XTs they only > > had 8 bit interrupts, and when 16 bit came they decided to cascase IRQ 2 > > to 9. Don't ask me why. :) > > The interrupt controller chip used in the XT and AT was the Intel > 8259A. It handled 8 interrupts, but had a so-called "cascade mode", > where you could designate each of the primary interrupts as > representing another group of 8. This is what they did in the AT: > they took IRQ2, which up to this point had hardly been used, and used > it for the interrupt input from the second 8259A. The *real* IRQ2 > thus represents all of the IRQs from 8 to 15. This is (almost) > completely transparent to the software, the only exception being the > interrupt controller initialisation routines. > > There is also an ISA bus line called IRQ2 (B4: on the rear of the > connector, 4th from left when you have the connector pointing down) > It used to be connected to IRQ2 on the XT, but it now homeless, since > it couldn't be connected to IRQ2. Instead, they connected it to > IRQ9. Unfortunately, the line is (AFAIK) still called IRQ2. Thus the > confusion. > > Bottom line: it's really IRQ9, but it's the only one of the IRQs 8-15 > which you can use with an 8 bit board. Thanks for the info. > Is this clear? Is it interesting? Shall I put it in the next edition > of the book? It's OK as is, but maybe the above would be interesting as a sidebar. You might add instructions on how to add a second disk into the system. I don't think it's even documented anywhere in the FreeBSD Doc Project, and is one of the Frequently Asked Questions here, and should be easily answerable (after all, it's pretty basic!). 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 Fri Apr 19 01:22:25 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA08224 for current-outgoing; Fri, 19 Apr 1996 01:22:25 -0700 (PDT) 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 BAA08189 Fri, 19 Apr 1996 01:22:10 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id SAA08903; Fri, 19 Apr 1996 18:19:31 +1000 Date: Fri, 19 Apr 1996 18:19:31 +1000 From: Bruce Evans Message-Id: <199604190819.SAA08903@godzilla.zeta.org.au> To: bde@zeta.org.au, j@uriah.heep.sax.de Subject: Re: Interesting bash bug - anyone else see this? Cc: freebsd-current@FreeBSD.ORG, ports@FreeBSD.ORG Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> This works fine here because my `more' is aliased to `less' like it should >Our more is basically a less. I can reproduce the problem for less, My `less' is basically version 97 which is much less than the current version :-). It has no problems, perhaps for the same reason that `cat' has no problems. They don't make programs like less-97 any more :-). It was less in many ways even in 1988. E.g., it doesn't use ctype and it prints character 0xFF as "^?" although isprint(0xFF) is nonzero. Bruce From owner-freebsd-current Fri Apr 19 01:31:03 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA08656 for current-outgoing; Fri, 19 Apr 1996 01:31:03 -0700 (PDT) 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 BAA08647 for ; Fri, 19 Apr 1996 01:31:00 -0700 (PDT) Received: from gilberto.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de) by mail.rwth-aachen.de (PMDF V5.0-4 #13110) id <01I3Q08NDRXC001RAP@mail.rwth-aachen.de> for freebsd-current@freefall.FreeBSD.org; Fri, 19 Apr 1996 10:11:01 +0100 Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.6.11/8.6.9) id KAA12947 for freebsd-current@freefall.cdrom.com; Fri, 19 Apr 1996 10:16:55 +0200 Date: Fri, 19 Apr 1996 10:16:55 +0200 From: "Christoph P. Kukulies" Subject: gzipped executables To: freebsd-current@freefall.FreeBSD.org Message-id: <199604190816.KAA12947@gilberto.physik.rwth-aachen.de> Content-transfer-encoding: 7BIT Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Is anyone working on fixing the broken gzip executable feature in -current? --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-current Fri Apr 19 06:22:08 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA04925 for current-outgoing; Fri, 19 Apr 1996 06:22:08 -0700 (PDT) Received: from elbe.desy.de (elbe.desy.de [131.169.82.208]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id GAA04912 for ; Fri, 19 Apr 1996 06:21:57 -0700 (PDT) From: Lars Gerhard Kuehl Date: Fri, 19 Apr 96 15:22:21 +0200 Message-Id: <9604191322.AA07511@elbe.desy.de> To: smpatel@umiacs.umd.edu Subject: Re: Changes for vfork() Cc: current@FreeBSD.ORG Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > We should briefly look over the source tree too. Some brain-dead programs > may rely on vfork() behavior (such as sleeping on the child, or altering > the parent's address space)... The current vfork() already doesn't allow the child to alter the parent's address space and sometimes it's very desirable (or at least convenient) if one can rely on the parent being suspended until the child calls execve() or _exit(). I'd prefer somthing like a pid_t newfork(int suspend_parent), fork implemented as pid_t fork() { return newfork(0); } and so far anybody needs it vfork as pid_t vfork() { return newfork(42); } fork1() is actually almost an implementation of that 'newfork()', thus with only negligible changes in the kernel and libc code the number of system calls could be decremented and nobody had to miss anything. Lars From owner-freebsd-current Fri Apr 19 07:04:09 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA06957 for current-outgoing; Fri, 19 Apr 1996 07:04:09 -0700 (PDT) Received: from gw3.att.com (gw4.att.com [204.179.186.34]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA06950 for ; Fri, 19 Apr 1996 07:04:01 -0700 (PDT) From: ejc@nasvr1.cb.att.com Received: from nasvr1.cb.att.com (naserver1.cb.att.com) by ig4.att.att.com id AA07340; Fri, 19 Apr 96 09:55:36 EDT Received: by nasvr1.cb.att.com (5.x/EMS-1.1 Sol2) id AA14352; Fri, 19 Apr 1996 10:04:06 -0400 Received: from ginger.cb.att.com by nasvr1.cb.att.com (5.x/EMS-1.1 Sol2) id AA14348; Fri, 19 Apr 1996 10:04:03 -0400 Received: by ginger.cb.att.com (5.x/EMS-1.1 Sol2) id AA10021; Fri, 19 Apr 1996 10:07:16 -0400 Date: Fri, 19 Apr 1996 10:07:16 -0400 Message-Id: <9604191407.AA10021@ginger.cb.att.com> To: julian@TFS.COM Subject: DEVFS and syslogd Cc: freebsd-current@freebsd.org X-Sun-Charset: US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello I just installed DEVFS on my -current systems as of 960418 the syslogd has a problem with it. This is what I did: Added options DEVFS in my kernel. Added a line at the end of my fstab "dev /dev devfs rw 0 0" everything seems to work except syslogd. When I boot I get the error "syslogd: cannot create /dev/log: operation not supported" Is this a known problem, did I do something wrong? I scanned all the old email in questions, hackers, current with devfs and did not see anything. Any information would be helpful. Peace, ejc From owner-freebsd-current Fri Apr 19 07:18:05 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA07683 for current-outgoing; Fri, 19 Apr 1996 07:18:05 -0700 (PDT) Received: from xi.dorm.umd.edu (root@xi.dorm.umd.edu [129.2.152.45]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id HAA07674 for ; Fri, 19 Apr 1996 07:18:02 -0700 (PDT) Received: from localhost (smpatel@localhost [127.0.0.1]) by xi.dorm.umd.edu (8.7.5/8.6.12) with SMTP id KAA02838; Fri, 19 Apr 1996 10:17:24 -0400 (EDT) Date: Fri, 19 Apr 1996 10:17:24 -0400 (EDT) From: Sujal Patel X-Sender: smpatel@xi.dorm.umd.edu To: Lars Gerhard Kuehl cc: current@FreeBSD.ORG Subject: Re: Changes for vfork() In-Reply-To: <9604191322.AA07511@elbe.desy.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 Fri, 19 Apr 1996, Lars Gerhard Kuehl wrote: > The current vfork() already doesn't allow the child to alter the parent's > address space and sometimes it's very desirable (or at least convenient) > if one can rely on the parent being suspended until the child calls > execve() or _exit(). Convenient perhaps, but this is by no means correct (or desirable). If you really want to alter the parent's address space, you should fork with rfork (RFPROC|RFMEM) Sujal From owner-freebsd-current Fri Apr 19 08:39:41 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA13510 for current-outgoing; Fri, 19 Apr 1996 08:39:41 -0700 (PDT) Received: from snarf.dorm.umd.edu (snarf.dorm.umd.edu [129.2.152.38]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id IAA13504 for ; Fri, 19 Apr 1996 08:39:35 -0700 (PDT) Received: from localhost (kashmir@localhost) by snarf.dorm.umd.edu (8.7.4/rimshot) with SMTP id LAA12254; Fri, 19 Apr 1996 11:02:05 -0400 (EDT) X-Authentication-Warning: snarf.dorm.umd.edu: kashmir owned process doing -bs Date: Fri, 19 Apr 1996 11:02:05 -0400 (EDT) From: Mike Grupenhoff To: Lars Gerhard Kuehl cc: smpatel@umiacs.UMD.EDU, current@FreeBSD.ORG Subject: Re: Changes for vfork() In-Reply-To: <9604191322.AA07511@elbe.desy.de> Message-ID: X-Phase-of-the-Moon: Waxing Crescent (2% of Full) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 19 Apr 1996, Lars Gerhard Kuehl wrote: > I'd prefer somthing like a pid_t newfork(int suspend_parent), You already have it: #define fork() rfork(RFPROC|RFFDG) #define vfork() rfork(RFPROC|RFFDG|RFPPWAIT) The RFPPWAIT flag is equivalent to your suspend_parent argument. mike From owner-freebsd-current Fri Apr 19 09:37:20 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA16313 for current-outgoing; Fri, 19 Apr 1996 09:37:20 -0700 (PDT) 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 JAA16308 for ; Fri, 19 Apr 1996 09:37:16 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id CAA28706; Sat, 20 Apr 1996 02:32:31 +1000 Date: Sat, 20 Apr 1996 02:32:31 +1000 From: Bruce Evans Message-Id: <199604191632.CAA28706@godzilla.zeta.org.au> To: ejc@nasvr1.cb.att.com, julian@TFS.COM Subject: Re: DEVFS and syslogd Cc: freebsd-current@FreeBSD.ORG Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Added options DEVFS in my kernel. Added a line at the end of my fstab >"dev /dev devfs rw 0 0" everything seems to work except syslogd. When I boot >I get the error "syslogd: cannot create /dev/log: operation not supported" >Is this a known problem, did I do something wrong? I scanned all the old email >in questions, hackers, current with devfs and did not see anything. It's known. syslogd needs to write the log file in a stupid place (/dev/log) for compatibility and devfs just doesn't support this. This was discussed a lot in the commit mailing list(s). The current mail doesn't seem to be very useful compared with the commit mail for following what is happening in -current. Bruce From owner-freebsd-current Fri Apr 19 09:58:46 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA17397 for current-outgoing; Fri, 19 Apr 1996 09:58:46 -0700 (PDT) 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 JAA17392 for ; Fri, 19 Apr 1996 09:58:42 -0700 (PDT) Received: from Early-Bird-1.Think.COM by mail.think.com; Fri, 19 Apr 96 12:58:37 -0400 Received: from compound.Think.COM (fergus-27.dialup.cfa.org) by Early-Bird.Think.COM; Fri, 19 Apr 96 12:58:33 EDT Received: (from alk@localhost) by compound.Think.COM (8.7.5/8.7.3) id MAA05534; Fri, 19 Apr 1996 12:58:27 -0500 (CDT) Date: Fri, 19 Apr 1996 12:58:27 -0500 (CDT) Message-Id: <199604191758.MAA05534@compound.Think.COM> From: Tony Kimball To: current@freebsd.org Subject: devfs Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk From: ejc@nasvr1.cb.att.com Date: Fri, 19 Apr 1996 10:07:16 -0400 Subject: DEVFS and syslogd I get the error "syslogd: cannot create /dev/log: operation not supported" While on the subject, XF86_S3 3.1.2D isn't working with devfs and a busmouse. Booting without devfs resolves the problem. The symptoms include rapidly degrading keyboard response, terminating in a total lockup. The system will not ping at this point, nor will X die or switch vtys, within 30-40 seconds of startx. Something about /dev/random? Or perhaps /dev/mse0? From owner-freebsd-current Fri Apr 19 10:24:13 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA19187 for current-outgoing; Fri, 19 Apr 1996 10:24:13 -0700 (PDT) Received: (from mpp@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA19178 Fri, 19 Apr 1996 10:24:11 -0700 (PDT) From: Mike Pritchard Message-Id: <199604191724.KAA19178@freefall.freebsd.org> Subject: Re: DEVFS and syslogd To: bde@zeta.org.au (Bruce Evans) Date: Fri, 19 Apr 1996 10:24:11 -0700 (PDT) Cc: ejc@nasvr1.cb.att.com, julian@TFS.COM, freebsd-current@FreeBSD.ORG, jmb (Jonathan M. Bresler) In-Reply-To: <199604191632.CAA28706@godzilla.zeta.org.au> from "Bruce Evans" at Apr 20, 96 02:32:31 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Bruce Evans wrote: > [...] > This was discussed a lot in the commit mailing list(s). The current > mail doesn't seem to be very useful compared with the commit mail for > following what is happening in -current. And as I have pointed out a couple of times in the past, neither of the archive files for freebsd-commit or cvs-all are being updated, so there is no easy way to scan through the commit mailing lists looking for a subject. You have to check each individual cvs-* archive file to find what you are looking for. -- Mike Pritchard mpp@freebsd.org "Go that way. Really fast. If something gets in your way, turn" From owner-freebsd-current Fri Apr 19 11:22:57 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA22559 for current-outgoing; Fri, 19 Apr 1996 11:22:57 -0700 (PDT) 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 LAA22551 for ; Fri, 19 Apr 1996 11:22:54 -0700 (PDT) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id UAA04208; Fri, 19 Apr 1996 20:20:45 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id UAA03971; Fri, 19 Apr 1996 20:20:45 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id TAA06829; Fri, 19 Apr 1996 19:52:30 +0200 (MET DST) From: J Wunsch Message-Id: <199604191752.TAA06829@uriah.heep.sax.de> Subject: Re: DEVFS and syslogd To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Fri, 19 Apr 1996 19:52:28 +0200 (MET DST) Cc: julian@TFS.COM, ejc@nasvr1.cb.att.com Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <9604191407.AA10021@ginger.cb.att.com> from "ejc@nasvr1.cb.att.com" at Apr 19, 96 10:07:16 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 ejc@nasvr1.cb.att.com wrote: > Added options DEVFS in my kernel. Added a line at the end of my fstab > "dev /dev devfs rw 0 0" everything seems to work except syslogd. When I boot > I get the error "syslogd: cannot create /dev/log: operation not supported" > Is this a known problem, did I do something wrong? It's a known problem. The clean solution would be moving /dev/log to /var/run/log, but this will break binary compatibility for statically linked old binaries. Next to this, we could create it under /var/run/log, but maintain a symlink to /dev/log for compatibility. Alas, devfs doesn't understand symlinks yet 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 Fri Apr 19 12:30:53 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA26518 for current-outgoing; Fri, 19 Apr 1996 12:30:53 -0700 (PDT) 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 MAA26512 for ; Fri, 19 Apr 1996 12:30:48 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA08783; Fri, 19 Apr 1996 12:27:10 -0700 From: Terry Lambert Message-Id: <199604191927.MAA08783@phaeton.artisoft.com> Subject: Re: gzipped executables To: kuku@gilberto.physik.rwth-aachen.de (Christoph P. Kukulies) Date: Fri, 19 Apr 1996 12:27:10 -0700 (MST) Cc: freebsd-current@freefall.freebsd.org In-Reply-To: <199604190816.KAA12947@gilberto.physik.rwth-aachen.de> from "Christoph P. Kukulies" at Apr 19, 96 10:16:55 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 > Is anyone working on fixing the broken gzip executable feature in > -current? It's a cache interaction. Pentium caches are written back inside the cache queue depth, whereas pre-Pentium processors have immutable cache queues. It can be fixed by incorporating 32 NOP's (until the next processor revision, anyway), in part of the code. This is a kludge, but, of course, it works... of such ugly working things are permanent warts grown. Alternately, it can be caused by faulty writeback/invalidate hardware on an external L2 cache. Needless to say, I don't have any hardware with broken L2 cache interaction, so I couldn't test even a kludge if that's where it's falling down on you. Typically, binvd'ing the cache line range impacted immediately following a load and again immediately following a buffer decompression would *probably* fix the 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 Fri Apr 19 12:36:08 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA26907 for current-outgoing; Fri, 19 Apr 1996 12:36:08 -0700 (PDT) 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 MAA26848 for ; Fri, 19 Apr 1996 12:36:01 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA08792; Fri, 19 Apr 1996 12:29:57 -0700 From: Terry Lambert Message-Id: <199604191929.MAA08792@phaeton.artisoft.com> Subject: Re: DEVFS and syslogd To: joerg_wunsch@uriah.heep.sax.de Date: Fri, 19 Apr 1996 12:29:56 -0700 (MST) Cc: freebsd-current@FreeBSD.ORG, julian@TFS.COM, ejc@nasvr1.cb.att.com In-Reply-To: <199604191752.TAA06829@uriah.heep.sax.de> from "J Wunsch" at Apr 19, 96 07:52:28 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Added options DEVFS in my kernel. Added a line at the end of my fstab > > "dev /dev devfs rw 0 0" everything seems to work except syslogd. When I boot > > I get the error "syslogd: cannot create /dev/log: operation not supported" > > Is this a known problem, did I do something wrong? > > It's a known problem. > > The clean solution would be moving /dev/log to /var/run/log, but this > will break binary compatibility for statically linked old binaries. > > Next to this, we could create it under /var/run/log, but maintain a > symlink to /dev/log for compatibility. Alas, devfs doesn't understand > symlinks yet either. Or register a portal to a dumb log concatenation program. 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 19 13:14:48 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA28664 for current-outgoing; Fri, 19 Apr 1996 13:14:48 -0700 (PDT) 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 NAA28658 for ; Fri, 19 Apr 1996 13:14:43 -0700 (PDT) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id OAA04133; Fri, 19 Apr 1996 14:12:51 -0600 Date: Fri, 19 Apr 1996 14:12:51 -0600 From: Nate Williams Message-Id: <199604192012.OAA04133@rocky.sri.MT.net> To: Terry Lambert Cc: kuku@gilberto.physik.rwth-aachen.de (Christoph P. Kukulies), freebsd-current@freefall.freebsd.org Subject: Re: gzipped executables In-Reply-To: <199604191927.MAA08783@phaeton.artisoft.com> References: <199604190816.KAA12947@gilberto.physik.rwth-aachen.de> <199604191927.MAA08783@phaeton.artisoft.com> Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Terry Lambert writes: > > Is anyone working on fixing the broken gzip executable feature in > > -current? > > It's a cache interaction. Pentium caches are written back inside > the cache queue depth, whereas pre-Pentium processors have > immutable cache queues. > > It can be fixed by incorporating 32 NOP's (until the next processor > revision, anyway), in part of the code. If this is the case, why did it used to work on Pentium processors? Nate From owner-freebsd-current Fri Apr 19 13:15:28 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA28711 for current-outgoing; Fri, 19 Apr 1996 13:15:28 -0700 (PDT) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA28706 for ; Fri, 19 Apr 1996 13:15:24 -0700 (PDT) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0uAMaJ-0003xGC; Fri, 19 Apr 96 13:15 PDT 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 UAA00726; Fri, 19 Apr 1996 20:15:12 GMT X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: Terry Lambert cc: kuku@gilberto.physik.rwth-aachen.de (Christoph P. Kukulies), freebsd-current@freefall.freebsd.org Subject: Re: gzipped executables In-reply-to: Your message of "Fri, 19 Apr 1996 12:27:10 MST." <199604191927.MAA08783@phaeton.artisoft.com> Date: Fri, 19 Apr 1996 20:15:11 +0000 Message-ID: <724.829944911@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Terry, come up with a patch, or stop this nonsense. there is no self-modifying code involved... Christph: No I'm sorry I don't have time. It shouldn't be that hard though, if you have cvs try to find out when it broke, that would help a lot. Poul-Henning > > Is anyone working on fixing the broken gzip executable feature in > > -current? > > It's a cache interaction. Pentium caches are written back inside > the cache queue depth, whereas pre-Pentium processors have > immutable cache queues. > > It can be fixed by incorporating 32 NOP's (until the next processor > revision, anyway), in part of the code. > > This is a kludge, but, of course, it works... of such ugly working > things are permanent warts grown. > > Alternately, it can be caused by faulty writeback/invalidate hardware > on an external L2 cache. Needless to say, I don't have any hardware > with broken L2 cache interaction, so I couldn't test even a kludge > if that's where it's falling down on you. Typically, binvd'ing > the cache line range impacted immediately following a load and > again immediately following a buffer decompression would *probably* > fix the problem. > > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. -- 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 Fri Apr 19 13:35:05 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA00228 for current-outgoing; Fri, 19 Apr 1996 13:35:05 -0700 (PDT) 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 NAA00212 for ; Fri, 19 Apr 1996 13:34:51 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA08890; Fri, 19 Apr 1996 13:30:31 -0700 From: Terry Lambert Message-Id: <199604192030.NAA08890@phaeton.artisoft.com> Subject: Re: gzipped executables To: nate@sri.MT.net (Nate Williams) Date: Fri, 19 Apr 1996 13:30:31 -0700 (MST) Cc: terry@lambert.org, kuku@gilberto.physik.rwth-aachen.de, freebsd-current@freefall.freebsd.org In-Reply-To: <199604192012.OAA04133@rocky.sri.MT.net> from "Nate Williams" at Apr 19, 96 02:12:51 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > Is anyone working on fixing the broken gzip executable feature in > > > -current? > > > > It's a cache interaction. Pentium caches are written back inside > > the cache queue depth, whereas pre-Pentium processors have > > immutable cache queues. > > > > It can be fixed by incorporating 32 NOP's (until the next processor > > revision, anyway), in part of the code. > > If this is the case, why did it used to work on Pentium processors? Because it's circumstantial based on where the code is loaded -- and now it's loaded at a new place and you see the problem -- an optimized loop is wholly in cache. I'm suprised, given the size of the cache, that it worked at all on Pentium boxes, ever. In either case, I was able to kludge a fix locally. A real fix wants to alternate the compress-from/compress-to areas to intentionally force LRU activity. As in inverting the compressed image, or inverting the page ordering between decompress and execute. Alternately, throwing 32 NOP's before jumping will work with current cache queue depths. Didn't we discuss all this in detail before? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Fri Apr 19 13:43:36 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA00921 for current-outgoing; Fri, 19 Apr 1996 13:43:36 -0700 (PDT) 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 NAA00848 for ; Fri, 19 Apr 1996 13:42:30 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA08918; Fri, 19 Apr 1996 13:37:59 -0700 From: Terry Lambert Message-Id: <199604192037.NAA08918@phaeton.artisoft.com> Subject: Re: gzipped executables To: phk@critter.tfs.com (Poul-Henning Kamp) Date: Fri, 19 Apr 1996 13:37:59 -0700 (MST) Cc: terry@lambert.org, kuku@gilberto.physik.rwth-aachen.de, freebsd-current@freefall.freebsd.org In-Reply-To: <724.829944911@critter.tfs.com> from "Poul-Henning Kamp" at Apr 19, 96 08:15:11 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 > Terry, come up with a patch, or stop this nonsense. > there is no self-modifying code involved... > > Christph: No I'm sorry I don't have time. It shouldn't be that hard > though, if you have cvs try to find out when it broke, that would > help a lot. > > Poul-Henning My root assumptions as to the cause may be incorrect. Flushing the cache queue with 32 NOP's, nevertheless, works, even if *my* reason isn't *the* reason. Feel free to come up with another explanation, or feel free to kludge the NOP's before the jmp and accept the fact that it works without a satisfactory (to you) explanation of *why* it works. If I'm correct, I expect it to "fix" a 486 with 16 NOP's but not a Pentium (and this has been observed in testing on my machines), and to fix a Pentium and a 486 with 32 NOP's (which also works in testing on my machines). Admittedly, my theory is only a theory which fits all known facts (which, I willingly admit, doesn't necessarily make it true). Apply my "fix" from the previous discussion of -current on this same topic... quoted "fix" because I believe it's a kludge around what is really a bug in the decompressor. 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 Fri Apr 19 15:09:18 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA06624 for current-outgoing; Fri, 19 Apr 1996 15:09:18 -0700 (PDT) Received: (from jmb@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA06617 Fri, 19 Apr 1996 15:09:17 -0700 (PDT) From: "Jonathan M. Bresler" Message-Id: <199604192209.PAA06617@freefall.freebsd.org> Subject: cvs-all and freebsd-commit To: mpp@freefall.freebsd.org (Mike Pritchard) Date: Fri, 19 Apr 1996 15:09:16 -0700 (PDT) Cc: bde@zeta.org.au, ejc@nasvr1.cb.att.com, julian@TFS.COM, freebsd-current@FreeBSD.ORG In-Reply-To: <199604191724.KAA19178@freefall.freebsd.org> from "Mike Pritchard" at Apr 19, 96 10:24:11 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Mike Pritchard wrote: > > Bruce Evans wrote: > > > [...] > > This was discussed a lot in the commit mailing list(s). The current > > mail doesn't seem to be very useful compared with the commit mail for > > following what is happening in -current. > > And as I have pointed out a couple of times in the past, neither > of the archive files for freebsd-commit or cvs-all are being updated, > so there is no easy way to scan through the commit mailing lists looking > for a subject. You have to check each individual cvs-* archive > file to find what you are looking for. FreeBSD-commit has been a dead list since last spring. i guess that time has come to remove the remnants of the list. the cvs messages that you are looking for are easily found by looking in the logs/archives for the subsystem in question. this is one more reason people should be careful with their addressing. cvs-all-digest is also available. all 342 issues (last count). send "index cvs-all" to majordomo for a list of files, no search mechanism, sorry (hmmm...) all cvs messags go to cvs-all. -- Jonathan M. Bresler FreeBSD Postmaster jmb@FreeBSD.ORG FreeBSD--4.4BSD Unix for PC clones, source included. http://www.freebsd.org/ From owner-freebsd-current Fri Apr 19 16:11:51 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA10136 for current-outgoing; Fri, 19 Apr 1996 16:11:51 -0700 (PDT) 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 QAA10131 for ; Fri, 19 Apr 1996 16:11:48 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA09930 for current@freebsd.org; Fri, 19 Apr 1996 16:09:23 -0700 From: Terry Lambert Message-Id: <199604192309.QAA09930@phaeton.artisoft.com> Subject: /src/usr.sbin/config To: current@freebsd.org Date: Fri, 19 Apr 1996 16:09:22 -0700 (MST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Build dependencies are broken. It should not be necessary to do a "make clean" before doing a "make". 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 19 16:30:59 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA11041 for current-outgoing; Fri, 19 Apr 1996 16:30:59 -0700 (PDT) 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 QAA11036 for ; Fri, 19 Apr 1996 16:30:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with SMTP id QAA02746; Fri, 19 Apr 1996 16:30:16 -0700 (PDT) To: Nate Williams cc: Terry Lambert , kuku@gilberto.physik.rwth-aachen.de (Christoph P. Kukulies), freebsd-current@freefall.freebsd.org Subject: Re: gzipped executables In-reply-to: Your message of "Fri, 19 Apr 1996 14:12:51 MDT." <199604192012.OAA04133@rocky.sri.MT.net> Date: Fri, 19 Apr 1996 16:30:16 -0700 Message-ID: <2744.829956616@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > If this is the case, why did it used to work on Pentium processors? It also ignores the fact that it also fails on my 486/DX2.. :-) Terry, I think you're totally off-base on this one and should simply come clean on that fact before we consider entering you for this month's Jesus Monroy award! :-) Jordan From owner-freebsd-current Fri Apr 19 17:04:01 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA12351 for current-outgoing; Fri, 19 Apr 1996 17:04:01 -0700 (PDT) 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 RAA12324 for ; Fri, 19 Apr 1996 17:03:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with SMTP id RAA02995; Fri, 19 Apr 1996 17:02:59 -0700 (PDT) cc: Nate Williams , Terry Lambert , kuku@gilberto.physik.rwth-aachen.de (Christoph P. Kukulies), freebsd-current@freefall.freebsd.org Subject: Re: gzipped executables In-reply-to: Your message of "Fri, 19 Apr 1996 16:30:16 PDT." <2744.829956616@time.cdrom.com> Date: Fri, 19 Apr 1996 17:02:59 -0700 Message-ID: <2993.829958579@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > If this is the case, why did it used to work on Pentium processors? > > It also ignores the fact that it also fails on my 486/DX2.. :-) Sorry, just to clarify what I meant here since I can see how Terry would read the above and say "say what?! I was saying that it only failed on *Pentium* processors due to their differing cache architecture! I never said *anything* about the 486!" I expressed my point poorly. What I *meant* to say was that it used to work on all the Intel processor types then began failing on all of them at the same time, from the 486 to the Pentium. This doesn't lead me to believe that the failure is related to any particular processor or cache architecture so much as it is a simple bug which has crept in and whacked the gzip emulator. Jordan From owner-freebsd-current Fri Apr 19 17:05:58 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA12437 for current-outgoing; Fri, 19 Apr 1996 17:05:58 -0700 (PDT) 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 RAA12432 for ; Fri, 19 Apr 1996 17:05:51 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA11279; Fri, 19 Apr 1996 17:01:44 -0700 From: Terry Lambert Message-Id: <199604200001.RAA11279@phaeton.artisoft.com> Subject: Re: gzipped executables To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Fri, 19 Apr 1996 17:01:44 -0700 (MST) Cc: nate@sri.MT.net, terry@lambert.org, kuku@gilberto.physik.rwth-aachen.de, freebsd-current@freefall.freebsd.org In-Reply-To: <2744.829956616@time.cdrom.com> from "Jordan K. Hubbard" at Apr 19, 96 04:30:16 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 > > If this is the case, why did it used to work on Pentium processors? > > It also ignores the fact that it also fails on my 486/DX2.. :-) > > Terry, I think you're totally off-base on this one and should simply > come clean on that fact before we consider entering you for this > month's Jesus Monroy award! :-) I already said that my explanation of the fix might not be the right one... did you miss that post? It has no bearing one way or the other on whether the fix works (it does), or whether the fix is a kludge (it is). I suspect the original poster was asking because they wanted it to work, and they really didn't give a damn *why* it worked. Dumping the cache queue with NOPs will 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 Fri Apr 19 17:11:24 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA12724 for current-outgoing; Fri, 19 Apr 1996 17:11:24 -0700 (PDT) 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 RAA12719 for ; Fri, 19 Apr 1996 17:11:22 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA11299; Fri, 19 Apr 1996 17:05:07 -0700 From: Terry Lambert Message-Id: <199604200005.RAA11299@phaeton.artisoft.com> Subject: Re: gzipped executables To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Fri, 19 Apr 1996 17:05:07 -0700 (MST) Cc: nate@sri.MT.net, terry@lambert.org, kuku@gilberto.physik.rwth-aachen.de, freebsd-current@freefall.freebsd.org In-Reply-To: <2993.829958579@time.cdrom.com> from "Jordan K. Hubbard" at Apr 19, 96 05:02:59 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 > > > If this is the case, why did it used to work on Pentium processors? > > > > It also ignores the fact that it also fails on my 486/DX2.. :-) > > Sorry, just to clarify what I meant here since I can see how Terry > would read the above and say "say what?! I was saying that it only > failed on *Pentium* processors due to their differing cache > architecture! I never said *anything* about the 486!" I expressed my > point poorly. Nevertheless, I understood your intent. No clarification was needed. > What I *meant* to say was that it used to work on all the Intel > processor types then began failing on all of them at the same time, > from the 486 to the Pentium. This doesn't lead me to believe that the > failure is related to any particular processor or cache architecture > so much as it is a simple bug which has crept in and whacked the gzip > emulator. And all I was saying is that dumping the cache queue makes it work again, regardless of *why* this happens, it *does* happen, and can be used by the original poster as a "fix". I took the care I did in puting forth my working hypothesis because I think it would be stupid to integrate the cache queue dumping as "*the* fix". 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 19 18:08:09 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA15041 for current-outgoing; Fri, 19 Apr 1996 18:08:09 -0700 (PDT) Received: from babba.cu-online.com (somebody@babba.cu-online.com [205.198.248.21]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id SAA15036 for ; Fri, 19 Apr 1996 18:08:06 -0700 (PDT) Received: from localhost (somebody@localhost) by babba.cu-online.com (8.7.5/8.7.3) with SMTP id UAA28752 for ; Fri, 19 Apr 1996 20:07:47 -0500 (CDT) Date: Fri, 19 Apr 1996 20:07:47 -0500 (CDT) From: Somebody To: current@freebsd.org Subject: ffs troubles. In-Reply-To: <199604192309.QAA09930@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 Hello I have just started building a 2nd news server and I am get a machine panic every couple of hours. The messsages saids "cpu panic ffs_allocg map corrupted then something about panic allog block not in map" This is on a P100 with 32M of ram and Adaptec 2940U and a Quantum Atlas II drive. I wondering if freebsd has the same troubles with the 2940U that other unixes have. Wether I should trade this out for a 946C Buslogic. Or if its just that current is unstable? Carlos Carlos Ramirez (217) 356 - 4009 Voice CU-Online System Administrator (217) 356 - 3600 Data Offerings Circuits Upto T1/E1 Speeds at affordable rates. "Your one stop Internet Provider" From owner-freebsd-current Fri Apr 19 18:20:04 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA15584 for current-outgoing; Fri, 19 Apr 1996 18:20:04 -0700 (PDT) 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 SAA15523 for ; Fri, 19 Apr 1996 18:19:57 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id SAA11465; Fri, 19 Apr 1996 18:17:35 -0700 From: Terry Lambert Message-Id: <199604200117.SAA11465@phaeton.artisoft.com> Subject: KERNEL SUPPORT FOR NFS LOCKING (server side rpc.lockd support) To: current@freebsd.org Date: Fri, 19 Apr 1996 18:17:35 -0700 (MST) Cc: terry@phaeton.artisoft.com (Terry Lambert) 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 Jordan, et. al: Here are the patches for the kernel to provide the support code for Andrew's rpc.lockd in the -current source tree. This is kernel support for server-side locking. You will be able to NFS lock files on a FreeBSD NFS server, but a FreeBSD NFS client will not be able to lock files on a remote NFS server. With the exception of the vfs_syscalls.c, which is a context diff because my FS changes have not been integrated and CVS mirroring is inadequatei for people without commit priveledges, these are a set of CVS diffs to the files: kern/kern_descrip.c kern/kern_lockf.c sys/fcntl.h sys/lockf.h (If you don't like where I put my parenthesis, learn to run "indent"). These changes maintain binary backward comapatability because of the way local flock calls copy in and out only the local (old) flock data. The large reserve area is intentional, and is there so that future extensions still do not require a system call number change to be integrated (the same reason SunOS provides a reserve area). Expected usage is for, among other applications, mandatory and non-coelesive record/range locking. The call interface is identical to the one used by SunOS to support NFS server side locking. This is intentional because NFS is not the only program that consumes the proxy locking interface. --- ::NOTES:: HOW IT WORKS This is a proxy locking facility. It assumes a pid_t sized (or smaller) remote process id, and a long (or smaller) remote system id. This is a signed long, per SunOS (programs like the NetWare for UNIX server depend on the interface not changing). CAVEAT: l_rsys type This probably wants to be a defined sysid_t in the types file, but I didn't want to screw with sys/types.h and the existing rpc.lockd code to make it work. CAVEAT: GRACELESS SHUTDOWN Resource tracking cleanup (ie: on graceless exit of the rpc.lockd) is not supported. As noted in the code, the advisory locking facility that resulted from the 4.4BSD integration of the Heideman code has broken advisory lock layering. This is also the reason that NFS client locking code was not provided at this time. When the rpc.lockd goes down, only locally held locks by rpc.lockd itself (ie: there should be none anyway) would be cleaned. To support this correctly, it would be necesssary to add a "local vs. remote" flag to the VOP_ADVLOCK() call, which would require modification of every existing file system implementation. To support NFS client locking with overlay, loopback, and other FS stacking constructs in the Heidemann framework, it would be necessary convert the VOP_ADVLOCK() architecture from "call-through" to "veto". This would further necessitate changes to loopback and union FS types to implement call-through from superior to inferior stack veto, only in those cases (the corrected top level code can only operate on top level FS's exposed at the VFS layer). This has been discussed in detail on various lists. It is mentioned here because it bears on allowable user space (rpc.lockd, NetWare daemon file locking) assumptions; a crashed rpc.lockd *will* leave proxy state hanging from the node. The conversion process is described in greater detail in the WARNING comment in the kern/kern_lockf.c file in the F_UNLKSYS case. CAVEAT: INTERFACE AMBIGUITY Because it was unclear from the rpc.lockd code itself (which is not complete in this regard), the F_CNVT fcntl() call is not fully implemented; instead it is stubbed in kern/kern_descrip.c. This fcntl() call takes as an argument *any* file fd to get it into the VFS (this can be *any* fd, if the "struct fileops" garbage used by the pipe and socket code, is reworked, like it should be), the command "F_CNVT", and a pointer to an NFS handle. The fcntl() is to return an error, or to return an fd, allocated in the open file table of the calling process. It is expected that the rpc.lockd will maintain a reference count and a hash, so that if the same file is locked by multiple servers, only one rpc.lockd fd (and therefore one system open file table entry) is consumed. The suggested rpc.lockd implementation is to stat the resulting fd, and hash based on the stat results to locate an existing fd for the same file, if any. If one exists, the hash reference structure reference count is to be incremented, and the second (duplicate) fd closed. Because there is no kernel support for asynchronous calls to the fcntl() system call, it is expected that F_RSETLKW will not typically be used; instead, F_RSETLK will be used, and if EWOULDBLOCK is returned, a retry is to be queued to a timer-kicked retry list in the rpc.lockd. It is expected that there will eventually be a thread spawned for a blocking request to allow it to run to completion, OR an async call trap gate will be defined so that the rpc.lockd will not hang pending completion of blocked F_RSETLKW calls. Unless the an async call or *kernel* threading mechanism is used to implement the blocking lock requests, a race condition is introduced by the queue service latency that can cause starvation deadlock on NFS clients using the lock services. The implementation was left as incomplete because: 1) It requires knowledge of the handle format used by the rpc.lockd (which is hopefully the same as that used by NFS). 2) It requires registration of the handle conversion lookup function from the NFS code (nfsrv_fhtovp() in nfs/nfs_subs.c) in the same way that the LEASE functions are currently registered, or NFS will have to be statically linked at all times). 3) The LEASE function registration code is bogus; like the search continuation ("cookie") code, it is fundamentally broken, and should be moved to a "server as file system consumer presentation layer" to get rid of the common overhead case. Given #1 & #2, it is possible to kludge a workable soloution. #3 would require integration of previously submitted FS layering patches (specifically, the namei/nameifree and the "EXCLUDE" flag changes to kern/vfs_lookup.c). CAVEAT: DOCUMENTATION I have not modified the fcntl() man page to include the proxy extensions to the fcntl() locking interface. In addition, the behaviour of the interface is not well documented, except by the code, since it is derived from user-space experimentation on binary systems (lack of this kind of documentation is why there has not been a public rpc.lockd implementation prior to this time). Patches follow my signature. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. == 8< cut here 8< ========================================================== *** /sys/kern/vfs_syscalls.c.nonfs Fri Apr 19 14:38:32 1996 --- /sys/kern/vfs_syscalls.c Fri Apr 19 15:34:18 1996 *************** *** 6,11 **** --- 6,12 ---- * to the University of California by American Telephone and Telegraph * Co. or Unix System Laboratories, Inc. and are reproduced herein with * the permission of UNIX System Laboratories, Inc. + * Copyright (c) 1996 Terrence R. Lambert. All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions *************** *** 19,24 **** --- 20,26 ---- * must display the following acknowledgement: * This product includes software developed by the University of * California, Berkeley and its contributors. + * This product includes software developed by Terrence R. Lambert. * 4. Neither the name of the University nor the names of its contributors * may be used to endorse or promote products derived from this software * without specific prior written permission. *************** *** 741,746 **** --- 743,750 ---- lf.l_type = F_WRLCK; else lf.l_type = F_RDLCK; + lf.l_rsys = FLOCK_LOCAL_LOCK; + lf.l_rpid = FLOCK_LOCAL_LOCK; type = F_FLOCK; if ((flags & FNONBLOCK) == 0) type |= F_WAIT; == 8< cut here 8< ========================================================== Index: kern_descrip.c =================================================================== RCS file: /b/cvstree/ncvs/src/sys/kern/kern_descrip.c,v retrieving revision 1.28 diff -r1.28 kern_descrip.c 8a9 > * Copyright (c) 1996 Terrence R. Lambert. All rights reserved. 21a23 > * This product includes software developed by Terrence R. Lambert. 210c212 < struct flock fl; --- > struct flock flk; 282a285 > case F_RSETLKW: 286a290 > case F_RSETLK: 291c295,318 < error = copyin((caddr_t)uap->arg, (caddr_t)&fl, sizeof (fl)); --- > if( ( uap->cmd == F_SETLKW) || ( uap->cmd == F_SETLK)) { > /* > * Local lock. Only copy in old lock structure > * to ensure backward binary compatability (the > * lock structure may butt up against memory > * for which a copyin would be invalid). > */ > error = copyin( (caddr_t)uap->arg, > (caddr_t)&flk, > sizeof(struct oflock)); > flk.l_rsys = FLOCK_LOCAL_LOCK; > flk.l_rpid = FLOCK_LOCAL_LOCK; > } else { > /* > * Remote lock proxy request. Only root is > * allowed to make proxy requests. Copy > * in full flock structure. > */ > if( !suser(p->p_ucred, &p->p_acflag)) > return( EPERM); > error = copyin( (caddr_t)uap->arg, > (caddr_t)&flk, > sizeof(struct flock)); > } 294,296c321,323 < if (fl.l_whence == SEEK_CUR) < fl.l_start += fp->f_offset; < switch (fl.l_type) { --- > if (flk.l_whence == SEEK_CUR) > flk.l_start += fp->f_offset; > switch (flk.l_type) { 302c329 < return (VOP_ADVLOCK(vp, (caddr_t)p, F_SETLK, &fl, flg)); --- > return (VOP_ADVLOCK(vp, (caddr_t)p, F_SETLK, &flk, flg)); 308c335 < return (VOP_ADVLOCK(vp, (caddr_t)p, F_SETLK, &fl, flg)); --- > return (VOP_ADVLOCK(vp, (caddr_t)p, F_SETLK, &flk, flg)); 311c338,342 < return (VOP_ADVLOCK(vp, (caddr_t)p, F_UNLCK, &fl, --- > return (VOP_ADVLOCK(vp, (caddr_t)p, F_UNLCK, &flk, > F_POSIX)); > > case F_UNLKSYS: > return (VOP_ADVLOCK(vp, (caddr_t)p, F_UNLKSYS, &flk, 318a350 > case F_RGETLK: 323c355,378 < error = copyin((caddr_t)uap->arg, (caddr_t)&fl, sizeof (fl)); --- > if( uap->cmd == F_GETLK) { > /* > * Local lock. Only copy in old lock structure > * to ensure backward binary compatability (the > * lock structure may butt up against memory > * for which a copyin would be invalid). > */ > error = copyin( (caddr_t)uap->arg, > (caddr_t)&flk, > sizeof(struct oflock)); > flk.l_rsys = FLOCK_LOCAL_LOCK; > flk.l_rpid = FLOCK_LOCAL_LOCK; > } else { > /* > * Remote lock proxy request. Only root is > * allowed to make proxy requests. Copy > * in full flock structure. > */ > if( !suser(p->p_ucred, &p->p_acflag)) > return( EPERM); > error = copyin( (caddr_t)uap->arg, > (caddr_t)&flk, > sizeof(struct flock)); > } 326,328c381,383 < if (fl.l_whence == SEEK_CUR) < fl.l_start += fp->f_offset; < if ((error = VOP_ADVLOCK(vp,(caddr_t)p,F_GETLK,&fl,F_POSIX))) --- > if (flk.l_whence == SEEK_CUR) > flk.l_start += fp->f_offset; > if ((error = VOP_ADVLOCK(vp,(caddr_t)p,F_GETLK,&flk,F_POSIX))) 330c385,421 < return (copyout((caddr_t)&fl, (caddr_t)uap->arg, sizeof (fl))); --- > /* > * Only copy out full structure if not F_GETLK to ensure > * we do not (incorrectly) fault the caller. > */ > if( uap->cmd == F_GETLK) { > /* old lock structure is enough...*/ > return( copyout((caddr_t)&flk, > (caddr_t)uap->arg, > sizeof(struct oflock))); > } else { /* F_RGETLK*/ > /* new lock structure is required...*/ > return( copyout((caddr_t)&flk, > (caddr_t)uap->arg, > sizeof(struct flock))); > } > /* NOTREACHED*/ > > case F_CNVT: > /* > * Convert an NFS file handle into a descriptor open > * in the calling process context (used by the lockd > * to establish open file state as a holder for a > * lock). > */ > if( !suser(p->p_ucred, &p->p_acflag)) > return( EPERM); > > /* > * XXX requires knowledge of the handle format to > * be presented via this interface. > * XXX requires registration of the conversion > * function (which already exists in the > * NFS code!) via a mechanism similar to > * that used by the existing LEASES code > * to allow continued use of NFS as an LKM. > */ > return( EBADF); 857c948 < struct flock lf; --- > struct flock flk; 871,874c962,967 < lf.l_whence = SEEK_SET; < lf.l_start = 0; < lf.l_len = 0; < lf.l_type = F_UNLCK; --- > flk.l_whence = SEEK_SET; > flk.l_start = 0; > flk.l_len = 0; > flk.l_type = F_UNLCK; > flk.l_rsys = FLOCK_LOCAL_LOCK; > flk.l_rpid = FLOCK_LOCAL_LOCK; 876c969 < (void) VOP_ADVLOCK(vp, (caddr_t)p, F_UNLCK, &lf, F_POSIX); --- > (void) VOP_ADVLOCK(vp, (caddr_t)p, F_UNLCK, &flk, F_POSIX); 883,886c976,981 < lf.l_whence = SEEK_SET; < lf.l_start = 0; < lf.l_len = 0; < lf.l_type = F_UNLCK; --- > flk.l_whence = SEEK_SET; > flk.l_start = 0; > flk.l_len = 0; > flk.l_type = F_UNLCK; > flk.l_rsys = FLOCK_LOCAL_LOCK; > flk.l_rpid = FLOCK_LOCAL_LOCK; 888c983 < (void) VOP_ADVLOCK(vp, (caddr_t)fp, F_UNLCK, &lf, F_FLOCK); --- > (void) VOP_ADVLOCK(vp, (caddr_t)fp, F_UNLCK, &flk, F_FLOCK); 920c1015 < struct flock lf; --- > struct flock flk; 928,930c1023,1027 < lf.l_whence = SEEK_SET; < lf.l_start = 0; < lf.l_len = 0; --- > flk.l_whence = SEEK_SET; > flk.l_start = 0; > flk.l_len = 0; > flk.l_rsys = FLOCK_LOCAL_LOCK; > flk.l_rpid = FLOCK_LOCAL_LOCK; 932c1029 < lf.l_type = F_UNLCK; --- > flk.l_type = F_UNLCK; 934c1031 < return (VOP_ADVLOCK(vp, (caddr_t)fp, F_UNLCK, &lf, F_FLOCK)); --- > return (VOP_ADVLOCK(vp, (caddr_t)fp, F_UNLCK, &flk, F_FLOCK)); 937c1034 < lf.l_type = F_WRLCK; --- > flk.l_type = F_WRLCK; 939c1036 < lf.l_type = F_RDLCK; --- > flk.l_type = F_RDLCK; 944,945c1041,1042 < return (VOP_ADVLOCK(vp, (caddr_t)fp, F_SETLK, &lf, F_FLOCK)); < return (VOP_ADVLOCK(vp, (caddr_t)fp, F_SETLK, &lf, F_FLOCK|F_WAIT)); --- > return (VOP_ADVLOCK(vp, (caddr_t)fp, F_SETLK, &flk, F_FLOCK)); > return (VOP_ADVLOCK(vp, (caddr_t)fp, F_SETLK, &flk, F_FLOCK|F_WAIT)); Index: kern_lockf.c =================================================================== RCS file: /b/cvstree/ncvs/src/sys/kern/kern_lockf.c,v retrieving revision 1.5 diff -r1.5 kern_lockf.c 3a4 > * Copyright (c) 1996 Terrence R. Lambert. All rights reserved. 19a21 > * This product includes software developed by Terrence R. Lambert. 142a145,146 > lock->lf_rsys = fl->l_rsys; > lock->lf_rpid = fl->l_rpid; 149a154,178 > case F_UNLKSYS: > /* > * WARNING: lf_overlap() uses LOCK_COMPARE, which will > * not match true a remote system id/pid given a lock > * removal on close. If the rpc.lockd implementation > * crashes (close on resource cleanup), locks held > * by a remote system will *NOT* be cleaned! To fix > * this, we would need a "proxy" flag to this routine > * which is propagated down via lf_clearlock() to > * lf_findoverlap() and flags LOCK_COMPARE() to > * ignore remote system id/pid in comparing. Since > * we believe that VOP_ADVLOCK() is improperly > * implemented, rather than changing every file > * system now, we will wait until we do a global > * clean up of the advisory locking code. Note > * that this means the rpc.lockd can not "optimize" > * by closing the fd to free locks for the final > * reference instance for the file; it *must* > * call with F_UNLKSYS (see closef() in kern_descrip.c). > * Resource track cleanup on crash will only free locks > * held by rpc.lockd itself (ie: none), not those held > * by proxy. > * > * -- Terry Lambert > */ 504a534,535 > fl->l_rsys = block->lf_rsys; > fl->l_rpid = block->lf_rpid; 565,566c596,597 < if (((type & SELF) && lf->lf_id != lock->lf_id) || < ((type & OTHERS) && lf->lf_id == lock->lf_id)) { --- > if (((type & SELF) && !LOCK_COMPARE(lf, lock)) || > ((type & OTHERS) && LOCK_COMPARE(lf, lock))) { 772a804 > lock->lf_type == F_UNLKSYS ? "unlock_sys" : 774c806 < if (lock->lf_block) --- > if (lock->lf_block) { 776,777c808,812 < else < printf("\n"); --- > if( lock->lf_rsys == FLOCK_LOCAL_LOCK) > printf( " (LCL)\n"); > else printf( " (NFS=0x%08x:0x%08x)\n", > lock->lf_rsys, lock->lf_rpid); > } else printf("\n"); 800a836 > lf->lf_type == F_UNLKSYS ? "unlock_sys" : 802c838 < if (lf->lf_block) --- > if (lf->lf_block) { 804,805c840,844 < else < printf("\n"); --- > if( lock->lf_rsys == FLOCK_LOCAL_LOCK) > printf( " (LCL)\n"); > else printf( " (NFS=0x%08x:0x%08x)\n", > lock->lf_rsys, lock->lf_rpid); > } else printf("\n"); Index: fcntl.h =================================================================== RCS file: /b/cvstree/ncvs/src/sys/sys/fcntl.h,v retrieving revision 1.3 diff -r1.3 fcntl.h 8a9 > * Copyright (c) 1996 Terrence R. Lambert. All rights reserved. 21a23 > * This product includes software developed by Terrence R. Lambert. 141a144,149 > #ifndef _POSIX_SOURCE > #define F_RGETLK 10 /* remote F_GETLK*/ > #define F_RSETLK 11 /* remote F_SETLK*/ > #define F_CNVT 12 /* open a file by NFS file handle*/ > #define F_RSETLKW 13 /* remote F_SETLKW*/ > #endif /* _POSIX_SOURCE*/ 149a158,160 > #ifndef _POSIX_SOURCE > #define F_UNLKSYS 4 /* remove all locks by system*/ > #endif /* _POSIX_SOURCE*/ 165a177,179 > long l_rsys; /* remote system id*/ > pid_t l_rpid; /* pid from remote system*/ > long l_reserved[ 4]; /* future use -- avoid syscall id change*/ 166a181,198 > > #ifdef KERNEL > /* > * Backward compatability advisory file segment locking data type; used > * only by kernel to ensure binary compatability. We only copy in this > * size of structure for F_GETLK, F_SETLK, and F_SETLKW. > */ > struct oflock { > off_t l_start; /* starting offset */ > off_t l_len; /* len = 0 means until end of file */ > pid_t l_pid; /* lock owner */ > short l_type; /* lock type: read/write, etc. */ > short l_whence; /* type of l_start */ > }; > > /* token for l_rsys, l_rpid*/ > #define FLOCK_LOCAL_LOCK 0 /* a non-NFS lock*/ > #endif /* KERNEL*/ Index: lockf.h =================================================================== RCS file: /b/cvstree/ncvs/src/sys/sys/lockf.h,v retrieving revision 1.3 diff -r1.3 lockf.h 3a4 > * Copyright (c) 1996 Terrence R. Lambert. All rights reserved. 19a21 > * This product includes software developed by Terrence R. Lambert. 54a57,58 > long lf_rsys; /* remote system id*/ > pid_t lf_rpid; /* pid from remote system*/ 58a63,71 > > /* > * Compare credentials on two locks. Returns TRUE if credentials are > * equivalent, FALSE otherwise. > */ > #define LOCK_COMPARE(l1, l2) (( l1->lf_id == l2->lf_id) && \ > ( l1->lf_rsys == l2->lf_rsys) && \ > ( l1->lf_rpid == l2->lf_rpid) \ > ) == 8< cut here 8< ========================================================== From owner-freebsd-current Fri Apr 19 18:35:11 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA16135 for current-outgoing; Fri, 19 Apr 1996 18:35:11 -0700 (PDT) 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 SAA16130 for ; Fri, 19 Apr 1996 18:35:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with SMTP id SAA00247 for ; Fri, 19 Apr 1996 18:09:39 -0700 (PDT) To: current@freebsd.org Subject: Anyone else notice NFS broken in -current? Date: Fri, 19 Apr 1996 18:09:39 -0700 Message-ID: <245.829962579@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Running the latest 2.2 kernels on two boxes here, I can only use NFS for a short time before any process doing NFS I/O hangs. After awhile of this, one of the systems will then reset to the BIOS. This and other reports now leads me to say that NFS is very, very broken. The only question is - who broke it, and when? Jordan From owner-freebsd-current Fri Apr 19 18:40:05 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA16295 for current-outgoing; Fri, 19 Apr 1996 18:40:05 -0700 (PDT) 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 SAA16290 for ; Fri, 19 Apr 1996 18:40:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with SMTP id SAA01458; Fri, 19 Apr 1996 18:39:53 -0700 (PDT) To: Somebody cc: current@FreeBSD.ORG Subject: Re: ffs troubles. In-reply-to: Your message of "Fri, 19 Apr 1996 20:07:47 CDT." Date: Fri, 19 Apr 1996 18:39:52 -0700 Message-ID: <1456.829964392@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Hello I have just started building a 2nd news server and I am get > a machine panic every couple of hours. The messsages saids "cpu panic > ffs_allocg map corrupted then something about panic allog block not in > map" This is on a P100 with 32M of ram and Adaptec 2940U and a Quantum > Atlas II drive. I wondering if freebsd has the same troubles with the > 2940U that other unixes have. Wether I should trade this out for a 946C > Buslogic. Or if its just that current is unstable? The 2940 Ultra controllers we have around here work just great - you say you're running -current on this machine? Hmmmm. Erm, why? I would think that 2.1-STABLE would give you everything you need without all the potential instability. Jordan From owner-freebsd-current Fri Apr 19 20:53:12 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id UAA21041 for current-outgoing; Fri, 19 Apr 1996 20:53:12 -0700 (PDT) Received: from potato.Dorm8.NCTU.edu.tw (potato.Dorm8.NCTU.edu.tw [140.113.188.20]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id UAA21036 for ; Fri, 19 Apr 1996 20:53:05 -0700 (PDT) Received: (from SPotato@localhost) by potato.Dorm8.NCTU.edu.tw (8.7.5/8.6.12) id LAA19570 for current@FreeBSD.ORG; Sat, 20 Apr 1996 11:51:53 +0800 (CST) From: Chao-Cheng Huang Message-Id: <199604200351.LAA19570@potato.Dorm8.NCTU.edu.tw> Subject: Cant use NCSA 2.3.07 Telnet and 2.2C? To: current@FreeBSD.ORG Date: Sat, 20 Apr 1996 11:51:52 +0800 (CST) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi: Sorry for my poor English. I am using FreeBSD 2.2C now. When I upgrade from 2.1R to 2.2C, I found something wrong. My dos box with NCSA 2.3.07 Telnet can't connect to my FreeBSD box. It always time out. I try to replace telnetd/inetd with 2.1R's , but it seems doesn't work, it still time out when I connect. Maybe it is a kernel problem, But I don't know what can I do. Thanks, for your FreeBSD. Sincerely, -- _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ Chao-cheng Huang Department Management Science 87G of NCTU in Taiwan_/ _/ E-mail: SPotato@potato.Dorm8.NCTU.edu.tw or u8331056@cc.nctu.edu.tw _/ _/ URL: telnet://potato.Dorm8.NCTU.edu.tw Phone:(035)712121 Ext. 78302 _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ From owner-freebsd-current Sat Apr 20 00:17:21 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA27687 for current-outgoing; Sat, 20 Apr 1996 00:17:21 -0700 (PDT) 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 AAA27682 for ; Sat, 20 Apr 1996 00:17:19 -0700 (PDT) Received: from gilberto.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de) by mail.rwth-aachen.de (PMDF V5.0-4 #13110) id <01I3RC64GK74001TPX@mail.rwth-aachen.de> for freebsd-current@freefall.FreeBSD.org; Sat, 20 Apr 1996 09:03:22 +0100 Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.6.11/8.6.9) id JAA16608 for freebsd-current@freefall.cdrom.com; Sat, 20 Apr 1996 09:09:13 +0200 Date: Sat, 20 Apr 1996 09:09:13 +0200 From: "Christoph P. Kukulies" Subject: data point on stability - negative To: freebsd-current@freefall.FreeBSD.org Message-id: <199604200709.JAA16608@gilberto.physik.rwth-aachen.de> Content-transfer-encoding: 7BIT Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Toots, a P150, 32MB IDE system, builds -current world daily in the morning hours. build world time presently around 12.000 s real. I'm using obj on a different drive and -pipe. Every other day I build a new kernel and boot reboot the machine. Last nights world build choked: cc -fpic -DPIC -O2 -m486 -pipe -fno-strength-reduce -nostdinc -I/usr/src/gnu/lib/libg++/include -I/usr/include -c /usr/src/gnu/lib/libg++/libg++/timer.c -o timer.so c++ -fpic -DPIC -O2 -m486 -pipe -fno-strength-reduce -nostdinc -I/usr/src/gnu/lib/libg++/include -I/usr/include -I/usr/src/gnu/lib/libg++/include -I/usr/include/g++ -I/usr/include -nostdinc++ -c /usr/src/gnu/lib/libg++/libg++/ACG.cc -o ACG.so c++ -fpic -DPIC -O2 -m486 -pipe -fno-strength-reduce -nostdinc -I/usr/src/gnu/lib/libg++/include -I/usr/include -I/usr/src/gnu/lib/libg++/include -I/usr/include/g++ -I/usr/include -nostdinc++ -c /usr/src/gnu/lib/libg++/libg++/AllocRing.cc -o AllocRing.so c++ -fpic -DPIC -O2 -m486 -pipe -fno-strength-reduce -nostdinc -I/usr/src/gnu/lib/libg++/include -I/usr/include -I/usr/src/gnu/lib/libg++/include -I/usr/include/g++ -I/usr/include -nostdinc++ -c /usr/src/gnu/lib/libg++/libg++/Binomial.cc -o Binomial.so c++ -fpic -DPIC -O2 -m486 -pipe -fno-strength-reduce -nostdinc -I/usr/src/gnu/lib/libg++/include -I/usr/include -I/usr/src/gnu/lib/libg++/include -I/usr/include/g++ -I/usr/include -nostdinc++ -c /usr/src/gnu/lib/libg++/libg++/BitSet.cc -o BitSet.so c++ -fpic -DPIC -O2 -m486 -pipe -fno-strength-reduce -nostdinc -I/usr/src/gnu/lib/libg++/include -I/usr/include -I/usr/src/gnu/lib/libg++/include -I/usr/include/g++ -I/usr/include -nostdinc++ -c /usr/src/gnu/lib/libg++/libg++/BitString.cc -o BitString.so Memory fault - core dumped *** Error code 139 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. 6736.82 real 4539.26 user 1136.06 sys I will start over again and see what happens. I remember that I had problems in early 2.2 days with a similar configuration (-pipe and obj on a different drive). --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-current Sat Apr 20 00:52:43 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA28616 for current-outgoing; Sat, 20 Apr 1996 00:52:43 -0700 (PDT) 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 AAA28610 for ; Sat, 20 Apr 1996 00:52:40 -0700 (PDT) Received: from gilberto.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de) by mail.rwth-aachen.de (PMDF V5.0-4 #13110) id <01I3RDCGDEJK001UJN@mail.rwth-aachen.de>; Sat, 20 Apr 1996 09:37:31 +0100 Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.6.11/8.6.9) id JAA16759; Sat, 20 Apr 1996 09:42:57 +0200 Date: Sat, 20 Apr 1996 09:42:56 +0200 (MET DST) From: "Christoph P. Kukulies" Subject: Re: gzipped executables In-reply-to: <199604191927.MAA08783@phaeton.artisoft.com> To: terry@lambert.org (Terry Lambert) Cc: kuku@gilberto.physik.rwth-aachen.de, freebsd-current@freefall.freebsd.org Reply-to: Christoph Kukulies Message-id: <199604200742.JAA16759@gilberto.physik.rwth-aachen.de> MIME-version: 1.0 X-Mailer: ELM [version 2.4 PL25 ME8b] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > Is anyone working on fixing the broken gzip executable feature in > > -current? > > It's a cache interaction. Pentium caches are written back inside > the cache queue depth, whereas pre-Pentium processors have > immutable cache queues. Jordan said it already and I can confirm it: It doesn't work on my DX-2/66 anymore where it used to work under 2.1.0. I appended an rcslog of /sys/kern/imgact_gzip.c I don't know if I'm enough a kernel expert to find out if it was one of the VM changes that caused it and whether imgact_gzip.c is the culprit anyway. [considerations about P5 L2 cache removed] > > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de RCS file: imgact_gzip.c,v Working file: imgact_gzip.c head: 1.20 branch: locks: strict access list: symbolic names: wollman_polling: 1.20.0.2 RELENG_2_1_0_RELEASE: 1.14 RELENG_2_1_0: 1.14.0.4 RELENG_2_1_0_BP: 1.14 RELENG_2_0_5_RELEASE: 1.14 RELENG_2_0_5: 1.14.0.2 RELENG_2_0_5_BP: 1.14 RELENG_2_0_5_ALPHA: 1.13 OLAH_TTCP: 1.10.0.4 RELEASE_2_0: 1.10 BETA_2_0: 1.10 ALPHA_2_0: 1.10.0.2 keyword substitution: kv total revisions: 20; selected revisions: 20 description: ---------------------------- revision 1.20 date: 1996/03/19 15:02:47; author: bde; state: Exp; lines: +2 -2 Fixed unsigned longs that should have been vm_offset_t. vm_offset_t is currently unsigned long but should probably be plain unsigned for i386's to match the choice of minimal types to represent for fixed-width types in Lite2. Anyway, it shouldn't be assumed to be unsigned long. I only fixed the type mismatches that were detected when I changed vm_offset_t to unsigned. Only pointer type mismatches were detected. ---------------------------- revision 1.19 date: 1996/02/13 14:16:36; author: phk; state: Exp; lines: +8 -6 rewrap some long lines. ---------------------------- revision 1.18 date: 1996/01/19 03:57:56; author: dyson; state: Exp; lines: +2 -2 Eliminated many redundant vm_map_lookup operations for vm_mmap. Speed up for vfs_bio -- addition of a routine bqrelse to greatly diminish overhead for merged cache. Efficiency improvement for vfs_cluster. It used to do alot of redundant calls to cluster_rbuild. Correct the ordering for vrele of .text and release of credentials. Use the selective tlb update for 486/586/P6. Numerous fixes to the size of objects allocated for files. Additionally, fixes in the various pagers. Fixes for proper positioning of vnode_pager_setsize in msdosfs and ext2fs. Fixes in the swap pager for exhausted resources. The pageout code will not as readily thrash. Change the page queue flags (PG_ACTIVE, PG_INACTIVE, PG_FREE, PG_CACHE) into page queue indices (PQ_ACTIVE, PQ_INACTIVE, PQ_FREE, PQ_CACHE), thereby improving efficiency of several routines. Eliminate even more unnecessary vm_page_protect operations. Significantly speed up process forks. Make vm_object_page_clean more efficient, thereby eliminating the pause that happens every 30seconds. Make sequential clustered writes B_ASYNC instead of B_DELWRI even in the case of filesystems mounted async. Fix a panic with busy pages when write clustering is done for non-VMIO buffers. ---------------------------- revision 1.17 date: 1995/12/07 12:46:35; author: davidg; state: Exp; lines: +7 -1 Untangled the vm.h include file spaghetti. ---------------------------- revision 1.16 date: 1995/12/02 16:32:01; author: bde; state: Exp; lines: +3 -2 Staticized. Added prototypes. ---------------------------- revision 1.15 date: 1995/11/06 12:52:30; author: davidg; state: Exp; lines: +6 -6 All: Changed vnodep -> vp for consistency with the rest of the kernel, and changed iparams -> imgp for brevity. kern_exec.c: Explicitly initialized some additional parts of the image_params struct to avoid bzeroing it. Rewrote the set-id code to reduce the number of logical tests. The rewrite exposed a mostly benign bug in the algorithm: traced set-id images would get ktracing disabled even if the set-id didn't happen for other reasons. ---------------------------- revision 1.14 date: 1995/05/30 08:05:18; author: rgrimes; state: Exp; lines: +2 -2 Remove trailing whitespace. ---------------------------- revision 1.13 date: 1995/03/16 18:12:27; author: bde; state: Exp; lines: +1 -3 Add and move declarations to fix all of the warnings from `gcc -Wimplicit' (except in netccitt, netiso and netns) and most of the warnings from `gcc -Wnested-externs'. Fix all the bugs found. There were no serious ones. ---------------------------- revision 1.12 date: 1995/02/20 22:23:07; author: davidg; state: Exp; lines: +17 -15 Use of vm_allocate() and vm_deallocate() has been deprecated. ---------------------------- revision 1.11 date: 1995/02/13 07:40:33; author: phk; state: Exp; lines: +2 -2 Actually access the right first page if the file. Bruce finally caught this bogon for me, Thank you Bruce ! Due to some part of the VM/buffer/pmap magic doing clustering, this bogon managed to work better than 99.9% of the time. Amazing. If You ever again see a weird message from the gzip code, please tell me. ---------------------------- revision 1.10 date: 1994/10/22 11:55:16; author: phk; state: Exp; lines: +3 -2 Make the diagnostics a little more useful. A word of wisdom, don't do this: | cd /usr/bin | for i in * | do | cp $i /tmp/a | gzip -9 < /tmp/a > $i | done It will compress files with multiple links several times. do it this way: | cd /usr/bin | for i in * | do | gunzip -f < $i > /tmp/a | gzip -9 < /tmp/a > $i | done ---------------------------- revision 1.9 date: 1994/10/22 11:40:27; author: phk; state: Exp; lines: +301 -220 I belive imgact_gzip is finally reentrant. It is also a whole lot more readable. inflate is now much more general, and is there if anybody feels like making a uncompressing filesystem or something like that (hint hint !) ---------------------------- revision 1.8 date: 1994/10/11 11:29:09; author: csgr; state: Exp; lines: +9 -7 - remove unnecessary #includes (I think a couple of redundant ones remain) - excise some unused code (#if 0'd out - don't want to nuke it yet) - fix problems with "make depend" - some macros were screwing it up - get rid of some static local variables There still seems to be a small reentrancy problem somewhere. ---------------------------- revision 1.7 date: 1994/10/07 22:26:51; author: csgr; state: Exp; lines: +9 -1211 First stage of getting imgact_gzip reentrant: 1) cut this up into /sys/sys/inflate.h, sys/kern/inflate.c sys/kern/ingact_gzip.c 2) make a lot more things static 3) make a lot of globals const 4) make some args const 5) first stage of making globals into a struct (not used yet) The vm_allocate() call which was introduced between revisions 1.4 and 1.5 of imagact_gzip.c broke things. I have backed that out for the time being. (Davidg: help please) WARNING: if you have gzip enabled in your kernel, you must now run config again, as another source file has been added. Otherwise your kernel compile will fall over. This is all still WIP. More commits to come. Suggestions from: phk. ---------------------------- revision 1.6 date: 1994/10/06 18:22:24; author: phk; state: Exp; lines: +8 -1 Steven Wallace provided a program which broke this stuff. I guess there are more weird kinds of a.out than anyone can argue for. This code failed to load the first 28K of the text-segment, in the case where the first page of the a.out contains only the a.out-header, and the text is still at 0x0. Thanks Steven ! ---------------------------- revision 1.5 date: 1994/10/05 00:58:33; author: phk; state: Exp; lines: +5 -5 David Greenman told me to do this: (Thanks!) use vm_allocate to allocate the uncompression buffer. Now malloc(M_GZIP) is used for all the Huffman- tree stuff only. Numbers so far indicate < 15Kb Malloc use + 32 Kb for the abovementioned buffer while uncompressing. ---------------------------- revision 1.4 date: 1994/10/04 06:51:42; author: phk; state: Exp; lines: +13 -6 Added M_GZIP for the imgact_gzip code. The gzip-code is likely to be used for other weird things in the future (hint, hint!) ---------------------------- revision 1.3 date: 1994/10/04 03:09:13; author: phk; state: Exp; lines: +68 -54 Based on the applause (in this case: not downright rejection :-) I have cleaned up much of the cruft in this thing. No printf's in the case where things go well. Gzip-headers can contain filenames and comments (as long as they're shorter than the page-size.) I don't think we leak memory, in the "exec/aout" code. I'm not quite sure about the inflate code yet, but I don't think memory is lost. Q: Can I add a class M_GZIP to and bump M_LAST one up without any thing else needing tweaking ? Poul-Henning ---------------------------- revision 1.2 date: 1994/10/03 23:14:48; author: phk; state: Exp; lines: +9 -3 First bug-fix. This this depends on something odd. I am looking at it, but every now and then it will fail without an explanation :-( ---------------------------- revision 1.1 date: 1994/10/03 05:23:01; author: phk; state: Exp; *** WARNING: THIS MATERIAL MIGHT GO AWAY! This material needs the core-groups approval to stay here for the 2.0 release. If the core-group does not concent to this commit, it will be backed out. *** It is a non-gpl'ed "unzip" which will allow execution of a.out files which have been sent through "gzip -9". The idea being saved disk-space. Just now this code has quality rating: "working prototype". To compress a file to be used with this, do it exactly this way: gzip -9 -v < /bin/FOO > /tmp/FOO remember to chmod /tmp/FOO as needed. DON'T compress all of you binaries right away ! There are several things which you should consider first: 1. Using compressed binaries, you use >MUCH< more VM, and thus swap-space. 2. It is slow. 3. It might crash your machine. Apart from that, I welcome comments... NB: There is also a change to sys/conf/files, but cvs core-dumped on me, so it didn't get into the logs or emailed, but the commit seems to have happended OK. ---------------------------- ============================================================================= From owner-freebsd-current Sat Apr 20 03:02:54 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA03987 for current-outgoing; Sat, 20 Apr 1996 03:02:54 -0700 (PDT) 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 DAA03982 for ; Sat, 20 Apr 1996 03:02:50 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id UAA02505; Sat, 20 Apr 1996 20:01:19 +1000 Date: Sat, 20 Apr 1996 20:01:19 +1000 From: Bruce Evans Message-Id: <199604201001.UAA02505@godzilla.zeta.org.au> To: current@freebsd.org, jkh@time.cdrom.com Subject: Re: Anyone else notice NFS broken in -current? Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Running the latest 2.2 kernels on two boxes here, I can only use NFS >for a short time before any process doing NFS I/O hangs. After awhile >of this, one of the systems will then reset to the BIOS. >This and other reports now leads me to say that NFS is very, very >broken. The only question is - who broke it, and when? The ip header optimizations broken it yesterday. All large packets are probably broken. I'm running with the following fix. Note that it has breakpoint instructions to trap the header optimizations that haven't failed yet. Bruce *** ip_output.c~ Fri Apr 19 17:11:21 1996 --- ip_output.c Sat Apr 20 11:21:36 1996 *************** *** 332,336 **** ip->ip_sum = 0; if (ip->ip_vhl == IP_VHL_BORING) { ! ip->ip_sum = in_cksum_hdr(ip); } else { ip->ip_sum = in_cksum(m, hlen); --- 332,340 ---- ip->ip_sum = 0; if (ip->ip_vhl == IP_VHL_BORING) { ! u_short tmp; ! tmp = in_cksum_hdr(ip); ! ip->ip_sum = in_cksum(m, hlen); ! if (tmp != ip->ip_sum) ! breakpoint(); } else { ip->ip_sum = in_cksum(m, hlen); *************** *** 414,418 **** mhip->ip_sum = 0; if (mhip->ip_vhl == IP_VHL_BORING) { ! mhip->ip_sum = in_cksum_hdr(ip); } else { mhip->ip_sum = in_cksum(m, mhlen); --- 418,426 ---- mhip->ip_sum = 0; if (mhip->ip_vhl == IP_VHL_BORING) { ! u_short tmp; ! tmp = in_cksum_hdr(ip); ! mhip->ip_sum = in_cksum(m, mhlen); ! if (tmp != mhip->ip_sum) ! breakpoint(); } else { mhip->ip_sum = in_cksum(m, mhlen); *************** *** 432,440 **** ip->ip_off = htons((u_short)(ip->ip_off | IP_MF)); ip->ip_sum = 0; if (ip->ip_vhl == IP_VHL_BORING) { ! ip->ip_sum = in_cksum_hdr(ip); } else { ip->ip_sum = in_cksum(m, hlen); } sendorfree: for (m = m0; m; m = m0) { --- 440,456 ---- ip->ip_off = htons((u_short)(ip->ip_off | IP_MF)); ip->ip_sum = 0; + #if 0 if (ip->ip_vhl == IP_VHL_BORING) { ! u_short tmp; ! tmp = in_cksum_hdr(ip); ! ip->ip_sum = in_cksum(m, hlen); ! if (tmp != ip->ip_sum) ! breakpoint(); } else { ip->ip_sum = in_cksum(m, hlen); } + #else + ip->ip_sum = in_cksum(m, hlen); + #endif sendorfree: for (m = m0; m; m = m0) { *************** *** 1223,1227 **** ip->ip_sum = 0; if (ip->ip_vhl == IP_VHL_BORING) { ! ip->ip_sum = in_cksum_hdr(ip); } else { ip->ip_sum = in_cksum(copym, --- 1239,1248 ---- ip->ip_sum = 0; if (ip->ip_vhl == IP_VHL_BORING) { ! u_short tmp; ! tmp = in_cksum_hdr(ip); ! ip->ip_sum = in_cksum(copym, ! IP_VHL_HL(ip->ip_vhl) << 2); ! if (tmp != ip->ip_sum) ! breakpoint(); } else { ip->ip_sum = in_cksum(copym, From owner-freebsd-current Sat Apr 20 03:55:19 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA05772 for current-outgoing; Sat, 20 Apr 1996 03:55:19 -0700 (PDT) Received: from snake.hut.fi (snake.hut.fi [193.167.6.99]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id DAA05765 for ; Sat, 20 Apr 1996 03:55:15 -0700 (PDT) Received: from lk-hp-20.hut.fi (inkari@lk-hp-20.hut.fi [130.233.247.33]) by snake.hut.fi (8.7.5/8.7.3) with ESMTP id NAA21728 for ; Sat, 20 Apr 1996 13:55:09 +0300 From: Juha Inkari Received: (inkari@localhost) by lk-hp-20.hut.fi (8.6.12/8.6.7) id NAA13571 for freebsd-current@freebsd.org; Sat, 20 Apr 1996 13:55:09 +0300 Message-Id: <199604201055.NAA13571@lk-hp-20.hut.fi> Subject: /usr/include/net/if.h:394: unbalanced `#endif' To: freebsd-current@freebsd.org Date: Sat, 20 Apr 1996 13:55:08 +0300 (EETDST) X-Mailer: ELM [version 2.4 PL25] 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 make all just stopped to: ------- ===> lib/libpcap cc -O -DFDDI -I. -I/home/source/FreeBSD/current/src/lib/libpcap -c /home/source/FreeBSD/current/src/lib/libpcap/pcap-bpf.c -o pcap-bpf.o In file included from /home/source/FreeBSD/current/src/lib/libpcap/pcap-bpf.c:38: /usr/include/net/if.h:394: unbalanced `#endif' *** Error code 1 Stop. ------ From owner-freebsd-current Sat Apr 20 06:20:41 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA12464 for current-outgoing; Sat, 20 Apr 1996 06:20:41 -0700 (PDT) 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 GAA12459 for ; Sat, 20 Apr 1996 06:20:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with SMTP id GAA00206; Sat, 20 Apr 1996 06:20:05 -0700 (PDT) To: Bruce Evans cc: current@freebsd.org Subject: Re: Anyone else notice NFS broken in -current? In-reply-to: Your message of "Sat, 20 Apr 1996 20:01:19 +1000." <199604201001.UAA02505@godzilla.zeta.org.au> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <203.830006404.1@time.cdrom.com> Date: Sat, 20 Apr 1996 06:20:05 -0700 Message-ID: <204.830006405@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > The ip header optimizations broken it yesterday. All large packets > are probably broken. :-( Is this part of a larger fix you're working on, or should we run with some interim solution to fix the broken state of the world? > I'm running with the following fix. Note that it has breakpoint > instructions to trap the header optimizations that haven't failed > yet. Yep, I just hit one.. :-) Do you want the crash dump, or do you already have plenty of your own to look at? Jordan From owner-freebsd-current Sat Apr 20 06:53:17 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA13754 for current-outgoing; Sat, 20 Apr 1996 06:53:17 -0700 (PDT) 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 GAA13749 for ; Sat, 20 Apr 1996 06:53:14 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id XAA17330; Sat, 20 Apr 1996 23:50:50 +1000 Date: Sat, 20 Apr 1996 23:50:50 +1000 From: Bruce Evans Message-Id: <199604201350.XAA17330@godzilla.zeta.org.au> To: bde@zeta.org.au, jkh@time.cdrom.com Subject: Re: Anyone else notice NFS broken in -current? Cc: current@freebsd.org Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> The ip header optimizations broken it yesterday. All large packets >> ... >Is this part of a larger fix you're working on, or should we run >with some interim solution to fix the broken state of the world? I'm waiting for Garrett to read his mail :-). I can only fix the inline function, and it seemed OK. >> I'm running with the following fix. Note that it has breakpoint >> instructions to trap the header optimizations that haven't failed >> yet. >Yep, I just hit one.. :-) Do you want the crash dump, or do you already >have plenty of your own to look at? No. Just remove the breakpoints. Then the wrong code will only be used for checking. Bruce From owner-freebsd-current Sat Apr 20 11:56:40 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA23518 for current-outgoing; Sat, 20 Apr 1996 11:56:40 -0700 (PDT) Received: from xi.dorm.umd.edu (root@xi.dorm.umd.edu [129.2.152.45]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id LAA23512 for ; Sat, 20 Apr 1996 11:56:38 -0700 (PDT) Received: from localhost (smpatel@localhost [127.0.0.1]) by xi.dorm.umd.edu (8.7.5/8.6.12) with SMTP id OAA19350 for ; Sat, 20 Apr 1996 14:56:28 -0400 (EDT) Date: Sat, 20 Apr 1996 14:56:25 -0400 (EDT) From: Sujal Patel X-Sender: smpatel@xi.dorm.umd.edu To: current@freebsd.org Subject: ncftp - Change Request Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Is there any particular reason why we compile ncftp with -DSYSLOG? It is pretty annoying having all transfers logged... Sujal From owner-freebsd-current Sat Apr 20 12:27:54 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA24648 for current-outgoing; Sat, 20 Apr 1996 12:27:54 -0700 (PDT) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA24631 Sat, 20 Apr 1996 12:27:45 -0700 (PDT) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0uAiJl-0003wuC; Sat, 20 Apr 96 12:27 PDT 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 TAA03213; Sat, 20 Apr 1996 19:27:27 GMT X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: Mark Murray cc: current@FreeBSD.org, stable@FreeBSD.org Subject: Re: CTM Delta cvs-cur.1900S.gz In-reply-to: Your message of "Wed, 17 Apr 1996 22:03:09 +0200." <199604172003.WAA01354@grumble.grondar.za> Date: Sat, 20 Apr 1996 19:27:25 +0000 Message-ID: <3211.830028445@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk done. > Hi > > I have built this delta (cvs-cur.1900S.gz) which is a "starter" > delta against the 23 March SNAP CDROM's CVS snapshot. > > If anyone wants it, it in my home directory on freefall:~/markm. > > Poul-Henning, could you please put it into the anonymous ftp area > and announce it if that is OK? > > Thanks! > > Enjoy! > > M > > -- > Mark Murray > 46 Harvey Rd, Claremont, Cape Town 7700, South Africa > +27 21 61-3768 GMT+0200 > Finger mark@grondar.za for PGP key -- 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 20 14:35:55 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA04183 for current-outgoing; Sat, 20 Apr 1996 14:35:55 -0700 (PDT) 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 OAA04178 for ; Sat, 20 Apr 1996 14:35:49 -0700 (PDT) Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA19580; Sat, 20 Apr 1996 17:35:32 -0400 Date: Sat, 20 Apr 1996 17:35:32 -0400 From: Garrett Wollman Message-Id: <9604202135.AA19580@halloran-eldar.lcs.mit.edu> To: Bruce Evans Cc: current@freebsd.org, jkh@time.cdrom.com Subject: Re: Anyone else notice NFS broken in -current? In-Reply-To: <199604201001.UAA02505@godzilla.zeta.org.au> References: <199604201001.UAA02505@godzilla.zeta.org.au> Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk < said: > The ip header optimizations broken it yesterday. All large packets > are probably broken. There is something seriously wrong here. I don't have time to take a look at it right now, but for the moment Bruce's fix is acceptable. I'll look into in tomorrow morning. > I'm running with the following fix. Note that it has breakpoint > instructions to trap the header optimizations that haven't failed > yet. [patch deleted - use the archves] -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 20 18:55:06 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA15071 for current-outgoing; Sat, 20 Apr 1996 18:55:06 -0700 (PDT) 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 SAA15057 for ; Sat, 20 Apr 1996 18:54:57 -0700 (PDT) Received: (from news@localhost) by haywire.DIALix.COM (8.7.5/8.7.3) id JAA26235 for freebsd-current@freebsd.org; Sun, 21 Apr 1996 09:55:01 +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: 21 Apr 96 01:50:45 GMT From: peter@jhome.DIALix.COM (Peter Wemm) Message-ID: Organization: DIALix Services, Perth, Australia. References: <9604181607.AA06704@halloran-eldar.lcs.mit.edu>, Subject: Re: Changes for vfork() Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk smpatel@umiacs.umd.edu (Sujal Patel) writes: >On Thu, 18 Apr 1996, Garrett Wollman wrote: >> and everything should Just Work. (Make sure to do all of these steps >> before recompiling the world, though.) >We should briefly look over the source tree too. Some brain-dead programs >may rely on vfork() behavior (such as sleeping on the child, or altering >the parent's address space)... Note that there are some programs still using these features.. tcsh, for one, uses the shared address space semantics to update some statistics in the parent. Naturally, this does not work on FreeBSD, because of the incomplete vfork() emulation. It's ironic.. vfork() was a traditional BSD thing, and now System V machines implement it better than the current BSD's do. >Sujal -Peter From owner-freebsd-current Sat Apr 20 21:01:57 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA21273 for current-outgoing; Sat, 20 Apr 1996 21:01:57 -0700 (PDT) Received: from bunyip.cc.uq.oz.au (pp@bunyip.cc.uq.oz.au [130.102.2.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id VAA21263 for ; Sat, 20 Apr 1996 21:01:38 -0700 (PDT) Received: from bunyip.cc.uq.oz.au by bunyip.cc.uq.oz.au id <28227-0@bunyip.cc.uq.oz.au>; Sun, 21 Apr 1996 14:00:54 +1000 Received: from netfl15a.devetir.qld.gov.au by pandora.devetir.qld.gov.au (8.6.10/DEVETIR-E0.3a) with ESMTP id NAA17173; Sun, 21 Apr 1996 13:27:47 +1000 Received: from localhost by netfl15a.devetir.qld.gov.au (8.6.8.1/DEVETIR-0.1) id DAA17213; Sun, 21 Apr 1996 03:30:57 GMT Message-Id: <199604210330.DAA17213@netfl15a.devetir.qld.gov.au> X-Mailer: exmh version 1.6.5 12/11/95 To: "Jordan K. Hubbard" cc: current@freebsd.org Subject: Re: Anyone else notice NFS broken in -current? In-reply-to: Your message of "Fri, 19 Apr 1996 18:09:39 MST." <245.829962579@time.cdrom.com> X-Face: 3}heU+2?b->-GSF-G4T4>jEB9~FR(V9lo&o>kAy=Pj&;oVOc<|pr%I/VSG"ZD32J>5gGC0N 7gj]^GI@M:LlqNd]|(2OxOxy@$6@/!,";-!OlucF^=jq8s57$%qXd/ieC8DhWmIy@J1AcnvSGV\|*! >Bvu7+0h4zCY^]{AxXKsDTlgA2m]fX$W@'8ev-Qi+-;%L'CcZ'NBL!@n?}q!M&Em3*eW7,093nOeV8 M)(u+6D;%B7j\XA/9j4!Gj~&jYzflG[#)E9sI&Xe9~y~Gn%fA7>F:YKr"Wx4cZU*6{^2ocZ!YyR Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 21 Apr 1996 13:30:56 +1000 From: Stephen Hocking Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Yup - I've noticed this today. Not nice at all! Stephen -- The views expressed above are not those of the Worker's Compensation Board of Queensland, Australia. From owner-freebsd-current Sat Apr 20 21:32:11 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA22379 for current-outgoing; Sat, 20 Apr 1996 21:32:11 -0700 (PDT) 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 VAA22374 for ; Sat, 20 Apr 1996 21:32:10 -0700 (PDT) Message-Id: <199604210432.VAA22374@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: Host localhost.cdrom.com [127.0.0.1] didn't use HELO protocol To: current Subject: Aic7xxx driver update in current Date: Sat, 20 Apr 1996 21:32:10 -0700 From: "Justin T. Gibbs" Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk For those of you who don't watch the commit mailing list, I've just put into current my changes to allow SCB paging on the aic7xxx cards. What does this mean for you? It should mean better throughput in your server class machines. SCB paging allows up to 255 concurrent commands on the adapters that support it which means more tagged commands active per device and better I/O scheduling to reduce seek times. Because the code is new and has only been tested by two people so far, it is not enabled by default. You must add the option "AHC_SCBPAGING_ENABLE" to your kernel config file. The default behavior of the driver is to use 4 tags per device without SCB paging and 8 with. This may change as I get more information from people using the driver and do more benchmarks. Tagged queueing is no longer an option (its been tested for 1 year now) and the QUEUE_FULL_SUPPORTED stuff has gone away too. Please test out the new driver and report any problems back to me. I intend to bring this driver into -stable soon (as it fixes some other bugs too), but I want to wait for more people to test it in -current first. Thanks! -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Sat Apr 20 23:19:34 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA26654 for current-outgoing; Sat, 20 Apr 1996 23:19:34 -0700 (PDT) Received: from xi.dorm.umd.edu (root@xi.dorm.umd.edu [129.2.152.45]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id XAA26649 for ; Sat, 20 Apr 1996 23:19:32 -0700 (PDT) Received: from localhost (smpatel@localhost [127.0.0.1]) by xi.dorm.umd.edu (8.7.5/8.6.12) with SMTP id CAA01170; Sun, 21 Apr 1996 02:19:20 -0400 (EDT) Date: Sun, 21 Apr 1996 02:19:20 -0400 (EDT) From: Sujal Patel X-Sender: smpatel@xi.dorm.umd.edu To: Peter Wemm cc: current@freebsd.org Subject: Re: Changes for vfork() 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 21 Apr 1996, Peter Wemm wrote: > Note that there are some programs still using these features.. tcsh, > for one, uses the shared address space semantics to update some statistics > in the parent. This is an absolutely horrible thing for a user program to do. The vfork() call was never intended to allow you to update the parent's address space and as the man page states, should never be used in such a way. Besides, FreeBSD doesn't have an implementation that supports this anyway :) If tcsh (I think it's actually csh) *really* wants to update some of the parents address space on FreeBSD, it should use rfork() instead IMO. Sujal