From owner-freebsd-current Sun Mar 3 00:32:11 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA28019 for current-outgoing; Sun, 3 Mar 1996 00:32:11 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id AAA28014 Sun, 3 Mar 1996 00:32:07 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id SAA15061; Sun, 3 Mar 1996 18:26:46 +1000 Date: Sun, 3 Mar 1996 18:26:46 +1000 From: Bruce Evans Message-Id: <199603030826.SAA15061@godzilla.zeta.org.au> To: hosokawa@mt.cs.keio.ac.jp, hsu@freefall.freebsd.org Subject: Re: new sio delays Cc: bde@freefall.freebsd.org, current@freefall.freebsd.org Sender: owner-current@FreeBSD.ORG Precedence: bulk >>> The 3 DELAY()s which were added last week to sio.c breaks the probe of >>> my internal Boca 1440 modem. Does anyone else have problems finding >>> serial ports with these DELAY()s? >I tested this patch with some PCMCIA modem cards that fails some of >these tests, but it helps nothing. More xx(x)50 incompatibles :-(. I think I'll remove most of the probe. sioprobe() is the only probe that attempts to autoconfigure IRQs by checking that they actually work, and it doesn't quite succeed, and the configuration part hasn't been implemented. >I want to know the means of this patch. Read the commit mail. Bruce From owner-freebsd-current Sun Mar 3 00:52:05 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA29381 for current-outgoing; Sun, 3 Mar 1996 00:52:05 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id AAA29351 Sun, 3 Mar 1996 00:52:00 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id TAA06706; Sun, 3 Mar 1996 19:26:10 +1030 From: Michael Smith Message-Id: <199603030856.TAA06706@genesis.atrad.adelaide.edu.au> Subject: Re: new sio delays To: hsu@freefall.freebsd.org (Jeffrey Hsu) Date: Sun, 3 Mar 1996 19:26:09 +1030 (CST) Cc: bde@freefall.freebsd.org, current@freefall.freebsd.org In-Reply-To: <199603030130.RAA00943@freefall.freebsd.org> from "Jeffrey Hsu" at Mar 2, 96 05:30:04 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG Precedence: bulk Jeffrey Hsu stands accused of saying: > > The 3 DELAY()s which were added last week to sio.c breaks the probe of > my internal Boca 1440 modem. Does anyone else have problems finding > serial ports with these DELAY()s? Sonovabitch 8( They went in to help finding bogus UART-less internal modems; I thought actually that one of the ones that was helped was a Boca model. Looks like we need a 'slow modem probe' flag 8( -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[ From owner-freebsd-current Sun Mar 3 00:58:24 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA00547 for current-outgoing; Sun, 3 Mar 1996 00:58:24 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id AAA00534 Sun, 3 Mar 1996 00:58:18 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id TAA06718; Sun, 3 Mar 1996 19:30:46 +1030 From: Michael Smith Message-Id: <199603030900.TAA06718@genesis.atrad.adelaide.edu.au> Subject: Re: new sio delays To: hosokawa@mt.cs.keio.ac.jp (HOSOKAWA Tatsumi) Date: Sun, 3 Mar 1996 19:30:46 +1030 (CST) Cc: hsu@freefall.freebsd.org, bde@freefall.freebsd.org, current@freefall.freebsd.org, hosokawa@mt.cs.keio.ac.jp In-Reply-To: <199603030740.QAA00912@frig.mt.cs.keio.ac.jp> from "HOSOKAWA Tatsumi" at Mar 3, 96 04:40:46 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG Precedence: bulk HOSOKAWA Tatsumi stands accused of saying: > > In article <199603030130.RAA00943@freefall.freebsd.org> > hsu@freefall.freebsd.org writes: > > >> The 3 DELAY()s which were added last week to sio.c breaks the probe of > >> my internal Boca 1440 modem. Does anyone else have problems finding > >> serial ports with these DELAY()s? > > I tested this patch with some PCMCIA modem cards that fails some of > these tests, but it helps nothing. > > I want to know the means of this patch. Some ISA 'internal modems' don't have real 8250-family UARTs, they attempt to emulate them using their onboard processors. Most of these are quite slow at generating interrupts, and responding in general, so waiting a while gives them time to react. Over the last six months or so, we've had a number of successful results with these delays, hence bde committing them. > HOSOKAWA, Tatsumi E-mail: hosokawa@mt.cs.keio.ac.jp -- ]] 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 Mar 3 02:03:44 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA06173 for current-outgoing; Sun, 3 Mar 1996 02:03:44 -0800 (PST) Received: from nervosa.com (root@nervosa.com [192.187.228.86]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id CAA06168 for ; Sun, 3 Mar 1996 02:03:40 -0800 (PST) Received: from nervosa.com (coredump@onyx.nervosa.com [10.0.0.1]) by nervosa.com (8.7.4/nervosa.com.2) with SMTP id CAA03000 for ; Sun, 3 Mar 1996 02:03:35 -0800 (PST) Date: Sun, 3 Mar 1996 02:03:33 -0800 (PST) From: invalid opcode To: FreeBSD-current Subject: Another tmpfs bug in SunOS 4 (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk Hmm, could this be similar to our current problems with mv and panics? == Chris Layne ============================================================= == coredump@nervosa.com ================ http://www.nervosa.com/~coredump == ---------- Forwarded message ---------- Date: Sat, 2 Dec 1995 23:50:40 +0100 From: Arfst Ludwig To: Multiple recipients of list BUGTRAQ Subject: Another tmpfs bug in SunOS 4 Hi! Unprivileged users can crash the system such that a power down power up cyle is needed. Vulnerable OS is (at least) SunOS 4.1.3. With the right permissions (umask) the following sequence crahes the system. The kernel does not panic, nor the abort sequece enters the boot promt, the system is halted, need to power down. 8<------------------------- cut here ------------------------- user1> cd /tmp user1> mkdir foo user1> su user2 user2> mkdir foo/bar user2> touch foo/bar/{plop,blup} user2> exit user1> cd foo user1> mv bar .. 8<------------------------- cut here ------------------------- /tmp's permissons are drwxrwxrwt root wheel I have not explored this bug very much because of the ungracefully consequences. Workaround: Avoid using (the marvelous) TMPFS filesystems :-( or (IMHO even worse) switch to Solaris 2 ? Cheers, Arfst ______________________________________________________________________ __ (00) Arfst Ludwig \`\/ E-Mail: Arfst.Ludwig@luxor.in-berlin.de "" carpe diem From owner-freebsd-current Sun Mar 3 04:12:44 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA19660 for current-outgoing; Sun, 3 Mar 1996 04:12:44 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id EAA19655 for ; Sun, 3 Mar 1996 04:12:41 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id WAA23783; Sun, 3 Mar 1996 22:11:13 +1000 Date: Sun, 3 Mar 1996 22:11:13 +1000 From: Bruce Evans Message-Id: <199603031211.WAA23783@godzilla.zeta.org.au> To: coredump@nervosa.com, current@FreeBSD.org Subject: Re: Another tmpfs bug in SunOS 4 (fwd) Sender: owner-current@FreeBSD.org Precedence: bulk >Hmm, could this be similar to our current problems with mv and panics? >Subject: Another tmpfs bug in SunOS 4 No. These are similar to old and current problems with rename() in msdosfs. rename() is hard to implement. Bruce From owner-freebsd-current Sun Mar 3 10:24:41 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA06004 for current-outgoing; Sun, 3 Mar 1996 10:24:41 -0800 (PST) Received: from terra.stack.urc.tue.nl (terra.stack.urc.tue.nl [131.155.140.128]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA05999 for ; Sun, 3 Mar 1996 10:24:39 -0800 (PST) Received: from xaa.stack.urc.tue.nl (uucp@localhost) by terra.stack.urc.tue.nl (8.6.11) with UUCP id TAA08670 for freebsd-current@freebsd.org; Sun, 3 Mar 1996 19:24:29 +0100 Received: (from xaa@localhost) by xaa.stack.urc.tue.nl (8.7.4/8.6.12) id TAA00606 for freebsd-current@freebsd.org; Sun, 3 Mar 1996 19:02:04 +0100 (MET) From: Mark Huizer Message-Id: <199603031802.TAA00606@xaa.stack.urc.tue.nl> Subject: sysctl - bus error To: freebsd-current@freebsd.org Date: Sun, 3 Mar 1996 19:02:03 +0100 (MET) Reply-To: xaa@stack.urc.tue.nl X-Mailer: ELM [version 2.4ME+ PL10 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org Precedence: bulk Hmm... with my current kernel (CTM: src-cur.1544.gz) and with a 2 hour old make world, my sysctl is giving me bus errors: # sysctl -a kern.ostype: FreeBSD kern.osrelease: 2.2-CURRENT kern.osrevision: 199306 kern.version: FreeBSD 2.2-CURRENT #0: Sun Mar 3 18:31:30 MET 1996 root@xaa.stack.urc.tue.nl:/mnt/usr2/src/sys/compile/XAA kern.maxvnodes: 1161 kern.maxproc: 180 kern.maxfiles: 360 kern.argmax: 65536 kern.securelevel: -1 kern.hostname: xaa.stack.urc.tue.nl kern.hostid: 0 kern.clockrate: { hz = 100, tick = 10000, profhz = 1024, stathz = 128 } kern.posix1version: 198808 kern.ngroups: 16 kern.job_control: 1 kern.saved_ids: 1 kern.boottime: { sec = 825874628, usec = 710000 } Bus error Any clues how this happens??? Mark ---xaa@stack.urc.tue.nl----huizer@circlesoft.nl----rcbamh@urc.tue.nl--- with so many things to say, and no one to talk to From owner-freebsd-current Sun Mar 3 12:14:27 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA11147 for current-outgoing; Sun, 3 Mar 1996 12:14:27 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA11141 for ; Sun, 3 Mar 1996 12:14:22 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA04509; Sun, 3 Mar 1996 13:10:58 -0700 From: Terry Lambert Message-Id: <199603032010.NAA04509@phaeton.artisoft.com> Subject: Re: Another tmpfs bug in SunOS 4 (fwd) To: coredump@nervosa.com (invalid opcode) Date: Sun, 3 Mar 1996 13:10:57 -0700 (MST) Cc: current@FreeBSD.org In-Reply-To: from "invalid opcode" at Mar 3, 96 02:03:33 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org Precedence: bulk > Hmm, could this be similar to our current problems with mv and panics? > > == Chris Layne ============================================================= > == coredump@nervosa.com ================ http://www.nervosa.com/~coredump == > > ---------- Forwarded message ---------- > Date: Sat, 2 Dec 1995 23:50:40 +0100 > From: Arfst Ludwig > To: Multiple recipients of list BUGTRAQ > Subject: Another tmpfs bug in SunOS 4 > > Hi! > > Unprivileged users can crash the system such > that a power down power up cyle is needed. > > Vulnerable OS is (at least) SunOS 4.1.3. > > With the right permissions (umask) the following > sequence crahes the system. The kernel does not > panic, nor the abort sequece enters the boot > promt, the system is halted, need to power down. This is a problem with a starvation deadlock due to a problem in the implementation of the reeentrancy protections in the tmpfs in Solaris. This is a well known problem, and seems to result because of a bad lock placement in tmpfs, coupled with the fact that locks and mutexes in Solaris are not hierarchical in nature. I'd also say it results from Sun being unwilling to document the FS locking model, even internally. 8-|. Basically, this means that they can't detect a deadly embrace between the two locking systems when it occurs because they are incapable of computing transitive closure over the two graphs because their design is such that there is not a common root for both locking systems. This is not something we have to worry about now, and because we are well aware of the design issues in hierarchical locking for kernel multithreading and exception/interrupt reentrancy, it's something we will be avoiding when we get to SMP/kernel threading anyway. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Sun Mar 3 12:14:58 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA11179 for current-outgoing; Sun, 3 Mar 1996 12:14:58 -0800 (PST) Received: from PBINET.com (chumash.snfc21.pbi.net [206.13.28.17]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id MAA11172 for ; Sun, 3 Mar 1996 12:14:56 -0800 (PST) Received: from bitch.Lamb.net (root@ppp-3-11.okld03.pbinet.com [206.170.3.11]) by PBINET.com (8.7.1/8.7.1) with ESMTP id MAA16171; Sun, 3 Mar 1996 12:14:44 -0800 (PST) Received: (from ulf@localhost) by bitch.Lamb.net (8.7.4/8.6.12) id MAA01695; Sun, 3 Mar 1996 12:16:28 -0800 (PST) Message-Id: <199603032016.MAA01695@bitch.Lamb.net> Subject: Re: sysctl - bus error To: xaa@stack.urc.tue.nl Date: Sun, 3 Mar 1996 12:16:17 -0800 (PST) From: "Ulf Zimmermann" Cc: freebsd-current@freebsd.org In-Reply-To: <199603031802.TAA00606@xaa.stack.urc.tue.nl> from "Mark Huizer" at Mar 3, 96 07:02:03 pm X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org Precedence: bulk > > Hmm... with my current kernel (CTM: src-cur.1544.gz) and with a 2 hour > old make world, my sysctl is giving me bus errors: > > # sysctl -a > > kern.ostype: FreeBSD > kern.osrelease: 2.2-CURRENT > kern.osrevision: 199306 > kern.version: FreeBSD 2.2-CURRENT #0: Sun Mar 3 18:31:30 MET 1996 > root@xaa.stack.urc.tue.nl:/mnt/usr2/src/sys/compile/XAA > > kern.maxvnodes: 1161 > kern.maxproc: 180 > kern.maxfiles: 360 > kern.argmax: 65536 > kern.securelevel: -1 > kern.hostname: xaa.stack.urc.tue.nl > kern.hostid: 0 > kern.clockrate: { hz = 100, tick = 10000, profhz = 1024, stathz = 128 } > kern.posix1version: 198808 > kern.ngroups: 16 > kern.job_control: 1 > kern.saved_ids: 1 > kern.boottime: { sec = 825874628, usec = 710000 } Bus error > > Any clues how this happens??? > > Mark > I have the same problems. My bus error is even earlier: bitch root /root #sysctl -a kern.ostype: FreeBSD kern.osrelease: 2.2-CURRENT kern.osrevision: 199306 kern.version: FreeBSD 2.2-CURRENT #0: Sat Mar 2 22:07:55 PST 1996 root@bitch:/usr/src/sys/compile/BITCH kern.maxvnodes: 3852 kern.maxproc: 180 kern.maxfiles: 360 kern.argmax: 65536 kern.securelevel: -1 kern.hostname: bitch kern.hostid: 0 kern.clockrate: { hz = 100, tick = 10000, profhz = 1024, stathz = 128 } Bus error Ulf. From owner-freebsd-current Sun Mar 3 12:38:39 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA12020 for current-outgoing; Sun, 3 Mar 1996 12:38:39 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id MAA12015 for ; Sun, 3 Mar 1996 12:38:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.4/8.6.9) with SMTP id MAA00349; Sun, 3 Mar 1996 12:37:39 -0800 (PST) To: "Ulf Zimmermann" cc: xaa@stack.urc.tue.nl, freebsd-current@freebsd.org Subject: Re: sysctl - bus error In-reply-to: Your message of "Sun, 03 Mar 1996 12:16:17 PST." <199603032016.MAA01695@bitch.Lamb.net> Date: Sun, 03 Mar 1996 12:37:38 -0800 Message-ID: <347.825885458@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org Precedence: bulk > I have the same problems. My bus error is even earlier: You guys must be out of sync somewhere. I have a complete make world and new kernel from this morning's -current and I can't reproduce the problem. > kern.osrevision: 199306 > kern.version: FreeBSD 2.2-CURRENT #0: Sat Mar 2 22:07:55 PST 1996 > root@bitch:/usr/src/sys/compile/BITCH Nice machine name. You have a BASTARD somewhere as well as a counterpart to this one? :-) Jordan From owner-freebsd-current Sun Mar 3 13:01:51 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA13028 for current-outgoing; Sun, 3 Mar 1996 13:01:51 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA13021 for ; Sun, 3 Mar 1996 13:01:46 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id IAA05368; Mon, 4 Mar 1996 08:00:41 +1100 Date: Mon, 4 Mar 1996 08:00:41 +1100 From: Bruce Evans Message-Id: <199603032100.IAA05368@godzilla.zeta.org.au> To: freebsd-current@FreeBSD.ORG, xaa@xaa.stack.urc.tue.nl Subject: Re: sysctl - bus error Sender: owner-current@FreeBSD.ORG Precedence: bulk >Hmm... with my current kernel (CTM: src-cur.1544.gz) and with a 2 hour >old make world, my sysctl is giving me bus errors: ># sysctl -a >... >kern.boottime: { sec = 825874628, usec = 710000 } Bus error >Any clues how this happens??? gdb says that it occurs in localtime.so.LC2. localtime.so.LC2 is the result of running "ld -r -x" to mutilate the symbol table in localtime.so. The error actually occurs in the static function tzload(). (The label _tzload is removed because it is static and the label LC2 is renamed because there is a bug.) The error occurs in code that used to work: _tzload: pushl %ebp movl %esp,%ebp subl $0x2328,%esp # lots of local variables pushl %edi # use a stack page that was just allocated The last instruction causes a SIGBUS. Bruce From owner-freebsd-current Sun Mar 3 16:11:49 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA21884 for current-outgoing; Sun, 3 Mar 1996 16:11:49 -0800 (PST) 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 QAA21865 for ; Sun, 3 Mar 1996 16:11:39 -0800 (PST) Received: from rabbit by mubo.augusta.de with uucp (Smail3.1.28.1 #1) id m0ttNrp-0008flC; Mon, 4 Mar 96 01:11 MEZ Received: by rabbit.augusta.de (Smail3.1.29.1 #1) id m0ttCal-0003QHC; Sun, 3 Mar 96 13:08 MET Message-Id: X-Mailer: exmh version 1.6.5 12/11/95 To: freebsd-current@FreeBSD.org Subject: My Date Problem (solved) Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Sun, 03 Mar 1996 13:08:47 +0100 From: Andreas Kohout Sender: owner-current@FreeBSD.org Precedence: bulk Hello, I compiled -current after the last SNAP and the Date problem is solved ... sorry -- Gruß, Andy -------------------------------------------------------------------------- Der Mensch hat die Atombombe erfunden, eine Maus würde niemals eine Mausefalle bauen! shanee@rabbit.augusta.de Zirbelnußtown __________________________________________________________________________ From owner-freebsd-current Sun Mar 3 16:12:07 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA21950 for current-outgoing; Sun, 3 Mar 1996 16:12:07 -0800 (PST) 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 QAA21944 for ; Sun, 3 Mar 1996 16:12:02 -0800 (PST) Received: from rabbit by mubo.augusta.de with uucp (Smail3.1.28.1 #1) id m0ttNrq-0008fpC; Mon, 4 Mar 96 01:11 MEZ Received: by rabbit.augusta.de (Smail3.1.29.1 #1) id m0ttJGb-0003QHC; Sun, 3 Mar 96 20:16 MET Message-Id: X-Mailer: exmh version 1.6.5 12/11/95 To: current@freebsd.org Subject: Some questions about compiling -current Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Sun, 03 Mar 1996 20:16:25 +0100 From: Andreas Kohout Sender: owner-current@freebsd.org Precedence: bulk Hello, yesterday I comppiled -current again and there are some questions: 1. while playing an Sun/NeXT audio data (and sometimes else) there is an output on the console: isa_dmastart: channel 1 busy Is this normal? 2. while compiling there is an error at termcap: ex - /usr/src/share/termcap/termcap.src < /usr/src/share/termcap/reorder with an error. If I do the same on the shell than it works fine, a ´make all install´ again run without errors. 3. at the beginning of make world the script changes the permission from /var/mail. But myy smail need 1777 at /var/mail. Is there anything with my smail? rabbit:/root# ll /usr/local/bin/smail -r-sr-xr-x 1 root bin 241664 19 Dez 16:24 /usr/local/bin/smail* 4. When should I compile -current? Every SNAP-Release or earlier? Thanks for your help ... -- Gruß, Andy -------------------------------------------------------------------------- Der Mensch hat die Atombombe erfunden, eine Maus würde niemals eine Mausefalle bauen! shanee@rabbit.augusta.de Zirbelnußtown __________________________________________________________________________ From owner-freebsd-current Sun Mar 3 18:38:48 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA27051 for current-outgoing; Sun, 3 Mar 1996 18:38:48 -0800 (PST) Received: from PBINET.com (chumash.snfc21.pbi.net [206.13.28.17]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id SAA27044 for ; Sun, 3 Mar 1996 18:38:45 -0800 (PST) Received: from bitch.Lamb.net (root@ppp-3-11.okld03.pbinet.com [206.170.3.11]) by PBINET.com (8.7.1/8.7.1) with ESMTP id SAA19726; Sun, 3 Mar 1996 18:38:33 -0800 (PST) Received: (from ulf@localhost) by bitch.Lamb.net (8.7.4/8.6.12) id SAA02280; Sun, 3 Mar 1996 18:40:17 -0800 (PST) Message-Id: <199603040240.SAA02280@bitch.Lamb.net> Subject: Re: sysctl - bus error To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Sun, 3 Mar 1996 18:40:06 -0800 (PST) From: "Ulf Zimmermann" Cc: xaa@stack.urc.tue.nl, freebsd-current@freebsd.org In-Reply-To: <347.825885458@time.cdrom.com> from "Jordan K. Hubbard" at Mar 3, 96 12:37:38 pm X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org Precedence: bulk > > > > I have the same problems. My bus error is even earlier: > > You guys must be out of sync somewhere. I have a complete make world > and new kernel from this morning's -current and I can't reproduce > the problem. My sup is from Friday 10 pm. I make world the night (started at midnight), made another sup at noon on saturday for the kernel sources, as there was a problem > > > kern.osrevision: 199306 > > kern.version: FreeBSD 2.2-CURRENT #0: Sat Mar 2 22:07:55 PST 1996 > > root@bitch:/usr/src/sys/compile/BITCH > > Nice machine name. You have a BASTARD somewhere as well as a > counterpart to this one? :-) > > Jordan not yet, but good idea :) Ulf. From owner-freebsd-current Sun Mar 3 21:37:16 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA05104 for current-outgoing; Sun, 3 Mar 1996 21:37:16 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id VAA05099 for ; Sun, 3 Mar 1996 21:37:13 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id QAA11603 for current@freebsd.org; Mon, 4 Mar 1996 16:11:54 +1030 From: Michael Smith Message-Id: <199603040541.QAA11603@genesis.atrad.adelaide.edu.au> Subject: XF86 3.1.2D under -current? To: current@freebsd.org Date: Mon, 4 Mar 1996 16:11:53 +1030 (CST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org Precedence: bulk Just wondering if anyone is running the current XFree beta under -current on an S3 card. I've got an interesting problem that I'd like to confirm before whining about it... (This is -current supped as of friday last). -- ]] 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 Mar 3 21:58:46 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA05495 for current-outgoing; Sun, 3 Mar 1996 21:58:46 -0800 (PST) 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 VAA05490 for ; Sun, 3 Mar 1996 21:58:37 -0800 (PST) Received: from grumble.grondar.za (mark@localhost [127.0.0.1]) by grumble.grondar.za (8.7.4/8.7.3) with ESMTP id HAA16715; Mon, 4 Mar 1996 07:55:58 +0200 (SAT) Message-Id: <199603040555.HAA16715@grumble.grondar.za> To: Andreas Kohout cc: current@freebsd.org Subject: Re: Some questions about compiling -current Date: Mon, 04 Mar 1996 07:55:57 +0200 From: Mark Murray Sender: owner-current@freebsd.org Precedence: bulk Andreas Kohout wrote: > yesterday I comppiled -current again and there are some questions: > > 1. while playing an Sun/NeXT audio data (and sometimes else) there is an > output on the console: isa_dmastart: channel 1 busy > > Is this normal? Dunno. I get this too. > 2. while compiling there is an error at termcap: > > ex - /usr/src/share/termcap/termcap.src < /usr/src/share/termcap/reorder > > with an error. If I do the same on the shell than it works fine, a ´make > all install´ again run without errors. This has been fixed now. > 3. at the beginning of make world the script changes the permission from > /var/mail. But myy smail need 1777 at /var/mail. Is there anything with my > smail? > > rabbit:/root# ll /usr/local/bin/smail > -r-sr-xr-x 1 root bin 241664 19 Dez 16:24 /usr/local/bin/smail* Yes. Having your maildir world writable is a _huge_ security hole. Do you have your own smail, or did you build it from ports? I believe the one in /usr/ports/mail/smail is OK. change to that directory and type "make". (put your smail source tarball in /usr/ports/distfiles first). > 4. When should I compile -current? Every SNAP-Release or earlier? Up to you. I do it about once a week if there have been enough changes. 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 Sun Mar 3 22:46:50 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA07655 for current-outgoing; Sun, 3 Mar 1996 22:46:50 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id WAA07645 for ; Sun, 3 Mar 1996 22:46:47 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id RAA12053; Mon, 4 Mar 1996 17:18:23 +1030 From: Michael Smith Message-Id: <199603040648.RAA12053@genesis.atrad.adelaide.edu.au> Subject: Re: Some questions about compiling -current To: mark@grondar.za (Mark Murray) Date: Mon, 4 Mar 1996 17:18:22 +1030 (CST) Cc: shanee@rabbit.augusta.de, current@freebsd.org In-Reply-To: <199603040555.HAA16715@grumble.grondar.za> from "Mark Murray" at Mar 4, 96 07:55:57 am MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org Precedence: bulk Mark Murray stands accused of saying: > > > 3. at the beginning of make world the script changes the permission from > > /var/mail. But myy smail need 1777 at /var/mail. Is there anything with my > > smail? > > > > rabbit:/root# ll /usr/local/bin/smail > > -r-sr-xr-x 1 root bin 241664 19 Dez 16:24 /usr/local/bin/smail* > > Yes. Having your maildir world writable is a _huge_ security hole. Do you > have your own smail, or did you build it from ports? I believe the one in > /usr/ports/mail/smail is OK. change to that directory and type "make". > (put your smail source tarball in /usr/ports/distfiles first). It's not actually quite so bad - Netscape requires this for its builtin movemail to work too. > Mark Murray -- ]] 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 Mar 3 23:13:03 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA08472 for current-outgoing; Sun, 3 Mar 1996 23:13:03 -0800 (PST) Received: from irz301.inf.tu-dresden.de ([141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA08460 for ; Sun, 3 Mar 1996 23:12:57 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id IAA02584 for ; Mon, 4 Mar 1996 08:12:52 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id IAA03372 for freebsd-current@FreeBSD.org; Mon, 4 Mar 1996 08:13:04 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id OAA01097 for freebsd-current@FreeBSD.org; Sat, 2 Mar 1996 14:11:27 +0100 (MET) From: J Wunsch Message-Id: <199603021311.OAA01097@uriah.heep.sax.de> Subject: Re: 2.2-960226-SNAP now on ftp.freebsd.org To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sat, 2 Mar 1996 14:11:26 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <13453.825450507@time.cdrom.com> from "Jordan K. Hubbard" at Feb 27, 96 11:48:27 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org Precedence: bulk As Jordan K. Hubbard wrote: > I've just popped a new 2.2-CURRENT snapshot up on the FTP site: > > ftp://ftp.freebsd.org/pub/FreeBSD/2.2-960226-SNAP/ > > All the basics seem to work in this release, though I had to disable > all the ethernet cards I wasn't using before my test system would come > up (it hung in the ep0 driver probe). It also seems to work without > the DES distribution, so that problem (from the last snap) would > appear to be gone. Things i've been noticing so far on my own SNAP(s): . /sbin/init and /bin/ed in the `filesys' are the DES versions. You might wanna care for this when releasing it on a CD. . A friend of mine has been reporting serious troubles with a pppd PPP server against IIJPPP clients (the server used to work fine with 2.1R). I've temporarily compile-time disabled CCP on his machine to get it at least running again. . root's .cshrc and .profile miss the ``stty erase ^h''. Alternat- ively, we should modify the VT initialization in syscons to enter the character emitted when hitting the <--- key as the default erase character into the termios structure. This would perhaps be the principle of least surprise: people who've been changing their keymap to use ^? for this character won't notice the change. . We need a compat2x distribution, and this one must be offered for installation when it comes to XFree86(tm). libc.so.2.2 must be in it. . Using the fixit floppy from any recent installation floppy silently resets the machine after the called program has been paged in from the (fixit) floppy. Using a 2.1R installation floppy instead works (with same fixit). . The installation floppy seems to miss allot of documentation that used to be there. Further, using the latest XFree86 betas against a -current system shows strange effects. Running the server with the (new) Xkb extension enabled immediately freezes the machine after the first couple of X clients popped up. Running without the extension only seldom freezes, but i can give a good bet in that ~ 50 % of all attempts to login my notebook via PPP (@ 115 kbps on a plain 16450 UART) would freeze it, too. I'm not yet sure whether to blame XFree86 or FreeBSD for these effects. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sun Mar 3 23:13:36 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA08530 for current-outgoing; Sun, 3 Mar 1996 23:13:36 -0800 (PST) Received: from irz301.inf.tu-dresden.de ([141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA08503 for ; Sun, 3 Mar 1996 23:13:29 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id IAA02572; Mon, 4 Mar 1996 08:12:46 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id IAA03365; Mon, 4 Mar 1996 08:12:57 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id NAA00942; Sat, 2 Mar 1996 13:46:53 +0100 (MET) From: J Wunsch Message-Id: <199603021246.NAA00942@uriah.heep.sax.de> Subject: Re: -current submitting policys To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sat, 2 Mar 1996 13:46:53 +0100 (MET) Cc: ejc@nasvr1.cb.att.com Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <9602281316.AA14142@ginger.cb.att.com> from "ejc@nasvr1.cb.att.com" at Feb 28, 96 08:16:57 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 Precedence: bulk As ejc@nasvr1.cb.att.com wrote: > This brings up a few questions at least for me. Should the code be > buildable and installable on the developers machine with the latest > -current before submitting? Should a code diff be inspected by > another peer before submitting? We are all humans only. Paul did follow all of this, he's been asking in -current before, and he had his change peer-reviewed, as you can see in the log message: revision 1.3 date: 1996/02/23 17:57:32; author: pst; state: Exp; lines: +2 -1 If a .db file is 0 length, initialize it as if it did not exist. Reviewed by: wollman Nevertheless, once used on much more than two machines, the real problems with it started popping up. You can hardly blame Paul for this accident, even though the consequences were fatal for a number of people. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sun Mar 3 23:13:51 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA08601 for current-outgoing; Sun, 3 Mar 1996 23:13:51 -0800 (PST) Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA08523 Sun, 3 Mar 1996 23:13:35 -0800 (PST) Received: by sequent.kiae.su id AA00141 (5.65.kiae-2 ); Mon, 4 Mar 1996 10:02:18 +0300 Received: by sequent.KIAE.su (UUMAIL/2.0); Mon, 4 Mar 96 10:02:17 +0300 Received: (from ache@localhost) by ache.dialup.ru (8.7.4/8.7.3) id KAA00703; Mon, 4 Mar 1996 10:01:18 +0300 (MSK) Message-Id: <199603040701.KAA00703@ache.dialup.ru> Subject: chpass not work: NIS wanted To: current@freebsd.org (FreeBSD-current) Date: Mon, 4 Mar 1996 10:01:18 +0300 (MSK) Cc: wpaul@freebsd.org 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+ PL11 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org Precedence: bulk #> chpass chpass: can't get name of master NIS server chpass: /etc/master.passwd: unchanged Please, fix it, I don't need/want/run any NIS. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-current Sun Mar 3 23:18:39 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA08776 for current-outgoing; Sun, 3 Mar 1996 23:18:39 -0800 (PST) Received: from irz301.inf.tu-dresden.de ([141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA08758 for ; Sun, 3 Mar 1996 23:18:35 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id IAA03082 for ; Mon, 4 Mar 1996 08:18:28 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id IAA03438 for freebsd-current@FreeBSD.org; Mon, 4 Mar 1996 08:18:39 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id OAA01111 for freebsd-current@FreeBSD.org; Sat, 2 Mar 1996 14:13:54 +0100 (MET) From: J Wunsch Message-Id: <199603021313.OAA01111@uriah.heep.sax.de> Subject: Re: 2.2-960226-SNAP now on ftp.freebsd.org To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sat, 2 Mar 1996 14:13:53 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <13453.825450507@time.cdrom.com> from "Jordan K. Hubbard" at Feb 27, 96 11:48:27 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org Precedence: bulk Addition: One of the guys i met on the GUUG meeting has been testing the SNAP that is on the GUUG CDROM (mid February SNAP). He praised that it was easy enough to install it, even without reading any documentation first :), but while the installation kernel worked fine, the _installed_ GENERIC kernel hung right at the (bogus) message that it was probing for PCI devices (which weren't there). -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sun Mar 3 23:18:45 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA08802 for current-outgoing; Sun, 3 Mar 1996 23:18:45 -0800 (PST) Received: from irz301.inf.tu-dresden.de ([141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA08792 for ; Sun, 3 Mar 1996 23:18:41 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id IAA03095 for ; Mon, 4 Mar 1996 08:18:30 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id IAA03440 for freebsd-current@FreeBSD.org; Mon, 4 Mar 1996 08:18:42 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id QAA00528 for freebsd-current@FreeBSD.org; Sat, 2 Mar 1996 16:19:52 +0100 (MET) From: J Wunsch Message-Id: <199603021519.QAA00528@uriah.heep.sax.de> Subject: fixit crashes for recent kernels To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sat, 2 Mar 1996 16:19:52 +0100 (MET) 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 Precedence: bulk I've found the culprit: Executing gzip'ed binaries does immediately reset any machine running a -current kernel. The binary on the fixit floppy is gzip'ed. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sun Mar 3 23:19:31 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA08904 for current-outgoing; Sun, 3 Mar 1996 23:19:31 -0800 (PST) Received: from irz301.inf.tu-dresden.de ([141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA08839 for ; Sun, 3 Mar 1996 23:18:55 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id IAA03145 for ; Mon, 4 Mar 1996 08:18:44 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id IAA03447; Mon, 4 Mar 1996 08:18:54 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id SAA06125; Sat, 2 Mar 1996 18:00:16 +0100 (MET) From: J Wunsch Message-Id: <199603021700.SAA06125@uriah.heep.sax.de> Subject: Re: processes wouldn't die (again) To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sat, 2 Mar 1996 18:00:15 +0100 (MET) Cc: charnier@lirmm.fr In-Reply-To: <199603010742.IAA28576@lirmm.lirmm.fr> from "Philippe Charnier" at Mar 1, 96 08:42:24 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 Precedence: bulk As Philippe Charnier wrote: > I didn't upgrade to current for a week to see if I can reproduce the bug. > installing float.h floatingpoint.h stdarg.h varargs.h > ===> rpcsvc > cd /usr/src/include/rpcsvc ; rpcgen -h yp.x -o /usr/src/include/rpcsvc/obj/yp.h ... > stopped for more than an hour, system is still alive and top reports: > 90 daemon 2 0 176K 0K select 0:00 0.00% 0.00% > 717 root -6 0 152K 200K piperd 0:00 0.00% 0.00% tee ^^^^^^ > 1754 root -20 0 480K 136K subpro 0:00 0.00% 0.00% sh You're suffering from a kernel with broken pipe code. Upgrade it. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sun Mar 3 23:46:39 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA09897 for current-outgoing; Sun, 3 Mar 1996 23:46:39 -0800 (PST) Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA09887 for ; Sun, 3 Mar 1996 23:46:26 -0800 (PST) Received: by sequent.kiae.su id AA12600 (5.65.kiae-2 for current@freebsd.org); Mon, 4 Mar 1996 10:39:35 +0300 Received: by sequent.KIAE.su (UUMAIL/2.0); Mon, 4 Mar 96 10:39:34 +0300 Received: (from ache@localhost) by ache.dialup.ru (8.7.4/8.7.3) id KAA00194 for current@freebsd.org; Mon, 4 Mar 1996 10:33:48 +0300 (MSK) Message-Id: <199603040733.KAA00194@ache.dialup.ru> Subject: panic when exit from X11 To: current@freebsd.org (FreeBSD-current) Date: Mon, 4 Mar 1996 10:33:48 +0300 (MSK) 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+ PL11 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org Precedence: bulk I last days I often got "page fault while in kernel mode" when exit from X. Stack looks like: pmap_clear_modify+0xbe: cmpl $0,0(%ecx,%eax,4) swap_pager_getpages vm_pager_get_pages vm_fault trap_pfault trap -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-current Mon Mar 4 00:01:36 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA10460 for current-outgoing; Mon, 4 Mar 1996 00:01:36 -0800 (PST) Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id AAA10447 for ; Mon, 4 Mar 1996 00:01:20 -0800 (PST) Received: by sequent.kiae.su id AA18863 (5.65.kiae-2 for current@freebsd.org); Mon, 4 Mar 1996 10:58:52 +0300 Received: by sequent.KIAE.su (UUMAIL/2.0); Mon, 4 Mar 96 10:58:52 +0300 Received: (from ache@localhost) by ache.dialup.ru (8.7.4/8.7.3) id KAA00356 for current@freebsd.org; Mon, 4 Mar 1996 10:58:26 +0300 (MSK) Message-Id: <199603040758.KAA00356@ache.dialup.ru> Subject: swapinfo _always_ show 100% swap occuped To: current@freebsd.org (FreeBSD-current) Date: Mon, 4 Mar 1996 10:58:26 +0300 (MSK) 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+ PL11 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org Precedence: bulk It is in 1days old -current. Somewhat breaks pstat. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-current Mon Mar 4 00:23:17 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA11531 for current-outgoing; Mon, 4 Mar 1996 00:23:17 -0800 (PST) Received: from irz401.inf.tu-dresden.de (irz401.inf.tu-dresden.de [141.76.1.12]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id AAA11522 for ; Mon, 4 Mar 1996 00:23:08 -0800 (PST) Received: from sax.sax.de by irz401.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id JAA06690 for ; Mon, 4 Mar 1996 09:20:41 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id JAA03921 for freebsd-current@FreeBSD.org; Mon, 4 Mar 1996 09:20:41 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id JAA09769 for freebsd-current@FreeBSD.org; Mon, 4 Mar 1996 09:05:03 +0100 (MET) From: J Wunsch Message-Id: <199603040805.JAA09769@uriah.heep.sax.de> Subject: Re: /etc/netstart and NFS /usr To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Mon, 4 Mar 1996 09:05:02 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199603012119.NAA24288@precipice.shockwave.com> from "Paul Traina" at Mar 1, 96 01:19:46 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 Precedence: bulk As Paul Traina wrote: > However, I had a "interesting" problem last night, and found that > having a standalone version of "mt(1)" very very very important > (thank god for /stand). When i've merged the functionality of the old st(8) program into mt(1), i've been asking this list about this. Funny, no response. People using a tape drive that is correctly supported by the driver, and who use only dump(8) to backup their files might not need it, but all other ones will love it. (The reason: correctly detected drives will operate with the right blocksize out of the box, and restore has an option to advance the tape to any tape file.) -- 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 Mar 4 01:09:51 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA14287 for current-outgoing; Mon, 4 Mar 1996 01:09:51 -0800 (PST) Received: from MediaCity.com (root@easy1.mediacity.com [205.216.172.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id BAA14282 for ; Mon, 4 Mar 1996 01:09:48 -0800 (PST) Received: (from brian@localhost) by MediaCity.com (8.6.11/8.6.9) id BAA18612; Mon, 4 Mar 1996 01:15:02 -0800 Message-Id: <199603040915.BAA18612@MediaCity.com> Subject: Re: new sio delays To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Mon, 4 Mar 1996 01:15:02 -0800 (PST) From: "Brian Litzinger" Cc: current@freefall.freebsd.org In-Reply-To: <199603030900.TAA06718@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Mar 3, 96 07:30:46 pm X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG Precedence: bulk > Some ISA 'internal modems' don't have real 8250-family UARTs, they attempt > to emulate them using their onboard processors. > > Most of these are quite slow at generating interrupts, and responding in > general, so waiting a while gives them time to react. > > Over the last six months or so, we've had a number of successful results > with these delays, hence bde committing them. > -- > ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ Is that why I no longer have to delete test 5 from sio.c to get my Cardinal PCMCIA modem to be recognized? -- Brian Litzinger Powered by FreeBSD http[s]://www.mpress.com speakfree.mpress.com [use -t (GSM)] How to program in c++: // Child Abuse: Denying a child a mother and a father From owner-freebsd-current Mon Mar 4 01:18:48 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA14798 for current-outgoing; Mon, 4 Mar 1996 01:18:48 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id BAA14793 for ; Mon, 4 Mar 1996 01:18:37 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id TAA12382; Mon, 4 Mar 1996 19:53:08 +1030 From: Michael Smith Message-Id: <199603040923.TAA12382@genesis.atrad.adelaide.edu.au> Subject: Re: new sio delays To: brian@easy1.mediacity.com (Brian Litzinger) Date: Mon, 4 Mar 1996 19:53:08 +1030 (CST) Cc: msmith@atrad.adelaide.edu.au, current@freefall.freebsd.org In-Reply-To: <199603040915.BAA18612@MediaCity.com> from "Brian Litzinger" at Mar 4, 96 01:15:02 am MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG Precedence: bulk Brian Litzinger stands accused of saying: > > > Some ISA 'internal modems' don't have real 8250-family UARTs, they attempt > > to emulate them using their onboard processors. > > > > Most of these are quite slow at generating interrupts, and responding in > > general, so waiting a while gives them time to react. > > > > Over the last six months or so, we've had a number of successful results > > with these delays, hence bde committing them. > > Is that why I no longer have to delete test 5 from sio.c to get my > Cardinal PCMCIA modem to be recognized? That's the general idea, yes. > Brian Litzinger -- ]] 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 Mar 4 01:54:40 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA17113 for current-outgoing; Mon, 4 Mar 1996 01:54:40 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id BAA17107 for ; Mon, 4 Mar 1996 01:54:35 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id KAA09080 for ; Mon, 4 Mar 1996 10:54:21 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id KAA04510 for freebsd-current@FreeBSD.org; Mon, 4 Mar 1996 10:54:21 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id KAA10981 for freebsd-current@FreeBSD.org; Mon, 4 Mar 1996 10:22:54 +0100 (MET) From: J Wunsch Message-Id: <199603040922.KAA10981@uriah.heep.sax.de> Subject: Re: Some questions about compiling -current To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Mon, 4 Mar 1996 10:22:54 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199603040648.RAA12053@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Mar 4, 96 05:18: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 Precedence: bulk As Michael Smith wrote: > > Yes. Having your maildir world writable is a _huge_ security hole. > It's not actually quite so bad - Netscape requires this for its builtin > movemail to work too. You've got it reverse. If Netcrap has got something broken, this doesn't make it a good reason. One more thing to avoid Netcrap... -- 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 Mar 4 01:57:38 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA17351 for current-outgoing; Mon, 4 Mar 1996 01:57:38 -0800 (PST) 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 BAA17268 for ; Mon, 4 Mar 1996 01:56:57 -0800 (PST) Received: from bunyip.cc.uq.oz.au by bunyip.cc.uq.oz.au id <29321-0@bunyip.cc.uq.oz.au>; Mon, 4 Mar 1996 19:56:51 +1000 Received: from netfl15a.devetir.qld.gov.au by pandora.devetir.qld.gov.au (8.6.10/DEVETIR-E0.3a) with ESMTP id TAA01699; Mon, 4 Mar 1996 19:56:35 +1000 Received: from localhost by netfl15a.devetir.qld.gov.au (8.6.8.1/DEVETIR-0.1) id KAA25671; Mon, 4 Mar 1996 10:00:07 GMT Message-Id: <199603041000.KAA25671@netfl15a.devetir.qld.gov.au> X-Mailer: exmh version 1.6.5 12/11/95 To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) cc: current@freebsd.org Subject: Re: 2.2-960226-SNAP now on ftp.freebsd.org In-reply-to: Your message of "Sat, 02 Mar 1996 14:11:26 +0100." <199603021311.OAA01097@uriah.heep.sax.de> 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: Mon, 04 Mar 1996 20:00:07 +1000 From: Stephen Hocking Sender: owner-current@freebsd.org Precedence: bulk > > Further, using the latest XFree86 betas against a -current system > shows strange effects. Running the server with the (new) Xkb > extension enabled immediately freezes the machine after the first > couple of X clients popped up. Running without the extension only > seldom freezes, but i can give a good bet in that ~ 50 % of all > attempts to login my notebook via PPP (@ 115 kbps on a plain 16450 > UART) would freeze it, too. I'm not yet sure whether to blame XFree86 > or FreeBSD for these effects. > > This is a known problem with the xkbd stuff - it's trampling memory somewhere & people are still trying to figure it out. It shows up more on FreeBSD than others becuase of Pohl's u-beaut space-saving-super-swift malloc code. A number of Xfree86 people and members of the X Consortium (Hi Kaleb) are working on it. Stephen -- I do not speak for the Worker's Compensation Board of Queensland - They don't pay me enough for that! From owner-freebsd-current Mon Mar 4 01:58:19 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA17432 for current-outgoing; Mon, 4 Mar 1996 01:58:19 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id BAA17425 for ; Mon, 4 Mar 1996 01:58:11 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id KAA09076 for ; Mon, 4 Mar 1996 10:54:20 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id KAA04509 for freebsd-current@FreeBSD.org; Mon, 4 Mar 1996 10:54:20 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id KAA00345 for freebsd-current@FreeBSD.org; Mon, 4 Mar 1996 10:36:23 +0100 (MET) From: J Wunsch Message-Id: <199603040936.KAA00345@uriah.heep.sax.de> Subject: Re: XF86 3.1.2D under -current? To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Mon, 4 Mar 1996 10:36:23 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199603040541.QAA11603@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Mar 4, 96 04:11:53 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org Precedence: bulk As Michael Smith wrote: > > Just wondering if anyone is running the current XFree beta under -current > on an S3 card. I've got an interesting problem that I'd like to confirm > before whining about it... You think of the freeze (or other) problems when Xkb is enabled? Are you on the xfree86-beta list? The problem is being discussed there, the reasons are still not clear. -- 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 Mar 4 02:23:38 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA18701 for current-outgoing; Mon, 4 Mar 1996 02:23:38 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id CAA18696 for ; Mon, 4 Mar 1996 02:23:32 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id LAA09880 for ; Mon, 4 Mar 1996 11:21:55 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id LAA04678 for freebsd-current@FreeBSD.org; Mon, 4 Mar 1996 11:21:32 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id KAA00737 for freebsd-current@FreeBSD.org; Mon, 4 Mar 1996 10:59:08 +0100 (MET) From: J Wunsch Message-Id: <199603040959.KAA00737@uriah.heep.sax.de> Subject: Re: panic when exit from X11 To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Mon, 4 Mar 1996 10:59:08 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199603040733.KAA00194@ache.dialup.ru> from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Mar 4, 96 10:33:48 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 Precedence: bulk As =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= wrote: > I last days I often got "page fault while in kernel mode" when > exit from X. > > Stack looks like: > pmap_clear_modify+0xbe: cmpl $0,0(%ecx,%eax,4) > swap_pager_getpages > vm_pager_get_pages > vm_fault > trap_pfault > trap Seems to be similar to the panics i've been experiencing with my kernel as of a week ago. I haven't tried again now, but this older kernel used to panic at various VM-related locations, not only when leaving X. -- 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 Mar 4 02:47:45 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA20125 for current-outgoing; Mon, 4 Mar 1996 02:47:45 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id CAA20119 for ; Mon, 4 Mar 1996 02:47:42 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id VAA08303; Mon, 4 Mar 1996 21:43:21 +1100 Date: Mon, 4 Mar 1996 21:43:21 +1100 From: Bruce Evans Message-Id: <199603041043.VAA08303@godzilla.zeta.org.au> To: freebsd-current@FreeBSD.ORG, j@uriah.heep.sax.de Subject: Re: 2.2-960226-SNAP now on ftp.freebsd.org Sender: owner-current@FreeBSD.ORG Precedence: bulk >. root's .cshrc and .profile miss the ``stty erase ^h''. Alternat- Lots of other things went missing. > ively, we should modify the VT initialization in syscons to enter > the character emitted when hitting the <--- key as the default erase > character into the termios structure. This would perhaps be the Also in pcvt. The default just happens to agree with , except possibly if the keymap has been modified. Bruce From owner-freebsd-current Mon Mar 4 04:27:58 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA26809 for current-outgoing; Mon, 4 Mar 1996 04:27:58 -0800 (PST) Received: from dyson.iquest.net ([198.70.144.127]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id EAA26804 for ; Mon, 4 Mar 1996 04:27:56 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.6.11/8.6.9) id HAA01182; Mon, 4 Mar 1996 07:22:37 GMT From: "John S. Dyson" Message-Id: <199603040722.HAA01182@dyson.iquest.net> Subject: Re: swapinfo _always_ show 100% swap occuped To: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Date: Mon, 4 Mar 1996 07:22:37 +0000 () Cc: current@freebsd.org In-Reply-To: <199603040758.KAA00356@ache.dialup.ru> from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Mar 4, 96 10:58:26 am X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org Precedence: bulk > > It is in 1days old -current. Somewhat breaks pstat. > Missed it, will fix tonite if someone else doesn't sooner. John From owner-freebsd-current Mon Mar 4 04:36:08 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA27290 for current-outgoing; Mon, 4 Mar 1996 04:36:08 -0800 (PST) Received: from gw1.att.com (gw1.att.com [192.20.239.133]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id EAA27261 for ; Mon, 4 Mar 1996 04:35:48 -0800 (PST) Received: from clipper.cb.att.com by ig2.att.att.com id AA10273; Mon, 4 Mar 96 07:36:49 EST Received: by clipper.cb.att.com (4.1/EMS-1.1 SunOS) id AA00134; Mon, 4 Mar 96 07:35:37 EST From: Daniel.M.Obrien@att.com Cc: ec0@ganet.net, ejc@naserver1.cb.att.com Received: from cbsky.cb.att.com by clipper.cb.att.com (4.1/EMS-1.1 SunOS) id AA00118; Mon, 4 Mar 96 07:35:33 EST Received: by cbsky.cb.att.com (5.x/EMS-1.1 client.cf 1/8/94 (SMI-4.1/SVR4)) id AA03513; Mon, 4 Mar 1996 07:35:33 -0500 Date: Mon, 4 Mar 1996 07:35:33 -0500 Original-From: dob@clipper.cb.att.com Message-Id: <9603041235.AA03513@cbsky.cb.att.com> To: freebsd-current@freebsd.org Subject: Re: Sig 11's on current Original-Cc: ec0@ganet.net, ejc@nasvr1.cb.att.com X-Sun-Charset: US-ASCII Sender: owner-current@freebsd.org Precedence: bulk > From: Keith Mitchell > Date: Sat, 2 Mar 1996 16:29:29 -0500 (EST) > Subject: Sig 11's on current > > I just compiled current (3/2) (just after some vm changes) and now I get > a bunch of SIG 10 and 11's, especially when compiling. Me too. I get sig 10/11 when trying to make top, bonnie, et.al. Top would compile, but make would core if I tried make install. Make blows up on Bonnie during the ``extraction'' phase. A kernel older than Saturday works fine. I'll check the exact times and dates of the good kernel and the SUPS when I get home tonight to see which change it is sensitive to. BTW: I have only 8 megs of memory. Seems to be load related. If I su to root it would fail consistently, but if I logged out and back in as root, it would work. That is how I got top to make and install. Bonnie, consistently fails either way. Peace, Dan O'Brien Lucent Technologies (Bell Labs) Columbus, OH USA From owner-freebsd-current Mon Mar 4 04:44:34 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA27803 for current-outgoing; Mon, 4 Mar 1996 04:44:34 -0800 (PST) Received: from MediaCity.com (root@easy1.mediacity.com [205.216.172.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id EAA27798 for ; Mon, 4 Mar 1996 04:44:32 -0800 (PST) Received: (from brian@localhost) by MediaCity.com (8.6.11/8.6.9) id EAA21030 for freebsd-current@freebsd.org; Mon, 4 Mar 1996 04:50:27 -0800 Message-Id: <199603041250.EAA21030@MediaCity.com> Subject: ranlib: libwhatever.a: Invalid argument To: freebsd-current@freebsd.org Date: Mon, 4 Mar 1996 04:50:27 -0800 (PST) From: "Brian Litzinger" X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org Precedence: bulk # ranlib libwhatever.a ranlib: libwhatever.a: Invalid argument I did a sup and make world yesterday. Then today I was building an app (happened to be SSLeay) and when it went to do a ranlib libcrypto.a I got the error message ranlib: libcrypto.a: Invalid argument Other apps that I have tried to build, such as Jim Lowe's multimedia stuff now suffer the same fate. What has gone awry? -- Brian Litzinger Powered by FreeBSD http[s]://www.mpress.com From owner-freebsd-current Mon Mar 4 05:24:16 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA29183 for current-outgoing; Mon, 4 Mar 1996 05:24:16 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id FAA29091 for ; Mon, 4 Mar 1996 05:23:02 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id OAA02536 for ; Mon, 4 Mar 1996 14:20:39 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id OAA06279 for freebsd-current@FreeBSD.org; Mon, 4 Mar 1996 14:20:37 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id NAA01205 for freebsd-current@FreeBSD.org; Mon, 4 Mar 1996 13:44:33 +0100 (MET) From: J Wunsch Message-Id: <199603041244.NAA01205@uriah.heep.sax.de> Subject: Re: 2.2-960226-SNAP now on ftp.freebsd.org To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Mon, 4 Mar 1996 13:44:33 +0100 (MET) In-Reply-To: <199603041043.VAA08303@godzilla.zeta.org.au> from "Bruce Evans" at Mar 4, 96 09:43:21 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 Precedence: bulk As Bruce Evans wrote: > > ively, we should modify the VT initialization in syscons to enter > > the character emitted when hitting the <--- key as the default erase > > character into the termios structure. This would perhaps be the > > Also in pcvt. The default just happens to agree with , > except possibly if the keymap has been modified. Agreed. I don't mind, as long as i don't need to tweak dozens of config files around the world. The current situation is a mess, the whole point is religuous, so we should do the best we can. It's more emerging for syscons, since this is the default console driver people are being faced with (single-user shell or fixit floppy come to mind). -- 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 Mar 4 05:28:56 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA29380 for current-outgoing; Mon, 4 Mar 1996 05:28:56 -0800 (PST) Received: from dyson.iquest.net ([198.70.144.127]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id FAA29370 for ; Mon, 4 Mar 1996 05:28:54 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.6.11/8.6.9) id IAA05192; Mon, 4 Mar 1996 08:24:53 GMT From: "John S. Dyson" Message-Id: <199603040824.IAA05192@dyson.iquest.net> Subject: Re: Sig 11's on current To: Daniel.M.Obrien@att.com Date: Mon, 4 Mar 1996 08:24:53 +0000 () Cc: ec0@ganet.net, ejc@naserver1.cb.att.com, freebsd-current@freebsd.org In-Reply-To: <9603041235.AA03513@cbsky.cb.att.com> from "Daniel.M.Obrien@att.com" at Mar 4, 96 07:35:33 am X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org Precedence: bulk > > > > From: Keith Mitchell > > Date: Sat, 2 Mar 1996 16:29:29 -0500 (EST) > > Subject: Sig 11's on current > > > > I just compiled current (3/2) (just after some vm changes) and now I get > > a bunch of SIG 10 and 11's, especially when compiling. > > Me too. I get sig 10/11 when trying to make top, bonnie, et.al. Top would > compile, but make would core if I tried make install. Make blows up on Bonnie > during the ``extraction'' phase. A kernel older than Saturday works fine. > I'll do some more complete testing on 6M and 8M machines tonite. John dyson@freebsd.org From owner-freebsd-current Mon Mar 4 05:42:11 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA00364 for current-outgoing; Mon, 4 Mar 1996 05:42:11 -0800 (PST) Received: from Sysiphos (Sysiphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id FAA00359 for ; Mon, 4 Mar 1996 05:42:04 -0800 (PST) Received: by Sysiphos id AA09676 (5.67b/IDA-1.5 for freebsd-current@FreeBSD.org); Mon, 4 Mar 1996 14:41:56 +0100 Message-Id: <199603041341.AA09676@Sysiphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Mon, 4 Mar 1996 14:41:56 +0100 In-Reply-To: J Wunsch "Re: 2.2-960226-SNAP now on ftp.freebsd.org" (Mar 2, 14:13) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Subject: Re: 2.2-960226-SNAP now on ftp.freebsd.org Cc: freebsd-current@freebsd.org (FreeBSD-current users) Sender: owner-current@freebsd.org Precedence: bulk On Mar 2, 14:13, J Wunsch wrote: } Subject: Re: 2.2-960226-SNAP now on ftp.freebsd.org } Addition: } } One of the guys i met on the GUUG meeting has been testing the SNAP } that is on the GUUG CDROM (mid February SNAP). He praised that it was } easy enough to install it, even without reading any documentation } first :), but while the installation kernel worked fine, the } _installed_ GENERIC kernel hung right at the (bogus) message that it } was probing for PCI devices (which weren't there). O well :( The probe code is identical in both cases (GENERIC or BOOTMFS) ... Hope you told him to send me detailed information ... 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 Mon Mar 4 09:24:47 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA15409 for current-outgoing; Mon, 4 Mar 1996 09:24:47 -0800 (PST) Received: from mail1.is.net (root@mail1.is.net [198.69.24.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA15404 for ; Mon, 4 Mar 1996 09:24:45 -0800 (PST) Received: from visual.is.net (visual.is.net [204.180.29.228]) by mail1.is.net (8.6.11/8.6.12) with SMTP id MAA01466 for ; Mon, 4 Mar 1996 12:19:23 -0500 Message-ID: <313ADFA5.41C67EA6@visual.is.net> Date: Mon, 04 Mar 1996 12:18:45 +0000 From: Adam Mitchell Organization: Adam Mitchell Consulting, Inc. X-Mailer: Mozilla 2.0 (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: mpool.c Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org Precedence: bulk Does anyone know when the mpool.c from lib/libc/db should be functional again? Or how I can get around it? I can't 'make world'. Thanks, AM From owner-freebsd-current Mon Mar 4 11:45:33 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA22420 for current-outgoing; Mon, 4 Mar 1996 11:45:33 -0800 (PST) Received: from jhome.DIALix.COM (jhome.DIALix.COM [192.203.228.69]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id LAA22415 for ; Mon, 4 Mar 1996 11:45:29 -0800 (PST) Received: from localhost.DIALix.oz.au (peter@localhost.DIALix.oz.au [127.0.0.1]) by jhome.DIALix.COM (8.7.4/8.7.3) with SMTP id DAA01144 for ; Tue, 5 Mar 1996 03:44:56 +0800 (WST) Message-Id: <199603041944.DAA01144@jhome.DIALix.COM> X-Authentication-Warning: jhome.DIALix.COM: Host peter@localhost.DIALix.oz.au [127.0.0.1] didn't use HELO protocol To: current@freebsd.org Subject: The Netscape/Linux emulator scrollbar bug exposed!!! :-) Date: Tue, 05 Mar 1996 03:44:55 +0800 From: Peter Wemm Sender: owner-current@freebsd.org Precedence: bulk Well, I'm afraid I'm going to do it.. I'm going to tell _what_ trivial bug was preventing the Netscape scrollbars being rendered when using Netscape-2.0 under the Linux emulator.. It's nothing grand, like the Motif botches, Netscape programming errors, signal emulation, select emulation, pipe write coalescing, socket code, lost Xserver events, phase of the moon, etc. :-) It's actually *unbelievably* trivial! :-) It is.. *drum roll*.... The Linux emulation of the time(2) syscall was getting an EFAULT for time(0) and returning zero instead of the correct time.... ***AAARRRGGGGHHHH!!!!*** I presume Netscape were simply calling time(0) in their main buzz-loop and once every second, they were rendering the scrollbar. Presumably the initial "last_time_rendered" variable was zero, so it was never drawn, because time(0) was returning zero.. *** SCREAM ***!! Yes, this ~10 character change is trivial enough to go into -stable.. :-) Cheers, -Peter From owner-freebsd-current Mon Mar 4 13:38:28 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA29871 for current-outgoing; Mon, 4 Mar 1996 13:38:28 -0800 (PST) Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id NAA29866 for ; Mon, 4 Mar 1996 13:38:26 -0800 (PST) Received: from localhost.shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.4/8.7.3) with SMTP id NAA03782; Mon, 4 Mar 1996 13:37:34 -0800 (PST) Message-Id: <199603042137.NAA03782@precipice.shockwave.com> To: Adam Mitchell cc: freebsd-current@FreeBSD.ORG Subject: Re: mpool.c In-reply-to: Your message of "Mon, 04 Mar 1996 12:18:45 GMT." <313ADFA5.41C67EA6@visual.is.net> Date: Mon, 04 Mar 1996 13:37:33 -0800 From: Paul Traina Sender: owner-current@FreeBSD.ORG Precedence: bulk It's fine, do make includes after a sup. From: Adam Mitchell Subject: mpool.c Does anyone know when the mpool.c from lib/libc/db should be functional again? Or how I can get around it? I can't 'make world'. Thanks, AM From owner-freebsd-current Mon Mar 4 15:58:28 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA10282 for current-outgoing; Mon, 4 Mar 1996 15:58:28 -0800 (PST) Received: from gw1.att.com (gw1.att.com [192.20.239.133]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA10259 for ; Mon, 4 Mar 1996 15:58:24 -0800 (PST) From: ejc@nasvr1.cb.att.com Received: from nasvr1.cb.att.com (naserver1.cb.att.com) by ig1.att.att.com id AA24638; Mon, 4 Mar 96 18:55:48 EST Received: by nasvr1.cb.att.com (5.x/EMS-1.1 Sol2) id AA06629; Mon, 4 Mar 1996 18:58:17 -0500 Cc: ejc@nasvr1.cb.att.com Received: from ginger.cb.att.com by nasvr1.cb.att.com (5.x/EMS-1.1 Sol2) id AA06623; Mon, 4 Mar 1996 18:58:12 -0500 Received: by ginger.cb.att.com (5.x/EMS-1.1 Sol2) id AA04466; Mon, 4 Mar 1996 19:01:44 -0500 Date: Mon, 4 Mar 1996 19:01:44 -0500 Message-Id: <9603050001.AA04466@ginger.cb.att.com> To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch), freebsd-current@FreeBSD.org (FreeBSD-current users) Original-Cc: ejc@nasvr1 Subject: Re: -current submitting policys Sender: owner-current@FreeBSD.org Precedence: bulk From owner-freebsd-current Mon Mar 4 16:09:01 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA10827 for current-outgoing; Mon, 4 Mar 1996 16:09:01 -0800 (PST) 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 QAA10822 for ; Mon, 4 Mar 1996 16:08:59 -0800 (PST) Received: from bunyip.cc.uq.oz.au by bunyip.cc.uq.oz.au id <23638-0@bunyip.cc.uq.oz.au>; Tue, 5 Mar 1996 10:05:19 +1000 Received: from netfl15a.devetir.qld.gov.au by pandora.devetir.qld.gov.au (8.6.10/DEVETIR-E0.3a) with ESMTP id JAA03440; Tue, 5 Mar 1996 09:40:53 +1000 Received: from localhost by netfl15a.devetir.qld.gov.au (8.6.8.1/DEVETIR-0.1) id XAA29449; Mon, 4 Mar 1996 23:44:25 GMT Message-Id: <199603042344.XAA29449@netfl15a.devetir.qld.gov.au> X-Mailer: exmh version 1.6.5 12/11/95 To: Adam Mitchell cc: current@freebsd.org Subject: Re: mpool.c In-reply-to: Your message of "Mon, 04 Mar 1996 12:18:45 GMT." <313ADFA5.41C67EA6@visual.is.net> 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: Tue, 05 Mar 1996 09:44:22 +1000 From: Stephen Hocking Sender: owner-current@freebsd.org Precedence: bulk > Does anyone know when the mpool.c from lib/libc/db should be functional > again? Or how I can get around it? I can't 'make world'. > Try doing a "make includes" from /usr/src first up. Actually, now's a good time for a make world. Stephen -- I do not speak for the Worker's Compensation Board of Queensland - They don't pay me enough for that! From owner-freebsd-current Mon Mar 4 17:44:12 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA16774 for current-outgoing; Mon, 4 Mar 1996 17:44:12 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id RAA16769 for ; Mon, 4 Mar 1996 17:44:08 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id SAA07309; Mon, 4 Mar 1996 18:41:02 -0700 From: Terry Lambert Message-Id: <199603050141.SAA07309@phaeton.artisoft.com> Subject: Re: -current submitting policys To: ejc@nasvr1.cb.att.com Date: Mon, 4 Mar 1996 18:41:01 -0700 (MST) Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-current@FreeBSD.ORG In-Reply-To: <9603050001.AA04466@ginger.cb.att.com> from "ejc@nasvr1.cb.att.com" at Mar 4, 96 07:01:44 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG Precedence: bulk > > > I can give you rule of thumb, re: the subject you sent. By default, UCB-style copyright/license is preferred. For mandatory kernel components, it is mandatory. For optional kernel components, it's recommended, but not required. It must be possible for a third party to put the code on CDROM, do any component providing base functionality must not have commercial use or distribution restrictions (the intent is to allow commercial use of the base system, if desired). Note that the current GPL'ed code in the source tree meets this criteria (it is allowable on a CDROM, it does not implement any mandary kernel components, and kernel components that are GPL'ed are loadable as modules to allow the choice to encumber to be made locally by the end user). Last time I checked, the web pages didn't cover this; Jordan probably needs to make an official policy statement and publish a URL. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Mon Mar 4 18:32:17 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA19935 for current-outgoing; Mon, 4 Mar 1996 18:32:17 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id SAA19929 for ; Mon, 4 Mar 1996 18:32:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.4/8.6.9) with SMTP id SAA26126; Mon, 4 Mar 1996 18:31:33 -0800 (PST) To: Terry Lambert cc: ejc@nasvr1.cb.att.com, joerg_wunsch@uriah.heep.sax.de, freebsd-current@FreeBSD.ORG Subject: Re: -current submitting policys In-reply-to: Your message of "Mon, 04 Mar 1996 18:41:01 MST." <199603050141.SAA07309@phaeton.artisoft.com> Date: Mon, 04 Mar 1996 18:31:33 -0800 Message-ID: <26123.825993093@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.ORG Precedence: bulk > Last time I checked, the web pages didn't cover this; Jordan > probably needs to make an official policy statement and publish > a URL. There's no unified statement, though I discuss some of our terms of preference in the submitter's guide. I suppose I could make an even more obvious top-level document available if people are missing this one (http://www.freebsd.org/handbook/submitters.html, section 17.2.4). Jordan From owner-freebsd-current Mon Mar 4 19:35:37 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id TAA24835 for current-outgoing; Mon, 4 Mar 1996 19:35:37 -0800 (PST) Received: from MediaCity.com (root@easy1.mediacity.com [205.216.172.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id TAA24826 for ; Mon, 4 Mar 1996 19:35:31 -0800 (PST) Received: (from brian@localhost) by MediaCity.com (8.6.11/8.6.9) id TAA14005 for freebsd-current@freebsd.org; Mon, 4 Mar 1996 19:41:30 -0800 Message-Id: <199603050341.TAA14005@MediaCity.com> Subject: Does NFS Version 3 stuff work? To: freebsd-current@freebsd.org Date: Mon, 4 Mar 1996 19:41:29 -0800 (PST) From: "Brian Litzinger" X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org Precedence: bulk Does the NFS Version 3 stuff work in -current? -- Brian Litzinger Powered by FreeBSD http[s]://www.mpress.com From owner-freebsd-current Tue Mar 5 01:22:09 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA13217 for current-outgoing; Tue, 5 Mar 1996 01:22:09 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id BAA13196 for ; Tue, 5 Mar 1996 01:21:48 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id KAA15888 for ; Tue, 5 Mar 1996 10:21:10 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id KAA23797 for freebsd-current@FreeBSD.org; Tue, 5 Mar 1996 10:21:09 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id KAA05299 for freebsd-current@FreeBSD.org; Tue, 5 Mar 1996 10:18:07 +0100 (MET) From: J Wunsch Message-Id: <199603050918.KAA05299@uriah.heep.sax.de> Subject: Re: 2.2-960226-SNAP now on ftp.freebsd.org To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Tue, 5 Mar 1996 10:18:06 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199603041341.AA09676@Sysiphos> from "Stefan Esser" at Mar 4, 96 02:41:56 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org Precedence: bulk As Stefan Esser wrote: > } ... while the installation kernel worked fine, the > } _installed_ GENERIC kernel hung right at the (bogus) message that it > } was probing for PCI devices (which weren't there). > > O well :( > > The probe code is identical > in both cases (GENERIC or > BOOTMFS) ... I know. I've also been surprised, it's the first time i've heard such a report. > Hope you told him to send > me detailed information ... ...or me. Let's see if he's coming back at us. -- 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 Mar 5 02:24:18 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA17198 for current-outgoing; Tue, 5 Mar 1996 02:24:18 -0800 (PST) Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id CAA17192 Tue, 5 Mar 1996 02:24:13 -0800 (PST) Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.7.4/8.6.9) id CAA11414; Tue, 5 Mar 1996 02:24:11 -0800 (PST) Date: Tue, 5 Mar 1996 02:24:11 -0800 (PST) Message-Id: <199603051024.CAA11414@silvia.HIP.Berkeley.EDU> To: jkh@freebsd.org CC: freebsd-current@freebsd.org In-reply-to: <199603021311.OAA01097@uriah.heep.sax.de> (message from J Wunsch on Sat, 2 Mar 1996 14:11:26 +0100 (MET)) Subject: Re: 2.2-960226-SNAP now on ftp.freebsd.org From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-current@freebsd.org Precedence: bulk I haven't tested the snap, but please make sure you include the ports/package paths as "/pub/FreeBSD/ports-current" and ".../packages-current". (Although many of the packages would fail due to libc.so.2.2 references right now.) By the way, packages-current was missing on wcarchive so I recreated the directory and copied all the packages over from my staging area on thud. Satoshi From owner-freebsd-current Tue Mar 5 02:49:46 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA18481 for current-outgoing; Tue, 5 Mar 1996 02:49:46 -0800 (PST) Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id CAA18475 Tue, 5 Mar 1996 02:49:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by Root.COM (8.6.12/8.6.5) with SMTP id CAA20307; Tue, 5 Mar 1996 02:49:55 -0800 Message-Id: <199603051049.CAA20307@Root.COM> X-Authentication-Warning: implode.Root.COM: Host localhost didn't use HELO protocol To: asami@cs.berkeley.edu (Satoshi Asami) cc: jkh@freebsd.org, freebsd-current@freebsd.org Subject: Re: 2.2-960226-SNAP now on ftp.freebsd.org From: David Greenman Reply-To: davidg@Root.COM Date: Tue, 05 Mar 1996 02:49:55 -0800 Sender: owner-current@freebsd.org Precedence: bulk >By the way, packages-current was missing on wcarchive so I recreated >the directory and copied all the packages over from my staging area on >thud. This happend when the FreeBSD filesystem got trashed due to a defective disk drive on wcarchive. I had to re-create the whole thing from our mirrors and SUP. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-current Tue Mar 5 02:58:05 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA18805 for current-outgoing; Tue, 5 Mar 1996 02:58:05 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id CAA18800 Tue, 5 Mar 1996 02:58:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.4/8.6.9) with SMTP id CAA03535; Tue, 5 Mar 1996 02:57:43 -0800 (PST) To: asami@cs.berkeley.edu (Satoshi Asami) cc: jkh@freebsd.org, freebsd-current@freebsd.org Subject: Re: 2.2-960226-SNAP now on ftp.freebsd.org In-reply-to: Your message of "Tue, 05 Mar 1996 02:24:11 PST." <199603051024.CAA11414@silvia.HIP.Berkeley.EDU> Date: Tue, 05 Mar 1996 02:57:43 -0800 Message-ID: <3533.826023463@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org Precedence: bulk > I haven't tested the snap, but please make sure you include the > ports/package paths as "/pub/FreeBSD/ports-current" and > ".../packages-current". Gotcha, though I may have to make a symlink for `packages' so that the package adding tool in sysinstall will work! :( Jordan From owner-freebsd-current Tue Mar 5 03:08:58 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA19680 for current-outgoing; Tue, 5 Mar 1996 03:08:58 -0800 (PST) Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id DAA19665 Tue, 5 Mar 1996 03:08:55 -0800 (PST) Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.7.4/8.6.9) id DAA11504; Tue, 5 Mar 1996 03:08:48 -0800 (PST) Date: Tue, 5 Mar 1996 03:08:48 -0800 (PST) Message-Id: <199603051108.DAA11504@silvia.HIP.Berkeley.EDU> To: jkh@time.cdrom.com CC: jkh@freebsd.org, freebsd-current@freebsd.org In-reply-to: <3533.826023463@time.cdrom.com> (jkh@time.cdrom.com) Subject: Re: 2.2-960226-SNAP now on ftp.freebsd.org From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-current@freebsd.org Precedence: bulk * Gotcha, though I may have to make a symlink for `packages' so * that the package adding tool in sysinstall will work! :( NO!!! The symlinks are pointing to ports-2.1/packages-2.1, and changing this will break the 2.1 release. Please don't touch those! Jordan, we went over this before, and I've also pointed it out on several occasions not to use that name. Besides, the "ports"/"packages" names should die (or at least not be used hard-coded in any install tool), and we are going to get rid of them as soon as 2.1R becomes obsolete (some time after 2.1.x is released, I guess). Satoshi From owner-freebsd-current Tue Mar 5 03:14:21 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA20281 for current-outgoing; Tue, 5 Mar 1996 03:14:21 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id DAA20276 Tue, 5 Mar 1996 03:14:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.4/8.6.9) with SMTP id DAA03804; Tue, 5 Mar 1996 03:14:01 -0800 (PST) To: asami@cs.berkeley.edu (Satoshi Asami) cc: jkh@freebsd.org, freebsd-current@freebsd.org Subject: Re: 2.2-960226-SNAP now on ftp.freebsd.org In-reply-to: Your message of "Tue, 05 Mar 1996 03:08:48 PST." <199603051108.DAA11504@silvia.HIP.Berkeley.EDU> Date: Tue, 05 Mar 1996 03:14:00 -0800 Message-ID: <3802.826024440@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org Precedence: bulk > * Gotcha, though I may have to make a symlink for `packages' so > * that the package adding tool in sysinstall will work! :( > > NO!!! The symlinks are pointing to ports-2.1/packages-2.1, and > changing this will break the 2.1 release. Please don't touch those! Huh?! I'm talking about on the CD, Satoshi! I can't call the packages collection on the CD packages-current and expect it to work, now can I? Not unless you've been hacking on sysinstall and hiding the commit messages! :-) > Jordan, we went over this before, and I've also pointed it out on > several occasions not to use that name. Besides, the Satoshi, I think you're very confused. Go to bed! :-) Jordan From owner-freebsd-current Tue Mar 5 03:31:48 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA21281 for current-outgoing; Tue, 5 Mar 1996 03:31:48 -0800 (PST) Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id DAA21275 Tue, 5 Mar 1996 03:31:43 -0800 (PST) Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.7.4/8.6.9) id DAA11603; Tue, 5 Mar 1996 03:31:30 -0800 (PST) Date: Tue, 5 Mar 1996 03:31:30 -0800 (PST) Message-Id: <199603051131.DAA11603@silvia.HIP.Berkeley.EDU> To: jkh@time.cdrom.com CC: jkh@freebsd.org, freebsd-current@freebsd.org In-reply-to: <3802.826024440@time.cdrom.com> (jkh@time.cdrom.com) Subject: Re: 2.2-960226-SNAP now on ftp.freebsd.org From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-current@freebsd.org Precedence: bulk * I'm talking about on the CD, Satoshi! I can't call the packages * collection on the CD packages-current and expect it to work, now * can I? Not unless you've been hacking on sysinstall and hiding * the commit messages! :-) Oh, the CD! Just call them ports/packages then, no need to use the names ports-current or packages-current. I was talking about the ftp install! By the way, when is the deadline for the CD? I'll try to rebuild as many packages as possible (because as I said, most of them were built pre- libc.3.0), but I've got a pretty busy schedule this week.... * > Jordan, we went over this before, and I've also pointed it out on * > several occasions not to use that name. Besides, the * * Satoshi, I think you're very confused. Go to bed! :-) Hee hee, you are the one who's confused, why should I care what you call the directories on the CD? :) I was talking about the ftp install all the way, and from what I see on packages.c, it seems like the problem is not fixed yet (I think you should just change one of the "%spackages/All" to "%spackages-current/All"...although I'm not sure at all.) Satoshi From owner-freebsd-current Tue Mar 5 05:03:12 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA24783 for current-outgoing; Tue, 5 Mar 1996 05:03:12 -0800 (PST) Received: from gw2.att.com (gw2.att.com [192.20.239.134]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id FAA24778 for ; Tue, 5 Mar 1996 05:03:01 -0800 (PST) From: ejc@nasvr1.cb.att.com Received: from nasvr1.cb.att.com (naserver1.cb.att.com) by ig1.att.att.com id AA06836; Tue, 5 Mar 96 08:00:21 EST Received: by nasvr1.cb.att.com (5.x/EMS-1.1 Sol2) id AA11088; Tue, 5 Mar 1996 08:02:49 -0500 Cc: ejc@nasvr1.cb.att.com, dob@nasvr1.cb.att.com Received: from ginger.cb.att.com by nasvr1.cb.att.com (5.x/EMS-1.1 Sol2) id AA11072; Tue, 5 Mar 1996 08:02:37 -0500 Received: by ginger.cb.att.com (5.x/EMS-1.1 Sol2) id AA06002; Tue, 5 Mar 1996 08:06:06 -0500 Date: Tue, 5 Mar 1996 08:06:06 -0500 Message-Id: <9603051306.AA06002@ginger.cb.att.com> To: freebsd-current@FreeBSD.org, joerg_wunsch@uriah.heep.sax.de Subject: Re: -current submitting policys Original-Cc: ejc@nasvr1, dob@nasvr1 X-Sun-Charset: US-ASCII Sender: owner-current@FreeBSD.org Precedence: bulk Hello My request for information on current development policies was in know way a judgement on Paul's quality of development. If my request was taken wrong, because of it's implicit connect to the previous -current make world failure, I would like to apologies to Paul. Paul I'm sorry if you took my post the wrong way, please continue your development on FreeBSD it is appreciated. On the other had I did not receive a single message on formal development policies for FreeBSD. I assume the policies for FreeBSD are then just personal development policies? Eric J. Chet (ejc@nasvr1.cb.att.com || ec0@ganet.net) Lucent Technologies, Bell Labs Columbus, Ohio > As ejc@nasvr1.cb.att.com wrote: > > > This brings up a few questions at least for me. Should the code be > > buildable and installable on the developers machine with the latest > > -current before submitting? Should a code diff be inspected by > > another peer before submitting? > > We are all humans only. Paul did follow all of this, he's been asking > in -current before, and he had his change peer-reviewed, as you can > see in the log message: > > revision 1.3 > date: 1996/02/23 17:57:32; author: pst; state: Exp; lines: +2 -1 > If a .db file is 0 length, initialize it as if it did not exist. > Reviewed by: wollman > > Nevertheless, once used on much more than two machines, the real > problems with it started popping up. You can hardly blame Paul for > this accident, even though the consequences were fatal for a number of > people. > > -- > 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 Mar 5 05:39:28 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA26008 for current-outgoing; Tue, 5 Mar 1996 05:39:28 -0800 (PST) Received: from asstdc.scgt.oz.au (asstdc.scgt.oz.au [202.14.234.65]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id FAA26003 Tue, 5 Mar 1996 05:39:20 -0800 (PST) Received: (from imb@localhost) by asstdc.scgt.oz.au (8.6.12/BSD4.4) id AAA14678; Wed, 6 Mar 1996 00:38:02 +1100 From: michael butler Message-Id: <199603051338.AAA14678@asstdc.scgt.oz.au> Subject: 2842 and the disappearing file-system :-( To: stable@freebsd.org, current@freebsd.org Date: Wed, 6 Mar 1996 00:38:00 +1100 (EST) X-Mailer: ELM [version 2.4 PL24beta] Content-Type: text Sender: owner-current@freebsd.org Precedence: bulk Without warning today, the recurrent collapse of -stable with "panic: inconsistent xxx queue" managed to trash my root file-system beyond recovery (/etc et al) and a substantial proportion of anything vaguely near a file-subsystem root directory (i.e. /var, /usr and /home are all separate file-systems and all were damaged to varying degrees). I presume that this was just particularly bad timing as there was significant activity on all of them at that moment (of the order of ~60 transfers second). After spending all day at this "game" (picking through a zillion remnants in lost+found directories and restoring what I could from tape), I've finally gotten this machine back to the point of being usable .. a fine effort for a "stable" system, if I might express some of my frustration ! This particular failure, as I mentioned before on the -stable list, is specific to the VESA controller (2842 rev C). It has never occurred with the BT542B and I've established that the "cheap" version (i.e. non-enhanced) of the Amd486DX4 that I'm using is only capable of running its internal cache in write-thru mode. My question is this .. since -stable is presently unusable unless I want to strangle my disk I/O (with news arriving at ~3 articles/second) and -release too buggy for "heavy-duty" use, is -current likely to be any better ? michael From owner-freebsd-current Tue Mar 5 08:43:23 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA07013 for current-outgoing; Tue, 5 Mar 1996 08:43:23 -0800 (PST) Received: from tcsi.tcs.com (tcsi.tcs.com [137.134.41.11]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id IAA07007 for ; Tue, 5 Mar 1996 08:43:20 -0800 (PST) Received: from phact.tcs.com (phact.tcs.com [137.134.41.99]) by tcsi.tcs.com (8.7.4/8.6.10) with ESMTP id IAA11773 for ; Tue, 5 Mar 1996 08:42:49 -0800 (PST) Received: from cozumel.tcs.com (cozumel.tcs.com [137.134.104.12]) by phact.tcs.com (8.6.10/8.6.10) with ESMTP id IAA03070 for ; Tue, 5 Mar 1996 08:42:48 -0800 From: Douglas Ambrisko Received: (ambrisko@localhost) by cozumel.tcs.com (8.6.10/8.6.10) id IAA01947 for freebsd-current@freebsd.org; Tue, 5 Mar 1996 08:41:27 -0800 Message-Id: <199603051641.IAA01947@cozumel.tcs.com> Subject: tip fix To: freebsd-current@freebsd.org Date: Tue, 5 Mar 1996 08:41:27 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-current@freebsd.org Precedence: bulk Here's a patch that fixes the problem with modem syncronization problems with tip. There are some hardwired timeouts that ignores the delay that you can set in the modem configuration file. The hard-wire delay is to short if the modem has to switch major modes and reset (ie going from fax to data mode with a reset). Now my modem transistions from HylaFax control to tip control and ppp mode without any problems. I would appreciate it if someone could apply it to current. Thanks, Doug A. *** unidialer.c.orig Tue May 30 04:13:22 1995 --- unidialer.c Sun Feb 4 12:05:19 1996 *************** *** 451,457 **** unidialer_modem_cmd (FD, init_string); ! if (!unidialer_get_okay (250)) goto badsynch; fflush (stdout); --- 451,457 ---- unidialer_modem_cmd (FD, init_string); ! if (!unidialer_get_okay (reset_delay)) goto badsynch; fflush (stdout); *************** *** 532,538 **** unidialer_modem_cmd (FD, escape_sequence); acu_nap (timeout_value); unidialer_modem_cmd (FD, hangup_command); ! okay = unidialer_get_okay (250); } if (!okay) { --- 532,538 ---- unidialer_modem_cmd (FD, escape_sequence); acu_nap (timeout_value); unidialer_modem_cmd (FD, hangup_command); ! okay = unidialer_get_okay (reset_delay); } if (!okay) { From owner-freebsd-current Tue Mar 5 10:15:25 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA12300 for current-outgoing; Tue, 5 Mar 1996 10:15:25 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA12295 Tue, 5 Mar 1996 10:15:23 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA08681; Tue, 5 Mar 1996 11:12:05 -0700 From: Terry Lambert Message-Id: <199603051812.LAA08681@phaeton.artisoft.com> Subject: Re: 2842 and the disappearing file-system :-( To: imb@scgt.oz.au (michael butler) Date: Tue, 5 Mar 1996 11:12:04 -0700 (MST) Cc: stable@FreeBSD.org, current@FreeBSD.org In-Reply-To: <199603051338.AAA14678@asstdc.scgt.oz.au> from "michael butler" at Mar 6, 96 00:38:00 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 Precedence: bulk > Without warning today, the recurrent collapse of -stable with "panic: > inconsistent xxx queue" managed to trash my root file-system beyond recovery > (/etc et al) and a substantial proportion of anything vaguely near a > file-subsystem root directory (i.e. /var, /usr and /home are all separate > file-systems and all were damaged to varying degrees). I presume that this > was just particularly bad timing as there was significant activity on all of > them at that moment (of the order of ~60 transfers second). Change: static int doasyncfree = 1; To: static int doasyncfree = 1; In /sys/ufs/ffs/ffs_alloc.c. This will resove the massive crash problem at some expense in synchronicity (the write clustering code pretty much sucks). > This particular failure, as I mentioned before on the -stable list, is > specific to the VESA controller (2842 rev C). It has never occurred with the > BT542B and I've established that the "cheap" version (i.e. non-enhanced) of > the Amd486DX4 that I'm using is only capable of running its internal cache > in write-thru mode. > > My question is this .. since -stable is presently unusable unless I want to > strangle my disk I/O (with news arriving at ~3 articles/second) and -release > too buggy for "heavy-duty" use, is -current likely to be any better ? Obviously your cache is not being updated correctly as a result of a DMA completion. Unfortunately, there is no way to compensate for bad motherboard wiring of cache notification pins other than to turn off the cache. All pentium motherboards with Saturn I (mask date prior to April 1994) chip sets can't maintain cache coherency on PCI -- ever wonder why the 60MHz Gateway systems were so cheap? Most VESA systems are worse, since they do not label information. Are you sure that the VESA controller is in a master slot? If it isn't, the VESA standard makes no guarantees regarding maintenance of cache coherency. Note that not all VESA motherboards even *have* master slots. For any given VESA system, it is most likely that the connector closest to the edge of the board is the master slot, if there is a master slot at all (VESA masters operate by stealing DRAM refresh cycles to achieve their high speed; you may need to adjust the bus on time down in the card setup, even if you correctly get it in a master slot -- Adaptec controllers are known to have aggressive bus-on times). In any case, it is a hardware problem related to bus mastering DMA and VESA, not a BSD problem. You may want to run an "advanced CMOS setup" or whatever passes for it in your BIOS, to ensure that you have a master slot and that mastering is enabled. You will *probably* need to run the Adaptec "bus-on time" setup, as described above. Alternately, jumper more wait states or go for 60 vs. 70ns RAM, etc. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Tue Mar 5 10:20:40 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA12834 for current-outgoing; Tue, 5 Mar 1996 10:20:40 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA12828 for ; Tue, 5 Mar 1996 10:20:38 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA08708; Tue, 5 Mar 1996 11:18:03 -0700 From: Terry Lambert Message-Id: <199603051818.LAA08708@phaeton.artisoft.com> Subject: Re: -current submitting policys To: ejc@nasvr1.cb.att.com Date: Tue, 5 Mar 1996 11:18:03 -0700 (MST) Cc: dob@nasvr1.cb.att.com, freebsd-current@FreeBSD.org, joerg_wunsch@uriah.heep.sax.de In-Reply-To: <9603051306.AA06002@ginger.cb.att.com> from "ejc@nasvr1.cb.att.com" at Mar 5, 96 08:06:06 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 Precedence: bulk > My request for information on current development policies > was in know way a judgement on Paul's quality of development. If my > request was taken wrong, because of it's implicit connect to the previous > -current make world failure, I would like to apologies to Paul. Paul I'm > sorry if you took my post the wrong way, please continue your development > on FreeBSD it is appreciated. > > On the other had I did not receive a single message on formal > development policies for FreeBSD. I assume the policies for FreeBSD are > then just personal development policies? Again: there are very few restrictions. The criteria I gave was a general set of guidelines which the members of the committer's list has been historically known to follow. Since one of the goals is (or should be; it's unstated) to allow as much participation as possible, and another is to allow commercial use of the Base OS and as much of the user space code as possible, you can pretty much derive everything I said from taking those two as axioms. Jordan has pointed out that there is a "submitters" section in the handbook (online at www.freebsd.org), and has stated that he is considering updating it with more formal information. Have you looked at the current criteria in the handbook today? I believe it is intentionally less formal than it could be to encourage as wide a set of participants as possible. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Tue Mar 5 10:32:24 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA13586 for current-outgoing; Tue, 5 Mar 1996 10:32:24 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA13578 for ; Tue, 5 Mar 1996 10:32:18 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA08730; Tue, 5 Mar 1996 11:29:18 -0700 From: Terry Lambert Message-Id: <199603051829.LAA08730@phaeton.artisoft.com> Subject: Re: Does NFS Version 3 stuff work? To: brian@easy1.mediacity.com (Brian Litzinger) Date: Tue, 5 Mar 1996 11:29:18 -0700 (MST) Cc: freebsd-current@FreeBSD.ORG In-Reply-To: <199603050341.TAA14005@MediaCity.com> from "Brian Litzinger" at Mar 4, 96 07:41:29 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG Precedence: bulk > Does the NFS Version 3 stuff work in -current? In my opinion: yes, with the caveat that you should not be using leases. The lease problem is, I think, related to the cache issue re: vnodes without associated inodes having their cache data flushed. Under heavy load, I believe leases would fail to do their job... in particular, a high vnode recycle rate (such as from a "find" on one or more clients) could cause a large race window. See the "xfs" discussion for more details. Obviously, I'd prefer the use of my FS patches as a whole, but there *are* some NFS related patches that eliminate at least two races that I know about combined with the nameifree reordering changes in the code where I caused a forced seperation of the FS interface abstraction from the underlying FS code. Finally, there are some known issues with the cookie code; the -hackers list archive of a discussion between myself and Doug Rabson on directory iteration restart without use of the "cookie" mechanism is applicable, if you want to work on resolving that. The cookie code is one of the big differences between FreeBSD and NetBSD implementations to get around the NFS wire vs. UFS storage encoding differences for the directory entry iteration interface used by the POSIX opendir/readdir/seekdir/telldir/closedir interface. The cookie issues are unrelated to the V3 code itself (except as it uses the cookies blindly, but they are opaque at that level), and the race conditions are issues with the underlying FS that NFS is calling to export file systems (and that's more a problem in the mount code and te recent "rename" race problems). If you have a problem finding any of the information, let me know; it will take me a while to get back to you on any request that large, but I could, eventually. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Tue Mar 5 11:03:58 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA15525 for current-outgoing; Tue, 5 Mar 1996 11:03:58 -0800 (PST) Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id LAA15515 Tue, 5 Mar 1996 11:03:51 -0800 (PST) Received: from localhost.shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.4/8.7.3) with SMTP id LAA16512; Tue, 5 Mar 1996 11:02:54 -0800 (PST) Message-Id: <199603051902.LAA16512@precipice.shockwave.com> To: ejc@nasvr1.cb.att.com cc: freebsd-current@FreeBSD.org, joerg_wunsch@uriah.heep.sax.de, dob@nasvr1.cb.att.com, committers@FreeBSD.org Subject: Paul's rules of order for committers (Re: -current submitting policys) In-reply-to: Your message of "Tue, 05 Mar 1996 08:06:06 EST." <9603051306.AA06002@ginger.cb.att.com> Date: Tue, 05 Mar 1996 11:02:54 -0800 From: Paul Traina Sender: owner-current@FreeBSD.org Precedence: bulk In no way did I take your message as a personal criticism. This was an example of someone following the intended procedure pretty well and blowing it totally nevertheless, which will occasionally happen. That's why it's -current. Now, for the record, let me state what I think the policy needs to be, and then throw it open for debate. I doubt there will be much. In one or two cases, I may mention specific events, these are for illustrative purposes only and in no way am I pointing fingers at people. (In fact, I'm doing this now because of my rather spectacular double-screw-up...no one can accuse me of taking the high road. :-) ). (a) don't break tree builds - try to do commits in an atomic fashion, minimize windows of vulnerablility if you can't be perfect (b) don't commit non-functional code - it's not ok to commit stuff that doesn't work. if you're working on something and want to let people know there is work-in-progress, just send mail to committers or current or hackers as appropriate. if you want people to test something, put it up separately for ftp - it's ok to commit stuff that doesn't quite work that is NEW, as long as it's not linked into the system -- this should only be done for collaborative efforts that are complex enough that using CVS as a go-between is a big win. (this is the exception rather than the rule). (c) code review code review code review - in a perfect world, EVERY commit should have two pairs of eyes go over it before it goes in... glasses don't count. - the world isn't perfect, so use your best judgement. If you're not familiar with the area you're touching, find one of the area gurus and coordinate with them, or, worst case, send a broadcast "please sanity check me" message to committers. - the more complex, the more important the code review - the code reviewer takes his or her job seriously, reviewing other people's code for errors is actually more important than writing code, don't do a half-assed job. At cisco, when someone introduces a bug the code reviewer takes as much negative energy as the author. (d) changes to fundamental semantics need to be announced BEFORE committing - don't pull the rug out from under people - don't change things just because you don't like it - don't make us more incompatible with 4.3, tahoe, BSDI, and NetBSD just because you don't "like" something (e) funky changes to the heart of the OS should get backed out if they're causing lots of grief - e.g. if a change to the kernel is made and things start breaking for a big number of people, back it out and test with the individuals. As an example, we had a -current kernel that was useless for almost a month because of bugs in an updated subsystem. This halts the development effort for everyone else, or, worse, causes people to do "blind" commits without adequate testing From: ejc@nasvr1.cb.att.com Subject: Re: -current submitting policys Hello My request for information on current development policies was in know way a judgement on Paul's quality of development. If my request was taken wrong, because of it's implicit connect to the previous -current make world failure, I would like to apologies to Paul. Paul I'm sorry if you took my post the wrong way, please continue your development on FreeBSD it is appreciated. On the other had I did not receive a single message on formal development policies for FreeBSD. I assume the policies for FreeBSD are then just personal development policies? Eric J. Chet (ejc@nasvr1.cb.att.com || ec0@ganet.net) Lucent Technologies, Bell Labs Columbus, Ohio > As ejc@nasvr1.cb.att.com wrote: > > > This brings up a few questions at least for me. Should the code be > > buildable and installable on the developers machine with the latest > > -current before submitting? Should a code diff be inspected by > > another peer before submitting? > > We are all humans only. Paul did follow all of this, he's been asking > in -current before, and he had his change peer-reviewed, as you can > see in the log message: > > revision 1.3 > date: 1996/02/23 17:57:32; author: pst; state: Exp; lines: +2 -1 > If a .db file is 0 length, initialize it as if it did not exist. > Reviewed by: wollman > > Nevertheless, once used on much more than two machines, the real > problems with it started popping up. You can hardly blame Paul for > this accident, even though the consequences were fatal for a number of > people. > > -- > cheers, J"org > > joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RI >>PE > Never trust an operating system you don't have sources for. ;-) > From owner-freebsd-current Tue Mar 5 11:05:20 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA15806 for current-outgoing; Tue, 5 Mar 1996 11:05:20 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA15799 Tue, 5 Mar 1996 11:05:18 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0tu22o-0003wrC; Tue, 5 Mar 96 11:05 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id TAA04329; Tue, 5 Mar 1996 19:05:12 GMT X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: Terry Lambert cc: imb@scgt.oz.au (michael butler), stable@FreeBSD.org, current@FreeBSD.org Subject: Re: 2842 and the disappearing file-system :-( In-reply-to: Your message of "Tue, 05 Mar 1996 11:12:04 MST." <199603051812.LAA08681@phaeton.artisoft.com> Date: Tue, 05 Mar 1996 19:05:10 +0000 Message-ID: <4327.826052710@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@FreeBSD.org Precedence: bulk > > Without warning today, the recurrent collapse of -stable with "panic: > > inconsistent xxx queue" managed to trash my root file-system beyond recover y > > (/etc et al) and a substantial proportion of anything vaguely near a > > file-subsystem root directory (i.e. /var, /usr and /home are all separate > > file-systems and all were damaged to varying degrees). I presume that this > > was just particularly bad timing as there was significant activity on all o f > > them at that moment (of the order of ~60 transfers second). > > Change: > static int doasyncfree = 1; > > To: > static int doasyncfree = 1; You forgot to mention that you patented this fix ? -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Tue Mar 5 11:53:01 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA18850 for current-outgoing; Tue, 5 Mar 1996 11:53:01 -0800 (PST) Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA18831 Tue, 5 Mar 1996 11:52:56 -0800 (PST) Message-Id: <199603051952.LAA18831@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: Host localhost.cdrom.com [127.0.0.1] didn't use HELO protocol To: Terry Lambert cc: imb@scgt.oz.au (michael butler), stable@FreeBSD.org, current@FreeBSD.org Subject: Re: 2842 and the disappearing file-system :-( In-reply-to: Your message of "Tue, 05 Mar 1996 11:12:04 MST." <199603051812.LAA08681@phaeton.artisoft.com> Date: Tue, 05 Mar 1996 11:52:56 -0800 From: "Justin T. Gibbs" Sender: owner-current@FreeBSD.org Precedence: bulk >> This particular failure, as I mentioned before on the -stable list, is >> specific to the VESA controller (2842 rev C). It has never occurred with the >> BT542B and I've established that the "cheap" version (i.e. non-enhanced) of >> the Amd486DX4 that I'm using is only capable of running its internal cache >> in write-thru mode. >> >> My question is this .. since -stable is presently unusable unless I want to >> strangle my disk I/O (with news arriving at ~3 articles/second) and -release >> too buggy for "heavy-duty" use, is -current likely to be any better ? > >Obviously your cache is not being updated correctly as a result of >a DMA completion. > Actually this appears to be a bug in eisaconf as it affects all eisa scsi controllers at the moment. I'm looking into it, but the problem is not obvious and doesn't occur in -current. > > Terry Lambert > terry@lambert.org >--- >Any opinions in this posting are my own and not those of my present >or previous employers. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Tue Mar 5 12:17:30 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA20486 for current-outgoing; Tue, 5 Mar 1996 12:17:30 -0800 (PST) Received: from widget.xmission.com (root@widget.xmission.com [198.60.22.228]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA20474 Tue, 5 Mar 1996 12:17:23 -0800 (PST) Received: (from rlenk@localhost) by widget.xmission.com (8.6.12/8.6.12) id NAA06046; Tue, 5 Mar 1996 13:17:05 -0700 From: Ron Lenk Message-Id: <199603052017.NAA06046@widget.xmission.com> Subject: Re: 2842 and the disappearing file-system :-( To: imb@scgt.oz.au (michael butler) Date: Tue, 5 Mar 1996 13:17:04 -0700 (MST) Cc: stable@freebsd.org, current@freebsd.org In-Reply-To: <199603051338.AAA14678@asstdc.scgt.oz.au> from "michael butler" at Mar 6, 96 00:38:00 am 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 Precedence: bulk > Without warning today, the recurrent collapse of -stable with "panic: > inconsistent xxx queue" managed to trash my root file-system beyond recovery > (/etc et al) and a substantial proportion of anything vaguely near a > file-subsystem root directory (i.e. /var, /usr and /home are all separate > file-systems and all were damaged to varying degrees). I presume that this > was just particularly bad timing as there was significant activity on all of > them at that moment (of the order of ~60 transfers second). Well, I can tell you that you're not alone in seeing these particular problems with -stable and the 2842. I've seen the same types of panics and hang conditions with -stable for the last two months. ( since the import of the new ahc driver in Jan ) Fortunately, however, I have been using a 2.1-RELEASE kernel without incident ( up 15 days right now ), so I haven't seen any spectacular filesystem damage. In any case, others have mentioned the same kinds of panics, and not necessarily with the 2842. In particular, people with 1742 controllers have seen them as well. Rod Grimes mentioned in one message that he has not seen them on PCI systems, but rather only on EISA systems. ( This would make sense, since the 2842 appears acts like an EISA card ) Anyway, I've vented my frustration in the past, and have been more or less quiet about things, hoping that someone would come along and fix the problem. :) Ron -- Ron Lenk -- rlenk@xmission.com From owner-freebsd-current Tue Mar 5 12:20:36 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA20835 for current-outgoing; Tue, 5 Mar 1996 12:20:36 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id MAA20827 Tue, 5 Mar 1996 12:20:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.4/8.6.9) with SMTP id MAA04810; Tue, 5 Mar 1996 12:20:11 -0800 (PST) To: asami@cs.berkeley.edu (Satoshi Asami) cc: jkh@freebsd.org, freebsd-current@freebsd.org Subject: Re: 2.2-960226-SNAP now on ftp.freebsd.org In-reply-to: Your message of "Tue, 05 Mar 1996 03:31:30 PST." <199603051131.DAA11603@silvia.HIP.Berkeley.EDU> Date: Tue, 05 Mar 1996 12:20:11 -0800 Message-ID: <4808.826057211@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org Precedence: bulk > Oh, the CD! Just call them ports/packages then, no need to use the > names ports-current or packages-current. I was talking about the ftp > install! I know.. :-) I wasn't, of course. In fact, I'd no intention of even putting a -current packages collection up for the FTP SNAP (I've never made a practice of doing this up to now, after all), and was doing it only for the CD because a CD has all that space left over.. I think that trying to syncronize the SNAPs and the packages collection is a bit insane, actually, and I'd be perfectly happy just to copy the 2.1-RELEASE packages dir onto all of them and make sure that a compat21 distribution gets put together. > By the way, when is the deadline for the CD? I'll try to rebuild as > many packages as possible (because as I said, most of them were built > pre- libc.3.0), but I've got a pretty busy schedule this week.... I wouldn't waste the effort, to be honest. I'm going to be doing this too often for you to ever have a hope of keeping something as huge as the packages collection in sync, so why set a precedent you won't be able to keep? > Hee hee, you are the one who's confused, why should I care what you > call the directories on the CD? :) You shouldn't. :-) Believe me, if I thought that a -current version of the packages collection to go along with each SNAP CD was a practical goal, I'd have been talking to you a lot sooner than this! Jordan From owner-freebsd-current Tue Mar 5 12:39:59 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA22170 for current-outgoing; Tue, 5 Mar 1996 12:39:59 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA22160 Tue, 5 Mar 1996 12:39:45 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA08976; Tue, 5 Mar 1996 13:35:34 -0700 From: Terry Lambert Message-Id: <199603052035.NAA08976@phaeton.artisoft.com> Subject: Re: 2842 and the disappearing file-system :-( To: gibbs@freefall.freebsd.org (Justin T. Gibbs) Date: Tue, 5 Mar 1996 13:35:34 -0700 (MST) Cc: terry@lambert.org, imb@scgt.oz.au, stable@FreeBSD.org, current@FreeBSD.org In-Reply-To: <199603051952.LAA18831@freefall.freebsd.org> from "Justin T. Gibbs" at Mar 5, 96 11:52:56 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 Precedence: bulk > >> This particular failure, as I mentioned before on the -stable list, is > >> specific to the VESA controller (2842 rev C). It has never occurred with the > >> BT542B and I've established that the "cheap" version (i.e. non-enhanced) of > >> the Amd486DX4 that I'm using is only capable of running its internal cache > >> in write-thru mode. > >> > >> My question is this .. since -stable is presently unusable unless I want to > >> strangle my disk I/O (with news arriving at ~3 articles/second) and -release > >> too buggy for "heavy-duty" use, is -current likely to be any better ? > > > >Obviously your cache is not being updated correctly as a result of > >a DMA completion. > > > > Actually this appears to be a bug in eisaconf as it affects all > eisa scsi controllers at the moment. I'm looking into it, but the > problem is not obvious and doesn't occur in -current. He has a VESA controller... brain farts are contagious! Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Tue Mar 5 12:42:23 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA22486 for current-outgoing; Tue, 5 Mar 1996 12:42:23 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA22475 Tue, 5 Mar 1996 12:42:22 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA08990; Tue, 5 Mar 1996 13:37:02 -0700 From: Terry Lambert Message-Id: <199603052037.NAA08990@phaeton.artisoft.com> Subject: Re: 2842 and the disappearing file-system :-( To: phk@critter.tfs.com (Poul-Henning Kamp) Date: Tue, 5 Mar 1996 13:37:02 -0700 (MST) Cc: terry@lambert.org, imb@scgt.oz.au, stable@FreeBSD.org, current@FreeBSD.org In-Reply-To: <4327.826052710@critter.tfs.com> from "Poul-Henning Kamp" at Mar 5, 96 07:05:10 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org Precedence: bulk > > Change: > > static int doasyncfree = 1; > > > > To: > > static int doasyncfree = 1; > > You forgot to mention that you patented this fix ? Yes. I claim "trade secret" rights for this line of code, since it's obvious you applied the fix to the -current source. 8-). Of course that second '1' is supposed to be a '0'. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Tue Mar 5 12:42:26 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA22503 for current-outgoing; Tue, 5 Mar 1996 12:42:26 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id MAA22485 for ; Tue, 5 Mar 1996 12:42:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.4/8.6.9) with SMTP id MAA04917; Tue, 5 Mar 1996 12:40:51 -0800 (PST) To: ejc@nasvr1.cb.att.com cc: freebsd-current@FreeBSD.org, joerg_wunsch@uriah.heep.sax.de, dob@nasvr1.cb.att.com Subject: Re: -current submitting policys In-reply-to: Your message of "Tue, 05 Mar 1996 08:06:06 EST." <9603051306.AA06002@ginger.cb.att.com> Date: Tue, 05 Mar 1996 12:40:51 -0800 Message-ID: <4915.826058451@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.org Precedence: bulk > On the other had I did not receive a single message on formal > development policies for FreeBSD. I assume the policies for FreeBSD are > then just personal development policies? Well, no one has actually sat down and formulated a policy that one could print out and stick on the wall, but there is nonetheless a sort of collective policy that's enforced by the core team and understood by most of the developers who've been around for awhile. When I say it's "enforced", I also simply mean that if a developer commits something that offends enough people's sensibilities in some way, enough negative response is generated that the problem self-corrects. Once a developer has been around for awhile, and perhaps been on the receiving end of such negative feedback once or twice, they get a fairly clear picture of what's expected. If I had to describe these expectations in actual words, I'd probably make something like the following list: 1. Test your changes before committing them (this one really gets you slapped). 2. Obey existing the existing style conventions of code you modify - no gratutitous reformatting to fit your own personal style. Code you write yourself is a different matter, and only rarely is it deemed necessary to comment on this (e.g. if your style involves the elimination of all whitespace, you'll probably get at least one comment saying "yuck!!" :-). 3. If you're planning on making an extensive change, or one that will change the calling syntax of some function or utility, you must propose it in the freebsd-current mailing list first and give people a chance to comment on the wisdom of such a change. 4. Respect existing domains. If you know for a fact that Tom and Dick have been working away on the VM system, you should probably coordinate any plans of your own in this area with them. If you're not sure of the state of existing development in some area, ask first. No answer received in a reasonable time-frame can be taken as a "go ahead." 5. If you're not sure of the efficacy of your approach, have someone else agree to review it for you before committing it. This request can be sent to -current if you've not already got a "FreeBSD buddy" picked out (just like Scuba diving :-). 6. If you're really having problems coordinating some change, talk to the core team - that's what they're there for. And that's about it! Jordan From owner-freebsd-current Tue Mar 5 13:00:22 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA24212 for current-outgoing; Tue, 5 Mar 1996 13:00:22 -0800 (PST) Received: from skiddaw.elsevier.co.uk (skiddaw.elsevier.co.uk [193.131.222.60]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA24118 Tue, 5 Mar 1996 13:00:01 -0800 (PST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by skiddaw.elsevier.co.uk (8.6.12/8.6.12) with ESMTP id UAA15854; Tue, 5 Mar 1996 20:58:03 GMT Received: from tees by snowdon with SMTP (PP); Tue, 5 Mar 1996 20:55:29 +0000 Received: (from dpr@localhost) by tees (SMI-8.6/8.6.12) id UAA03676; Tue, 5 Mar 1996 20:58:12 GMT Date: Tue, 5 Mar 1996 20:58:12 GMT From: Paul Richards Message-Id: <199603052058.UAA03676@tees> To: imb@scgt.oz.au, terry@lambert.org Subject: Re: 2842 and the disappearing file-system :-( Cc: stable@FreeBSD.org, current@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: f2+qrXxeCIyV2zlga1uyIw== Sender: owner-current@FreeBSD.org Precedence: bulk > > Change: > static int doasyncfree = 1; > > To: > static int doasyncfree = 1; Not one of your most usefull pieces of advice Terry :-) From owner-freebsd-current Tue Mar 5 13:16:51 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA25244 for current-outgoing; Tue, 5 Mar 1996 13:16:51 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA25239 for ; Tue, 5 Mar 1996 13:16:47 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id IAA13187 for current@freebsd.org; Wed, 6 Mar 1996 08:16:43 +1100 Date: Wed, 6 Mar 1996 08:16:43 +1100 From: Bruce Evans Message-Id: <199603052116.IAA13187@godzilla.zeta.org.au> To: current@freebsd.org Subject: automatic DST adjustment in adjkerntz found harmful Sender: owner-current@freebsd.org Precedence: bulk adjkerntz screwed up the DST adjustment here in a novel way this year. The local DST rule changed from "Mar Sun >= 1" to "Mar lastSun". The timezone files were updated on freefall 7 hours (+-1 :-) after the bogus "Sun >= 1" came into effect, and I didn't update my /etc/localtime files until much later, so adjkerntz bogusly adjusted my hardware clocks at about 3:01am on Sunday 3. Bruce From owner-freebsd-current Tue Mar 5 13:21:21 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA25640 for current-outgoing; Tue, 5 Mar 1996 13:21:21 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA25633 for ; Tue, 5 Mar 1996 13:21:11 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id WAA17740 for ; Tue, 5 Mar 1996 22:21:02 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id WAA02005 for freebsd-current@FreeBSD.org; Tue, 5 Mar 1996 22:21:02 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id VAA07082 for freebsd-current@FreeBSD.org; Tue, 5 Mar 1996 21:51:36 +0100 (MET) From: J Wunsch Message-Id: <199603052051.VAA07082@uriah.heep.sax.de> Subject: Re: Paul's rules of order for committers (Re: -current submitting policys) To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Tue, 5 Mar 1996 21:51:36 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199603051902.LAA16512@precipice.shockwave.com> from "Paul Traina" at Mar 5, 96 11:02:54 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 Precedence: bulk As Paul Traina wrote: > Now, for the record, let me state what I think the policy needs to be, and > then throw it open for debate. I doubt there will be much. Good summary! (And not unrealistic... :) -- 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 Mar 5 13:21:38 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA25691 for current-outgoing; Tue, 5 Mar 1996 13:21:38 -0800 (PST) Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA25661 Tue, 5 Mar 1996 13:21:29 -0800 (PST) Message-Id: <199603052121.NAA25661@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: Host localhost.cdrom.com [127.0.0.1] didn't use HELO protocol To: Terry Lambert cc: imb@scgt.oz.au, stable@FreeBSD.org, current@FreeBSD.org Subject: Re: 2842 and the disappearing file-system :-( In-reply-to: Your message of "Tue, 05 Mar 1996 13:35:34 MST." <199603052035.NAA08976@phaeton.artisoft.com> Date: Tue, 05 Mar 1996 13:21:28 -0800 From: "Justin T. Gibbs" Sender: owner-current@FreeBSD.org Precedence: bulk >> Actually this appears to be a bug in eisaconf as it affects all >> eisa scsi controllers at the moment. I'm looking into it, but the >> problem is not obvious and doesn't occur in -current. > >He has a VESA controller... brain farts are contagious! He has a VESA controller that uses an EISA probe and so is also affected. > Terry Lambert > terry@lambert.org >--- >Any opinions in this posting are my own and not those of my present >or previous employers. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Tue Mar 5 13:51:36 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA28202 for current-outgoing; Tue, 5 Mar 1996 13:51:36 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA28184 for ; Tue, 5 Mar 1996 13:51:25 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id WAA18370 for ; Tue, 5 Mar 1996 22:51:15 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id WAA02650 for freebsd-current@FreeBSD.org; Tue, 5 Mar 1996 22:51:14 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id WAA07384 for freebsd-current@FreeBSD.org; Tue, 5 Mar 1996 22:47:47 +0100 (MET) From: J Wunsch Message-Id: <199603052147.WAA07384@uriah.heep.sax.de> Subject: Re: Fixit floppy (Was: Please Read This) To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Tue, 5 Mar 1996 22:47:46 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199603052052.UAA03670@tees> from "Paul Richards" at Mar 5, 96 08:52:33 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 Precedence: bulk As Paul Richards wrote: > To make matters worse, there isn't a very usefull fixit disk anywhere to > grab. The fixit image on the cdrom doesn't have a kernel on it! The kernel > on the install floppy is a bit weird :-) The suggested way of using the fixit floppy is to boot the install floppy, and select the fixit option. DON'T DO IT WITH A 2.2 INSTALL FLOPPY! The gzip execution code is currently *WAY* broken, you usually end up with a machine silently resetting. :-(( You can use a 2.1R installation floppy however, even against a newer fixit. The fixit floppy is still in need of some items, for example the protocols file, and a reasonable subset of /etc/services. Should you need a tweaked kernel in order to use the fixit floppy (but then again, NOT from 2.2-current!), simply newfs a floppy, stick the kernel there, boot it, and swap this floppy for the fixit one while the boot is proceeding. The fixit floppy should contain enough stuff to get you going... Aaaaie, sheesh, somebody removed /sbin/init from there. :-(( -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Tue Mar 5 14:21:58 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA00819 for current-outgoing; Tue, 5 Mar 1996 14:21:58 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA00806 for ; Tue, 5 Mar 1996 14:21:49 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id XAA19002 for ; Tue, 5 Mar 1996 23:21:47 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id XAA02883 for freebsd-current@FreeBSD.org; Tue, 5 Mar 1996 23:21:46 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id WAA07463 for freebsd-current@FreeBSD.org; Tue, 5 Mar 1996 22:58:56 +0100 (MET) From: J Wunsch Message-Id: <199603052158.WAA07463@uriah.heep.sax.de> Subject: Re: Fixit #2 To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Tue, 5 Mar 1996 22:58:56 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199603052141.IAA14098@godzilla.zeta.org.au> from "Bruce Evans" at Mar 6, 96 08:41:53 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 Precedence: bulk As Bruce Evans wrote: > I noticed the following bugs and limitations with this: > - it only mounts /dev/fd0, but I made my first fixit floppy for /dev/fd1 > and it was 5.25-3.5 inches too wide to fit in /dev/fd0 :-). sysinstall should also fsck it automagically if it cannot be mounted. This solves the problem when your machine died while the fixit was mounted. > - the utilities on the fixit floppy aren't anything like the ones I > would prefer, and there aren't enough of them although there's > plenty of room to spare. > > I'd prefer to have a bootable fixit floppy. Then there wouldn't be > room to spare. I'd prefere a semi-bootable fixit floppy. Everything that's needed for the actual system, but no kernel. This should still leave plenty of space. If the install floppy isn't good for you, you can always create a boot floppy by simply newfs'ing, and copying /kernel over to it. Then swap floppies while the boot is proceeding. (If you're paranoid, boot with -c, swap floppies, then type `q'.) There are more things missing, for example i'd like to see a simple ps(1) that's procfs-based. -- 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 Mar 5 14:39:39 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA02610 for current-outgoing; Tue, 5 Mar 1996 14:39:39 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id OAA02605 for ; Tue, 5 Mar 1996 14:39:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.4/8.6.9) with SMTP id OAA02241 for ; Tue, 5 Mar 1996 14:39:35 -0800 (PST) To: current@freebsd.org Subject: Another comment on the 2.2-960303-SNAP.. Date: Tue, 05 Mar 1996 14:39:35 -0800 Message-ID: <2239.826065575@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org Precedence: bulk I forgot to mention that the ATAPI driver is now standard in this snapshot, e.g. it's always enabled so there's only one boot floppy and one kernel. *Please* let me know if your IDE installation fails with this snapshot! We're still not 100% sure that it won't clobber functionality for some IDE drives or WD controllers, so it'd be nice to find out before going with this as a long-term default. Jordan From owner-freebsd-current Tue Mar 5 15:03:03 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA04218 for current-outgoing; Tue, 5 Mar 1996 15:03:03 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA04206 Tue, 5 Mar 1996 15:02:56 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA09308; Tue, 5 Mar 1996 15:57:28 -0700 From: Terry Lambert Message-Id: <199603052257.PAA09308@phaeton.artisoft.com> Subject: Re: 2842 and the disappearing file-system :-( To: gibbs@freefall.freebsd.org (Justin T. Gibbs) Date: Tue, 5 Mar 1996 15:57:28 -0700 (MST) Cc: terry@lambert.org, imb@scgt.oz.au, stable@FreeBSD.org, current@FreeBSD.org In-Reply-To: <199603052121.NAA25661@freefall.freebsd.org> from "Justin T. Gibbs" at Mar 5, 96 01:21: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 Precedence: bulk > >> Actually this appears to be a bug in eisaconf as it affects all > >> eisa scsi controllers at the moment. I'm looking into it, but the > >> problem is not obvious and doesn't occur in -current. > > > >He has a VESA controller... brain farts are contagious! > > He has a VESA controller that uses an EISA probe and so is > also affected. Ah. That's broken. 8-(. This must be a VESA/EISA box for it to see the EISA signature and hit the EISA code? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Tue Mar 5 15:27:23 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA06124 for current-outgoing; Tue, 5 Mar 1996 15:27:23 -0800 (PST) Received: from kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA06119 Tue, 5 Mar 1996 15:27:21 -0800 (PST) Received: from venus.mcs.com (root@Venus.mcs.com [192.160.127.92]) by kitten.mcs.com (8.6.12/8.6.9) with SMTP id RAA02881; Tue, 5 Mar 1996 17:27:09 -0600 Received: by venus.mcs.com (/\==/\ Smail3.1.28.1 #28.5) id ; Tue, 5 Mar 96 17:27 CST Message-Id: Subject: Re: 2842 and the disappearing file-system :-( To: rlenk@widget.xmission.com (Ron Lenk) Date: Tue, 5 Mar 1996 17:27:08 -0600 (CST) From: "Karl Denninger, MCSNet" Cc: imb@scgt.oz.au, stable@freebsd.org, current@freebsd.org In-Reply-To: <199603052017.NAA06046@widget.xmission.com> from "Ron Lenk" at Mar 5, 96 01:17:04 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@freebsd.org Precedence: bulk > > > Without warning today, the recurrent collapse of -stable with "panic: > > inconsistent xxx queue" managed to trash my root file-system beyond recovery > > (/etc et al) and a substantial proportion of anything vaguely near a > > file-subsystem root directory (i.e. /var, /usr and /home are all separate > > file-systems and all were damaged to varying degrees). I presume that this > > was just particularly bad timing as there was significant activity on all of > > them at that moment (of the order of ~60 transfers second). > > Well, I can tell you that you're not alone in seeing these particular > problems with -stable and the 2842. I've seen the same types of panics > and hang conditions with -stable for the last two months. ( since the > import of the new ahc driver in Jan ) Fortunately, however, I have been > using a 2.1-RELEASE kernel without incident ( up 15 days right now ), > so I haven't seen any spectacular filesystem damage. I have given up on 27xx EISA adapters under FreeBSD. I get hangs of different kinds, and a few panics. 1742s and the PCI boards seem to be fine so far. So long as the PCI situation holds, we can live with a broken EISA card for *new* machines. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity Modem: [+1 312 248-0900] | T1 from $600 monthly; speeds to DS-3 available Voice: [+1 312 803-MCS1] | 21 Chicagoland POPs, ISDN, 28.8, much more Fax: [+1 312 248-9865] | Email to "info@mcs.net" WWW: http://www.mcs.net/ ISDN - Get it here TODAY! | Home of Chicago's only FULL Clarinet feed! From owner-freebsd-current Tue Mar 5 15:33:10 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA06671 for current-outgoing; Tue, 5 Mar 1996 15:33:10 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id PAA06664 for ; Tue, 5 Mar 1996 15:33:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.4/8.6.9) with SMTP id PAA00320; Tue, 5 Mar 1996 15:32:55 -0800 (PST) To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) cc: freebsd-current@freebsd.org (FreeBSD-current users) Subject: Re: Fixit floppy (Was: Please Read This) In-reply-to: Your message of "Tue, 05 Mar 1996 22:47:46 +0100." <199603052147.WAA07384@uriah.heep.sax.de> Date: Tue, 05 Mar 1996 15:32:55 -0800 Message-ID: <318.826068775@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org Precedence: bulk > FLOPPY! The gzip execution code is currently *WAY* broken, you > usually end up with a machine silently resetting. :-(( Bleh! I guess we need to fix that! > The fixit floppy is still in need of some items, for example the > protocols file, and a reasonable subset of /etc/services. I'm happy to see commits to /usr/src/release/Makefile.. :-) Everything on the fixit floppy was really just what I thought to throw on there at the last minute, and I've put almost no time at all into trying to improve it. Given that I've never even used the fixit floppy myself (well, I've tested it but that's it), I'm really not the best person to decide how to make it the best possible resource. Jordan From owner-freebsd-current Tue Mar 5 15:34:45 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA06812 for current-outgoing; Tue, 5 Mar 1996 15:34:45 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id PAA06807 for ; Tue, 5 Mar 1996 15:34:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.4/8.6.9) with SMTP id PAA00341; Tue, 5 Mar 1996 15:34:28 -0800 (PST) To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) cc: freebsd-current@FreeBSD.org (FreeBSD-current users) Subject: Re: Fixit #2 In-reply-to: Your message of "Tue, 05 Mar 1996 22:58:56 +0100." <199603052158.WAA07463@uriah.heep.sax.de> Date: Tue, 05 Mar 1996 15:34:28 -0800 Message-ID: <339.826068868@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.org Precedence: bulk > I'd prefere a semi-bootable fixit floppy. Everything that's needed > for the actual system, but no kernel. This should still leave plenty See my previous message - feel free! :-) Jordan From owner-freebsd-current Tue Mar 5 15:35:05 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA06875 for current-outgoing; Tue, 5 Mar 1996 15:35:05 -0800 (PST) Received: from sunrise.cs.berkeley.edu (sunrise.CS.Berkeley.EDU [128.32.38.121]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA06860 Tue, 5 Mar 1996 15:35:01 -0800 (PST) Received: (from asami@localhost) by sunrise.cs.berkeley.edu (8.6.12/8.6.12) id PAA08565; Tue, 5 Mar 1996 15:37:01 -0800 Date: Tue, 5 Mar 1996 15:37:01 -0800 Message-Id: <199603052337.PAA08565@sunrise.cs.berkeley.edu> To: jkh@time.cdrom.com CC: jkh@freebsd.org, freebsd-current@freebsd.org In-reply-to: <4808.826057211@time.cdrom.com> (jkh@time.cdrom.com) Subject: Re: 2.2-960226-SNAP now on ftp.freebsd.org From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-current@freebsd.org Precedence: bulk * In fact, I'd no intention of even putting a -current packages * collection up for the FTP SNAP (I've never made a practice of doing * this up to now, after all), and was doing it only for the CD because a * CD has all that space left over.. The -current packages are already up there on wcarchive, you just need to fix the paths in sysinstall to get them! :) * I think that trying to syncronize the SNAPs and the packages * collection is a bit insane, actually, and I'd be perfectly happy just * to copy the 2.1-RELEASE packages dir onto all of them and make sure * that a compat21 distribution gets put together. Uuh...I don't think that's a very good idea. The packages-current subtree is exactly for purposes like this, why don't you just use that instead? It's probably in much better shape than 2.1R packages (in terms of running on a 2.2-* system), and most of the packages are already built at one time or another after 2.1R came out. I really can't think of any reason to use the 2.1R packages for the 2.2 snap.... * I wouldn't waste the effort, to be honest. I'm going to be doing this * too often for you to ever have a hope of keeping something as huge as * the packages collection in sync, so why set a precedent you won't be * able to keep? It's just that the libc change that occurred quite recently. The packages-current is quite well-synchronized to the ports-current tree, as I build the packages as soon as (I can after) I see the commit messages. So there really isn't much trouble keeping it in sync. The huge rush/freeze thing before the release is mainly due to my insisting that the packages be tested properly for a while, and for snap users, packages-current should be much better (later versions, more new ports, etc.). * Believe me, if I thought that a -current version of the packages * collection to go along with each SNAP CD was a practical goal, I'd * have been talking to you a lot sooner than this! Well, I think it's a practical goal, and even if we don't rebuild it right now, it should still work better than the 2.1R packages with your snap (which will require the old libc anyway). Convinced? :) Satoshi From owner-freebsd-current Tue Mar 5 15:40:03 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA07333 for current-outgoing; Tue, 5 Mar 1996 15:40:03 -0800 (PST) Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA07251 Tue, 5 Mar 1996 15:39:58 -0800 (PST) Message-Id: <199603052339.PAA07251@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: Host localhost.cdrom.com [127.0.0.1] didn't use HELO protocol To: Terry Lambert cc: imb@scgt.oz.au, stable@FreeBSD.org, current@FreeBSD.org Subject: Re: 2842 and the disappearing file-system :-( In-reply-to: Your message of "Tue, 05 Mar 1996 15:57:28 MST." <199603052257.PAA09308@phaeton.artisoft.com> Date: Tue, 05 Mar 1996 15:39:57 -0800 From: "Justin T. Gibbs" Sender: owner-current@FreeBSD.org Precedence: bulk >> >> Actually this appears to be a bug in eisaconf as it affects all >> >> eisa scsi controllers at the moment. I'm looking into it, but the >> >> problem is not obvious and doesn't occur in -current. >> > >> >He has a VESA controller... brain farts are contagious! >> >> He has a VESA controller that uses an EISA probe and so is >> also affected. > >Ah. That's broken. 8-(. This must be a VESA/EISA box for it to >see the EISA signature and hit the EISA code? The eisaconf code always probes for eisa ids if it is configured in your system. It hasn't caused any conflicts on any system that I've seen, and since we have at least one device driver that would have to copy the same probe code in order to work, I decied to make eisaconf work this way. > Terry Lambert > terry@lambert.org >--- >Any opinions in this posting are my own and not those of my present >or previous employers. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Tue Mar 5 16:35:19 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA10775 for current-outgoing; Tue, 5 Mar 1996 16:35:19 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id QAA10769 for ; Tue, 5 Mar 1996 16:35:13 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id LAA20694 for current@freebsd.org; Wed, 6 Mar 1996 11:08:42 +1030 From: Michael Smith Message-Id: <199603060038.LAA20694@genesis.atrad.adelaide.edu.au> Subject: More on the Linux emulator (problem?) To: current@freebsd.org Date: Wed, 6 Mar 1996 11:08:42 +1030 (CST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org Precedence: bulk Hiho, more Linuxulator stuff... I'm trying to track down a bogon, and in the process have come across something a bit weird : 199 idl RET write 324/0x144 199 idl CALL read(0x3,0xefbfcb18,0x20) 199 idl RET read -1 errno -11 Unknown error: -11 fd 3 is the connection to the X server. After this, it selects, and then reads successfully from fd 3. Shortly after this, the bogon occurs. (And I can't tell for sure if it's related or not, as the error message related to the bogon is rather vague.) Also, if anyone knows anything about the floating point environment under Linux; any commentary on differences that might cause problems would be handy. -- ]] 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 Mar 5 18:10:59 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA17514 for current-outgoing; Tue, 5 Mar 1996 18:10:59 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id SAA17507 for ; Tue, 5 Mar 1996 18:10:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.4/8.6.9) with SMTP id SAA00696; Tue, 5 Mar 1996 18:10:49 -0800 (PST) To: asami@cs.berkeley.edu (Satoshi Asami) cc: freebsd-current@freebsd.org Subject: Re: 2.2-960226-SNAP now on ftp.freebsd.org In-reply-to: Your message of "Tue, 05 Mar 1996 15:37:01 PST." <199603052337.PAA08565@sunrise.cs.berkeley.edu> Date: Tue, 05 Mar 1996 18:10:49 -0800 Message-ID: <694.826078249@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org Precedence: bulk > The -current packages are already up there on wcarchive, you just need > to fix the paths in sysinstall to get them! :) Hmmmm. Meaning that there needs to be some gross version-specific hack in sysinstall so that I don't need to keep ping-ponging back and forth between versions for 2.1.x and 2.2-x. Needless to say, I don't like this idea very much. If we're going to be doing this kind of thing as a general rule then we need to go to something more scientific, like ports-${VERSION} and packages-${VERSION} directories, or we need to put ports and packages *under* the release directories and stop offering them at the top in their own hierarchy. The current situation is simply gross. Jordan From owner-freebsd-current Tue Mar 5 18:18:39 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA18138 for current-outgoing; Tue, 5 Mar 1996 18:18:39 -0800 (PST) Received: from sunrise.cs.berkeley.edu (sunrise.CS.Berkeley.EDU [128.32.38.121]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id SAA18133 for ; Tue, 5 Mar 1996 18:18:36 -0800 (PST) Received: (from asami@localhost) by sunrise.cs.berkeley.edu (8.6.12/8.6.12) id SAA08786; Tue, 5 Mar 1996 18:20:42 -0800 Date: Tue, 5 Mar 1996 18:20:42 -0800 Message-Id: <199603060220.SAA08786@sunrise.cs.berkeley.edu> To: jkh@time.cdrom.com CC: freebsd-current@freebsd.org In-reply-to: <694.826078249@time.cdrom.com> (jkh@time.cdrom.com) Subject: Re: 2.2-960226-SNAP now on ftp.freebsd.org From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-current@freebsd.org Precedence: bulk * or we need to put ports and packages * *under* the release directories and stop offering them at the top in * their own hierarchy. The current situation is simply gross. Actually, I think this is what we did last time, and I thought you were pulling in the ports/packages from there until you send me a mail saying "Argh! The 2.1R sysinstall is pulling in the packages from the top level, and is getting the -current version!". :) Why don't we just move everything down one level? Wherever the top level directory is going to be (whether it's a snap or a release), we can just populate it with appropriate symlinks and everything's going to work like a snap (no pun intended). Satoshi From owner-freebsd-current Tue Mar 5 18:23:02 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA18588 for current-outgoing; Tue, 5 Mar 1996 18:23:02 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id SAA18583 for ; Tue, 5 Mar 1996 18:23:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.4/8.6.9) with SMTP id SAA00793; Tue, 5 Mar 1996 18:22:52 -0800 (PST) To: asami@cs.berkeley.edu (Satoshi Asami) cc: freebsd-current@freebsd.org Subject: Re: 2.2-960226-SNAP now on ftp.freebsd.org In-reply-to: Your message of "Tue, 05 Mar 1996 18:20:42 PST." <199603060220.SAA08786@sunrise.cs.berkeley.edu> Date: Tue, 05 Mar 1996 18:22:52 -0800 Message-ID: <791.826078972@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org Precedence: bulk > Actually, I think this is what we did last time, and I thought you > were pulling in the ports/packages from there until you send me a mail > saying "Argh! The 2.1R sysinstall is pulling in the packages from the > top level, and is getting the -current version!". :) Well yes, it was, but that was mainly because we hadn't coordinated our efforts so that everything's expectations were in line! :-) > Why don't we just move everything down one level? Wherever the > top level directory is going to be (whether it's a snap or a release) I agree totally. I can hack sysinstall right now to expect ports and packages dirs to be under ${RELNAME} and will do so. Jordan From owner-freebsd-current Tue Mar 5 20:11:48 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id UAA28690 for current-outgoing; Tue, 5 Mar 1996 20:11:48 -0800 (PST) Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id UAA28681 for ; Tue, 5 Mar 1996 20:11:44 -0800 (PST) Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.7.4/8.6.9) id UAA13392; Tue, 5 Mar 1996 20:11:30 -0800 (PST) Date: Tue, 5 Mar 1996 20:11:30 -0800 (PST) Message-Id: <199603060411.UAA13392@silvia.HIP.Berkeley.EDU> To: jkh@time.cdrom.com CC: freebsd-current@freebsd.org In-reply-to: <791.826078972@time.cdrom.com> (jkh@time.cdrom.com) Subject: Re: 2.2-960226-SNAP now on ftp.freebsd.org From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-current@freebsd.org Precedence: bulk * > Why don't we just move everything down one level? Wherever the * > top level directory is going to be (whether it's a snap or a release) * * I agree totally. I can hack sysinstall right now to expect ports * and packages dirs to be under ${RELNAME} and will do so. Cool cool. Satoshi From owner-freebsd-current Tue Mar 5 21:03:45 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA05499 for current-outgoing; Tue, 5 Mar 1996 21:03:45 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id VAA05481 for ; Tue, 5 Mar 1996 21:03:36 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id PAA23174 for current@freebsd.org; Wed, 6 Mar 1996 15:39:34 +1030 From: Michael Smith Message-Id: <199603060509.PAA23174@genesis.atrad.adelaide.edu.au> Subject: Re: More on the Linux emulator (problem?) To: current@freebsd.org Date: Wed, 6 Mar 1996 15:39:34 +1030 (CST) In-Reply-To: <199603060038.LAA20694@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Mar 6, 96 11:08:42 am MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org Precedence: bulk Michael Smith stands accused of saying: > > I'm trying to track down a bogon, and in the process have come across > something a bit weird : > > 199 idl RET write 324/0x144 > 199 idl CALL read(0x3,0xefbfcb18,0x20) > 199 idl RET read -1 errno -11 Unknown error: -11 > > fd 3 is the connection to the X server. After this, it selects, and > then reads successfully from fd 3. If this is at all hard, forget it. It's not a problem, but a bug in the application that bites it native under Linux as well. > Also, if anyone knows anything about the floating point environment under > Linux; any commentary on differences that might cause problems would be > handy. And on this topic I can happily reassure people that FP code for Linux appears to work 100% correct under FreeBSD as well. -- ]] 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 Mar 5 21:23:24 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA08847 for current-outgoing; Tue, 5 Mar 1996 21:23:24 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id VAA08818 for ; Tue, 5 Mar 1996 21:23:18 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id GAA00140 for ; Wed, 6 Mar 1996 06:23:16 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id GAA07270 for freebsd-current@FreeBSD.org; Wed, 6 Mar 1996 06:23:15 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id AAA08249 for freebsd-current@FreeBSD.org; Wed, 6 Mar 1996 00:51:17 +0100 (MET) From: J Wunsch Message-Id: <199603052351.AAA08249@uriah.heep.sax.de> Subject: Re: Fixit #2 To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Wed, 6 Mar 1996 00:51:17 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <339.826068868@time.cdrom.com> from "Jordan K. Hubbard" at Mar 5, 96 03:34:28 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org Precedence: bulk As Jordan K. Hubbard wrote: > > > I'd prefere a semi-bootable fixit floppy. Everything that's needed > > for the actual system, but no kernel. This should still leave plenty > > See my previous message - feel free! :-) Well, i didn't blame you on this. ;) Anyway, i don't have the time right now, and in particular cutting down /etc/services on the fly will be a bit of Makefile work. Ya'know, i'm the least one who would mind hacking the `release' Makefile. :) -- 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 Mar 5 21:27:28 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA09469 for current-outgoing; Tue, 5 Mar 1996 21:27:28 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id VAA09462 for ; Tue, 5 Mar 1996 21:27:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.4/8.6.9) with SMTP id VAA04967; Tue, 5 Mar 1996 21:27:16 -0800 (PST) To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) cc: freebsd-current@FreeBSD.org (FreeBSD-current users) Subject: Re: 2.2-960226-SNAP now on ftp.freebsd.org In-reply-to: Your message of "Sat, 02 Mar 1996 14:11:26 +0100." <199603021311.OAA01097@uriah.heep.sax.de> Date: Tue, 05 Mar 1996 21:27:14 -0800 Message-ID: <4961.826090034@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.org Precedence: bulk > . /sbin/init and /bin/ed in the `filesys' are the DES versions. You > might wanna care for this when releasing it on a CD. Thanks, Mark and I are looking into it. It's odd. > . A friend of mine has been reporting serious troubles with a pppd PPP > server against IIJPPP clients (the server used to work fine with > 2.1R). I've temporarily compile-time disabled CCP on his machine to > get it at least running again. Hmmmm! This one may not be fixed by the time the snap is regenerated. > . root's .cshrc and .profile miss the ``stty erase ^h''. Alternat- I've put them back for now.. > ively, we should modify the VT initialization in syscons to enter > the character emitted when hitting the <--- key as the default erase > character into the termios structure. This would perhaps be the > principle of least surprise: people who've been changing their > keymap to use ^? for this character won't notice the change. I agree, but in the meantime it's just 2 extra lines in the .login and .profile (.cshrc never contained a stty and should not have?). > . We need a compat2x distribution, and this one must be offered for > installation when it comes to XFree86(tm). libc.so.2.2 must be in > it. Would someone here care to make one? I always get stuck making the compat* dists, and there are always complaints! :-) > . Using the fixit floppy from any recent installation floppy silently > resets the machine after the called program has been paged in from > the (fixit) floppy. Using a 2.1R installation floppy instead works > (with same fixit). This is, I assume, the gzip problem? Poul-H? Help! > . The installation floppy seems to miss allot of documentation that > used to be there. Can you be more specific? > Further, using the latest XFree86 betas against a -current system > shows strange effects. Running the server with the (new) Xkb > extension enabled immediately freezes the machine after the first > couple of X clients popped up. Running without the extension only Interesting. I've never tried any of the betas, but this certainly leads me think that I'm better off not sticking 3.1.2D on there! :-) Jordan From owner-freebsd-current Tue Mar 5 23:12:06 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA26014 for current-outgoing; Tue, 5 Mar 1996 23:12:06 -0800 (PST) Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id XAA25942 for ; Tue, 5 Mar 1996 23:12:00 -0800 (PST) Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.7.4/8.6.9) id XAA15540; Tue, 5 Mar 1996 23:11:57 -0800 (PST) Date: Tue, 5 Mar 1996 23:11:57 -0800 (PST) Message-Id: <199603060711.XAA15540@silvia.HIP.Berkeley.EDU> To: current@freebsd.org Subject: funny "make" bug From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-current@freebsd.org Precedence: bulk This is on thud, with a kernel built about a month ago. === >> cat Makefile all: libfoo.a libfoo.a: foo.o ar -r $@ $? ranlib $@ foo.o: touch foo.o >> make touch foo.o ar -r libfoo.a foo.o ar: creating archive libfoo.a ranlib libfoo.a Malloc warning: free(): malloc() never got called. >> make ar -r libfoo.a ar: no archive members specified usage: ar -d [-Tv] archive file ... ar -m [-Tv] archive file ... ar -m [-abiTv] position archive file ... ar -p [-Tv] archive [file ...] ar -q [-cTv] archive file ... ar -r [-cuTv] archive file ... ar -r [-abciuTv] position archive file ... ar -t [-Tv] archive [file ...] ar -x [-ouTv] archive [file ...] *** Error code 1 Stop. >> ls -lT foo.o libfoo.a 0 -rw-r--r-- 1 asami asami 0 Mar 5 23:08:17 1996 foo.o 2 -rw-r--r-- 1 asami asami 136 Mar 5 23:08:18 1996 libfoo.a === Well, the "Malloc warning:" probably should be fixed in ranlib, but the main bug doesn't occur on my really-current machine. If it persists after a kernel rebuild, I'll send in a PR.... Satoshi From owner-freebsd-current Tue Mar 5 23:29:39 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA29031 for current-outgoing; Tue, 5 Mar 1996 23:29:39 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA29025 for ; Tue, 5 Mar 1996 23:29:35 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id SAA08278; Wed, 6 Mar 1996 18:22:29 +1100 Date: Wed, 6 Mar 1996 18:22:29 +1100 From: Bruce Evans Message-Id: <199603060722.SAA08278@godzilla.zeta.org.au> To: jkh@time.cdrom.com, joerg_wunsch@uriah.heep.sax.de Subject: Re: 2.2-960226-SNAP now on ftp.freebsd.org Cc: freebsd-current@FreeBSD.org Sender: owner-current@FreeBSD.org Precedence: bulk >> . root's .cshrc and .profile miss the ``stty erase ^h''. Alternat- >I've put them back for now.. >> ively, we should modify the VT initialization in syscons to enter >> ... >I agree, but in the meantime it's just 2 extra lines in the .login >and .profile (.cshrc never contained a stty and should not have?). It should only be run at login time, not every time a shell is started, so it should only be in .login and .profile. See Lite2 for unhacked versions. Bruce From owner-freebsd-current Tue Mar 5 23:40:47 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA01155 for current-outgoing; Tue, 5 Mar 1996 23:40:47 -0800 (PST) Received: from apollo.COSC.GOV (root@apollo.COSC.GOV [198.94.103.34]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id XAA01150 for ; Tue, 5 Mar 1996 23:40:45 -0800 (PST) Received: (from vince@localhost) by apollo.COSC.GOV (8.7.4/8.7.3) id XAA06448; Tue, 5 Mar 1996 23:40:42 -0800 (PST) Date: Tue, 5 Mar 1996 23:40:42 -0800 (PST) From: -Vince- To: current@FreeBSD.ORG Subject: chfn/chpass doesn't work Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG Precedence: bulk Hi everyone, After the March 4 -current build, chfn and chpass doesn't work when the passwd is on the local machine... root@apollo [11:38pm][/usr/home/vince] >> chpass chpass: can't get name ofmaster NIS server chpass: /etc/master.passwd: unchanged root@apollo [11:38pm][/usr/home/vince] >> chfn chfn: can't get name of master NIS server chfn: /etc/master.passwd: unchanged root@apollo [11:38pm][/usr/home/vince] >> Cheers, -Vince- vince@COSC.GOV - GUS Mailing Lists Admin - http://www.COSC.GOV/~vince UC Berkeley AstroPhysics - Electrical Engineering (Honorary B.S.) Chabot Observatory & Science Center - Board of Advisors Running FreeBSD - Real UN*X for Free! Linda Wong/Vivian Chow/Hacken Lee/Danny Chan/Priscilla Chan Fan Club Mailing Lists Admin From owner-freebsd-current Tue Mar 5 23:52:34 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA03246 for current-outgoing; Tue, 5 Mar 1996 23:52:34 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA03221 for ; Tue, 5 Mar 1996 23:52:28 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id SAA09666; Wed, 6 Mar 1996 18:50:15 +1100 Date: Wed, 6 Mar 1996 18:50:15 +1100 From: Bruce Evans Message-Id: <199603060750.SAA09666@godzilla.zeta.org.au> To: jhay@mikom.csir.co.za Subject: fixes for rename panic (round 1) Cc: freebsd-current@FreeBSD.ORG Sender: owner-current@FreeBSD.ORG Precedence: bulk The main cause of the panic is broken reference counting in certain error cases. relookup() calls vput(fdvp) when it fails, so callers must increment the reference count before calling relookup() and decrement it if relookup() doesn't fail. Not doing this caused v_usecount for the test directory to eventually become negative. relookup() fails when the `from' file went away. Different bad things happen if it went away and came back. Then relookup doesn't fail, but the wrong file or directory is removed. If a regular file went away and came back as a directory, then the file system is corrupted. Bruce *** ufs_vnops.c~ Sat Jan 20 06:57:41 1996 --- ufs_vnops.c Wed Mar 6 17:23:23 1996 *************** *** 866,870 **** panic("ufs_rename: lost from startdir"); fcnp->cn_nameiop = DELETE; ! (void) relookup(fdvp, &fvp, fcnp); return (VOP_REMOVE(fdvp, fvp, fcnp)); } --- 904,911 ---- panic("ufs_rename: lost from startdir"); fcnp->cn_nameiop = DELETE; ! VREF(fdvp); ! error = relookup(fdvp, &fvp, fcnp); ! if (error == 0) ! vrele(fdvp); return (VOP_REMOVE(fdvp, fvp, fcnp)); } *************** *** 953,958 **** --- 1005,1012 ---- panic("ufs_rename: lost to startdir"); error = relookup(tdvp, &tvp, tcnp); + VREF(tdvp); if (error) goto out; + vrele(tdvp); dp = VTOI(tdvp); xp = NULL; *************** *** 1101,1105 **** if ((fcnp->cn_flags & SAVESTART) == 0) panic("ufs_rename: lost from startdir"); ! (void) relookup(fdvp, &fvp, fcnp); if (fvp != NULL) { xp = VTOI(fvp); --- 1155,1162 ---- if ((fcnp->cn_flags & SAVESTART) == 0) panic("ufs_rename: lost from startdir"); ! VREF(fdvp); ! error = relookup(fdvp, &fvp, fcnp); ! if (error == 0) ! vrele(fdvp); if (fvp != NULL) { xp = VTOI(fvp); From owner-freebsd-current Wed Mar 6 00:51:56 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA17475 for current-outgoing; Wed, 6 Mar 1996 00:51:56 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id AAA17437 for ; Wed, 6 Mar 1996 00:51:43 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id JAA06279 for ; Wed, 6 Mar 1996 09:50:40 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id JAA12662 for freebsd-current@FreeBSD.org; Wed, 6 Mar 1996 09:50:39 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id JAA10302 for freebsd-current@FreeBSD.org; Wed, 6 Mar 1996 09:20:15 +0100 (MET) From: J Wunsch Message-Id: <199603060820.JAA10302@uriah.heep.sax.de> Subject: Re: Another comment on the 2.2-960303-SNAP.. To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Wed, 6 Mar 1996 09:20:15 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <2239.826065575@time.cdrom.com> from "Jordan K. Hubbard" at Mar 5, 96 02:39:35 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 Precedence: bulk As Jordan K. Hubbard wrote: [ATAPI] > *Please* let me know if your IDE installation fails with this > snapshot! IDE did work, but an attempt to access an ATAPI CD miserably failed. This was a Toshiba XM5, neither wdc0/drive 1 nor wdc1/ drive 0 did probe it successfully. This was with my ``GUUG'' SNAP which was about 2 weeks ahead of Jordan's. (For the curious: i had to assemble three machines, and have test- installed FreeBSD on them to prove the hardware works. Two of the machines were really Plug&Play -- the couple of SCSI machines. The IDE $%!@ took me about half an hour more. :) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Wed Mar 6 00:54:17 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA17957 for current-outgoing; Wed, 6 Mar 1996 00:54:17 -0800 (PST) Received: from apollo.COSC.GOV (root@apollo.COSC.GOV [198.94.103.34]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id AAA17946 for ; Wed, 6 Mar 1996 00:54:16 -0800 (PST) Received: (from vince@localhost) by apollo.COSC.GOV (8.7.4/8.7.3) id AAA07452; Wed, 6 Mar 1996 00:54:11 -0800 (PST) Date: Wed, 6 Mar 1996 00:54:11 -0800 (PST) From: -Vince- To: current@FreeBSD.ORG Subject: chpass Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG Precedence: bulk Sorry everyone but looks like a resup fixed the problem.. Cheers, -Vince- vince@COSC.GOV - GUS Mailing Lists Admin - http://www.COSC.GOV/~vince UC Berkeley AstroPhysics - Electrical Engineering (Honorary B.S.) Chabot Observatory & Science Center - Board of Advisors Running FreeBSD - Real UN*X for Free! Linda Wong/Vivian Chow/Hacken Lee/Danny Chan/Priscilla Chan Fan Club Mailing Lists Admin From owner-freebsd-current Wed Mar 6 01:27:52 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA27387 for current-outgoing; Wed, 6 Mar 1996 01:27:52 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id BAA26325 for ; Wed, 6 Mar 1996 01:24:27 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id KAA07624 for ; Wed, 6 Mar 1996 10:21:48 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id KAA12970 for freebsd-current@FreeBSD.org; Wed, 6 Mar 1996 10:21:47 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id KAA10635 for freebsd-current@FreeBSD.org; Wed, 6 Mar 1996 10:03:16 +0100 (MET) From: J Wunsch Message-Id: <199603060903.KAA10635@uriah.heep.sax.de> Subject: Re: 2.2-960226-SNAP now on ftp.freebsd.org To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Wed, 6 Mar 1996 10:03:15 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <4961.826090034@time.cdrom.com> from "Jordan K. Hubbard" at Mar 5, 96 09:27:14 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 Precedence: bulk As Jordan K. Hubbard wrote: > > . /sbin/init and /bin/ed in the `filesys' are the DES versions. You > > might wanna care for this when releasing it on a CD. > > Thanks, Mark and I are looking into it. It's odd. It's not too odd. Somebody (ache?) modified the Makefile to DTRT for a regular build environment. This involves building the DES versions only if /usr/src/secure exists. I've modified the Makefiles again to also build the non-DES version if ``RELEASEDIR'' is set (this is only the case while building a release), but the statically linked binaries using -lcrypt remain to be the DES-encumbered ones. You have to relink them somewhere after moving the DES versions away for the `des' distribution. /sbin/init and /bin/[r]ed are the only binaries statically linked against -lcrypt (to the best of my knowledge). > > . A friend of mine has been reporting serious troubles with a pppd PPP > > server against IIJPPP clients (the server used to work fine with > > 2.1R). I've temporarily compile-time disabled CCP on his machine to > > get it at least running again. > > Hmmmm! This one may not be fixed by the time the snap is regenerated. I've got a four-liner for review to Peter W. and Poul-Henning that simply closes down the CCP layer if no matching compression protocol could be negotiated. > I agree, but in the meantime it's just 2 extra lines in the .login > and .profile (.cshrc never contained a stty and should not have?). Don't forget /.profile, for the single-user shell. > > . We need a compat2x distribution, and this one must be offered for > > installation when it comes to XFree86(tm). libc.so.2.2 must be in > > it. > > Would someone here care to make one? I always get stuck making > the compat* dists, and there are always complaints! :-) Ick. (Shyly looking around to find a volunteer. Awww. Nobody pops up! Silently retreating from the scene, leaving the volunteers alone there. :-) > > . The installation floppy seems to miss allot of documentation that > > used to be there. > > Can you be more specific? I could select whatever menu item from the ``Documentation'' menu, and only got ``Sorry, this ain't here''. Of course, this was for my own SNAP, so if it's there in your version i assume you've done some extra work besides ``make release''? > > Further, using the latest XFree86 betas against a -current system > > shows strange effects. > Interesting. I've never tried any of the betas, but this certainly > leads me think that I'm better off not sticking 3.1.2D on there! :-) Wait for release time... -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Wed Mar 6 01:43:44 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA02153 for current-outgoing; Wed, 6 Mar 1996 01:43:44 -0800 (PST) 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 BAA02088 for ; Wed, 6 Mar 1996 01:43:32 -0800 (PST) Received: from grumble.grondar.za (mark@localhost [127.0.0.1]) by grumble.grondar.za (8.7.4/8.7.3) with ESMTP id LAA29420; Wed, 6 Mar 1996 11:42:32 +0200 (SAT) Message-Id: <199603060942.LAA29420@grumble.grondar.za> To: "Jordan K. Hubbard" cc: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch), freebsd-current@FreeBSD.org (FreeBSD-current users) Subject: Re: 2.2-960226-SNAP now on ftp.freebsd.org Date: Wed, 06 Mar 1996 11:42:31 +0200 From: Mark Murray Sender: owner-current@FreeBSD.org Precedence: bulk "Jordan K. Hubbard" wrote: > > . /sbin/init and /bin/ed in the `filesys' are the DES versions. You > > might wanna care for this when releasing it on a CD. > > Thanks, Mark and I are looking into it. It's odd. I found out why last night. The make world is "allowing" this to happen by not having a -DNOCRYPT in release/Makefile release: target. We should have some cruft a' la the eBones crap for explicitly generating the crypto versions. I am working on that now - init is done - ed will come tonight along with the changes to lib/Makefile and some others. > > . We need a compat2x distribution, and this one must be offered for > > installation when it comes to XFree86(tm). libc.so.2.2 must be in > > it. > > Would someone here care to make one? I always get stuck making > the compat* dists, and there are always complaints! :-) Why are we carrying some of this crap? Ok I know why we need the old shared libraries, but there is a libgcc.so.261.0 in the distribution that really aught to go in the libcompat set? Let me know what is involved in broad terms and I'll look at it. > > Further, using the latest XFree86 betas against a -current system > > shows strange effects. Running the server with the (new) Xkb > > extension enabled immediately freezes the machine after the first > > couple of X clients popped up. Running without the extension only > > Interesting. I've never tried any of the betas, but this certainly > leads me think that I'm better off not sticking 3.1.2D on there! :-) Isn't sticking buggy software on a developer's CD an incentive to fix it? ]:-> 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 Mar 6 01:50:50 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA04709 for current-outgoing; Wed, 6 Mar 1996 01:50:50 -0800 (PST) Received: from skiddaw.elsevier.co.uk (skiddaw.elsevier.co.uk [193.131.222.60]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id BAA04687 for ; Wed, 6 Mar 1996 01:50:45 -0800 (PST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by skiddaw.elsevier.co.uk (8.6.12/8.6.12) with ESMTP id JAA21206 for ; Wed, 6 Mar 1996 09:48:47 GMT Received: from tees by snowdon with SMTP (PP); Wed, 6 Mar 1996 09:46:35 +0000 Received: (from dpr@localhost) by tees (SMI-8.6/8.6.12) id JAA04751; Wed, 6 Mar 1996 09:49:34 GMT Date: Wed, 6 Mar 1996 09:49:34 GMT From: Paul Richards Message-Id: <199603060949.JAA04751@tees> To: freebsd-current@freebsd.org, joerg_wunsch@uriah.heep.sax.de Subject: Re: Fixit floppy (Was: Please Read This) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: 8klZBbXR3ZAgwlRM143b/A== Sender: owner-current@freebsd.org Precedence: bulk > As Paul Richards wrote: > > > To make matters worse, there isn't a very usefull fixit disk anywhere to > > grab. The fixit image on the cdrom doesn't have a kernel on it! The kernel > > on the install floppy is a bit weird :-) > > The suggested way of using the fixit floppy is to boot the install > floppy, and select the fixit option. DON'T DO IT WITH A 2.2 INSTALL > FLOPPY! The gzip execution code is currently *WAY* broken, you > usually end up with a machine silently resetting. :-(( I couldn't get this to work, it's what I tried. The install floppy always goes into sysinstall and I didn't see a fixit option, which probably means I have an old install floppy. > Should you need a tweaked kernel in order to use the fixit floppy (but > then again, NOT from 2.2-current!), simply newfs a floppy, stick the > kernel there, boot it, and swap this floppy for the fixit one while > the boot is proceeding. The fixit floppy should contain enough stuff > to get you going... Aaaaie, sheesh, somebody removed /sbin/init from > there. :-(( > A missing /sbin/init is I think part of the problem I had :-) You might want to explain to me how I newfs a floppy to recover from when all I had was DOS and the cdrom :-) The fixit recovery method is currently not much use when you're *completely* spammed. I was basically missing a kernel to boot and the image on the install floppy has lots of weird things going on, like gzip and inline root filesystems and things that make it a bit hard to make sense of when you're dead in the water. A simple single user boot to sh with some basic tools is much more important in such a spammed situation and we don't have that available anymore. As a recovery tool I'd be happy with *2* floppies if we're short of space, one I can boot a kernel off and one with recovery tools as a filesystem image. We don't need to be so user-friendly in such situations since it's going to take an experienced user to recover from such a situation anyway, we just need to provide the images on the cdrom so you can recover yourself when you only have DOS left. If you don't have DOS on your box then you're going to need to create these floppies off the cdrom when you install initially a'la Win NT etc. From owner-freebsd-current Wed Mar 6 02:04:37 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA05833 for current-outgoing; Wed, 6 Mar 1996 02:04:37 -0800 (PST) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id CAA05828 for ; Wed, 6 Mar 1996 02:04:33 -0800 (PST) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id CAA06386; Wed, 6 Mar 1996 02:04:00 -0800 From: "Rodney W. Grimes" Message-Id: <199603061004.CAA06386@GndRsh.aac.dev.com> Subject: Re: 2.2-960226-SNAP now on ftp.freebsd.org To: joerg_wunsch@uriah.heep.sax.de Date: Wed, 6 Mar 1996 02:04:00 -0800 (PST) Cc: freebsd-current@FreeBSD.org In-Reply-To: <199603060903.KAA10635@uriah.heep.sax.de> from "J Wunsch" at Mar 6, 96 10:03:15 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org Precedence: bulk ... > > I agree, but in the meantime it's just 2 extra lines in the .login > > and .profile (.cshrc never contained a stty and should not have?). > > Don't forget /.profile, for the single-user shell. /.profile is a hardlink to /root/.profile. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Wed Mar 6 02:51:38 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA10246 for current-outgoing; Wed, 6 Mar 1996 02:51:38 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id CAA10238 for ; Wed, 6 Mar 1996 02:51:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.4/8.6.9) with SMTP id CAA14851; Wed, 6 Mar 1996 02:50:20 -0800 (PST) To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) cc: freebsd-current@FreeBSD.org (FreeBSD-current users) Subject: Re: Another comment on the 2.2-960303-SNAP.. In-reply-to: Your message of "Wed, 06 Mar 1996 09:20:15 +0100." <199603060820.JAA10302@uriah.heep.sax.de> Date: Wed, 06 Mar 1996 02:50:20 -0800 Message-ID: <14849.826109420@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.org Precedence: bulk > IDE did work, but an attempt to access an ATAPI CD miserably failed. > This was a Toshiba XM5, neither wdc0/drive 1 nor wdc1/ > drive 0 did probe it successfully. This was with my ``GUUG'' SNAP > which was about 2 weeks ahead of Jordan's. Thanks for the report. I'm trying to get Serge a couple of IDE CDROM drives purchased - I can add this one to the list if you can give me a precise part number! > (For the curious: i had to assemble three machines, and have test- > installed FreeBSD on them to prove the hardware works. Two of the > machines were really Plug&Play -- the couple of SCSI machines. The > IDE $%!@ took me about half an hour more. :) Uh, do you still have these set up? Lieber freund, tovarich, BETA tester! :-) Jordan From owner-freebsd-current Wed Mar 6 03:08:44 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA11836 for current-outgoing; Wed, 6 Mar 1996 03:08:44 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id DAA11823 for ; Wed, 6 Mar 1996 03:08:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.4/8.6.9) with SMTP id DAA14916; Wed, 6 Mar 1996 03:07:22 -0800 (PST) To: Mark Murray cc: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch), freebsd-current@FreeBSD.org (FreeBSD-current users) Subject: Re: 2.2-960226-SNAP now on ftp.freebsd.org In-reply-to: Your message of "Wed, 06 Mar 1996 11:42:31 +0200." <199603060942.LAA29420@grumble.grondar.za> Date: Wed, 06 Mar 1996 03:07:21 -0800 Message-ID: <14914.826110441@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.org Precedence: bulk > I found out why last night. The make world is "allowing" this to happen > by not having a -DNOCRYPT in release/Makefile release: target. We should > have some cruft a' la the eBones crap for explicitly generating the crypto > versions. I am working on that now - init is done - ed will come tonight > along with the changes to lib/Makefile and some others. Awesome! Thanks, Mark! > Why are we carrying some of this crap? Ok I know why we need the old > shared libraries, but there is a libgcc.so.261.0 in the distribution > that really aught to go in the libcompat set? Let me know what is > involved in broad terms and I'll look at it. Well, as to why, I guess backwards compatibility. People want to continue running their old bins. If there's something from a previous release that needs to go into a new one in order to support this, there's the start of a compat dist. The libgcc.so.261.0 was a special case because Poul-Henning didn't feel like rolling a compat205 distribution with only one file in it.. :-) > Isn't sticking buggy software on a developer's CD an incentive to fix > it? ]:-> That's one way of looking at it, I suppose.. :-) If the XFree86 people actually feel that this would be of value to them, I'll do it. Otherwise, I'll just stick with what's there. Jordan From owner-freebsd-current Wed Mar 6 03:09:49 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA11915 for current-outgoing; Wed, 6 Mar 1996 03:09:49 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id DAA11904 for ; Wed, 6 Mar 1996 03:09:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.4/8.6.9) with SMTP id DAA14927; Wed, 6 Mar 1996 03:09:08 -0800 (PST) To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) cc: freebsd-current@FreeBSD.org (FreeBSD-current users) Subject: Re: 2.2-960226-SNAP now on ftp.freebsd.org In-reply-to: Your message of "Wed, 06 Mar 1996 10:03:15 +0100." <199603060903.KAA10635@uriah.heep.sax.de> Date: Wed, 06 Mar 1996 03:09:08 -0800 Message-ID: <14925.826110548@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.org Precedence: bulk > I could select whatever menu item from the ``Documentation'' menu, and > only got ``Sorry, this ain't here''. Of course, this was for my own > SNAP, so if it's there in your version i assume you've done some extra > work besides ``make release''? Huh! Let me test that.. :-) Jordan From owner-freebsd-current Wed Mar 6 03:45:07 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA13959 for current-outgoing; Wed, 6 Mar 1996 03:45:07 -0800 (PST) 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 DAA13953 for ; Wed, 6 Mar 1996 03:45:01 -0800 (PST) Received: from grumble.grondar.za (mark@localhost [127.0.0.1]) by grumble.grondar.za (8.7.4/8.7.3) with ESMTP id NAA29815; Wed, 6 Mar 1996 13:43:47 +0200 (SAT) Message-Id: <199603061143.NAA29815@grumble.grondar.za> To: "Jordan K. Hubbard" cc: Mark Murray , joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch), freebsd-current@FreeBSD.org (FreeBSD-current users) Subject: Re: 2.2-960226-SNAP now on ftp.freebsd.org Date: Wed, 06 Mar 1996 13:43:47 +0200 From: Mark Murray Sender: owner-current@FreeBSD.org Precedence: bulk "Jordan K. Hubbard" wrote: > > Why are we carrying some of this crap? Ok I know why we need the old > > shared libraries, but there is a libgcc.so.261.0 in the distribution > > that really aught to go in the libcompat set? Let me know what is > > involved in broad terms and I'll look at it. > > Well, as to why, I guess backwards compatibility. People want to > continue running their old bins. If there's something from a previous > release that needs to go into a new one in order to support this, > there's the start of a compat dist. The libgcc.so.261.0 was a special > case because Poul-Henning didn't feel like rolling a compat205 > distribution with only one file in it.. :-) Proposal: why do we not just get all of them - libc.so.2.2, libgcc.so.261.0 etc and make one compat2.n out of them (or is that done already?)? I'll do it if you fill me in on what you did... 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 Mar 6 04:15:58 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA15755 for current-outgoing; Wed, 6 Mar 1996 04:15:58 -0800 (PST) Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id EAA15750 for ; Wed, 6 Mar 1996 04:15:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by Root.COM (8.6.12/8.6.5) with SMTP id EAA23308; Wed, 6 Mar 1996 04:13:57 -0800 Message-Id: <199603061213.EAA23308@Root.COM> X-Authentication-Warning: implode.Root.COM: Host localhost didn't use HELO protocol To: Bruce Evans cc: jhay@mikom.csir.co.za, freebsd-current@FreeBSD.ORG Subject: Re: fixes for rename panic (round 1) In-reply-to: Your message of "Wed, 06 Mar 1996 18:50:15 +1100." <199603060750.SAA09666@godzilla.zeta.org.au> From: David Greenman Reply-To: davidg@Root.COM Date: Wed, 06 Mar 1996 04:13:57 -0800 Sender: owner-current@FreeBSD.ORG Precedence: bulk >*************** >*** 953,958 **** >--- 1005,1012 ---- > panic("ufs_rename: lost to startdir"); > error = relookup(tdvp, &tvp, tcnp); >+ VREF(tdvp); > if (error) > goto out; >+ vrele(tdvp); > dp = VTOI(tdvp); > xp = NULL; It seems like this hunk should be similar to the others - the VREF() should be before the call to relookup(). Right? -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-current Wed Mar 6 04:17:20 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA15945 for current-outgoing; Wed, 6 Mar 1996 04:17:20 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id EAA15936 for ; Wed, 6 Mar 1996 04:17:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.4/8.6.9) with SMTP id EAA15206; Wed, 6 Mar 1996 04:14:52 -0800 (PST) To: Mark Murray cc: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch), freebsd-current@FreeBSD.org (FreeBSD-current users) Subject: Re: 2.2-960226-SNAP now on ftp.freebsd.org In-reply-to: Your message of "Wed, 06 Mar 1996 13:43:47 +0200." <199603061143.NAA29815@grumble.grondar.za> Date: Wed, 06 Mar 1996 04:14:52 -0800 Message-ID: <15204.826114492@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.org Precedence: bulk > Proposal: why do we not just get all of them - libc.so.2.2, libgcc.so.261.0 > etc and make one compat2.n out of them (or is that done already?)? I'll do Sounds fine to me! > it if you fill me in on what you did... Uh, you'll be disappointed - I looked at which libraries were bumped between the last and current releases and packed the old versions into a root-relative tarball by hand. That's all! :-) Jordan From owner-freebsd-current Wed Mar 6 04:21:23 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA16408 for current-outgoing; Wed, 6 Mar 1996 04:21:23 -0800 (PST) Received: from cray-ymp.acm.stuorg.vt.edu (root@cray-ymp.acm.stuorg.vt.edu [128.173.43.251]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id EAA16403 for ; Wed, 6 Mar 1996 04:21:20 -0800 (PST) Received: (from kmitch@localhost) by cray-ymp.acm.stuorg.vt.edu (8.6.13/8.6.12) id HAA06662 for current@freebsd.org; Wed, 6 Mar 1996 07:23:11 -0500 From: Keith Mitchell Message-Id: <199603061223.HAA06662@cray-ymp.acm.stuorg.vt.edu> Subject: Re: Sig 11's on current To: current@freebsd.org Date: Wed, 6 Mar 1996 07:23:11 -0500 (EST) In-Reply-To: <9603051252.AA06652@cbsky.cb.att.com> from "Daniel.M.Obrien@att.com" at Mar 5, 96 07:52:40 am Reply-To: kmitch@vt.edu 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 Precedence: bulk > Failing system: > > Digital, true Pentium 75MHZ, OC to 90MHZ (since forever with lots of cooling), > 8MB RAM, NO L2 CACHE (boy was I green when I bought this system :-( ), Noname > MoBo, Phoenix BIOS, Acculogic PPort20 (NCR53C825) SCSI ctrl, 1GB Seagate Hawk. My failing system is: Pentium 100, 16MB RAM. I am however running AcceleratedX which seems to be occupying abou 8-10 megs resident. BTW, I am still having these problems with -current as of 3/6/96 approx 0700EST. I did see one vm fix go in here that was supposed to fix this problem (I think) and it didn't seem to do any good. -- Keith Mitchell | The real danger is not that computers will Chesapeake/Blacksburg VA | begin to think like men, but that men will kmitch@infi.net | begin to think like computers. kmitch@csugrad.cs.vt.edu | -- Sydney J. Harris From owner-freebsd-current Wed Mar 6 05:25:10 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA19784 for current-outgoing; Wed, 6 Mar 1996 05:25:10 -0800 (PST) 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 FAA19777 for ; Wed, 6 Mar 1996 05:25:04 -0800 (PST) Received: from grumble.grondar.za (mark@localhost [127.0.0.1]) by grumble.grondar.za (8.7.4/8.7.3) with ESMTP id PAA00116; Wed, 6 Mar 1996 15:19:54 +0200 (SAT) Message-Id: <199603061319.PAA00116@grumble.grondar.za> To: "Jordan K. Hubbard" cc: Mark Murray , joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch), freebsd-current@FreeBSD.org (FreeBSD-current users) Subject: Re: 2.2-960226-SNAP now on ftp.freebsd.org Date: Wed, 06 Mar 1996 15:19:53 +0200 From: Mark Murray Sender: owner-current@FreeBSD.org Precedence: bulk "Jordan K. Hubbard" wrote: > > Proposal: why do we not just get all of them - libc.so.2.2, libgcc.so.261.0 > > etc and make one compat2.n out of them (or is that done already?)? I'll do > > Sounds fine to me! > > > it if you fill me in on what you did... > > Uh, you'll be disappointed - I looked at which libraries were bumped > between the last and current releases and packed the old versions into > a root-relative tarball by hand. That's all! :-) Proposal 2: I am gonna get flamed badly for this, I know :-( can't we check uuencoded compat libs into the repository? _OR_ have a libcompat spot where these are accumulated? Hmm (thinks) how about making a port out of these like the linuxcompat things, except loading them into /usr/lib? This way we could use the ports mechanism to keep them up to date. 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 Mar 6 07:51:12 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA29320 for current-outgoing; Wed, 6 Mar 1996 07:51:12 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA29315 for ; Wed, 6 Mar 1996 07:51:08 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id CAA27656; Thu, 7 Mar 1996 02:42:16 +1100 Date: Thu, 7 Mar 1996 02:42:16 +1100 From: Bruce Evans Message-Id: <199603061542.CAA27656@godzilla.zeta.org.au> To: bde@zeta.org.au, davidg@Root.COM Subject: Re: fixes for rename panic (round 1) Cc: freebsd-current@FreeBSD.ORG, jhay@mikom.csir.co.za Sender: owner-current@FreeBSD.ORG Precedence: bulk >>*************** >>*** 953,958 **** >>--- 1005,1012 ---- >> panic("ufs_rename: lost to startdir"); >> error = relookup(tdvp, &tvp, tcnp); >>+ VREF(tdvp); >> if (error) >> goto out; >>+ vrele(tdvp); >> dp = VTOI(tdvp); >> xp = NULL; > It seems like this hunk should be similar to the others - the VREF() should >be before the call to relookup(). Right? Right. The above will probably work because the reference count is > 0 because rename() holds a reference to ni_startdir, so there is no danger of the reference count going from 0 to -1 in the vput() in relookup(). For the same reason, it should work to only add a reference after an error: relookup() = ... if (error) { VREF(tdvp); goto out; } but it seems clearer to use a VREF() for each vrele(), at least statically. My tests only covered the following cases: - first relookup() called, always succeeded. - second relookup() never (?) called. - third relookup() called, sometimes failed. Bruce From owner-freebsd-current Wed Mar 6 08:26:43 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA01853 for current-outgoing; Wed, 6 Mar 1996 08:26:43 -0800 (PST) Received: from sag.space.lockheed.com (sag.space.lockheed.com [192.68.162.134]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id IAA01846 for ; Wed, 6 Mar 1996 08:26:36 -0800 (PST) Received: by sag.space.lockheed.com; (5.65v3.2/1.1.8.2/21Nov95-0423PM) id AA02478; Tue, 5 Mar 1996 08:25:19 -0800 Date: Tue, 5 Mar 1996 08:25:19 -0800 (PST) From: "Brian N. Handy" To: freebsd-current@freebsd.org Subject: Whee! Page Fault! Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk Hi Folks, I'm in cahoots with Michael Smith trying to run IDL on a FreeBSD box. As such...I'm running a -current kernel. I got the 2.2.0-960303 SNAP, then yesterday afternoon supped the sys bits. Then... I changed my config file to match my equipment. Compiled new kernel. Seems to work, doesn't complain about anything. Start an ijppp session. One virtual terminal is doing that. Another is fetching XFree86 from somewhere. The third is me, wandering around a CD looking for some other stuff. I did an 'ls' on the CD and got a page fault, kernel panic, a window of goodies flies by and I reboot. I haven't had a kernel panic in so long, I figured maybe I'd better report this one to someone. SOOOO...here's what we'll put here: (1) My rendition of the page fault, which I wrote down (2) My kernel config file (3) dmesg Talked to Nate about this, he conjectured that maybe John Dyson's changes yesterday could have fixed this...but here's a data point. Advice is always appreciated. I'm thinking about supping the latest changes in sys and trying again. Keep throwing the dice until I win! :-) Let me know if this is just a spectacularly dumb idea. I do need to run -current to get all the linuxulator stuff working. :-7 Brian PS: Hardware: ASUS-PCI/I-P55TP4N, 586DX133, 16MB, NCR 53c810, Quantum Atlas 2.1GB, Sony 1076s SCSI CD, STB Vel64 vid card ==================================================================== (1) The page fault: Fatal Trap 12: page fault while in kernel mode fault virtual address = 0xf089800d fault code = supervisor mode, page not present instruction pointer = 0x8:0xf0103c2b code segment = base 0x0,limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL=0 current process = 417 (ls) interrupt mask = panic: page fault (2) Kernel config # # GENERIC -- Generic machine with WD/AHx/NCR/BTx family disks # # $Id: GENERIC,v 1.60 1996/01/20 06:14:33 nate Exp $ # machine "i386" #cpu "I386_CPU" #cpu "I486_CPU" cpu "I586_CPU" #cpu "I686_CPU" ident LESPAUL maxusers 10 #options MATH_EMULATE #Support for x87 emulation options INET #InterNETworking options FFS #Berkeley Fast Filesystem options NFS #Network Filesystem options MSDOSFS #MSDOS Filesystem options "CD9660" #ISO 9660 Filesystem options PROCFS #Process filesystem options "COMPAT_43" #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=15 #Be pessimistic about Joe SCSI device options BOUNCE_BUFFERS #include support for DMA bounce buffers options UCONSOLE #Allow users to grab the console options LINUX config kernel root on wd0 controller isa0 controller eisa0 controller pci0 controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr disk fd0 at fdc0 drive 0 disk fd1 at fdc0 drive 1 tape ft0 at fdc0 drive 2 #controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr #disk wd0 at wdc0 drive 0 #disk wd1 at wdc0 drive 1 #controller wdc1 at isa? port "IO_WD2" bio irq 15 vector wdintr #disk wd2 at wdc1 drive 0 #disk wd3 at wdc1 drive 1 #options ATAPI #Enable ATAPI support for IDE bus #device wcd0 #IDE CD-ROM # A single entry for any of these controllers (ncr, ahb, ahc) is sufficient # for any number of installed devices. controller ncr0 controller ahb0 controller ahc0 #controller bt0 at isa? port "IO_BT0" bio irq ? vector bt_isa_intr #controller uha0 at isa? port "IO_UHA0" bio irq ? drq 5 vector uhaintr #controller aha0 at isa? port "IO_AHA0" bio irq ? drq 5 vector ahaintr #controller aic0 at isa? port 0x340 bio irq 11 vector aicintr #controller nca0 at isa? port 0x1f88 bio irq 10 vector ncaintr #controller nca1 at isa? port 0x350 bio irq 5 vector ncaintr #controller sea0 at isa? bio irq 5 iomem 0xc8000 iosiz 0x2000 vector seaintr controller scbus0 device sd0 device od0 device st0 device cd0 #Only need one of these, the code dynamically grows #device wt0 at isa? port 0x300 bio irq 5 drq 1 vector wtintr #device mcd0 at isa? port 0x300 bio irq 10 vector mcdintr #device mcd1 at isa? port 0x340 bio irq 11 vector mcdintr #controller matcd0 at isa? port 0x230 bio #device scd0 at isa? port 0x230 bio # syscons is the default console driver, resembling an SCO console device sc0 at isa? port "IO_KBD" tty irq 1 vector scintr # Enable this and PCVT_FREEBSD for pcvt vt220 compatible console driver #device vt0 at isa? port "IO_KBD" tty irq 1 vector pcrint #options PCVT_FREEBSD=210 # pcvt running on FreeBSD >= 2.0.5 #options XSERVER # include code for XFree86 #options FAT_CURSOR # start with block cursor # If you have a ThinkPAD, uncomment this along with the rest of the PCVT lines #options PCVT_SCANSET=2 # IBM keyboards are non-std # Mandatory, don't remove device npx0 at isa? port "IO_NPX" irq 13 vector npxintr device sio0 at isa? port "IO_COM1" tty irq 4 vector siointr device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr #device sio2 at isa? port "IO_COM3" tty irq 5 vector siointr #device sio3 at isa? port "IO_COM4" tty irq 9 vector siointr device lpt0 at isa? port? tty irq 7 vector lptintr #device lpt1 at isa? port? tty #device lpt2 at isa? port? tty # Order is important here due to intrusive probes, do *not* alphabetize # this list of network interfaces until the probes have been fixed. # Right now it appears that the ie0 must be probed before ep0. See # revision 1.20 of this file. device de0 device fxp0 #device ed0 at isa? port 0x280 net irq 5 iomem 0xd8000 vector edintr #device ed1 at isa? port 0x300 net irq 5 iomem 0xd8000 vector edintr #device ie0 at isa? port 0x360 net irq 7 iomem 0xd0000 vector ieintr #device ep0 at isa? port 0x300 net irq 10 vector epintr #device ix0 at isa? port 0x300 net irq 10 iomem 0xd0000 iosiz 32768 vector ixintr #device le0 at isa? port 0x300 net irq 5 iomem 0xd0000 vector le_intr #device lnc0 at isa? port 0x280 net irq 10 drq 0 vector lncintr #device lnc1 at isa? port 0x300 net irq 10 drq 0 vector lncintr #device ze0 at isa? port 0x300 net irq 5 iomem 0xd8000 vector zeintr #device zp0 at isa? port 0x300 net irq 10 iomem 0xd8000 vector zpintr pseudo-device loop pseudo-device ether pseudo-device log pseudo-device sl 1 # ijppp uses tun instead of ppp device pseudo-device ppp 1 pseudo-device tun 1 pseudo-device pty 16 # keep this if you want to be able to continue to use /stand/sysinstall pseudo-device gzip # Exec gzipped a.out's (3) dmesg FreeBSD 2.2-CURRENT #0: Tue Mar 5 17:02:32 1996 root@handy.space.lockheed.com:/usr/2.2.0-CURRENT/src/sys/compile/LESPAUL CPU: Pentium (132.61-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x52b Stepping=11 Features=0x1bf real memory = 16777216 (16384K bytes) avail memory = 14807040 (14460K bytes) Probing for devices on PCI bus 0: chip0 rev 2 on pci0:0 chip1 rev 2 on pci0:7 pci0:7: Intel Corporation, device=0x1230, class=storage (ide) [no driver assigned] vga0 rev 0 int a irq 10 on pci0:9 ncr0 rev 2 int a irq 11 on pci0:12 (ncr0:0:0): "Quantum XP32150 81HB" type 0 fixed SCSI 2 sd0(ncr0:0:0): Direct-Access sd0(ncr0:0:0): FAST SCSI-2 100ns (10 Mb/sec) offset 8. 2050MB (4199760 512 byte sectors) (ncr0:6:0): "SONY CD-ROM CDU-76S 1.1c" type 5 removable SCSI 2 cd0(ncr0:6:0): CD-ROM cd0(ncr0:6:0): 200ns (5 Mb/sec) offset 8. cd0(ncr0:6:0): UNIT ATTENTION asc:28,0 cd0(ncr0:6:0): Not ready to ready transition, medium may have changed cd present [400000 x 2048 byte records] Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 72065B fd0: 1.44MB 3.5in npx0 on motherboard npx0: INT 16 interface changing root device to sd0a new masks: bio c0000840, tty c003009a, net c003009a WARNING: / was not properly dismounted. From owner-freebsd-current Wed Mar 6 08:47:38 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA03384 for current-outgoing; Wed, 6 Mar 1996 08:47:38 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id IAA03376 for ; Wed, 6 Mar 1996 08:47:34 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id DAA29892; Thu, 7 Mar 1996 03:43:14 +1100 Date: Thu, 7 Mar 1996 03:43:14 +1100 From: Bruce Evans Message-Id: <199603061643.DAA29892@godzilla.zeta.org.au> To: joerg_wunsch@uriah.heep.sax.de, rgrimes@GndRsh.aac.dev.com Subject: Re: 2.2-960226-SNAP now on ftp.freebsd.org Cc: freebsd-current@freebsd.org Sender: owner-current@freebsd.org Precedence: bulk >> Don't forget /.profile, for the single-user shell. >/.profile is a hardlink to /root/.profile. Yuck. I've never installed it. The system-wide profile /etc/profile isn't installed. It should be installed and contain only comments in it, like /etc/csh.login. Perhaps something like /etc/csh.cshrc should be implemented using $ENV. Bruce From owner-freebsd-current Wed Mar 6 09:22:21 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA06163 for current-outgoing; Wed, 6 Mar 1996 09:22:21 -0800 (PST) Received: from marble.eps.nagoya-u.ac.jp (marble.eps.nagoya-u.ac.jp [133.6.57.68]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id JAA06158 for ; Wed, 6 Mar 1996 09:22:19 -0800 (PST) Received: from marble.eps.nagoya-u.ac.jp (localhost [127.0.0.1]) by marble.eps.nagoya-u.ac.jp (8.7.4+2.6Wbeta6/3.3W9) with ESMTP id CAA00254 for ; Thu, 7 Mar 1996 02:21:54 +0900 (JST) Message-Id: <199603061721.CAA00254@marble.eps.nagoya-u.ac.jp> To: current@freebsd.org Subject: panic after exiting X X-Mailer: Mew beta version 0.96 on Emacs 19.28.1, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Thu, 07 Mar 1996 02:21:53 +0900 From: KATO Takenori Sender: owner-current@freebsd.org Precedence: bulk My kernel panics after exiting X. (Someone reported same problem, but I lost the log from mailbox.) This panic seems to occur after vm_map.c change from 1.34 to 1.36. The while-loop which was added by this change: while (object->backing_object) { object = object->backing_object; offset += object->backing_object_offset; if (object->size < OFF_TO_IDX( offset + size)) size = IDX_TO_OFF(object->size) - offset; } is executed without blocking interruption. If vm_object_collapse is called during while loop, the result may be wrong. Is this condition prevented elsewhere? I have run kernel between Mar 2's changes around vm and this change for not so long, so I don't know what change causes panic exactly. ---- KATO Takenori Dept. Earth Planet. Sci., Nagoya Univ., Nagoya 464-01 Voice: +81-52-789-2529 Fax: +81-52-789-3033 From owner-freebsd-current Wed Mar 6 09:24:27 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA06274 for current-outgoing; Wed, 6 Mar 1996 09:24:27 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA06268 Wed, 6 Mar 1996 09:24:24 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA11164; Wed, 6 Mar 1996 10:19:46 -0700 From: Terry Lambert Message-Id: <199603061719.KAA11164@phaeton.artisoft.com> Subject: Re: 2842 and the disappearing file-system :-( To: gibbs@freefall.freebsd.org (Justin T. Gibbs) Date: Wed, 6 Mar 1996 10:19:46 -0700 (MST) Cc: terry@lambert.org, imb@scgt.oz.au, stable@FreeBSD.org, current@FreeBSD.org In-Reply-To: <199603052339.PAA07251@freefall.freebsd.org> from "Justin T. Gibbs" at Mar 5, 96 03:39:57 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org Precedence: bulk > >> >> Actually this appears to be a bug in eisaconf as it affects all > >> >> eisa scsi controllers at the moment. I'm looking into it, but the > >> >> problem is not obvious and doesn't occur in -current. > >> > > >> >He has a VESA controller... brain farts are contagious! > >> > >> He has a VESA controller that uses an EISA probe and so is > >> also affected. > > > >Ah. That's broken. 8-(. This must be a VESA/EISA box for it to > >see the EISA signature and hit the EISA code? > > The eisaconf code always probes for eisa ids if it is configured > in your system. It hasn't caused any conflicts on any system that > I've seen, and since we have at least one device driver that would > have to copy the same probe code in order to work, I decied to make > eisaconf work this way. So if it checked for the signature word and didn't "eisaconf" without it, and the probe were duped (or multiply referenced, anyway), then his problem would go away? I think EISA probing ought to be limited to EISA bus machines. Call me strange. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Wed Mar 6 10:00:35 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA09047 for current-outgoing; Wed, 6 Mar 1996 10:00:35 -0800 (PST) Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA09029 Wed, 6 Mar 1996 10:00:31 -0800 (PST) Message-Id: <199603061800.KAA09029@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: Host localhost.cdrom.com [127.0.0.1] didn't use HELO protocol To: Terry Lambert cc: imb@scgt.oz.au, stable@FreeBSD.org, current@FreeBSD.org Subject: Re: 2842 and the disappearing file-system :-( In-reply-to: Your message of "Wed, 06 Mar 1996 10:19:46 MST." <199603061719.KAA11164@phaeton.artisoft.com> Date: Wed, 06 Mar 1996 10:00:31 -0800 From: "Justin T. Gibbs" Sender: owner-current@FreeBSD.org Precedence: bulk >So if it checked for the signature word and didn't "eisaconf" without >it, and the probe were duped (or multiply referenced, anyway), then >his problem would go away? Depends on if the bug were duped too. I think I found the real problem anyway, and it wasn't directly eisaconf's fault. Update_intr_masks() was broken in stable or its behavior changed in current, so that when the code was ported back to stable, it wasn't properly registering its interrupt. >I think EISA probing ought to be limited to EISA bus machines. Call >me strange. 8-). I think that using anything other than eisaconf for devices that look and behave like EISA devices is a waste of code and a cludge. Forcing the 2842 to use our ISA registration routines is certainly not a better alternative. > > > Terry Lambert > terry@lambert.org >--- >Any opinions in this posting are my own and not those of my present >or previous employers. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Wed Mar 6 11:35:32 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA16390 for current-outgoing; Wed, 6 Mar 1996 11:35:32 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA16379 for ; Wed, 6 Mar 1996 11:35:29 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA11620; Wed, 6 Mar 1996 12:32:28 -0700 From: Terry Lambert Message-Id: <199603061932.MAA11620@phaeton.artisoft.com> Subject: Re: Whee! Page Fault! To: handy@sag.space.lockheed.com (Brian N. Handy) Date: Wed, 6 Mar 1996 12:32:28 -0700 (MST) Cc: freebsd-current@FreeBSD.ORG In-Reply-To: from "Brian N. Handy" at Mar 5, 96 08:25:19 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG Precedence: bulk > I'm in cahoots with Michael Smith trying to run IDL on a FreeBSD box. As > such...I'm running a -current kernel. I got the 2.2.0-960303 SNAP, then > yesterday afternoon supped the sys bits. Then... [ ... ] > I did an 'ls' on the CD and got a page fault, kernel panic, a window of > goodies flies by and I reboot. I haven't had a kernel panic in so long, I > figured maybe I'd better report this one to someone. SOOOO...here's what > we'll put here: [ ... ] > Fatal Trap 12: page fault while in kernel mode > fault virtual address = 0xf089800d > fault code = supervisor mode, page not present > instruction pointer = 0x8:0xf0103c2b > code segment = base 0x0,limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL=0 > current process = 417 (ls) > interrupt mask = > panic: page fault What are the symbols in the 0xf0103c2b area? Specifically, this will tell you the name of the routine where the fault occurred. Off hand, I suspect the CD9660 FS of being unstable, but maybe that's just me being prejudiced against grody code... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Wed Mar 6 11:48:01 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA17627 for current-outgoing; Wed, 6 Mar 1996 11:48:01 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA17596 Wed, 6 Mar 1996 11:47:58 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA11641; Wed, 6 Mar 1996 12:43:21 -0700 From: Terry Lambert Message-Id: <199603061943.MAA11641@phaeton.artisoft.com> Subject: Re: 2842 and the disappearing file-system :-( To: gibbs@freefall.freebsd.org (Justin T. Gibbs) Date: Wed, 6 Mar 1996 12:43:21 -0700 (MST) Cc: terry@lambert.org, imb@scgt.oz.au, stable@FreeBSD.ORG, current@FreeBSD.ORG In-Reply-To: <199603061800.KAA09029@freefall.freebsd.org> from "Justin T. Gibbs" at Mar 6, 96 10:00:31 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 Precedence: bulk > >I think EISA probing ought to be limited to EISA bus machines. Call > >me strange. 8-). > > I think that using anything other than eisaconf for devices that > look and behave like EISA devices is a waste of code and a cludge. > Forcing the 2842 to use our ISA registration routines is certainly > not a better alternative. What about adding a VLB registration phase? There needs to be a disctinction between need for bounce buffers anyway... You call the VLB probe if the EISA tag isn't present. This unkludges a lot of things, including the things that are kludged by the EISA ID check on non-EISA boxes. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Wed Mar 6 12:03:06 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA19123 for current-outgoing; Wed, 6 Mar 1996 12:03:06 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA19118 for ; Wed, 6 Mar 1996 12:03:05 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA11679; Wed, 6 Mar 1996 12:57:28 -0700 From: Terry Lambert Message-Id: <199603061957.MAA11679@phaeton.artisoft.com> Subject: Re: fixes for rename panic (round 1) To: bde@zeta.org.au (Bruce Evans) Date: Wed, 6 Mar 1996 12:57:28 -0700 (MST) Cc: jhay@mikom.csir.co.za, freebsd-current@FreeBSD.ORG In-Reply-To: <199603060750.SAA09666@godzilla.zeta.org.au> from "Bruce Evans" at Mar 6, 96 06:50:15 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG Precedence: bulk > The main cause of the panic is broken reference counting in certain > error cases. relookup() calls vput(fdvp) when it fails, so callers > must increment the reference count before calling relookup() and > decrement it if relookup() doesn't fail. Not doing this caused > v_usecount for the test directory to eventually become negative. > > relookup() fails when the `from' file went away. Different bad things > happen if it went away and came back. Then relookup doesn't fail, but > the wrong file or directory is removed. If a regular file went away > and came back as a directory, then the file system is corrupted. [ ... patches ... ] Have you tested these changes with MDOSFS (especially) and EXT2FS (less especially)? I suspect a potential deadlock on identical path prefixes one path component off, and on "." and ".." references for some particular cases. The existance of the race on the rename is intentional based on the need to hold the directory exclusively when inserting an entry. This is, I think, an architectural side-effect of making rename an FS atomic operation. Not that I don't agree that it shouldn't cause a panic. 8-) 8-). My personal "dream soloution" to this problem is to issue reader/writer locks on the vnode and remove the ladder-chain release race on a path traversal entirely. The magic is that "R" and "IX" are not conflicting for the same thread (context/process ID/whatever); it's the promotion from "IX" to "X" that generates the conflict. This causes the vnode reference to exist, but doesn't screw the traversal because of the VLOCK recursion restriction. Alternately, in implementing the UFS under Win95's IFS framework, we set the IN_RECURSE bit, which has similar effect to the patches you have, without adding unduly to the complexity. This is a kludge, plain and simple, because the IN_RECURSE itself is a kludge (it's predicated on the possibility of a fault on the copyout in the uiomove with a swap file on the same FS as is performing the currently requested operation). Really, this goes to my suggestion before that the VOP_LOCK code go to common higher level code and become purely advisory in all FS's except UNIONFS (needs to hold underlying vnodes locked) and QUOTAFS (needs to hold the quota file vnode locked on the underlying FS to which quotas are being applied). That, in combination with the conversion of the lock to a counting semaphore (ala SVR4, SunOS, Solaris, SCO, Unix SVR4 ES/MP, and AIX) will resolve the recusion case cleanly as well, without involving the underlying FS's inodes. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Wed Mar 6 12:24:14 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA21246 for current-outgoing; Wed, 6 Mar 1996 12:24:14 -0800 (PST) Received: from sag.space.lockheed.com (sag.space.lockheed.com [192.68.162.134]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA21235 for ; Wed, 6 Mar 1996 12:24:12 -0800 (PST) Received: by sag.space.lockheed.com; (5.65v3.2/1.1.8.2/21Nov95-0423PM) id AA05014; Wed, 6 Mar 1996 12:23:56 -0800 Date: Wed, 6 Mar 1996 12:23:56 -0800 (PST) From: "Brian N. Handy" To: Terry Lambert Cc: freebsd-current@FreeBSD.ORG Subject: Re: Whee! Page Fault! In-Reply-To: <199603061932.MAA11620@phaeton.artisoft.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG Precedence: bulk > > I did an 'ls' on the CD and got a page fault, kernel panic, a window of > > goodies flies by and I reboot. I haven't had a kernel panic in so long, I > > figured maybe I'd better report this one to someone. SOOOO...here's what > > we'll put here: > > [ ... ] > > > panic: page fault > > What are the symbols in the 0xf0103c2b area? Argh. Already we've gotten over my head. I wouldn't be here if I didn't want the Linux emu stuff to work. Someone will need to walk me through this if it's of sufficient interest. > Off hand, I suspect the CD9660 FS of being unstable, but maybe that's > just me being prejudiced against grody code... I'm going to say Terry's nailed {probably} this one. I came back to the same CD later, with none of the other distracting stuff going on. Once I tried to go, oh, three levels deep or so into the CD tree, my machine fell over again. It is nice and reproducible. I didn't get the page fault info the second time, it just crashed and rebooted. Brian From owner-freebsd-current Wed Mar 6 12:33:17 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA21705 for current-outgoing; Wed, 6 Mar 1996 12:33:17 -0800 (PST) Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA21684 Wed, 6 Mar 1996 12:33:13 -0800 (PST) Message-Id: <199603062033.MAA21684@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: Host localhost.cdrom.com [127.0.0.1] didn't use HELO protocol To: Terry Lambert cc: imb@scgt.oz.au, stable@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: 2842 and the disappearing file-system :-( In-reply-to: Your message of "Wed, 06 Mar 1996 12:43:21 MST." <199603061943.MAA11641@phaeton.artisoft.com> Date: Wed, 06 Mar 1996 12:33:13 -0800 From: "Justin T. Gibbs" Sender: owner-current@FreeBSD.ORG Precedence: bulk >> >I think EISA probing ought to be limited to EISA bus machines. Call >> >me strange. 8-). >> >> I think that using anything other than eisaconf for devices that >> look and behave like EISA devices is a waste of code and a cludge. >> Forcing the 2842 to use our ISA registration routines is certainly >> not a better alternative. > >What about adding a VLB registration phase? Give me a break! VLB is isa with a 32bit bus as far as probes go. I don't know of another VLB card that uses an eisa probe. In fact, the probes for VLB devices are usually identical to their ISA cousins. So, we may as well use ISA probes for VLB devices in the general case. >There needs to be a disctinction between need for bounce buffers >anyway... You call the VLB probe if the EISA tag isn't present. Not at all. There are EISA motherboards with broken 32bit DMA, There are VL motherboards with broken 32bit DMA. There are VL cards with broken 32bit DMA. There are EISA cards with broken 32bit DMA. You can't identify if a VLB motherboard is present, so having another special VL probe doesn't buy you anything. Each device driver is also capable ofenableing bounce buffers if it can detect broken hardware and the eisa module could even set a flag for all EISA devices to look at if it had a table of broken motherboard IDs. Look at how the bt driver deals with this to see exactly why this is not even relevent to this discussion. >This unkludges a lot of things, including the things that are >kludged by the EISA ID check on non-EISA boxes. How are they kludged? I haven't seen a single report of eisaconf without detected devices causing problems in a system. Furthermore, if you don't have a 2842 or and eisa machine, you can disable the eisa0 device in your config file. If you do have a 2842, you'd have to read the same bytes of the I/O address space, so it buys you nothing to have a separate probe for it. > > > Terry Lambert > terry@lambert.org >--- >Any opinions in this posting are my own and not those of my present >or previous employers. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Wed Mar 6 13:27:38 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA26326 for current-outgoing; Wed, 6 Mar 1996 13:27:38 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA26315 for ; Wed, 6 Mar 1996 13:27:31 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id IAA07079; Thu, 7 Mar 1996 08:24:45 +1100 Date: Thu, 7 Mar 1996 08:24:45 +1100 From: Bruce Evans Message-Id: <199603062124.IAA07079@godzilla.zeta.org.au> To: bde@zeta.org.au, terry@lambert.org Subject: Re: fixes for rename panic (round 1) Cc: freebsd-current@FreeBSD.ORG, jhay@mikom.csir.co.za Sender: owner-current@FreeBSD.ORG Precedence: bulk >Have you tested these changes with MDOSFS (especially) and EXT2FS >(less especially)? No. These fixes can't possible affect msdsofs since they are in ufs_rename() and msdosfs uses msdosfs_rename(). ext2fs uses ufs_rename() almost directly and should benefit from the changes, but I haven't tested it. msdosfs_rename() must make its own arrangement to handle the initial race (fvp == tvp), reference counting for relookup(), and races involving relookup(). It currently gets everything wrong. E.g., msdosfs doesn't have links, so (fvp == tvp) "can't happen", so it isn't handled. However, it happens because of the race in rename(). >I suspect a potential deadlock on identical >path prefixes one path component off, and on "." and ".." references >for some particular cases. I think the potential for deadlock is avoided by not locking fdvp/fvp, in rename(), and similar things in xxx_rename() (unlocking everything before calling relookup() and xxxcheckpath()). This costs a lot of complexity to handle the resulting races. >The existance of the race on the rename is intentional based on the >need to hold the directory exclusively when inserting an entry. No, it's because of the potential for deadlock if the `from' and the `to' directory entries and parent directories are all locked at once. fdvp/fvp are intentionally left unlocked so that deadlock can't occur. This creates problems later. The most complicated case is moving a directory to a new parent directory. As well as there being more links to change in this case, everything is unlocked so it it is possible for both the source and the destination directory entries and parent directory entries to vanish. Bruce From owner-freebsd-current Wed Mar 6 14:22:33 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA00700 for current-outgoing; Wed, 6 Mar 1996 14:22:33 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA00683 for ; Wed, 6 Mar 1996 14:22:22 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id XAA09174 for ; Wed, 6 Mar 1996 23:22:18 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id XAA21269 for freebsd-current@FreeBSD.org; Wed, 6 Mar 1996 23:22:18 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id XAA12380 for freebsd-current@FreeBSD.org; Wed, 6 Mar 1996 23:13:16 +0100 (MET) From: J Wunsch Message-Id: <199603062213.XAA12380@uriah.heep.sax.de> Subject: Re: 2.2-960226-SNAP now on ftp.freebsd.org To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Wed, 6 Mar 1996 23:13:15 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199603061004.CAA06386@GndRsh.aac.dev.com> from "Rodney W. Grimes" at Mar 6, 96 02:04:00 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 Precedence: bulk As Rodney W. Grimes wrote: > > Don't forget /.profile, for the single-user shell. > > /.profile is a hardlink to /root/.profile. Funny, i've never noticed it. :) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Wed Mar 6 14:22:44 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA00754 for current-outgoing; Wed, 6 Mar 1996 14:22:44 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA00608 for ; Wed, 6 Mar 1996 14:22:16 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id XAA09166 for ; Wed, 6 Mar 1996 23:22:12 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id XAA21267 for freebsd-current@FreeBSD.org; Wed, 6 Mar 1996 23:22:11 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id XAA12314 for freebsd-current@FreeBSD.org; Wed, 6 Mar 1996 23:08:35 +0100 (MET) From: J Wunsch Message-Id: <199603062208.XAA12314@uriah.heep.sax.de> Subject: Re: Fixit floppy (Was: Please Read This) To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Wed, 6 Mar 1996 23:08:35 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199603060949.JAA04751@tees> from "Paul Richards" at Mar 6, 96 09:49:34 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 Precedence: bulk As Paul Richards wrote: > > The suggested way of using the fixit floppy is to boot the install > > floppy, and select the fixit option. > I couldn't get this to work, it's what I tried. The install floppy > always goes into sysinstall and I didn't see a fixit option, which > probably means I have an old install floppy. Certainly. You need the boot floppy from a 2.1R. > If you don't have DOS on your box then you're going to need to create these > floppies off the cdrom when you install initially a'la Win NT etc. I don't see any advantage of a separate boot floppy with just the GENERIC kernel only. The install floppy does have the same kernel, only blown up by its builtin MFS. But functionally, they are the same. If you need a custom kernel, you will have to create your custom boot floppy anway. Of course, you'd best do this in advance. :-) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Wed Mar 6 14:23:54 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA00946 for current-outgoing; Wed, 6 Mar 1996 14:23:54 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA00935 for ; Wed, 6 Mar 1996 14:23:46 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id XAA09208 for ; Wed, 6 Mar 1996 23:23:02 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id XAA21277 for freebsd-current@FreeBSD.org; Wed, 6 Mar 1996 23:23:02 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id XAA12462 for freebsd-current@FreeBSD.org; Wed, 6 Mar 1996 23:21:33 +0100 (MET) From: J Wunsch Message-Id: <199603062221.XAA12462@uriah.heep.sax.de> Subject: Re: Another comment on the 2.2-960303-SNAP.. To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Wed, 6 Mar 1996 23:21:32 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <14849.826109420@time.cdrom.com> from "Jordan K. Hubbard" at Mar 6, 96 02:50:20 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org Precedence: bulk As Jordan K. Hubbard wrote: > Thanks for the report. I'm trying to get Serge a couple of IDE CDROM > drives purchased - I can add this one to the list if you can give > me a precise part number! Toshiba XM5301, if i remember well. The invoice does only have a funny name for them, no number. :-(( > > (For the curious: i had to assemble three machines, and have test- > > installed FreeBSD on them to prove the hardware works. Two of the > > machines were really Plug&Play -- the couple of SCSI machines. The > > IDE $%!@ took me about half an hour more. :) > > Uh, do you still have these set up? Lieber freund, tovarich, BETA > tester! :-) Nah, sorry. They were customer machines i've been assembling. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Wed Mar 6 14:51:18 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA05547 for current-outgoing; Wed, 6 Mar 1996 14:51:18 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA05529 for ; Wed, 6 Mar 1996 14:50:59 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id XAA11016 for ; Wed, 6 Mar 1996 23:50:55 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id XAA21552 for freebsd-current@FreeBSD.org; Wed, 6 Mar 1996 23:50:55 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id XAA12706 for freebsd-current@FreeBSD.org; Wed, 6 Mar 1996 23:27:06 +0100 (MET) From: J Wunsch Message-Id: <199603062227.XAA12706@uriah.heep.sax.de> Subject: Re: 2.2-960226-SNAP now on ftp.freebsd.org To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Wed, 6 Mar 1996 23:27:06 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <14914.826110441@time.cdrom.com> from "Jordan K. Hubbard" at Mar 6, 96 03:07:21 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 Precedence: bulk As Jordan K. Hubbard wrote: > > Isn't sticking buggy software on a developer's CD an incentive to fix > > it? ]:-> > > That's one way of looking at it, I suppose.. :-) > > If the XFree86 people actually feel that this would be of value to > them, I'll do it. Otherwise, I'll just stick with what's there. No sense. The XFree86 beta servers are publically available now, but they've got an expiration date, to force people to not continue to use beta software. So they will be most likely expired before the CD is 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 Wed Mar 6 14:59:54 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA06012 for current-outgoing; Wed, 6 Mar 1996 14:59:54 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA06007 Wed, 6 Mar 1996 14:59:51 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA11994; Wed, 6 Mar 1996 15:54:48 -0700 From: Terry Lambert Message-Id: <199603062254.PAA11994@phaeton.artisoft.com> Subject: Re: 2842 and the disappearing file-system :-( To: gibbs@freefall.freebsd.org (Justin T. Gibbs) Date: Wed, 6 Mar 1996 15:54:48 -0700 (MST) Cc: terry@lambert.org, imb@scgt.oz.au, stable@FreeBSD.ORG, current@FreeBSD.ORG In-Reply-To: <199603062033.MAA21684@freefall.freebsd.org> from "Justin T. Gibbs" at Mar 6, 96 12:33:13 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG Precedence: bulk > How are they kludged? I haven't seen a single report of eisaconf > without detected devices causing problems in a system. Furthermore, > if you don't have a 2842 or and eisa machine, you can disable the > eisa0 device in your config file. If you do have a 2842, you'd > have to read the same bytes of the I/O address space, so it buys > you nothing to have a separate probe for it. Maybe I'm missing something. Why do you have to have a seperate probe? Why can't you use the same probe routine address in two "driver instances"? And wouldn't this fix the interrrupt attach problem introduced by the eisaconf code in the VLB Adaptec case? You keep saying you need to duplicate cade -- I don't see it. I see that there is a need to duplicate ~32 bytes of data structure to get an EISA and non-EISA device instance. Tell me why Im wrong... 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 Wed Mar 6 15:03:07 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA06359 for current-outgoing; Wed, 6 Mar 1996 15:03:07 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id PAA06347 for ; Wed, 6 Mar 1996 15:03:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.4/8.6.9) with SMTP id PAA16732; Wed, 6 Mar 1996 15:02:48 -0800 (PST) To: "Brian N. Handy" cc: freebsd-current@freebsd.org Subject: Re: Whee! Page Fault! In-reply-to: Your message of "Tue, 05 Mar 1996 08:25:19 PST." Date: Wed, 06 Mar 1996 15:02:48 -0800 Message-ID: <16730.826153368@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org Precedence: bulk > yesterday could have fixed this...but here's a data point. Advice is > always appreciated. I'm thinking about supping the latest changes in sys > and trying again. Keep throwing the dice until I win! :-) Let me know > if this is just a spectacularly dumb idea. I do need to run -current to > get all the linuxulator stuff working. :-7 Actually, since you've started from 2.2-960303-SNAP, this is a pretty *good* idea, and should easily drop over your existing /usr/src/sys tree. Jordan From owner-freebsd-current Wed Mar 6 15:17:37 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA08651 for current-outgoing; Wed, 6 Mar 1996 15:17:37 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA08641 for ; Wed, 6 Mar 1996 15:17:35 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA12098; Wed, 6 Mar 1996 16:11:42 -0700 From: Terry Lambert Message-Id: <199603062311.QAA12098@phaeton.artisoft.com> Subject: Re: Whee! Page Fault! To: handy@sag.space.lockheed.com (Brian N. Handy) Date: Wed, 6 Mar 1996 16:11:41 -0700 (MST) Cc: terry@lambert.org, freebsd-current@FreeBSD.ORG In-Reply-To: from "Brian N. Handy" at Mar 6, 96 12:23:56 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG Precedence: bulk > > > I did an 'ls' on the CD and got a page fault, kernel panic, a window of > > > goodies flies by and I reboot. I haven't had a kernel panic in so long, I > > > figured maybe I'd better report this one to someone. SOOOO...here's what > > > we'll put here: > > > > [ ... ] > > > > > panic: page fault > > > > What are the symbols in the 0xf0103c2b area? > > Argh. Already we've gotten over my head. I wouldn't be here if I didn't > want the Linux emu stuff to work. Someone will need to walk me through > this if it's of sufficient interest. If you do "nm /kernel | sort | more", you will be able to find the offending code section, assuming you do it for the same kernel that fell over (ie: without an intervening rebuild). We need a "kernel post mortem" utility to do this for you so when people post questions like this, we can say "what does it say when you run /sbin/kpm as root?". 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Wed Mar 6 15:31:27 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA09600 for current-outgoing; Wed, 6 Mar 1996 15:31:27 -0800 (PST) Received: from sag.space.lockheed.com (sag.space.lockheed.com [192.68.162.134]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA09595 for ; Wed, 6 Mar 1996 15:31:24 -0800 (PST) Received: by sag.space.lockheed.com; (5.65v3.2/1.1.8.2/21Nov95-0423PM) id AA07642; Wed, 6 Mar 1996 15:31:20 -0800 Date: Wed, 6 Mar 1996 15:31:20 -0800 (PST) From: "Brian N. Handy" To: Terry Lambert Cc: freebsd-current@FreeBSD.ORG Subject: Re: Whee! Page Fault! In-Reply-To: <199603062311.QAA12098@phaeton.artisoft.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG Precedence: bulk > > > > I did an 'ls' on the CD and got a page fault, kernel panic, a window of > > > > goodies flies by and I reboot. I haven't had a kernel panic in so long, I > > > > figured maybe I'd better report this one to someone. SOOOO...here's what > > > > we'll put here: > > > > > > [ ... ] > > > > > > > panic: page fault > > > > > > What are the symbols in the 0xf0103c2b area? > > [...] > If you do "nm /kernel | sort | more",[...] 0xf0103a84 _cd9660_readdir 0xf0103f34 _cd9660_readlink Terry scores. Recall, I was doing an 'ls' at the time of the offending kernel panic. Brian From owner-freebsd-current Wed Mar 6 15:35:24 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA09798 for current-outgoing; Wed, 6 Mar 1996 15:35:24 -0800 (PST) Received: from hauki.clinet.fi (root@hauki.clinet.fi [194.100.0.1]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id PAA09793 for ; Wed, 6 Mar 1996 15:35:17 -0800 (PST) Received: from cantina.clinet.fi (root@cantina.clinet.fi [194.100.0.15]) by hauki.clinet.fi (8.7.3/8.6.4) with ESMTP id BAA03521 for ; Thu, 7 Mar 1996 01:34:37 +0200 (EET) Received: (hsu@localhost) by cantina.clinet.fi (8.7.3/8.6.4) id BAA07613; Thu, 7 Mar 1996 01:34:36 +0200 (EET) Date: Thu, 7 Mar 1996 01:34:36 +0200 (EET) Message-Id: <199603062334.BAA07613@cantina.clinet.fi> From: Heikki Suonsivu To: current@freebsd.org Subject: Now freebsd panics every time I sup. Organization: Clinet Ltd, Espoo, Finland Sender: owner-current@freebsd.org Precedence: bulk The last sup I did about 1-2 weeks ago panics or deadlocks repeatably when trying to sup a new one. Not a specific file, it seems to be something sup does. Even if it panics it won't generate a crash dump, so there aren't many pointers available. I'll try to sup the current with older kernel to get around this. -- Heikki Suonsivu, T{ysikuu 10 C 83/02210 Espoo/FINLAND, hsu@clinet.fi mobile +358-40-5519679 work +358-0-4375360 fax -4555276 home -8031121 From owner-freebsd-current Wed Mar 6 15:42:47 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA10404 for current-outgoing; Wed, 6 Mar 1996 15:42:47 -0800 (PST) Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA10384 Wed, 6 Mar 1996 15:42:39 -0800 (PST) Message-Id: <199603062342.PAA10384@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: Host localhost.cdrom.com [127.0.0.1] didn't use HELO protocol To: Terry Lambert cc: imb@scgt.oz.au, stable@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: 2842 and the disappearing file-system :-( In-reply-to: Your message of "Wed, 06 Mar 1996 15:54:48 MST." <199603062254.PAA11994@phaeton.artisoft.com> Date: Wed, 06 Mar 1996 15:42:39 -0800 From: "Justin T. Gibbs" Sender: owner-current@FreeBSD.ORG Precedence: bulk >> How are they kludged? I haven't seen a single report of eisaconf >> without detected devices causing problems in a system. Furthermore, >> if you don't have a 2842 or and eisa machine, you can disable the >> eisa0 device in your config file. If you do have a 2842, you'd >> have to read the same bytes of the I/O address space, so it buys >> you nothing to have a separate probe for it. > >Maybe I'm missing something. I would guess you didn't even look. Have you looked at eisaconf.c? or aic7770.c? >Why do you have to have a seperate probe? RTSL >Why can't you use the same probe routine address in two "driver instances"? Eisaconf doesn't work that way at all. >And wouldn't this fix the interrrupt attach problem introduced by the >eisaconf code in the VLB Adaptec case? Because the bug wasn't even in eisaconf. It was in i386/isa/isa.c. >You keep saying you need to duplicate cade -- I don't see it. I see >that there is a need to duplicate ~32 bytes of data structure to get >an EISA and non-EISA device instance. Tell me why Im wrong... Right now the code for dealing with the 2842 and the 2742 is one and the same. To do what you propose would mean adding an isa probe and doing the same looping through the slots that the eisaconf code does already, although the 2842 probe would have to do it once for each card probe instead of just creating the device nodes once like the eisaconf code does. There is simply no reason to break the probe up. It only adds complexity and code. > > > Regards, > Terry Lambert > terry@lambert.org >--- >Any opinions in this posting are my own and not those of my present >or previous employers. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Wed Mar 6 16:15:20 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA12806 for current-outgoing; Wed, 6 Mar 1996 16:15:20 -0800 (PST) Received: from cray-ymp.acm.stuorg.vt.edu (root@cray-ymp.acm.stuorg.vt.edu [128.173.43.251]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id QAA12798 for ; Wed, 6 Mar 1996 16:15:16 -0800 (PST) Received: (from kmitch@localhost) by cray-ymp.acm.stuorg.vt.edu (8.6.13/8.6.12) id TAA15198 for current@freebsd.org; Wed, 6 Mar 1996 19:17:07 -0500 From: Keith Mitchell Message-Id: <199603070017.TAA15198@cray-ymp.acm.stuorg.vt.edu> Subject: crypt.3 dependency in secure To: current@freebsd.org Date: Wed, 6 Mar 1996 19:17:07 -0500 (EST) Reply-To: kmitch@vt.edu 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 Precedence: bulk I found a slight problem in the dependencies of crypt.3 for a make world. Under the "libraries" target, it does a make for the secure stuff before the generic lib directory. crypt.3 now gets installed as part of lib/libc/gen. In secure/lib/libcipher it tries to make links to the crypt.3 that is not there yet. IMPACT: This has very little impact on most people, since the only way to experience it is if your man pages get deleted. ;-) -- Keith Mitchell | The real danger is not that computers will Chesapeake/Blacksburg VA | begin to think like men, but that men will kmitch@infi.net | begin to think like computers. kmitch@csugrad.cs.vt.edu | -- Sydney J. Harris From owner-freebsd-current Wed Mar 6 16:21:45 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA13382 for current-outgoing; Wed, 6 Mar 1996 16:21:45 -0800 (PST) Received: from linus.demon.co.uk (linus.demon.co.uk [158.152.10.220]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id QAA13316 for ; Wed, 6 Mar 1996 16:21:00 -0800 (PST) Received: (from mark@localhost) by linus.demon.co.uk (8.7.4/8.7.3) id AAA00301 for current@freebsd.org; Thu, 7 Mar 1996 00:17:47 GMT Message-Id: <199603070017.AAA00301@linus.demon.co.uk> From: mark@linus.demon.co.uk (Mark Valentine) Date: Thu, 7 Mar 1996 00:17:46 +0000 X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: current@freebsd.org Subject: reproducible fatal trap 12 Sender: owner-current@freebsd.org Precedence: bulk I can reliably reproduce a "Fatal trap 12: page fault while in kernel mode" in a current kernel (up to date as of a few hours ago). I reproduce it by mounting the FreeBSD 2.1 "live file system" CD and doing some file name completion in the Xlib source tree (using bash), e.g. $ more /cdrom/usr/X11R6/src/xc/lib/X11/ The fault address on one instance was 0xf08aa001, and the fault code is "supervisor read, page not present". The instruction pointer is at: _cd9660_readdir+0x1a7: movzbl 0(%ecx),%esi %ecx is the fault address. I have DDB enabled if anyone wants me to poke around, but I can't get dumps (last I tried anyway). This is a 486DX2/66, and the CD drive is a Toshiba XM3401B attached to an AHA1542C, if that's relevant. Although this is the first time I've seen just this problem, I've had a few problems recently, and the symptoms have changed over the last few days. For two or three weeks I've been getting a hang (in X) or silent reboot (not in X) *only* when bringing my PPP link up or down (about once every 4-5 connections, with kernel PPP). After some recent VM commits (Monday-ish?), I've had a couple of "unexpected" hangs (in X), though one of them was while playing xdoom with sound during a make world, which was asking for it... Incidentally, on the first of these reproducible crashes (only), nvi sent me mail dated "Mon, 6 Mar 2000 23:15:31 GMT" (which mush promptly sorted as "very old" and marked "Jan 17" :-/ - must look into that one!). My clock otherwise seems fine, no manual corrections required (I run it on local time). Mark. From owner-freebsd-current Wed Mar 6 16:58:13 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA17113 for current-outgoing; Wed, 6 Mar 1996 16:58:13 -0800 (PST) Received: from linus.demon.co.uk (linus.demon.co.uk [158.152.10.220]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id QAA17045 for ; Wed, 6 Mar 1996 16:57:54 -0800 (PST) Received: (from mark@localhost) by linus.demon.co.uk (8.7.4/8.7.3) id AAA01358; Thu, 7 Mar 1996 00:55:40 GMT Message-Id: <199603070055.AAA01358@linus.demon.co.uk> From: mark@linus.demon.co.uk (Mark Valentine) Date: Thu, 7 Mar 1996 00:55:40 +0000 In-Reply-To: "Brian N. Handy"'s message of Mar 6, 3:31pm X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: "Brian N. Handy" , Terry Lambert Subject: Re: Whee! Page Fault! Cc: freebsd-current@FreeBSD.ORG Sender: owner-current@FreeBSD.ORG Precedence: bulk > From: "Brian N. Handy" > Date: Wed 6 Mar, 1996 > Subject: Re: Whee! Page Fault! > 0xf0103a84 _cd9660_readdir > 0xf0103f34 _cd9660_readlink > > Terry scores. Recall, I was doing an 'ls' at the time of the offending > kernel panic. I can reliably reproduce this (see the message "reproducible fatal trap 12" I just mailed to this list). Must be some clue in this "coincidence", since the cd9660 code hasn't changed since early December... The last CTM delta I applied and built included the change to take sys/vm/swap_pager.c to revision 1.63. Mark. From owner-freebsd-current Wed Mar 6 17:52:49 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA25921 for current-outgoing; Wed, 6 Mar 1996 17:52:49 -0800 (PST) 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 RAA25820 Wed, 6 Mar 1996 17:52:26 -0800 (PST) Received: from clipper.cb.att.com by ig4.att.att.com id AA05294; Wed, 6 Mar 96 18:47:28 EST Received: by clipper.cb.att.com (4.1/EMS-1.1 SunOS) id AA20415; Wed, 6 Mar 96 16:42:00 EST From: Daniel.M.Obrien@att.com To: ejc@naserver1.cb.att.com, pst@shockwave.com Cc: freebsd-current@FreeBSD.org, joerg_wunsch@uriah.heep.sax.de, committers@FreeBSD.org, terry@lambert.org, jkh@time.cdrom.com Received: from cbsky.cb.att.com by clipper.cb.att.com (4.1/EMS-1.1 SunOS) id AA20391; Wed, 6 Mar 96 16:41:53 EST Received: by cbsky.cb.att.com (5.x/EMS-1.1 client.cf 1/8/94 (SMI-4.1/SVR4)) id AA10817; Wed, 6 Mar 1996 16:41:51 -0500 Date: Wed, 6 Mar 1996 16:41:51 -0500 Original-From: dob@clipper.cb.att.com Message-Id: <9603062141.AA10817@cbsky.cb.att.com> Original-To: ejc@nasvr1.cb.att.com, pst@shockwave.com Subject: Re: Paul's rules of order for committers (Re: -current submitting policys) Original-Cc: freebsd-current@FreeBSD.org, joerg_wunsch@uriah.heep.sax.de, committers@FreeBSD.org, terry@lambert.org, jkh@time.throck.com X-Sun-Charset: US-ASCII Sender: owner-current@FreeBSD.org Precedence: bulk > (b) don't commit non-functional code > - it's not ok to commit stuff that doesn't work. if you're working > on something and want to let people know there is work-in-progress, > just send mail to committers or current or hackers as appropriate. > if you want people to test something, put it up separately for ftp > - it's ok to commit stuff that doesn't quite work that is NEW, as > long as it's not linked into the system -- this should only be > done for collaborative efforts that are complex enough that using > CVS as a go-between is a big win. (this is the exception rather than > the rule). One observation I have made after 1) recently experiencing a ``broken -current'' (Sig 11's), and 2) watching submits really, really close (waiting for a fix), what disturbs me most are consecutive submissions saying ``Did this...'' and then ``Oops, shouldn't have done that...'' I guess it is good that the ``fix'' is turned around quickly, but what bothers me is that I'm left with the feeling that the source submission process (source tree) is being used as a place to park changes rather than parking them locally (on developer's system), and compiling & soaking them on the developer's system. (Thus bending Paul's unwritten rules above.) If the ``Oops'' submission didn't happen in time, nothing prevents me and others from pulling the changes and installing them into our systems. If the submitter found the ``Oops'' so quickly, why wasn't it found before the original submitting? My minds eye suggests the process being followed is 1) make change, 2) submit, 3) try it, 4) ``Oops'', 5) make new change, 6) submit, 7) try it.... This is based on my anecdotal observations of submits. I don't mind being a guinea pig testing code on my ``unique'' system, but would rather not be the first one to try something new... unless it's code I changed :-) Thanks for listening. Now back to lurking... Dan O'Brien Lucent Technologies (Bell Labs Innovations) Columbus, OH USA From owner-freebsd-current Wed Mar 6 18:20:35 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA01064 for current-outgoing; Wed, 6 Mar 1996 18:20:35 -0800 (PST) Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id SAA01005 Wed, 6 Mar 1996 18:20:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by Root.COM (8.6.12/8.6.5) with SMTP id SAA25870; Wed, 6 Mar 1996 18:20:41 -0800 Message-Id: <199603070220.SAA25870@Root.COM> X-Authentication-Warning: implode.Root.COM: Host localhost didn't use HELO protocol To: Daniel.M.Obrien@att.com cc: ejc@naserver1.cb.att.com, freebsd-current@FreeBSD.org, committers@FreeBSD.org Subject: Re: Paul's rules of order for committers (Re: -current submitting policys) In-reply-to: Your message of "Wed, 06 Mar 1996 16:41:51 EST." <9603062141.AA10817@cbsky.cb.att.com> From: David Greenman Reply-To: davidg@Root.COM Date: Wed, 06 Mar 1996 18:20:41 -0800 Sender: owner-current@FreeBSD.org Precedence: bulk >My minds eye suggests the process being followed is 1) make change, 2) submit, >3) try it, 4) ``Oops'', 5) make new change, 6) submit, 7) try it.... >This is based on my anecdotal observations of submits. Of course it's not at all this simple. There's a lot more to the process than meets the eye. Most of the FreeBSD developers have fairly lousy Internet connectivity and this can lead to portions of a patch being left out or uncommitted. We (almost?) always test things before committing them, but what works on my machine may very well not work on yours and the reasons for this can be extremely complex. Of course there is room for improvement, but I think we generally have very high standards for our source code management and I think most of the time we do a pretty damn good job about it. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-current Wed Mar 6 18:31:53 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA03178 for current-outgoing; Wed, 6 Mar 1996 18:31:53 -0800 (PST) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id SAA03171 Wed, 6 Mar 1996 18:31:47 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.6.11/8.6.9) id VAA02388; Wed, 6 Mar 1996 21:27:24 GMT From: "John S. Dyson" Message-Id: <199603062127.VAA02388@dyson.iquest.net> Subject: Re: Paul's rules of order for committers (Re: -current submitting policys) To: Daniel.M.Obrien@att.com Date: Wed, 6 Mar 1996 21:27:24 +0000 () Cc: ejc@naserver1.cb.att.com, pst@shockwave.com, freebsd-current@FreeBSD.org, joerg_wunsch@uriah.heep.sax.de, committers@FreeBSD.org, terry@lambert.org, jkh@time.cdrom.com In-Reply-To: <9603062141.AA10817@cbsky.cb.att.com> from "Daniel.M.Obrien@att.com" at Mar 6, 96 04:41:51 pm X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org Precedence: bulk > > I guess it is good that the ``fix'' is turned around quickly, but what bothers > me is that I'm left with the feeling that the source submission process > (source tree) is being used as a place to park changes rather than parking > them locally (on developer's system), and compiling & soaking them on the > developer's system. (Thus bending Paul's unwritten rules above.) > Unfortunately, the problem that we have is that each developer has only one, two, and perhaps fortunate ones have three systems to develop on. The VM changes that I added had been run on my system for about 2wks, and sent them to another person for them to use for about 1wk. Problems leak through, and I try to fix the problems that I create very quickly. I have some (evil) soak tests that I run, much worse than the SVR4 tests that I used to run at work (SVR4 would practically stop or break under the load that I put my system under.) -current is not the latest working code, but the latest attempted working code. Those that run -current in production need to track it very carefully and grab stable copies. We don't have a good, formal policy for backing changes out, and I am willing to back the VM changes out in a few days if the system continues to break. In fact, it might be useful to pull a few back one-by-one until the problems go away. AFAIK, -stable is the only "released" code. John From owner-freebsd-current Wed Mar 6 19:07:16 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id TAA11247 for current-outgoing; Wed, 6 Mar 1996 19:07:16 -0800 (PST) Received: from butterfly.inna.net (butterfly.inna.net [206.151.66.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id TAA11222 for ; Wed, 6 Mar 1996 19:07:06 -0800 (PST) Received: (from tom@localhost) by butterfly.inna.net (8.6.12/8.6.12) id WAA05695; Wed, 6 Mar 1996 22:07:57 GMT Date: Wed, 6 Mar 1996 22:07:56 +0000 () From: Thomas Arnold To: freebsd-current@freebsd.org Subject: Oh boy I'm gonna get flamed... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk Is there a FAQ or a "Getting Started with Current for People who Really Shouldn't but need a new feature badly" text available??? We have tried the latest Snapshot without success, we wind up missing tons of minor little binaries... I have also tried SUPing to Current and doing a make world but it always winds up missing something and ending the compile. Thanks! -Tom Arnold / No relation to Rosanne From owner-freebsd-current Wed Mar 6 20:01:39 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id UAA21234 for current-outgoing; Wed, 6 Mar 1996 20:01:39 -0800 (PST) Received: from veda.is (root@veda.is [193.4.230.1]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id UAA21203 for ; Wed, 6 Mar 1996 20:01:31 -0800 (PST) Received: (from adam@localhost) by veda.is (8.7.4/8.7.3) id EAA14075 for freebsd-current@freebsd.org; Thu, 7 Mar 1996 04:01:14 GMT From: Adam David Message-Id: <199603070401.EAA14075@veda.is> Subject: config -g KERNEL To: freebsd-current@freebsd.org Date: Thu, 7 Mar 1996 04:01:10 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL10 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org Precedence: bulk I tried making a kernel with debug symbols, using config -g and strip -x. While booting from this kernel, there were problems running some of the programs during /etc/rc processing, and LKMs failed to load. These same LKMs and programs work fine when the same kernel is built without debug symbols. Is support for this currently broken, or is there some important factor which I have overlooked? # cd /sys/i386/conf # config -g KERNEL # cd ../../compile/KERNEL # make depend && make all # cp kernel ../kernel.debug # strip -x kernel # make install Ideas? -- Adam David From owner-freebsd-current Wed Mar 6 21:10:50 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA00897 for current-outgoing; Wed, 6 Mar 1996 21:10:50 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id VAA00891 for ; Wed, 6 Mar 1996 21:10:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.4/8.6.9) with SMTP id VAA18379; Wed, 6 Mar 1996 21:10:35 -0800 (PST) To: Thomas Arnold cc: freebsd-current@FreeBSD.org Subject: Re: Oh boy I'm gonna get flamed... In-reply-to: Your message of "Wed, 06 Mar 1996 22:07:56 GMT." Date: Wed, 06 Mar 1996 21:10:34 -0800 Message-ID: <18377.826175434@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.org Precedence: bulk > We have tried the latest Snapshot without success, we wind up missing > tons of minor little binaries... I have also tried SUPing to Current and Uh, really? That shouldn't have happened - can you tell me a little more about what you tried and what was missing? Jordan From owner-freebsd-current Wed Mar 6 22:14:58 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA07771 for current-outgoing; Wed, 6 Mar 1996 22:14:58 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id WAA07761 for ; Wed, 6 Mar 1996 22:14:50 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id QAA00234; Thu, 7 Mar 1996 16:51:13 +1030 From: Michael Smith Message-Id: <199603070621.QAA00234@genesis.atrad.adelaide.edu.au> Subject: Re: Oh boy I'm gonna get flamed... To: tom@inna.net (Thomas Arnold) Date: Thu, 7 Mar 1996 16:51:12 +1030 (CST) Cc: freebsd-current@FreeBSD.ORG In-Reply-To: from "Thomas Arnold" at Mar 6, 96 10:07:56 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG Precedence: bulk Thomas Arnold stands accused of saying: > > Is there a FAQ or a "Getting Started with Current for People who Really > Shouldn't but need a new feature badly" text available??? It's called "experience". Such a guide would be an n-complete work. Just at the moment, it's easier : Install 2.1R. Sup -current. Boot everyone off the machine. cd to /usr/src and 'make world' make a new kernel, install it reboot. I've done this twice now in the last couple of days, and it works fine. > We have tried the latest Snapshot without success, we wind up missing > tons of minor little binaries... I have also tried SUPing to Current and > doing a make world but it always winds up missing something and ending > the compile. Such as? Some real examples would help here. As it is, you're currently wearing the 'luser' tag because it worked for _us_, and you can't show anything concrete. Prove us wrong. Please! > -Tom Arnold / No relation to Rosanne -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[ From owner-freebsd-current Wed Mar 6 22:51:53 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA10378 for current-outgoing; Wed, 6 Mar 1996 22:51:53 -0800 (PST) Received: from ki.net (root@ki.net [142.77.249.8]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id WAA10367 for ; Wed, 6 Mar 1996 22:51:48 -0800 (PST) Received: (from scrappy@localhost) by ki.net (8.7.4/8.7.4) id BAA03165; Thu, 7 Mar 1996 01:50:25 -0500 (EST) Date: Thu, 7 Mar 1996 01:50:23 -0500 (EST) From: "Marc G. Fournier" To: Adam David cc: freebsd-current@freebsd.org Subject: Re: config -g KERNEL In-Reply-To: <199603070401.EAA14075@veda.is> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk On Thu, 7 Mar 1996, Adam David wrote: > I tried making a kernel with debug symbols, using config -g and strip -x. I believe this should be 'strip -d', not -x... Marc G. Fournier | POP Mail Telnet Acct DNS Hosting System | WWW Services Database Services | Knowledge, Administrator | | Information and scrappy@ki.net | WWW: http://www.ki.net | Communications, Inc From owner-freebsd-current Thu Mar 7 00:01:19 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA16438 for current-outgoing; Thu, 7 Mar 1996 00:01:19 -0800 (PST) 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 AAA16430 Thu, 7 Mar 1996 00:01:13 -0800 (PST) Received: from bunyip.cc.uq.oz.au by bunyip.cc.uq.oz.au id <25321-0@bunyip.cc.uq.oz.au>; Thu, 7 Mar 1996 18:00:48 +1000 Received: from netfl15a.devetir.qld.gov.au by pandora.devetir.qld.gov.au (8.6.10/DEVETIR-E0.3a) with ESMTP id RAA07330; Thu, 7 Mar 1996 17:18:15 +1000 Received: from localhost by netfl15a.devetir.qld.gov.au (8.6.8.1/DEVETIR-0.1) id HAA09603; Thu, 7 Mar 1996 07:21:56 GMT Message-Id: <199603070721.HAA09603@netfl15a.devetir.qld.gov.au> X-Mailer: exmh version 1.6.5 12/11/95 To: bugs@freebsd.org, current@freebsd.org Subject: ffs_valloc: dup alloc 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: Thu, 07 Mar 1996 17:21:55 +1000 From: Stephen Hocking Sender: owner-current@freebsd.org Precedence: bulk I've seen a bunch of panics on a couple of machine from kernels built just recently (6th Mar, 7th Mar). They varied in size from 8Mb to 16Mb. The panics occur at _ffs_valloc(efbffdc4,0,efbffe30,efbfff0c,efbffdb8) at _ffs_valloc+0x133 called from _ufs_makeinode. I'd tell you more except that the machine died as I was typing in the details from the other one's crash! Stephen -- I do not speak for the Worker's Compensation Board of Queensland - They don't pay me enough for that! From owner-freebsd-current Thu Mar 7 00:01:37 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA16470 for current-outgoing; Thu, 7 Mar 1996 00:01:37 -0800 (PST) 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 AAA16445 Thu, 7 Mar 1996 00:01:19 -0800 (PST) Received: from bunyip.cc.uq.oz.au by bunyip.cc.uq.oz.au id <25329-0@bunyip.cc.uq.oz.au>; Thu, 7 Mar 1996 18:00:55 +1000 Received: from netfl15a.devetir.qld.gov.au by pandora.devetir.qld.gov.au (8.6.10/DEVETIR-E0.3a) with ESMTP id RAA07787; Thu, 7 Mar 1996 17:55:00 +1000 Received: from localhost by netfl15a.devetir.qld.gov.au (8.6.8.1/DEVETIR-0.1) id HAA10277; Thu, 7 Mar 1996 07:58:40 GMT Message-Id: <199603070758.HAA10277@netfl15a.devetir.qld.gov.au> X-Mailer: exmh version 1.6.5 12/11/95 To: bugs@freebsd.org, current@freebsd.org Subject: Re: ufs_valloc: dup whatever 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: Thu, 07 Mar 1996 17:58:39 +1000 From: Stephen Hocking Sender: owner-current@freebsd.org Precedence: bulk Just noticed something really curious - I was running two makes at once, and somehow the output of one compilation (an assembler file of all things) appeared in the middle of a .depend file of a make depend! Help! Terry, John & David, what's going on? Stephen -- I do not speak for the Worker's Compensation Board of Queensland - They don't pay me enough for that! From owner-freebsd-current Thu Mar 7 00:08:07 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA17062 for current-outgoing; Thu, 7 Mar 1996 00:08:07 -0800 (PST) Received: from veda.is (root@veda.is [193.4.230.1]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id AAA16929 for ; Thu, 7 Mar 1996 00:08:00 -0800 (PST) Received: (from adam@localhost) by veda.is (8.7.4/8.7.3) id IAA07027; Thu, 7 Mar 1996 08:04:55 GMT From: Adam David Message-Id: <199603070804.IAA07027@veda.is> Subject: Re: config -g KERNEL To: scrappy@ki.net (Marc G. Fournier) Date: Thu, 7 Mar 1996 08:04:54 +0000 (GMT) Cc: freebsd-current@freebsd.org In-Reply-To: from "Marc G. Fournier" at "Mar 7, 96 01:50:23 am" X-Mailer: ELM [version 2.4ME+ PL10 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org Precedence: bulk > > I tried making a kernel with debug symbols, using config -g and strip -x. > > I believe this should be 'strip -d', not -x... Thanks Marc :) If so, then handbook223 is incorrect and needs updating, along with any other such references that might be in the FAQ or handbook. Does anyone else think (with me) that /sys/compile/KERNEL/Makefile should contain the steps necessary for installing a stripped debug kernel, at least in the 'config -g' case? -- Adam David From owner-freebsd-current Thu Mar 7 01:16:25 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA21391 for current-outgoing; Thu, 7 Mar 1996 01:16:25 -0800 (PST) Received: from haywire.DIALix.COM (haywire.DIALix.COM [192.203.228.65]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id BAA21384 for ; Thu, 7 Mar 1996 01:16:17 -0800 (PST) Received: (from news@localhost) by haywire.DIALix.COM (8.7.4/8.6.12) id RAA05874 for freebsd-current@freebsd.org; Thu, 7 Mar 1996 17:17:20 +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: 7 Mar 96 09:14:55 GMT From: peter@jhome.DIALix.COM (Peter Wemm) Message-ID: Organization: DIALix Services, Perth, Australia. References: <199603061143.NAA29815@grumble.grondar.za>, <15204.826114492@time.cdrom.com> Subject: Re: 2.2-960226-SNAP now on ftp.freebsd.org Sender: owner-current@freebsd.org Precedence: bulk jkh@time.cdrom.com (Jordan K. Hubbard) writes: >> Proposal: why do we not just get all of them - libc.so.2.2, libgcc.so.261.0 >> etc and make one compat2.n out of them (or is that done already?)? I'll do >Sounds fine to me! >> it if you fill me in on what you did... >Uh, you'll be disappointed - I looked at which libraries were bumped >between the last and current releases and packed the old versions into >a root-relative tarball by hand. That's all! :-) Just a reminder to everybody.. We do *not* need compat libraries for minor number "bumps". eg: when libutil.so.2.0 is bumped to .2.1, you do **not** add a libutil.so.2.0 to the compat dist. The dynamic linker always takes the highest minor version number anyway, so it's just wasting space. However, if we do a "major" bump, eg: from libc.so.2.2 to libc.so.3.0, we _do_ need to put the most recent version of libc.so.2.2 into the compat dist that we can find. And above all, *never* overwrite the shipped libraries with the old release. eg: for 2.0.5 and (I think) 2.1, all the lib*.so.2.0 files were spammed by the buggy old 2.0-RELEASE libraries. This caused tremendous confustion with the cross version incompatabities, remember the infamous "ld: telnetd: undefined symbol _des_set_key" etc? This was caused by the compat dist placing an old libkrb.so.2.0 over the "latest" version of libkrb.so.2.0 or something like that. At this point, the only difference between the compat dists for -stable snap's and the -current snap's, is that the one for -current should have a libc.so.2.2 in it while -stable should not. There should only be about 6 libraries in the tarball from memory. The -current snap's should have the most recent libc.so.2.2 that can be located from the 2.2-current tree, because the -current libc.so.2.2 has phkmalloc in it, while -stable has the expensive memory-hungry malloc. > Jordan Cheers, -Peter From owner-freebsd-current Thu Mar 7 01:39:06 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA22553 for current-outgoing; Thu, 7 Mar 1996 01:39:06 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id BAA22548 Thu, 7 Mar 1996 01:39:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.4/8.6.9) with SMTP id BAA00383; Thu, 7 Mar 1996 01:38:08 -0800 (PST) To: Stephen Hocking cc: bugs@freebsd.org, current@freebsd.org Subject: Re: ufs_valloc: dup whatever In-reply-to: Your message of "Thu, 07 Mar 1996 17:58:39 +1000." <199603070758.HAA10277@netfl15a.devetir.qld.gov.au> Date: Thu, 07 Mar 1996 01:38:08 -0800 Message-ID: <381.826191488@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org Precedence: bulk > appeared in the middle of a .depend file of a make depend! Help! Terry, John & > David, what's going on? Now you've done it - you've evoked the names of Terry, John and David in the same sentence. I trust you didn't actually want a reply? :-) [Yes, Yes, I'm _just kidding_! :-)] Jordan From owner-freebsd-current Thu Mar 7 01:53:32 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA23397 for current-outgoing; Thu, 7 Mar 1996 01:53:32 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id BAA23388 for ; Thu, 7 Mar 1996 01:53:15 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id KAA26413; Thu, 7 Mar 1996 10:51:06 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id KAA28713; Thu, 7 Mar 1996 10:51:06 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id KAA16358; Thu, 7 Mar 1996 10:06:30 +0100 (MET) From: J Wunsch Message-Id: <199603070906.KAA16358@uriah.heep.sax.de> Subject: Re: Oh boy I'm gonna get flamed... To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Thu, 7 Mar 1996 10:06:30 +0100 (MET) Cc: tom@inna.net (Thomas Arnold) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from "Thomas Arnold" at Mar 6, 96 10:07:56 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org Precedence: bulk As Thomas Arnold wrote: > Is there a FAQ or a "Getting Started with Current for People who Really > Shouldn't but need a new feature badly" text available??? With a bit of care and hand-munging your /etc files, you should be able to bootstrap by installing the new source, compile and install the new config, configure and install a new kernel, then run a ``make world''. If you are paranoid, run it in single-user mode only. (I don't, though i have to live with things like a broken ps(1) during the compilation.) -- 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 Mar 7 03:00:23 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA27704 for current-outgoing; Thu, 7 Mar 1996 03:00:23 -0800 (PST) Received: from nervosa.com (root@nervosa.com [192.187.228.86]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id DAA27693 for ; Thu, 7 Mar 1996 03:00:17 -0800 (PST) Received: from nervosa.com (coredump@onyx.nervosa.com [10.0.0.1]) by nervosa.com (8.7.5/nervosa.com.2) with SMTP id CAA01046 for ; Thu, 7 Mar 1996 02:51:22 -0800 (PST) Date: Thu, 7 Mar 1996 02:51:22 -0800 (PST) From: invalid opcode To: FreeBSD-current Subject: changes to /etc/csh.* Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk I'm submitting my versions of /etc/csh.{login,logout,cshrc} as a potential new base. I suggest moving away from .cshrc, .login, .logout, and implementing it into the system /etc/csh.* files. This way the user can specify truly local options in .cshrc, .login, .etc instead of every user having the same .cshrc and .login in their home dirs. -- cut here ------------------------------------------------------- /etc/csh.login: #!/bin/csh if ( ($TERM == "") || ($TERM == "unknown") ) setenv TERM cons25 /bin/stty sane erase '' crt -tostop if ( $user == root ) then set path = ( /bin /sbin /usr/{bin,sbin,local/{bin,sbin},X11R6/bin} . ) else set path = ( /bin /usr/{bin,local/bin,X11R6/bin} . ) endif -- end ------------------------------------------------------------ -- cut here ------------------------------------------------------- /etc/csh.cshrc: #!/bin/csh if ( -e /etc/csh.alias ) source /etc/csh.alias setenv PAGER /usr/local/bin/less setenv HOSTNAME `/bin/hostname -s` setenv BLOCKSIZE 1K limit coredumpsize 0 if ( $?prompt ) then umask 2 set history = 100 set mail = /var/mail/$USER set notify if ( $?tcsh ) then set prompt = "[%n@%m] %B%~%#%b " set autolist set listjobs = long set nobeep if ( -e /etc/csh.bindkey ) source /etc/csh.bindkey endif endif -- end ------------------------------------------------------------ -- cut here ------------------------------------------------------- /etc/csh.logout: #!/bin/csh /bin/stty sane /usr/bin/clear -- end ------------------------------------------------------------ == Chris Layne ============================================================= == coredump@nervosa.com ================ http://www.nervosa.com/~coredump == From owner-freebsd-current Thu Mar 7 03:00:25 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA27723 for current-outgoing; Thu, 7 Mar 1996 03:00:25 -0800 (PST) Received: from nervosa.com (root@nervosa.com [192.187.228.86]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id DAA27703 for ; Thu, 7 Mar 1996 03:00:22 -0800 (PST) Received: from nervosa.com (coredump@onyx.nervosa.com [10.0.0.1]) by nervosa.com (8.7.5/nervosa.com.2) with SMTP id CAA00820 for ; Thu, 7 Mar 1996 02:14:05 -0800 (PST) Date: Thu, 7 Mar 1996 02:14:04 -0800 (PST) From: invalid opcode To: FreeBSD-current Subject: changes to /etc/ttys Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk I'm submitting a patch for /etc/ttys to make ttyv0 the default console of which no getty process runs on. ttyv[1-3] are now the default getty logins. -- cut here ------------------------------------------------------- *** ttys.orig Thu Mar 7 01:36:45 1996 --- ttys Thu Mar 7 01:35:43 1996 *************** *** 8,16 **** console none unknown off secure # ! ttyv0 "/usr/libexec/getty Pc" cons25 on secure # Virtual terminals ttyv1 "/usr/libexec/getty Pc" cons25 on secure ttyv2 "/usr/libexec/getty Pc" cons25 on secure ! ttyv3 "/usr/libexec/getty Pc" cons25 off secure # Serial terminals ttyd0 "/usr/libexec/getty std.9600" unknown off secure --- 8,17 ---- console none unknown off secure # ! ttyv0 "/usr/libexec/getty Pc" cons25 off secure # Virtual terminals ttyv1 "/usr/libexec/getty Pc" cons25 on secure ttyv2 "/usr/libexec/getty Pc" cons25 on secure ! ttyv3 "/usr/libexec/getty Pc" cons25 on secure # Serial terminals ttyd0 "/usr/libexec/getty std.9600" unknown off secure -- end ------------------------------------------------------------ == Chris Layne ============================================================= == coredump@nervosa.com ================ http://www.nervosa.com/~coredump == From owner-freebsd-current Thu Mar 7 06:20:55 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA10244 for current-outgoing; Thu, 7 Mar 1996 06:20:55 -0800 (PST) Received: from nixpbe.pdb.sni.de (mail.sni.de [192.109.2.33]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id GAA10236 for ; Thu, 7 Mar 1996 06:20:49 -0800 (PST) Received: (from nerv@localhost) by nixpbe.pdb.sni.de (8.6.12/8.6.12) id PAA05400 for freebsd-current@freebsd.org; Thu, 7 Mar 1996 15:20:27 +0100 Message-Id: <199603071420.PAA05400@nixpbe.pdb.sni.de> Subject: Re: config -g KERNEL To: adam@veda.is (Adam David) Date: Thu, 7 Mar 96 15:16:57 MET From: Greg Lehey Cc: freebsd-current@freebsd.org, freebsd-doc@freebsd.org (FreeBSD Documenters) In-Reply-To: <199603070804.IAA07027@veda.is>; from "Adam David" at Mar 7, 96 8:04 am X-Mailer: xmail 2.4 (based on ELM 2.2 PL16) Sender: owner-current@freebsd.org Precedence: bulk >>> I tried making a kernel with debug symbols, using config -g and strip -x. >> >> I believe this should be 'strip -d', not -x... > > Thanks Marc :) > If so, then handbook223 is incorrect and needs updating, along with any other > such references that might be in the FAQ or handbook. I don't have a machine here to check, but this is definitely one of the problems. One strip option removes local symbols, including a number which have recently been declared static, but which are still used by some programs. Since this time, you need the other option. > Does anyone else think (with me) that /sys/compile/KERNEL/Makefile should > contain the steps necessary for installing a stripped debug kernel, at least > in the 'config -g' case? Definitely. BSDI has done this all along. Greg From owner-freebsd-current Thu Mar 7 06:57:40 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA12494 for current-outgoing; Thu, 7 Mar 1996 06:57:40 -0800 (PST) Received: from aztec.co.za (aztec.co.za [196.7.70.131]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id GAA12489 for ; Thu, 7 Mar 1996 06:57:34 -0800 (PST) Received: from pcm.co.za [196.3.226.39] by aztec.co.za with smtp (Smail3.1.29.1 #2) id m0tuh7F-000aslC; Thu, 7 Mar 96 16:56 EET Received: from PCM1/MERC_Q by pcm.co.za (Mercury 1.21); 7 Mar 96 16:47:22 +2 Received: from MERC_Q by PCM1 (Mercury 1.21); 7 Mar 96 16:47:10 +2 From: "Irvine Short" Organization: Professional Computer Manufacturers To: freebsd-current@freebsd.org Date: Thu, 7 Mar 1996 16:47:02 +2 Subject: How to get new user ppp from current into release? X-Confirm-Reading-To: "Irvine Short" X-pmrqc: 1 Priority: normal X-mailer: Pegasus Mail for Windows (v2.23) Message-ID: <7C5DA0A71FA@pcm.co.za> Sender: owner-current@freebsd.org Precedence: bulk Hi All I've posted a similar msg to questions already. It seems that I need patches to ppp that are in current, notably the ones by Doug Rabson for stability and the ones by Nate Williams for the ddial option. How would I get these into my 2.1.0-RELEASE system? I am a complete newbie when it comes to these things... I do know ebough to compile a custom kernel, but that is extremely well documented. All help welcomed! Regards, Irvine Short http://www.pcm.co.za/homepage/ishort/irv_home.html Technical Support Engineer Professional Computer Manufacturers Amalgamated House, Jordaan St Cape Town, South Africa Tel: ++27-21-235084 Fax ++27-21-235089 From owner-freebsd-current Thu Mar 7 08:05:31 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA18142 for current-outgoing; Thu, 7 Mar 1996 08:05:31 -0800 (PST) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id IAA18136 for ; Thu, 7 Mar 1996 08:05:24 -0800 (PST) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id JAA01191; Thu, 7 Mar 1996 09:07:28 -0700 Date: Thu, 7 Mar 1996 09:07:28 -0700 From: Nate Williams Message-Id: <199603071607.JAA01191@rocky.sri.MT.net> To: invalid opcode Cc: FreeBSD-current Subject: Re: changes to /etc/csh.* In-Reply-To: References: Sender: owner-current@FreeBSD.org Precedence: bulk > I'm submitting my versions of /etc/csh.{login,logout,cshrc} as a > potential new base. Most of these look good, but this is unacceptable for a stock system since less isn't installed. > setenv PAGER /usr/local/bin/less ^^^^^^^^^^^^^^^^^^^ Nate From owner-freebsd-current Thu Mar 7 08:15:10 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA18796 for current-outgoing; Thu, 7 Mar 1996 08:15:10 -0800 (PST) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id IAA18789 for ; Thu, 7 Mar 1996 08:15:04 -0800 (PST) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id JAA01248; Thu, 7 Mar 1996 09:17:33 -0700 Date: Thu, 7 Mar 1996 09:17:33 -0700 From: Nate Williams Message-Id: <199603071617.JAA01248@rocky.sri.MT.net> To: "Irvine Short" Cc: freebsd-current@freebsd.org Subject: Re: How to get new user ppp from current into release? In-Reply-To: <7C5DA0A71FA@pcm.co.za> References: <7C5DA0A71FA@pcm.co.za> Sender: owner-current@freebsd.org Precedence: bulk > I've posted a similar msg to questions already. It seems that I need > patches to ppp that are in current, notably the ones by Doug Rabson > for stability and the ones by Nate Williams for the ddial option. Actually, you want the code from -stable, and not from -current. > How would I get these into my 2.1.0-RELEASE system? I am a complete > newbie when it comes to these things... ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-stable/src/usr.sbin/ppp/* Download all of these files and use them to replace the version on your box (you may just want to create a back directory just in case), and then re-build and re-install ppp and see if it helps. Nate From owner-freebsd-current Thu Mar 7 08:46:10 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA20605 for current-outgoing; Thu, 7 Mar 1996 08:46:10 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id IAA20600 Thu, 7 Mar 1996 08:46:07 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA14037; Thu, 7 Mar 1996 09:41:17 -0700 From: Terry Lambert Message-Id: <199603071641.JAA14037@phaeton.artisoft.com> Subject: Re: 2842 and the disappearing file-system :-( To: gibbs@freefall.freebsd.org (Justin T. Gibbs) Date: Thu, 7 Mar 1996 09:41:16 -0700 (MST) Cc: terry@lambert.org, imb@scgt.oz.au, stable@FreeBSD.ORG, current@FreeBSD.ORG In-Reply-To: <199603062342.PAA10384@freefall.freebsd.org> from "Justin T. Gibbs" at Mar 6, 96 03:42:39 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 Precedence: bulk > >> How are they kludged? I haven't seen a single report of eisaconf > >> without detected devices causing problems in a system. Furthermore, > >> if you don't have a 2842 or and eisa machine, you can disable the > >> eisa0 device in your config file. If you do have a 2842, you'd > >> have to read the same bytes of the I/O address space, so it buys > >> you nothing to have a separate probe for it. > > > >Maybe I'm missing something. > > I would guess you didn't even look. Have you looked at eisaconf.c? > or aic7770.c? You have guessed wrong (don't worry, this is the usual guess, and it's usually wrong). > >Why do you have to have a seperate probe? > > RTSL The *WORST* you would *POSSIBLY* need is an EISA nad an ISA stub routine. I *STILL* do not think EISA ID's should be looked for if the system doesn't claim to be an EISA bus. We have *one* example if an EISA/VLB driver where this, through the savings in code necessary to abstract the differences between the EISA and ISA configurations (which should be the same interface anyway). And that example is causing problems for people. > >Why can't you use the same probe routine address in two "driver instances"? > > Eisaconf doesn't work that way at all. You are (intentionally?) missing the point. > >And wouldn't this fix the interrrupt attach problem introduced by the > >eisaconf code in the VLB Adaptec case? > > Because the bug wasn't even in eisaconf. It was in i386/isa/isa.c. 8-P. > >You keep saying you need to duplicate cade -- I don't see it. I see > >that there is a need to duplicate ~32 bytes of data structure to get > >an EISA and non-EISA device instance. Tell me why Im wrong... > > Right now the code for dealing with the 2842 and the 2742 is one > and the same. To do what you propose would mean adding an isa probe > and doing the same looping through the slots that the eisaconf code does > already, although the 2842 probe would have to do it once for each > card probe instead of just creating the device nodes once like the > eisaconf code does. There is simply no reason to break the probe up. > It only adds complexity and code. 1) The ISA code, unless it's PnP, can't distinguish slots, so it would have a damn hard time requiring looping through them. 2) This is a VLB card, not an ISA card. I would not suggest calling the probe from ISA any more than I would suggest calling it from EISA. It is *NOT* an EISA device. 3) The ISA code needs to "create device nodes" in a similar fashion to EISA for PnP. This is a case of confusing ISA devices that can be mapped by a configuration manager with those that can't. Read the Microsoft PnP document. What I suggest is calling the probe in multiple locations with two stub routines: one EISA for eisaconf and one VLB (ISA, barring a fixed handling of VLB). If you want to call this "adding an ISA probe", fine. It's nowhere near the same order of effort as doing that, IMO. I can't fault you on the complexity argument: it will add a bit of logical complexity in the process of providing a logical abstraction. On the other hand, the abstraction can be made orthoganal so that it is easier to document and program to for other devices that can then seperate PnP mapping from driver attachment (substituting ISA PnP for probing in the same way eisaconf substitutes slot iteration for probing), so it seems like an acceptable tradeoff to me. 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 Thu Mar 7 09:11:54 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA22188 for current-outgoing; Thu, 7 Mar 1996 09:11:54 -0800 (PST) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA22150 for ; Thu, 7 Mar 1996 09:11:34 -0800 (PST) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id JAA07682; Thu, 7 Mar 1996 09:10:06 -0800 From: "Rodney W. Grimes" Message-Id: <199603071710.JAA07682@GndRsh.aac.dev.com> Subject: Re: changes to /etc/ttys To: coredump@nervosa.com (invalid opcode) Date: Thu, 7 Mar 1996 09:10:05 -0800 (PST) Cc: current@FreeBSD.org In-Reply-To: from "invalid opcode" at Mar 7, 96 02:14:04 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 Precedence: bulk > > I'm submitting a patch for /etc/ttys to make ttyv0 the default console of > which no getty process runs on. ttyv[1-3] are now the default getty logins. Why would you want to do this? This would mean that by default no login prompt would appear after a boot, something that I am sure would generate _lots_ of questions on the mailing list from users who did not know about it. What gain is there from doing this? > -- cut here ------------------------------------------------------- > *** ttys.orig Thu Mar 7 01:36:45 1996 > --- ttys Thu Mar 7 01:35:43 1996 > *************** > *** 8,16 **** > console none unknown off secure > # > ! ttyv0 "/usr/libexec/getty Pc" cons25 on secure > # Virtual terminals > ttyv1 "/usr/libexec/getty Pc" cons25 on secure > ttyv2 "/usr/libexec/getty Pc" cons25 on secure > ! ttyv3 "/usr/libexec/getty Pc" cons25 off secure > # Serial terminals > ttyd0 "/usr/libexec/getty std.9600" unknown off secure > --- 8,17 ---- > console none unknown off secure > # > ! ttyv0 "/usr/libexec/getty Pc" cons25 off secure > # Virtual terminals > ttyv1 "/usr/libexec/getty Pc" cons25 on secure > ttyv2 "/usr/libexec/getty Pc" cons25 on secure > ! ttyv3 "/usr/libexec/getty Pc" cons25 on secure > # Serial terminals > ttyd0 "/usr/libexec/getty std.9600" unknown off secure > -- end ------------------------------------------------------------ > > == Chris Layne ============================================================= > == coredump@nervosa.com ================ http://www.nervosa.com/~coredump == > -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Thu Mar 7 09:39:02 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA24233 for current-outgoing; Thu, 7 Mar 1996 09:39:02 -0800 (PST) Received: from covina.lightside.com (covina.lightside.com [198.81.209.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA24225 for ; Thu, 7 Mar 1996 09:39:00 -0800 (PST) Received: by covina.lightside.com (Smail3.1.28.1 #6) id m0tujeR-0004I8C; Thu, 7 Mar 96 09:38 PST Date: Thu, 7 Mar 1996 09:38:51 -0800 (PST) From: Jake Hamby To: current@FreeBSD.ORG Subject: 3/3 SNAP panics before sysinstall! Help!!! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG Precedence: bulk I tried the 2.2-960303-SNAP boot.flp last night, and it repeatedly crashed with the following message, just as sysinstall was about to start: panic: unwire: page not in pmap Syncing disks... My system is a 486DX4/100, AMI BIOS, 24 MB RAM, with an 850MB IDE drive, a 700MB Quantum SCSI connected to an Adaptec 2842VL, and a SCSI Iomega Zip drive as ID#5 on the same controller. Since everything probes properly in the kernel, I suspect this is a bug in sysinstall, perhaps related to the probing of my hard drives (IDE+SCSI combination confusing it?). I haven't tried the older snap, but the 2.1-RELEASE boot floppy works fine. I should also note that my ATAPI IDE CDROM isn't detected by this SNAP floppy either, although it does detect the secondary controller it is on. This is the same behavior as 2.1-RELEASE's floppy, which doesn't surprise me, since nobody has worked on the driver code. Doesn't matter much, since I'll probably buy a SCSI CDROM at the next computer show (1-1/2 weeks away)... Please send help on why this SNAP refuses to boot! ---Jake From owner-freebsd-current Thu Mar 7 10:00:47 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA25853 for current-outgoing; Thu, 7 Mar 1996 10:00:47 -0800 (PST) Received: from desiree.teleport.com (desiree.teleport.com [192.108.254.21]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA25848 for ; Thu, 7 Mar 1996 10:00:44 -0800 (PST) Received: from linda.teleport.com (mrl@linda.teleport.com [192.108.254.12]) by desiree.teleport.com (8.6.12/8.6.9) with ESMTP id KAA28512; Thu, 7 Mar 1996 10:00:41 -0800 From: Mostyn/Annabella Received: (mrl@localhost) by linda.teleport.com (8.6.12/8.6.12) id KAA10406; Thu, 7 Mar 1996 10:00:40 -0800 Message-Id: <199603071800.KAA10406@linda.teleport.com> Subject: PPP sometimes kills the OS To: current@freebsd.org Date: Thu, 7 Mar 1996 10:00:40 -0800 (PST) Cc: mrl@teleport.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-current@freebsd.org Precedence: bulk As Mark Valentine recenetly said -> "For two or three weeks I've been getting a hang (in X) or silent reboot (not in X) *only* when bringing my PPP link up or down (about once every 4-5 connections, with kernel PPP)." I concur with a -current about two weeks old. Dropping into ddb shows "sleepy" processes flag stat wmesg wchan sleep 4006 3 lockrd f0246068 ppd 6 3 lockrd f0246068 kermit 106 3 lockrd f0246068 .... .... Mostyn Lewis From owner-freebsd-current Thu Mar 7 10:06:00 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA26177 for current-outgoing; Thu, 7 Mar 1996 10:06:00 -0800 (PST) Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA26152 Thu, 7 Mar 1996 10:05:55 -0800 (PST) Message-Id: <199603071805.KAA26152@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: Host localhost.cdrom.com [127.0.0.1] didn't use HELO protocol To: Terry Lambert cc: imb@scgt.oz.au, stable@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: 2842 and the disappearing file-system :-( In-reply-to: Your message of "Thu, 07 Mar 1996 09:41:16 MST." <199603071641.JAA14037@phaeton.artisoft.com> Date: Thu, 07 Mar 1996 10:05:55 -0800 From: "Justin T. Gibbs" Sender: owner-current@FreeBSD.ORG Precedence: bulk >> I would guess you didn't even look. Have you looked at eisaconf.c? >> or aic7770.c? > >You have guessed wrong (don't worry, this is the usual guess, and it's >usually wrong). Perhaps you read it last night, but you certainly acted as if you thought eisaconf worked just like isa_configure() in all of your mail yesturday. > >> >Why do you have to have a seperate probe? >> >> RTSL > >The *WORST* you would *POSSIBLY* need is an EISA nad an ISA stub >routine. I *STILL* do not think EISA ID's should be looked for if >the system doesn't claim to be an EISA bus. An eisa and isa stub routine to what? The routine that collects the IDs? The routine that matches drivers to ids? The routinesx for irq/ioport, etc registration? It sounds like you want me to duplicate the probe in aic7770.c, but prepend everything with isa_ instead of eisa_. All for one card that acts just like an eisa card? What a waste of code and effort. Most isa cards don't care about the eisa ids, so why create yet another interface to them for the few isa cards that do. No matter your aversion to looking for eisa ids in a non eisa machine, it will have to happen regardless if you have a 2842 in your machine. If you don't like it, or don't need it, disable eisa0. >We have *one* example if an EISA/VLB driver where this, through the >savings in code necessary to abstract the differences between the >EISA and ISA configurations (which should be the same interface anyway). > >And that example is causing problems for people. I know of one person who has a conceptual problem with this approach(you). Show me one person experiencing actual failures after appling the patch I posted yesturday. > >> >Why can't you use the same probe routine address in two "driver instances"? >> >> Eisaconf doesn't work that way at all. > >You are (intentionally?) missing the point. You claim it doesn't add more code by saying I can call the same functions. I'm saying I can't. How am I missing the point. > >> >And wouldn't this fix the interrrupt attach problem introduced by the >> >eisaconf code in the VLB Adaptec case? >> >> Because the bug wasn't even in eisaconf. It was in i386/isa/isa.c. > >8-P. I think everyone who finds a bug and fixes it should get such treatment. >1) The ISA code, unless it's PnP, can't distinguish slots, so it > would have a damn hard time requiring looping through them. You know as well as I do that the eisa slot locations are fixed at 0xz000 for z 0-16. How do you think the eisaconf code finds the eisa ids? I don't see how this is relevent (again). >2) This is a VLB card, not an ISA card. I would not suggest > calling the probe from ISA any more than I would suggest > calling it from EISA. It is *NOT* an EISA device. What features does VLB have that make it of any use to differentiate between VLB and ISA probes? >3) The ISA code needs to "create device nodes" in a similar > fashion to EISA for PnP. This is a case of confusing ISA > devices that can be mapped by a configuration manager with > those that can't. Read the Microsoft PnP document. It does need to create nodes, but does that mean that the ISA code bperforms a PNP probe and then scans the eisa slot space just to satisfy the 2842? >What I suggest is calling the probe in multiple locations with two >stub routines: one EISA for eisaconf and one VLB (ISA, barring a >fixed handling of VLB). If you want to call this "adding an ISA probe", >fine. It's nowhere near the same order of effort as doing that, IMO. What probe routine? Eisa_match? >I can't fault you on the complexity argument: it will add a bit of >logical complexity in the process of providing a logical abstraction. >On the other hand, the abstraction can be made orthoganal so that it >is easier to document and program to for other devices that can then >seperate PnP mapping from driver attachment (substituting ISA PnP for >probing in the same way eisaconf substitutes slot iteration for >probing), so it seems like an acceptable tradeoff to me. > I disagree. > > Regards, > Terry Lambert > terry@lambert.org >--- >Any opinions in this posting are my own and not those of my present >or previous employers. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Thu Mar 7 10:22:38 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA27285 for current-outgoing; Thu, 7 Mar 1996 10:22:38 -0800 (PST) Received: from xena.mindspring.com (xena.mindspring.com [204.180.142.2]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA27279 for ; Thu, 7 Mar 1996 10:22:36 -0800 (PST) Received: (from rsanders@localhost) by xena.mindspring.com (8.6.12/8.6.12) id NAA02372; Thu, 7 Mar 1996 13:22:30 -0500 To: freebsd-current@freebsd.org Subject: ps and u_map allocation problems with kernel supped Mar 7 From: Robert Sanders Date: 07 Mar 1996 13:22:29 -0500 Message-ID: Organization: MindSpring Enterprises, Inc. Lines: 43 Sender: owner-current@freebsd.org Precedence: bulk $ date Thu Mar 7 13:11:58 EST 1996 $ uptime 1:12PM up 25 mins, 11 users, load averages: 2.63, 1.42, 0.74 $ ps auxw USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 589 4.0 2.0 216 600 p9 S+ 14Nov63 0:00.03 cc -c -O -W -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit - root 190 4.6 16.4 3652 4968 ?? S 11Nov63 0:18.97 X -bpp 32 (XF86_S3) root 588 1.0 1.0 452 304 p9 S+ 14Nov63 0:00.01 /bin/sh -ec cc -c -O -W -Wreturn-type -Wcomment -Wredundant-decls root 3 0.0 0.1 0 12 ?? DL 9Nov63 0:02.79 (vmdaemon) root 4 0.0 0.1 0 12 ?? DL 9Nov63 0:00.25 (update) root 60 0.0 0.6 420 176 ?? Ss 9Nov63 0:03.53 ppp -auto c-themaxx-sync root 76 0.0 0.3 184 96 ?? Ss 10Nov63 0:00.11 syslogd root 84 0.0 0.6 420 160 ?? S; Thu, 7 Mar 1996 11:21:04 -0800 (PST) Received: (from scrappy@localhost) by ki.net (8.7.4/8.7.4) id OAA20699; Thu, 7 Mar 1996 14:18:24 -0500 (EST) Date: Thu, 7 Mar 1996 14:18:23 -0500 (EST) From: "Marc G. Fournier" To: Adam David cc: freebsd-current@freebsd.org Subject: Re: config -g KERNEL In-Reply-To: <199603070804.IAA07027@veda.is> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk On Thu, 7 Mar 1996, Adam David wrote: > > > I tried making a kernel with debug symbols, using config -g and strip -x. > > > > I believe this should be 'strip -d', not -x... > > Thanks Marc :) > If so, then handbook223 is incorrect and needs updating, along with any other > such references that might be in the FAQ or handbook. > Actually, the reason that I'm not 100% certain about this was because just recently (in the past week or so), a change was commit'd to the handbook to switched -x to -d (99.9% positive, since I'm using -d here) Marc G. Fournier | POP Mail Telnet Acct DNS Hosting System | WWW Services Database Services | Knowledge, Administrator | | Information and scrappy@ki.net | WWW: http://www.ki.net | Communications, Inc From owner-freebsd-current Thu Mar 7 11:49:52 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA03530 for current-outgoing; Thu, 7 Mar 1996 11:49:52 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA03525 for ; Thu, 7 Mar 1996 11:49:47 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA14525; Thu, 7 Mar 1996 12:45:09 -0700 From: Terry Lambert Message-Id: <199603071945.MAA14525@phaeton.artisoft.com> Subject: Re: Whee! Page Fault! To: mark@linus.demon.co.uk (Mark Valentine) Date: Thu, 7 Mar 1996 12:45:09 -0700 (MST) Cc: handy@sag.space.lockheed.com, terry@lambert.org, freebsd-current@FreeBSD.ORG In-Reply-To: <199603070055.AAA01358@linus.demon.co.uk> from "Mark Valentine" at Mar 7, 96 00:55:40 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 Precedence: bulk > > From: "Brian N. Handy" > > Date: Wed 6 Mar, 1996 > > Subject: Re: Whee! Page Fault! > > > 0xf0103a84 _cd9660_readdir > > 0xf0103f34 _cd9660_readlink > > > > Terry scores. Recall, I was doing an 'ls' at the time of the offending > > kernel panic. > > I can reliably reproduce this (see the message "reproducible fatal trap 12" > I just mailed to this list). Must be some clue in this "coincidence", since > the cd9660 code hasn't changed since early December... > > The last CTM delta I applied and built included the change to take > sys/vm/swap_pager.c to revision 1.63. I suspect the buffer the readdir is reading into is not in core at the time, and so you get a page fault that reeenters the uiomove. This is part of the generic problem with the organization of the VOP_LOCK code that I was going on about in another thread; IMO, it shouldn't matter that you got the fault. The code needs to better handle reentrancy in some of the /sys/kern files. The CD9660 code keeps asking people to rewrite it (8-)), but the HPFS and RR stuff is so kludged in the mount code that it is nearly impossible to cleanly make a fix without rewriting most of the code. I pointed this out to Jordan before, mostly because he has a larger set of CDROM's that he can use to do testing than all of the rest of us put together (probably). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Thu Mar 7 11:56:52 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA03892 for current-outgoing; Thu, 7 Mar 1996 11:56:52 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA03879 for ; Thu, 7 Mar 1996 11:56:38 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id GAA05727; Fri, 8 Mar 1996 06:53:48 +1100 Date: Fri, 8 Mar 1996 06:53:48 +1100 From: Bruce Evans Message-Id: <199603071953.GAA05727@godzilla.zeta.org.au> To: current@freebsd.org, mark@linus.demon.co.uk Subject: Re: reproducible fatal trap 12 Sender: owner-current@freebsd.org Precedence: bulk >I can reliably reproduce a "Fatal trap 12: page fault while in kernel >mode" in a current kernel (up to date as of a few hours ago). I reproduce >it by mounting the FreeBSD 2.1 "live file system" CD and doing some file >name completion in the Xlib source tree (using bash), e.g. > $ more /cdrom/usr/X11R6/src/xc/lib/X11/ >The fault address on one instance was 0xf08aa001, and the fault code is >"supervisor read, page not present". The instruction pointer is at: > _cd9660_readdir+0x1a7: movzbl 0(%ecx),%esi >%ecx is the fault address. This is easy to reproduce and seems to be a bug in cd9660_readdir(). An invalid directory entry is accessed one statment before the check that finds it to be invalid. My fix delays the access and some other access until the reclen and namlen checks are done. Apparently it is OK to access the parts of the directory entry containing the reclen and the namlen, although there is no such thing as a partial struct in C. Skipping the faulting instructing in ddb happens to work safely. For some reason the bug wasn't reproducible after that (even after switching to another cdrom and back). Bruce *** cd9660_vnops.c~ Mon Dec 4 15:44:02 1995 --- cd9660_vnops.c Fri Mar 8 05:54:13 1996 *************** *** 559,562 **** --- 559,563 ---- struct iso_directory_record *ep; u_short elen; + int namlen; int reclen; int isoflags; *************** *** 620,625 **** reclen = isonum_711 (ep->length); - isoflags = isonum_711(imp->iso_ftype == ISO_FTYPE_HIGH_SIERRA? - &ep->date[6]: ep->flags); if (reclen == 0) { /* skip to next block, if any */ --- 621,624 ---- *************** *** 641,648 **** } /* XXX: be more intelligent if we can */ idp->current.d_type = DT_UNKNOWN; ! idp->current.d_namlen = isonum_711 (ep->name_len); if (isoflags & 2) isodirino(&idp->current.d_fileno,ep,imp); --- 640,656 ---- } + namlen = isonum_711 (ep->name_len); + if (reclen < ISO_DIRECTORY_RECORD_SIZE + namlen) { + error = EINVAL; + /* illegal entry, stop */ + break; + } + /* XXX: be more intelligent if we can */ idp->current.d_type = DT_UNKNOWN; ! idp->current.d_namlen = namlen; ! isoflags = isonum_711(imp->iso_ftype == ISO_FTYPE_HIGH_SIERRA? ! &ep->date[6]: ep->flags); if (isoflags & 2) isodirino(&idp->current.d_fileno,ep,imp); *************** *** 650,659 **** idp->current.d_fileno = dbtob(bp->b_blkno) + idp->curroff; - - if (reclen < ISO_DIRECTORY_RECORD_SIZE + idp->current.d_namlen) { - error = EINVAL; - /* illegal entry, stop */ - break; - } idp->curroff += reclen; --- 658,661 ---- From owner-freebsd-current Thu Mar 7 12:01:09 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA04236 for current-outgoing; Thu, 7 Mar 1996 12:01:09 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA04194 for ; Thu, 7 Mar 1996 12:00:48 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA14570; Thu, 7 Mar 1996 12:55:15 -0700 From: Terry Lambert Message-Id: <199603071955.MAA14570@phaeton.artisoft.com> Subject: Re: changes to /etc/ttys To: coredump@nervosa.com (invalid opcode) Date: Thu, 7 Mar 1996 12:55:15 -0700 (MST) Cc: current@FreeBSD.org In-Reply-To: from "invalid opcode" at Mar 7, 96 02:14:04 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 Precedence: bulk > I'm submitting a patch for /etc/ttys to make ttyv0 the default console of > which no getty process runs on. ttyv[1-3] are now the default getty logins. [ ... disable 0, enable 3 ... ] Why? Why do this? In the dynamic allocation case, you are causing the allocation of an unuse PTY in the "small memory system unable to run X" case, just where you *don't* want it. Note that the default after a boot is ttyv0. A new user would have to magically guess at the correct alt screen and know that the alt function keys did something to get installed. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Thu Mar 7 12:08:06 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA04628 for current-outgoing; Thu, 7 Mar 1996 12:08:06 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA04611 Thu, 7 Mar 1996 12:08:03 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA14613; Thu, 7 Mar 1996 13:04:36 -0700 From: Terry Lambert Message-Id: <199603072004.NAA14613@phaeton.artisoft.com> Subject: Re: ufs_valloc: dup whatever To: sysseh@devetir.qld.gov.au (Stephen Hocking) Date: Thu, 7 Mar 1996 13:04:36 -0700 (MST) Cc: bugs@FreeBSD.org, current@FreeBSD.org In-Reply-To: <199603070758.HAA10277@netfl15a.devetir.qld.gov.au> from "Stephen Hocking" at Mar 7, 96 05:58:39 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 Precedence: bulk > Just noticed something really curious - I was running two makes at once, and > somehow the output of one compilation (an assembler file of all things) > appeared in the middle of a .depend file of a make depend! Help! Terry, John & > David, what's going on? At a guess, I'd say Bruce was the best one to ask. It looks like the VREF/vrele code on the directory traversal has caused a vnode with a non-zero reference count to get onto the free list. I can't say I didn't expect this. It looks like the new pager code being more agressive in recovery is what revealed the traversal race condition. These are just guesses... unfortunately, I can't do anything about any of this, except to recommend going back to a checked out tree of the 1st or 2nd at the latest and waiting for it to be fixed. This is obviously related to your other posting in this thread. Rather than posting each additional problem as you see it, you should work with Bruce, David, and John on resolving the problem using your system as a test bed. I think that otherwise the cascade factor will cause you to post 10 or more problems all related to the same two codependent code changes; the symptoms you've reported so far should be sufficient to resolve the problem. PS: Is it possible that you are running with my "free vnode isn't" kludge fix? I believe this will interact badly with the VREF/vrele changes... if you are, you should remove my kludge, and get around the problem by cranking up numvnodes where the calculation takes place to set it up in the first place ("numvnodes *= 3;" or something similar). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Thu Mar 7 12:42:45 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA06759 for current-outgoing; Thu, 7 Mar 1996 12:42:45 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA06754 Thu, 7 Mar 1996 12:42:38 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA14706; Thu, 7 Mar 1996 13:36:16 -0700 From: Terry Lambert Message-Id: <199603072036.NAA14706@phaeton.artisoft.com> Subject: Re: 2842 and the disappearing file-system :-( To: gibbs@freefall.freebsd.org (Justin T. Gibbs) Date: Thu, 7 Mar 1996 13:36:15 -0700 (MST) Cc: terry@lambert.org, imb@scgt.oz.au, stable@FreeBSD.ORG, current@FreeBSD.ORG In-Reply-To: <199603071805.KAA26152@freefall.freebsd.org> from "Justin T. Gibbs" at Mar 7, 96 10:05: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 Precedence: bulk > >> I would guess you didn't even look. Have you looked at eisaconf.c? > >> or aic7770.c? > > > >You have guessed wrong (don't worry, this is the usual guess, and it's > >usually wrong). > > Perhaps you read it last night, but you certainly acted as if you > thought eisaconf worked just like isa_configure() in all of your mail > yesturday. I don't thin so, Quickstraw. > >The *WORST* you would *POSSIBLY* need is an EISA nad an ISA stub > >routine. I *STILL* do not think EISA ID's should be looked for if > >the system doesn't claim to be an EISA bus. > > An eisa and isa stub routine to what? The routine that collects > the IDs? The routine that matches drivers to ids? The routinesx > for irq/ioport, etc registration? It sounds like you want me to > duplicate the probe in aic7770.c, but prepend everything with isa_ > instead of eisa_. All for one card that acts just like an eisa > card? What a waste of code and effort. No; I want a dup of the EISA process in the ISA PnP space so that it's just a case of making a reference to the routines (and *remove* the "eisa_" designations entirely). > Most isa cards don't care about the eisa ids, so why create yet > another interface to them for the few isa cards that do. No matter > your aversion to looking for eisa ids in a non eisa machine, it > will have to happen regardless if you have a 2842 in your machine. > If you don't like it, or don't need it, disable eisa0. That's just the 2842, and it's an ISA driver configuration architecture problem with the ISA code. At the very least, we should admit that looking for EISA stuff on a non-EISA machine is a kludge. [ ... ] > I know of one person who has a conceptual problem with this approach(you). Well, it doesn't seem that many people are thinking in terms of a unified configuration manager ala Windows95 and WindowsNT. I expect the number of people doing so to increase over time as people desire better autoconfiguration out of FreeBSD. > Show me one person experiencing actual failures after appling the > patch I posted yesturday. The number of people running VLB is ver small... you have given me a very restricted search space with your demand. > >You are (intentionally?) missing the point. > > You claim it doesn't add more code by saying I can call the same functions. > I'm saying I can't. How am I missing the point. The point is you *should* be *able* to call the same functions for ISA, and for PnP, which uses non-invasive probing (unless you have an old IBM manufactured parallel port card), you *can*. > >1) The ISA code, unless it's PnP, can't distinguish slots, so it > > would have a damn hard time requiring looping through them. > > You know as well as I do that the eisa slot locations are fixed > at 0xz000 for z 0-16. How do you think the eisaconf code finds the eisa ids? > I don't see how this is relevent (again). This is a *card* problem, not a generic problem resolved for anthing other than the Adaptec card by calling the EISA code. > >2) This is a VLB card, not an ISA card. I would not suggest > > calling the probe from ISA any more than I would suggest > > calling it from EISA. It is *NOT* an EISA device. > > What features does VLB have that make it of any use to differentiate > between VLB and ISA probes? A) Default settings for driver configurable bus-on times, since VLB steals DRAM refresh cycles. VLB on time needs to be agregated and adjusted *down* where necessary. B) Use of bounce buffers on bus mastering VLB cards other than the *one* detected by the EISA probe by virtue of it's "EISA" nature. As you pointed out previously, *yes*, there are broken EISA and VLB DMA for > 16M. If you have a bus master controller already detected, it is possible to determine if DMA needs to be bounced. My approach would be to bounce *all* I/O until it is determined it is safe to not bounce. This is easier than it appears, since you could use an unused field in the disklabel, the root FS header, or some other location that defaults to "0" that says "check for ability to bounce" and gets written to "1" (always bounce, DMA is limited to 16M) or a "2" (don't bounce, DMA is OK above 16M) -- and only triggers if there is more than 16M detected in the machine. This would make the NiCE HiNT chipset EISA's (the only EISA machines where this is a problem) and the VLB machines you noted in a pervious posting *work* instead of *failing* by default. So the DMA argument doesn't support the EISA/VLB probe argument. > >3) The ISA code needs to "create device nodes" in a similar > > fashion to EISA for PnP. This is a case of confusing ISA > > devices that can be mapped by a configuration manager with > > those that can't. Read the Microsoft PnP document. > > It does need to create nodes, but does that mean that the ISA code > bperforms a PNP probe and then scans the eisa slot space just to satisfy the > 2842? No. I think it is incorrect to use the EISA slot space mechanism to probe the controller. The probe includes IRQ, DMA, and other info, that unless it's a real EISA card, isn't going to be in the EISA configuration space for VLB... even if such a space exists, the user didn't run the DOS EISA configuration utility for the card to set it. It is at least 75% of the way to an EISA-independent probe. > >What I suggest is calling the probe in multiple locations with two > >stub routines: one EISA for eisaconf and one VLB (ISA, barring a > >fixed handling of VLB). If you want to call this "adding an ISA probe", > >fine. It's nowhere near the same order of effort as doing that, IMO. > > What probe routine? Eisa_match? As I said before, you will have to break it out and provide EISA specific stubs. For ISA, you have to search the allowable space (and that is a data issue, as long as the probe is non-invasive). > >I can't fault you on the complexity argument: it will add a bit of > >logical complexity in the process of providing a logical abstraction. > >On the other hand, the abstraction can be made orthoganal so that it > >is easier to document and program to for other devices that can then > >seperate PnP mapping from driver attachment (substituting ISA PnP for > >probing in the same way eisaconf substitutes slot iteration for > >probing), so it seems like an acceptable tradeoff to me. > > > > I disagree. With me agreeing with you on the complexity argument? -- I was agreeing with you, reluctantly.. Or with my statement about orthogonality in a configuration management interface? -- If Microsoft can do it in Windows95, anyone can do it. Microsoft programmers are *not* gods. 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 Thu Mar 7 13:07:19 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA08547 for current-outgoing; Thu, 7 Mar 1996 13:07:19 -0800 (PST) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA08541 for ; Thu, 7 Mar 1996 13:07:16 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.6.11/8.6.9) id QAA00337; Thu, 7 Mar 1996 16:03:14 GMT From: "John S. Dyson" Message-Id: <199603071603.QAA00337@dyson.iquest.net> Subject: Re: ps and u_map allocation problems with kernel supped Mar 7 To: rsanders@mindspring.com (Robert Sanders) Date: Thu, 7 Mar 1996 16:03:13 +0000 () Cc: freebsd-current@freebsd.org In-Reply-To: from "Robert Sanders" at Mar 7, 96 01:22:29 pm X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org Precedence: bulk > > $ date > Thu Mar 7 13:11:58 EST 1996 > > $ uptime > 1:12PM up 25 mins, 11 users, load averages: 2.63, 1.42, 0.74 > There is some significant problems with the VM code as of 1-4Mar. I have most of the nits removed in my working code. Might get it fixed tonight. Also, I have grabbed a copy of the INN code that does the mmap nasty, and will be working on simulating the INN problem. I guess what I am saying is I AM LISTENING :-). John dyson@freebsd.org From owner-freebsd-current Thu Mar 7 13:24:22 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA09877 for current-outgoing; Thu, 7 Mar 1996 13:24:22 -0800 (PST) Received: from nervosa.com (root@nervosa.com [192.187.228.86]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id NAA09869 for ; Thu, 7 Mar 1996 13:24:17 -0800 (PST) Received: from nervosa.com (coredump@onyx.nervosa.com [10.0.0.1]) by nervosa.com (8.7.5/nervosa.com.2) with SMTP id NAA00196; Thu, 7 Mar 1996 13:24:02 -0800 (PST) Date: Thu, 7 Mar 1996 13:24:02 -0800 (PST) From: invalid opcode To: Nate Williams cc: FreeBSD-current Subject: Re: changes to /etc/csh.* In-Reply-To: <199603071607.JAA01191@rocky.sri.MT.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.org Precedence: bulk On Thu, 7 Mar 1996, Nate Williams wrote: > > I'm submitting my versions of /etc/csh.{login,logout,cshrc} as a > > potential new base. > > Most of these look good, but this is unacceptable for a stock system > since less isn't installed. > > > setenv PAGER /usr/local/bin/less > Nate Yes. I do agree. I figured it would be removed anyway. == Chris Layne ============================================================= == coredump@nervosa.com ================ http://www.nervosa.com/~coredump == From owner-freebsd-current Thu Mar 7 14:35:18 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA23377 for current-outgoing; Thu, 7 Mar 1996 14:35:18 -0800 (PST) Received: from nervosa.com (root@nervosa.com [192.187.228.86]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id OAA23327 for ; Thu, 7 Mar 1996 14:35:03 -0800 (PST) Received: from nervosa.com (coredump@onyx.nervosa.com [10.0.0.1]) by nervosa.com (8.7.5/nervosa.com.2) with SMTP id OAA00635; Thu, 7 Mar 1996 14:34:48 -0800 (PST) Date: Thu, 7 Mar 1996 14:34:48 -0800 (PST) From: invalid opcode To: "Rodney W. Grimes" cc: current@freebsd.org Subject: Re: changes to /etc/ttys In-Reply-To: <199603071710.JAA07682@GndRsh.aac.dev.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk On Thu, 7 Mar 1996, Rodney W. Grimes wrote: > > I'm submitting a patch for /etc/ttys to make ttyv0 the default console of > Why would you want to do this? This would mean that by default no login > prompt would appear after a boot, something that I am sure would generate > _lots_ of questions on the mailing list from users who did not know about > it. > Rod Grimes rgrimes@gndrsh.aac.dev.com Terry, Rod, I failed to think of that. Yes, that would generate TOO many questions over it. I was just thinking of consistency, and forgot about new users, *sigh*, nevermind it than. == Chris Layne ============================================================= == coredump@nervosa.com ================ http://www.nervosa.com/~coredump == From owner-freebsd-current Thu Mar 7 15:05:12 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA01923 for current-outgoing; Thu, 7 Mar 1996 15:05:12 -0800 (PST) Received: from tfd.com (tfd.com [206.205.61.2]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA01905 for ; Thu, 7 Mar 1996 15:05:05 -0800 (PST) Received: from sneezy.tfd.com by tfd.com with SMTP id AA29531 (5.65b/IDA-1.4.3 for freebsd-current@freebsd.org); Thu, 7 Mar 96 18:04:58 -0500 Received: by sneezy id AA03116 (5.65b/IDA-1.4.3 for freebsd-current@freebsd.org); Thu, 7 Mar 96 18:03:50 -0500 Date: Thu, 7 Mar 96 18:03:50 -0500 From: Kent Hauser Message-Id: <9603072303.AA03116@sneezy> To: freebsd-current@freebsd.org Subject: `make -DCLOBBER world' fails Sender: owner-current@freebsd.org Precedence: bulk The problem is that programs are compiled & run to generate some libs before `crt0.o' is created. Examples include "gnu/lib/libgmp" and "lib/libmytinfo". This problem could be prevented by moving the cd ${.CURDIR}/lib/csu/i386 && ${MAKE} depend all install .... to the beginning of the lib make. Kent From owner-freebsd-current Thu Mar 7 15:27:14 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA07928 for current-outgoing; Thu, 7 Mar 1996 15:27:14 -0800 (PST) Received: from mail.cs.tu-berlin.de (root@mail.cs.tu-berlin.de [130.149.17.13]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id PAA07893 for ; Thu, 7 Mar 1996 15:27:09 -0800 (PST) Received: from caramba.cs.tu-berlin.de (wosch@caramba.cs.tu-berlin.de [130.149.17.12]) by mail.cs.tu-berlin.de (8.6.12/8.6.12) with ESMTP id AAA27836 for ; Fri, 8 Mar 1996 00:12:31 +0100 Received: (from wosch@localhost) by campa.panke.de (8.6.9/8.6.9) id XAA01854; Thu, 7 Mar 1996 23:33:38 +0100 Date: Thu, 7 Mar 1996 23:33:38 +0100 From: Wolfram Schneider Message-Id: <199603072233.XAA01854@campa.panke.de> To: current@freebsd.org Subject: _PATH_* Reply-to: Wolfram Schneider MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-current@freebsd.org Precedence: bulk /usr/include/paths.h /* Default search path. */ #define _PATH_DEFPATH "/usr/bin:/bin" Why is /usr/bin before /bin? /* All standard utilities path. */ #define _PATH_STDPATH \ "/usr/bin:/bin:/usr/sbin:/sbin:" Same. And why the colon? Wolfram From owner-freebsd-current Thu Mar 7 15:27:17 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA07944 for current-outgoing; Thu, 7 Mar 1996 15:27:17 -0800 (PST) Received: from mail.cs.tu-berlin.de (root@mail.cs.tu-berlin.de [130.149.17.13]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id PAA07921 for ; Thu, 7 Mar 1996 15:27:13 -0800 (PST) Received: from caramba.cs.tu-berlin.de (wosch@caramba.cs.tu-berlin.de [130.149.17.12]) by mail.cs.tu-berlin.de (8.6.12/8.6.12) with ESMTP id AAA27841 for ; Fri, 8 Mar 1996 00:12:32 +0100 Received: (from wosch@localhost) by campa.panke.de (8.6.9/8.6.9) id XAA01898; Thu, 7 Mar 1996 23:47:03 +0100 Date: Thu, 7 Mar 1996 23:47:03 +0100 From: Wolfram Schneider Message-Id: <199603072247.XAA01898@campa.panke.de> To: current@freebsd.org Subject: *.mk wishes Reply-to: Wolfram Schneider MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-current@freebsd.org Precedence: bulk bsd.man.mk: MANGRP, MANOWN, MANMODE, MANDIR already defined in bsd.own.mk, should deleted bsd.own.mk: new variables DOCGRP, DOCOWN, DOCMODE, DOCDIR for documents sys.mk: MMAP_RO: read only mmap, for programs like grep, groff, look etc. MMAP_RW: write works (inn) Wolfram From owner-freebsd-current Thu Mar 7 15:27:20 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA07971 for current-outgoing; Thu, 7 Mar 1996 15:27:20 -0800 (PST) Received: from mail.cs.tu-berlin.de (root@mail.cs.tu-berlin.de [130.149.17.13]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id PAA07940 for ; Thu, 7 Mar 1996 15:27:15 -0800 (PST) Received: from caramba.cs.tu-berlin.de (wosch@caramba.cs.tu-berlin.de [130.149.17.12]) by mail.cs.tu-berlin.de (8.6.12/8.6.12) with ESMTP id AAA27844 for ; Fri, 8 Mar 1996 00:12:33 +0100 Received: (from wosch@localhost) by campa.panke.de (8.6.9/8.6.9) id XAA01857; Thu, 7 Mar 1996 23:34:39 +0100 Date: Thu, 7 Mar 1996 23:34:39 +0100 From: Wolfram Schneider Message-Id: <199603072234.XAA01857@campa.panke.de> To: current@freebsd.org Subject: Last pid Reply-to: Wolfram Schneider MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-current@freebsd.org Precedence: bulk The variable nextpid in fork1 (/sys/kern/kern_fork.c) is a local variable. Gcc rename internally nextpid to nextpid.178 ... So it is not possible to read the value of nextpid with kvm(3) or sysctl(3). Can we make nextpid to a global variable or is there any other way to read nextpid? It would be nice if top(1) can show the last pid. Wolfram From owner-freebsd-current Thu Mar 7 15:52:39 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA14372 for current-outgoing; Thu, 7 Mar 1996 15:52:39 -0800 (PST) Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id PAA14318 for ; Thu, 7 Mar 1996 15:52:29 -0800 (PST) Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id AAA28754 ; Fri, 8 Mar 1996 00:52:16 +0100 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id AAA22150 ; Fri, 8 Mar 1996 00:52:15 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.7.3/keltia-uucp-2.7) id AAA00319; Fri, 8 Mar 1996 00:48:44 +0100 (MET) From: Ollivier Robert Message-Id: <199603072348.AAA00319@keltia.freenix.fr> Subject: Re: ps and u_map allocation problems with kernel supped Mar 7 To: toor@dyson.iquest.net (John S. Dyson) Date: Fri, 8 Mar 1996 00:48:43 +0100 (MET) Cc: rsanders@mindspring.com, freebsd-current@FreeBSD.org In-Reply-To: <199603071603.QAA00337@dyson.iquest.net> from "John S. Dyson" at "Mar 7, 96 04:03:13 pm" X-Operating-System: FreeBSD 2.2-CURRENT ctm#1745 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 Precedence: bulk It seems that John S. Dyson said: > most of the nits removed in my working code. Might get it fixed tonight. > Also, I have grabbed a copy of the INN code that does the mmap nasty, and > will be working on simulating the INN problem. Nice. > I guess what I am saying is I AM LISTENING :-). Did you looked at the pipe-related problem Andreyspoke of last week, a problem seen with ssh (which use a pipe to "ssh" when you use "scp"). File transferts of more than 8 KB just lock. Thanks as always for your work. I always marvel at what your VM can do, even if sometimes it has some problems :-) Mar 7 20:10:46 keltia /kernel: FreeBSD 2.2-CURRENT #4: Thu Mar 7 00:38:05 MET 1996 Mar 7 20:10:46 keltia /kernel: roberto@keltia.freenix.fr:/src/src/sys/compile/DKELTIA Mar 7 22:03:28 keltia /kernel: pid 1517 (tcsh), uid 101: exited on signal 11 Mar 8 00:16:38 keltia /kernel: pid 1676 (tcsh), uid 101: exited on signal 10 Mar 8 00:28:14 keltia /kernel: pid 1516 (tcsh), uid 101: exited on signal 11 Mar 8 00:35:23 keltia /kernel: pid 1478 (XF86_S3), uid 0: exited on signal 6 Mar 8 00:35:25 keltia /kernel: pid 205 (tcsh), uid 101: exited on signal 11 Mar 8 00:35:25 keltia /kernel: pid 1609 (tcsh), uid 0: exited on signal 10 -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia.freenix.fr 2.2-CURRENT #1: Tue Feb 20 01:16:51 MET 1996 From owner-freebsd-current Thu Mar 7 16:28:17 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA20053 for current-outgoing; Thu, 7 Mar 1996 16:28:17 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id QAA20048 for ; Thu, 7 Mar 1996 16:28:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.4/8.6.9) with SMTP id QAA15640 for ; Thu, 7 Mar 1996 16:28:07 -0800 (PST) To: current@freebsd.org Subject: New kernel option proposed.. Date: Thu, 07 Mar 1996 16:28:07 -0800 Message-ID: <15638.826244887@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org Precedence: bulk Speak now or forever hold your peace, as they say.. Stefan Esser would like an option which he can use to conditionalize code to be "conservative" in the case where you're first installing. There is a good deal of other code that could probably also benefit from the ability to say "run this code if you care more about function than speed." In former times we used the GENERIC keyword to do stuff like this, but that was clearly gross. Stefan and I have tossed the idea around and come up with the keyword FAILSAFE as a reasonable proposal. CONSERVATIVE is probably just a bit too long, and people will probably think that you enable it in order to get your kernel to vote Republican anwyay.. :-) Comments? Jeers? If not, I'll commit it to LINT. Jordan From owner-freebsd-current Thu Mar 7 16:38:53 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA20604 for current-outgoing; Thu, 7 Mar 1996 16:38:53 -0800 (PST) Received: from sxt2.space.lockheed.com (sxt2.space.lockheed.com [192.68.162.109]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id QAA20598 for ; Thu, 7 Mar 1996 16:38:50 -0800 (PST) Received: by sxt2.space.lockheed.com (5.65/DEC-Ultrix/4.3) id AA04364; Thu, 7 Mar 1996 16:32:11 -0800 Date: Thu, 7 Mar 1996 16:32:11 -0800 (PST) From: "Brian N. Handy" To: Bruce Evans Cc: current@FreeBSD.ORG, mark@linus.demon.co.uk Subject: Re: reproducible fatal trap 12 In-Reply-To: <199603071953.GAA05727@godzilla.zeta.org.au> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG Precedence: bulk [...] > This is easy to reproduce and seems to be a bug in cd9660_readdir(). An > invalid directory entry is accessed one statment before the check that > finds it to be invalid. My fix delays the access and some other access > until the reclen and namlen checks are done. Apparently it is OK to > access the parts of the directory entry containing the reclen and the > namlen, although there is no such thing as a partial struct in C. > > Skipping the faulting instructing in ddb happens to work safely. For > some reason the bug wasn't reproducible after that (even after switching > to another cdrom and back). I patched this into my system and it seems to work here. (I being the originator of the "Page Fault" thread.) I'll exercise it for a while and see it I have any problems. Thanks! Brian From owner-freebsd-current Thu Mar 7 18:10:18 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA25990 for current-outgoing; Thu, 7 Mar 1996 18:10:18 -0800 (PST) Received: from utgard.bga.com (utgard.bga.com [205.238.129.45]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id SAA25984 for ; Thu, 7 Mar 1996 18:10:15 -0800 (PST) Received: (from faulkner@localhost) by utgard.bga.com (8.7.4/8.7.3) id UAA00391 for current@freebsd.org; Thu, 7 Mar 1996 20:10:07 -0559 (CST) Message-Id: <199603080209.UAA00391@utgard.bga.com> Subject: SCSI_DELAY not recognized in kernel build To: current@freebsd.org Date: Thu, 7 Mar 1996 20:10:07 -0559 (CST) From: "Boyd R. Faulkner" X-Mailer: ELM [version 2.4 PL25 ME8b] Content-Type: text Sender: owner-current@freebsd.org Precedence: bulk The config variable SCSI_DELAY is no longer recognized. It is now put into opt_scsi.h in /sys/compile/KERNEL. This is not included in /sys/scsi/scsiconf.h. Could someone fix this, please? Thanks, Boyd -- _____________________________________________________________________________ Boyd Faulkner "The fates lead him who will; faulkner@asgard.bga.com Him who won't, they drag." http://asgard.bga.com/~faulkner Old Roman Saying -- Source: Joseph Campbell _____________________________________________________________________________ From owner-freebsd-current Thu Mar 7 18:15:59 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA26396 for current-outgoing; Thu, 7 Mar 1996 18:15:59 -0800 (PST) Received: from freebsd.netcom.com (freebsd.netcom.com [198.211.79.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id SAA26388 for ; Thu, 7 Mar 1996 18:15:57 -0800 (PST) Received: by freebsd.netcom.com (8.6.12/SMI-4.1) id UAA13982; Thu, 7 Mar 1996 20:19:57 -0600 From: bugs@freebsd.netcom.com (Mark Hittinger) Message-Id: <199603080219.UAA13982@freebsd.netcom.com> Subject: re: New kernel option proposed.. To: current@freebsd.org Date: Thu, 7 Mar 1996 20:19:57 -0600 (CST) X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-current@freebsd.org Precedence: bulk > > In former times we used the GENERIC keyword to do stuff like this, but > that was clearly gross. Stefan and I have tossed the idea around and > come up with the keyword FAILSAFE as a reasonable proposal. > CONSERVATIVE is probably just a bit too long, and people will probably > think that you enable it in order to get your kernel to vote > Republican anwyay.. :-) > CHICKEN Regards, Mark Hittinger Netcom/Dallas bugs@freebsd.netcom.com From owner-freebsd-current Thu Mar 7 19:17:01 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id TAA03019 for current-outgoing; Thu, 7 Mar 1996 19:17:01 -0800 (PST) Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id TAA02977 Thu, 7 Mar 1996 19:16:53 -0800 (PST) Message-Id: <199603080316.TAA02977@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: Host localhost.cdrom.com [127.0.0.1] didn't use HELO protocol To: Terry Lambert cc: imb@scgt.oz.au, stable@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: 2842 and the disappearing file-system :-( In-reply-to: Your message of "Thu, 07 Mar 1996 13:36:15 MST." <199603072036.NAA14706@phaeton.artisoft.com> Date: Thu, 07 Mar 1996 19:16:52 -0800 From: "Justin T. Gibbs" Sender: owner-current@FreeBSD.ORG Precedence: bulk Again you have decided that if you at first miss the target, to choose a totally different target for your next attempt. Lets remember what started this whole thread... The 2842VLB SCSI card, a non PnP device, sticks its identifier in the EISA slot address space for identification. FreeBSD currently always looks for these IDs in the EISA slot address space even if the EISA motherboard ID at 0x0C80 is not found so that it can detect these cards. You complained that the EISA code should not probe the slot address space if the motherboard ID was not found. And thus this argument began. Since then, you've tried to make this into an agument for a configuration manager. Well, you have no argument from me for a configuration manager. In fact I wrote eisaconf with the sole intention of making it a prototype for a configuration manager that would encompass other device types. What you will, and have seen me argue against is the need to construct additional mechanisms into how we probe devices to cover a single VLB card that was designed to be probed like an EISA device. Having more than one way to trigger a scan of the EISA slot address space for devices is confusing at best, and leads to bugs at worst. The probe for EISA devices has proven non-invasive on the 100s of machines that currently have eisa0 in their config files and the same scan would be required anyway to support the 2842, so there is no technical reason to provide an alternate method for triggering the search. Furthermore, eisaconf must already properly report other ISA cards that can be configured in "eisa compatibility mode" as living on the ISA bus (the 3c509 for example) so it is already suited to the task of handing the 2842 with absolutly no additional code or complexity: ahc1: at 0x7c00-0x7cff irq 12 on isa >No; I want a dup of the EISA process in the ISA PnP space so that it's >just a case of making a reference to the routines (and *remove* the >"eisa_" designations entirely). But the 2842 is not a PnP device and forcing the ISA PnP mechanism to deal with non PnP hardware is a violation of layering in a configuration manager scenario. The configuration manager should moderate between the ISA PnP probe mechanism and the list of "possible probe locations" provided by ISA devices and their "bus manager". >> Most isa cards don't care about the eisa ids, so why create yet >> another interface to them for the few isa cards that do. No matter >> your aversion to looking for eisa ids in a non eisa machine, it >> will have to happen regardless if you have a 2842 in your machine. >> If you don't like it, or don't need it, disable eisa0. > >That's just the 2842, and it's an ISA driver configuration architecture >problem with the ISA code. And yet this was exactly the problem that spurred this thread. >At the very least, we should admit that looking for EISA stuff on a >non-EISA machine is a kludge. Complain to Adaptec. >> I know of one person who has a conceptual problem with this approach(you). > >Well, it doesn't seem that many people are thinking in terms of a unified >configuration manager ala Windows95 and WindowsNT. I expect the number >of people doing so to increase over time as people desire better >autoconfiguration out of FreeBSD. Probing the 2842 as an EISA device does not preclude a configuration manager aproach to solving our current device probe mess. >> Show me one person experiencing actual failures after appling the >> patch I posted yesturday. > >The number of people running VLB is ver small... you have given me a >very restricted search space with your demand. Anyone who currently has eisa0 in there kernel is proving the point that the probe of the eisa slot address space is non-invasive. The probe can't tell if you have a VLB motherboard in order to prevent the probe, and it can't know if you have a 2842 either without looking, so it always does the scan. >> >You are (intentionally?) missing the point. >> >> You claim it doesn't add more code by saying I can call the same functions. >> I'm saying I can't. How am I missing the point. > >The point is you *should* be *able* to call the same functions for ISA, >and for PnP, which uses non-invasive probing (unless you have an old >IBM manufactured parallel port card), you *can*. The match routines and forcing a scan of the eisa address space makes no sense in a generic ISA probe (deals with non PnP hardware) configuration sub-manager. >> >1) The ISA code, unless it's PnP, can't distinguish slots, so it >> > would have a damn hard time requiring looping through them. >> >> You know as well as I do that the eisa slot locations are fixed >> at 0xz000 for z 0-16. How do you think the eisaconf code finds the eisa ids >? >> I don't see how this is relevent (again). > >This is a *card* problem, not a generic problem resolved for anthing >other than the Adaptec card by calling the EISA code. Exactly! The Adaptec card behaves like an eisa device so you either have it use the EISA probe mechanism or you have it be an ISA probe that does the scan itself since it would be a layering violation to have it call into the EISA probe to force it to scan the slot address space even if it wasn't an EISA machine, call the eisa match routine to see if a proper ID was found, and then turn around and register itself with the ISA device manager. >> >2) This is a VLB card, not an ISA card. I would not suggest >> > calling the probe from ISA any more than I would suggest >> > calling it from EISA. It is *NOT* an EISA device. >> >> What features does VLB have that make it of any use to differentiate >> between VLB and ISA probes? > >A) Default settings for driver configurable bus-on times, since VLB > steals DRAM refresh cycles. VLB on time needs to be agregated > and adjusted *down* where necessary. This is a device driver issue, not a VLB bus issue, since only the driver knows if it is talking to a VLB card. >B) Use of bounce buffers on bus mastering VLB cards other than > the *one* detected by the EISA probe by virtue of it's "EISA" > nature. > >As you pointed out previously, *yes*, there are broken EISA and VLB DMA >for > 16M. If you have a bus master controller already detected, it >is possible to determine if DMA needs to be bounced. My approach would >be to bounce *all* I/O until it is determined it is safe to not bounce. Again, this is not a VLB issue. I'm all for a generic way to determine if bounce buffering is necessary, but this wasn't the issue we were discussing. >So the DMA argument doesn't support the EISA/VLB probe argument. It certainly doesn't support that there should be a separate VLB probe. > 16MB dma problems transend busses. >> >3) The ISA code needs to "create device nodes" in a similar >> > fashion to EISA for PnP. This is a case of confusing ISA >> > devices that can be mapped by a configuration manager with >> > those that can't. Read the Microsoft PnP document. >> >> It does need to create nodes, but does that mean that the ISA code >> bperforms a PNP probe and then scans the eisa slot space just to satisfy the >> 2842? > >No. I think it is incorrect to use the EISA slot space mechanism to >probe the controller. Complain to Adaptec. >The probe includes IRQ, DMA, and other info, >that unless it's a real EISA card, isn't going to be in the EISA >configuration space for VLB... even if such a space exists, the >user didn't run the DOS EISA configuration utility for the card >to set it. It is at least 75% of the way to an EISA-independent probe. For all of the EISA cards that I've added eisaconf probes for, the IRQ, DMA and most other interresting information is availible in registers initialized by the the EISA BIOS. The 2842 has the same registers availible that the 2742 so it is not an issue. Think of the 2842 as an EISA card that doesn't have an overlay file and so doesn't store anything in configuration space. We can't even read configuration space yet, but the eisaconf code will have to deal with devices that have nothing set up there anyway which is simple since it will simply leave it up to the device driver to interpret the data once the eisaconf code can provide a means to access it. >> >What I suggest is calling the probe in multiple locations with two >> >stub routines: one EISA for eisaconf and one VLB (ISA, barring a >> >fixed handling of VLB). If you want to call this "adding an ISA probe", >> >fine. It's nowhere near the same order of effort as doing that, IMO. >> >> What probe routine? Eisa_match? > >As I said before, you will have to break it out and provide EISA >specific stubs. For ISA, you have to search the allowable space >(and that is a data issue, as long as the probe is non-invasive). What is the gain in doing this? >> >I can't fault you on the complexity argument: it will add a bit of >> >logical complexity in the process of providing a logical abstraction. >> >On the other hand, the abstraction can be made orthoganal so that it >> >is easier to document and program to for other devices that can then >> >seperate PnP mapping from driver attachment (substituting ISA PnP for >> >probing in the same way eisaconf substitutes slot iteration for >> >probing), so it seems like an acceptable tradeoff to me. >> > >> >> I disagree. > >With me agreeing with you on the complexity argument? No, with your assertion that having the ISA PnP support akin to how eisaconf works, solves the 2842 issue. Coercing the 2842 to fit into an ISA PnP model (it uses a dip switch block combined with a "SCSI-Select" utility) is far worse than probing it as an EISA device as the manufacturer intended. > Regards, > Terry Lambert > terry@lambert.org >--- >Any opinions in this posting are my own and not those of my present >or previous employers. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Thu Mar 7 19:25:03 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id TAA03885 for current-outgoing; Thu, 7 Mar 1996 19:25:03 -0800 (PST) Received: from sumter.awod.com (awod.com [198.81.225.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id TAA03876 for ; Thu, 7 Mar 1996 19:25:00 -0800 (PST) Received: from Ken (tsunami.awod.com [198.81.225.31]) by sumter.awod.com (8.6.11/8.6.9) with SMTP id WAA13687; Thu, 7 Mar 1996 22:24:32 -0500 Message-Id: <1.5.4b11.32.19960308032438.006be60c@awod.com> X-Sender: klam@awod.com X-Mailer: Windows Eudora Light Version 1.5.4b11 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 07 Mar 1996 22:24:38 -0500 To: "Jordan K. Hubbard" From: Ken Lam Subject: Re: New kernel option proposed.. Cc: current@freebsd.org Sender: owner-current@freebsd.org Precedence: bulk At 04:28 PM 3/7/96 -0800, you wrote: [deleted] >In former times we used the GENERIC keyword to do stuff like this, but >that was clearly gross. Stefan and I have tossed the idea around and >come up with the keyword FAILSAFE as a reasonable proposal. >CONSERVATIVE is probably just a bit too long, and people will probably >think that you enable it in order to get your kernel to vote >Republican anwyay.. :-) > >Comments? Jeers? If not, I'll commit it to LINT. Hmmm.. seems more obvious, but then won't that kind of mean that we can't say RTFM? After all, the standard 4.4bsd manuals, Unix System Administrator Handbook, etc.. all refer to GENERIC in their kernel configuration sections. Clearly, when some of us are up in the twilight hours of Saturday morning with a stiff neck, red eyes, and slight hangover having gotten called in to fix some _minor_ problem.... with no brain cells to spare, the answer just not bubbling to the surface, we run to the console and type sd(0,a)/kernel.GENERIC at the boot prompt... only to have the boot prompt return :( Then suddenly, you snap, all sanity leaves your body .... .... "I never did like that hard drive and monitor! Good riddance!" Hmmm.... I think I've been up too long already :) Ah.. commit it (change is good), might as well commit me as well, so I don't hurt anyone ;) -ken From owner-freebsd-current Thu Mar 7 20:04:36 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id UAA07066 for current-outgoing; Thu, 7 Mar 1996 20:04:36 -0800 (PST) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id UAA07058 for ; Thu, 7 Mar 1996 20:04:32 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.6.11/8.6.9) id XAA00850; Thu, 7 Mar 1996 23:00:16 GMT From: "John S. Dyson" Message-Id: <199603072300.XAA00850@dyson.iquest.net> Subject: Re: ps and u_map allocation problems with kernel supped Mar 7 To: roberto@keltia.freenix.fr (Ollivier Robert) Date: Thu, 7 Mar 1996 23:00:15 +0000 () Cc: rsanders@mindspring.com, freebsd-current@FreeBSD.org In-Reply-To: <199603072348.AAA00319@keltia.freenix.fr> from "Ollivier Robert" at Mar 8, 96 00:48:43 am X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org Precedence: bulk > > > I guess what I am saying is I AM LISTENING :-). > > Did you looked at the pipe-related problem Andreyspoke of last week, > a problem seen with ssh (which use a pipe to "ssh" when you use > "scp"). File transferts of more than 8 KB just lock. > I think that was fixed last week. The problem was that the direct buffer transfers did not get waken up correctly. Select didn't even work with them. John From owner-freebsd-current Thu Mar 7 21:55:14 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA14207 for current-outgoing; Thu, 7 Mar 1996 21:55:14 -0800 (PST) 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 VAA14199 for ; Thu, 7 Mar 1996 21:55:05 -0800 (PST) Received: from grumble.grondar.za (mark@localhost [127.0.0.1]) by grumble.grondar.za (8.7.4/8.7.3) with ESMTP id HAA21722; Fri, 8 Mar 1996 07:54:43 +0200 (SAT) Message-Id: <199603080554.HAA21722@grumble.grondar.za> To: Kent Hauser cc: freebsd-current@FreeBSD.org Subject: Re: `make -DCLOBBER world' fails Date: Fri, 08 Mar 1996 07:54:42 +0200 From: Mark Murray Sender: owner-current@FreeBSD.org Precedence: bulk Kent Hauser wrote: > The problem is that programs are compiled & run to generate > some libs before `crt0.o' is created. > > Examples include "gnu/lib/libgmp" and "lib/libmytinfo". > > This problem could be prevented by moving the > > cd ${.CURDIR}/lib/csu/i386 && > ${MAKE} depend all install .... > > to the beginning of the lib make. I agree with this. May I do it? 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 Fri Mar 8 03:15:52 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA00526 for current-outgoing; Fri, 8 Mar 1996 03:15:52 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id DAA00493 for ; Fri, 8 Mar 1996 03:15:47 -0800 (PST) Received: from bunyip.cc.uq.oz.au (pp@bunyip.cc.uq.oz.au [130.102.2.1]) by who.cdrom.com (8.6.12/8.6.11) with SMTP id CAA23616 for ; Fri, 8 Mar 1996 02:01:32 -0800 Received: from bunyip.cc.uq.oz.au by bunyip.cc.uq.oz.au id <25431-0@bunyip.cc.uq.oz.au>; Fri, 8 Mar 1996 20:01:14 +1000 Received: from netfl15a.devetir.qld.gov.au by pandora.devetir.qld.gov.au (8.6.10/DEVETIR-E0.3a) with ESMTP id RAA24514 for ; Fri, 8 Mar 1996 17:19:59 +1000 Received: from localhost by netfl15a.devetir.qld.gov.au (8.6.8.1/DEVETIR-0.1) id HAA01712 for ; Fri, 8 Mar 1996 07:23:48 GMT Message-Id: <199603080723.HAA01712@netfl15a.devetir.qld.gov.au> X-Mailer: exmh version 1.6.5 12/11/95 To: current@FreeBSD.ORG Subject: More on the ffs_alloc: dup thingummy stuff 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: Fri, 08 Mar 1996 17:23:47 +1000 From: Stephen Hocking Sender: owner-current@FreeBSD.ORG X-Loop: owner-current@FreeBSD.ORG Precedence: bulk I've backed out the most recent change to vm_map.c and still se the error mentioned above. Can someone send me version 1.62 of swap_pager.c? Stephen -- I do not speak for the Worker's Compensation Board of Queensland - They don't pay me enough for that! From owner-freebsd-current Fri Mar 8 03:17:13 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA01005 for current-outgoing; Fri, 8 Mar 1996 03:17:13 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id DAA00930 for ; Fri, 8 Mar 1996 03:17:01 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id AAA23069 for ; Fri, 8 Mar 1996 00:21:27 -0800 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id JAA04325 for ; Fri, 8 Mar 1996 09:20:40 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id JAA11976 for freebsd-current@FreeBSD.org; Fri, 8 Mar 1996 09:20:39 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id JAA21005 for freebsd-current@FreeBSD.org; Fri, 8 Mar 1996 09:15:12 +0100 (MET) From: J Wunsch Message-Id: <199603080815.JAA21005@uriah.heep.sax.de> Subject: Re: New kernel option proposed.. To: freebsd-current@FreeBSD.ORG (FreeBSD-current users) Date: Fri, 8 Mar 1996 09:15:12 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <15638.826244887@time.cdrom.com> from "Jordan K. Hubbard" at Mar 7, 96 04:28:07 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: owner-current@FreeBSD.ORG Precedence: bulk As Jordan K. Hubbard wrote: > Stefan Esser would like an option which he can use to conditionalize > code to be "conservative" in the case where you're first installing. Too many people run the GENERIC kernel as their normal one. I don't have an idea which amount of code will be affected, but i'd rather vote for a sysctl variable (perhaps defaulting to ``conservative'' in the GENERIC kernel, and being turned off in /etc/rc later). -- 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 Mar 8 03:17:33 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA01123 for current-outgoing; Fri, 8 Mar 1996 03:17:33 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id DAA01074 for ; Fri, 8 Mar 1996 03:17:24 -0800 (PST) Received: from mail.think.com (Mail1.Think.COM [131.239.33.245]) by who.cdrom.com (8.6.12/8.6.11) with SMTP id XAA22363 for ; Thu, 7 Mar 1996 23:48:37 -0800 Received: from Early-Bird-1.Think.COM by mail.think.com; Fri, 8 Mar 96 02:48:32 -0500 Received: from compound (fergus-21.dialup.cfa.org) by Early-Bird.Think.COM; Fri, 8 Mar 96 02:48:27 EST Received: (from alk@localhost) by compound (8.6.12/8.6.112) id BAA00323; Fri, 8 Mar 1996 01:48:21 -0600 Date: Fri, 8 Mar 1996 01:48:21 -0600 Message-Id: <199603080748.BAA00323@compound> From: Tony Kimball To: freebsd-current@FreeBSD.ORG Subject: 3/3 SNAP panic Sender: owner-current@FreeBSD.ORG X-Loop: owner-current@FreeBSD.ORG Precedence: bulk FYI, and to whom it may concern: Booting the 960303 SNAP after install, I received a fatal trap 1: privelidged insn fault in kernel mode after the screenblank modload message. Details are: insn ptr 0x8:0xf010abe0 c seg base Q l 0xfffff type 0x1b dpc 0 presence 1 def32 1 gran 1 proc eflags : int enabled, resume, IOPL = 0 the process was modload (114), the imask was dumped as empty, and a panic immediately followed. I could reproduce it and do a savecore if that would be helpful. From owner-freebsd-current Fri Mar 8 04:27:43 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA01338 for current-outgoing; Fri, 8 Mar 1996 03:18:20 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id DAA01289 for ; Fri, 8 Mar 1996 03:18:08 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id XAA22194 for ; Thu, 7 Mar 1996 23:22:49 -0800 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.4/8.6.9) with SMTP id XAA16814; Thu, 7 Mar 1996 23:22:35 -0800 (PST) To: Ken Lam cc: current@FreeBSD.ORG Subject: Re: New kernel option proposed.. In-reply-to: Your message of "Thu, 07 Mar 1996 22:24:38 EST." <1.5.4b11.32.19960308032438.006be60c@awod.com> Date: Thu, 07 Mar 1996 23:22:35 -0800 Message-ID: <16812.826269755@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.ORG X-Loop: owner-current@FreeBSD.ORG Precedence: bulk > Hmmm.. seems more obvious, but then won't that kind of mean that we > can't say RTFM? After all, the standard 4.4bsd manuals, Unix System > Administrator Handbook, etc.. all refer to GENERIC in their kernel > configuration sections. I'm not proposing to remove the generic kernel, simply the magic meaning of the keyword "GENERIC" in our kernel sources. What if you wanted to compile a non-GENERIC kernel with safety belts still intact? Jordan From owner-freebsd-current Fri Mar 8 04:43:01 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA10821 for current-outgoing; Fri, 8 Mar 1996 04:43:01 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id EAA10815 for ; Fri, 8 Mar 1996 04:43:00 -0800 (PST) Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id EAA24713 for ; Fri, 8 Mar 1996 04:42:56 -0800 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.7.4/8.6.9) id EAA20950; Fri, 8 Mar 1996 04:41:32 -0800 (PST) Date: Fri, 8 Mar 1996 04:41:32 -0800 (PST) Message-Id: <199603081241.EAA20950@silvia.HIP.Berkeley.EDU> To: coredump@nervosa.com CC: rgrimes@GndRsh.aac.dev.com, current@FreeBSD.ORG In-reply-to: (message from invalid opcode on Thu, 7 Mar 1996 14:34:48 -0800 (PST)) Subject: Re: changes to /etc/ttys From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-current@FreeBSD.ORG X-Loop: owner-current@FreeBSD.ORG Precedence: bulk * Terry, Rod, I failed to think of that. Yes, that would generate TOO many * questions over it. I was just thinking of consistency, and forgot about * new users, *sigh*, nevermind it than. "NEW USERS"? Do you understand what Terry and Rod said? I'd be mightily surprised if I don't get a login prompt after a reboot. (And nobody will call me a new user. :) You seem to be generating lots of mails lately, and most of that seem to be, well, not very well thought out and ends up wasting other people's times. Maybe you can study the system a little before starting to suggest "improvements"? Satoshi From owner-freebsd-current Fri Mar 8 05:45:31 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA14850 for current-outgoing; Fri, 8 Mar 1996 05:45:31 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id FAA14844 for ; Fri, 8 Mar 1996 05:45:30 -0800 (PST) Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by who.cdrom.com (8.6.12/8.6.11) with SMTP id FAA25035 for ; Fri, 8 Mar 1996 05:29:40 -0800 Received: by sequent.kiae.su id AA22031 (5.65.kiae-2 ); Fri, 8 Mar 1996 16:06:56 +0300 Received: by sequent.KIAE.su (UUMAIL/2.0); Fri, 8 Mar 96 16:06:56 +0300 Received: (from ache@localhost) by astral.msk.su (8.7.4/8.7.3) id PAA00857; Fri, 8 Mar 1996 15:27:16 +0300 (MSK) Message-Id: <199603081227.PAA00857@astral.msk.su> Subject: Re: ps and u_map allocation problems with kernel supped Mar 7 To: toor@dyson.iquest.net (John S. Dyson) Date: Fri, 8 Mar 1996 15:27:16 +0300 (MSK) Cc: roberto@keltia.freenix.fr, rsanders@mindspring.com, freebsd-current@FreeBSD.org In-Reply-To: <199603072300.XAA00850@dyson.iquest.net> from "John S. Dyson" at "Mar 7, 96 11:00:15 pm" From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast X-Mailer: ELM [version 2.4ME+ PL11 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: owner-current@FreeBSD.ORG Precedence: bulk > > > > > I guess what I am saying is I AM LISTENING :-). > > > > Did you looked at the pipe-related problem Andreyspoke of last week, > > a problem seen with ssh (which use a pipe to "ssh" when you use > > "scp"). File transferts of more than 8 KB just lock. > > > I think that was fixed last week. The problem was that the direct > buffer transfers did not get waken up correctly. Select didn't even work > with them. I can confirm that this problem already fixed in -current. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-current Fri Mar 8 07:46:22 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA25150 for current-outgoing; Fri, 8 Mar 1996 07:46:22 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA25071 for ; Fri, 8 Mar 1996 07:46:07 -0800 (PST) Received: from Sisyphos (Sisyphos.MI.Uni-Koeln.DE [134.95.212.10]) by who.cdrom.com (8.6.12/8.6.11) with SMTP id GAA25376 for ; Fri, 8 Mar 1996 06:15:40 -0800 Received: by Sisyphos id AA10961 (5.67b/IDA-1.5 for current@FreeBSD.org); Fri, 8 Mar 1996 15:13:08 +0100 Message-Id: <199603081413.AA10961@Sisyphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Fri, 8 Mar 1996 15:13:07 +0100 In-Reply-To: "Jordan K. Hubbard" "Re: New kernel option proposed.." (Mar 7, 23:22) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: "Jordan K. Hubbard" Subject: Re: New kernel option proposed.. Cc: current@freebsd.org Sender: owner-current@freebsd.org X-Loop: owner-current@FreeBSD.ORG Precedence: bulk On Mar 7, 23:22, "Jordan K. Hubbard" wrote: } Subject: Re: New kernel option proposed.. } > Hmmm.. seems more obvious, but then won't that kind of mean that we } > can't say RTFM? After all, the standard 4.4bsd manuals, Unix System } > Administrator Handbook, etc.. all refer to GENERIC in their kernel } > configuration sections. } } I'm not proposing to remove the generic kernel, simply the magic } meaning of the keyword "GENERIC" in our kernel sources. What if you } wanted to compile a non-GENERIC kernel with safety belts still intact? Hmmm, but the idea isn't bad at all ... Why not put an options GENERIC line into the BOOTMFS and GENERIC kernel config files. This way all the earlier dependencies on the GENERIC kernel name will still work. The removal of the automatic definition of the kernel's name as a preprocesser symbol was good. But why not add the definition of GENERIC, since it serves a purpose, is explicit in the config file and a symbol that shouldn't be used for any other purpose currently ... 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 Fri Mar 8 08:53:41 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA28993 for current-outgoing; Fri, 8 Mar 1996 08:53:41 -0800 (PST) Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id IAA28986 for ; Fri, 8 Mar 1996 08:53:37 -0800 (PST) Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA15707; Fri, 8 Mar 1996 11:52:46 -0500 Date: Fri, 8 Mar 1996 11:52:46 -0500 From: "Garrett A. Wollman" Message-Id: <9603081652.AA15707@halloran-eldar.lcs.mit.edu> To: Wolfram Schneider Cc: current@freebsd.org Subject: *.mk wishes In-Reply-To: <199603072247.XAA01898@campa.panke.de> References: <199603072247.XAA01898@campa.panke.de> Sender: owner-current@freebsd.org X-Loop: owner-current@FreeBSD.ORG Precedence: bulk < said: > bsd.man.mk: > MANGRP, MANOWN, MANMODE, MANDIR already defined > in bsd.own.mk, should deleted Sure. > bsd.own.mk: > new variables DOCGRP, DOCOWN, DOCMODE, DOCDIR for documents Sure. > sys.mk: > MMAP_RO: read only mmap, for programs like grep, groff, look etc. > MMAP_RW: write works (inn) No. There is no need to support anything in our source tree other than FreeBSD. -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 Fri Mar 8 08:54:44 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA29054 for current-outgoing; Fri, 8 Mar 1996 08:54:44 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id IAA29049 Fri, 8 Mar 1996 08:54:43 -0800 (PST) Received: from veda.is (root@veda.is [193.4.230.1]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id IAA27152 ; Fri, 8 Mar 1996 08:54:36 -0800 Received: (from adam@localhost) by veda.is (8.7.4/8.7.3) id QAA12890; Fri, 8 Mar 1996 16:54:23 GMT From: Adam David Message-Id: <199603081654.QAA12890@veda.is> Subject: Re: Sig 11's on current To: dyson@freebsd.org Date: Fri, 8 Mar 1996 16:54:23 +0000 (GMT) Cc: freebsd-current@freebsd.org In-Reply-To: <199603072354.XAA23457@veda.is> from Adam David at "Mar 7, 96 11:54:21 pm" X-Mailer: ELM [version 2.4ME+ PL10 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: owner-current@FreeBSD.ORG Precedence: bulk > > > I just compiled current (3/2) (just after some vm changes) and now I get > > > a bunch of SIG 10 and 11's, especially when compiling. > > > > Me too. I get sig 10/11 when trying to make top, bonnie, et.al. Top would > > compile, but make would core if I tried make install. Make blows up on Bonnie > > during the ``extraction'' phase. A kernel older than Saturday works fine. > > > I'll do some more complete testing on 6M and 8M machines tonite. > > John > dyson@freebsd.org I have been getting these too, along with unusual Malloc warnings, and from all manner of programs. This is on a 16 MB machine which is heavily loaded for the memory size. Sources are from March 6th. The parent process of such abnormally terminated processes has been observed sometimes to wait forever, with CPU% in the region of 0% or 120%, until killed manually (does not respond to keyboard). -- Adam David From owner-freebsd-current Fri Mar 8 09:57:42 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA02422 for current-outgoing; Fri, 8 Mar 1996 09:57:42 -0800 (PST) Received: (from dyson@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA02416 Fri, 8 Mar 1996 09:57:41 -0800 (PST) From: John Dyson Message-Id: <199603081757.JAA02416@freefall.freebsd.org> Subject: Re: Sig 11's on current To: adam@veda.is (Adam David) Date: Fri, 8 Mar 1996 09:57:41 -0800 (PST) Cc: dyson@freebsd.org, freebsd-current@freebsd.org In-Reply-To: <199603081654.QAA12890@veda.is> from "Adam David" at Mar 8, 96 04:54:23 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@freebsd.org X-Loop: owner-current@FreeBSD.ORG Precedence: bulk > > I have been getting these too, along with unusual Malloc warnings, and from > all manner of programs. This is on a 16 MB machine which is heavily loaded > for the memory size. Sources are from March 6th. The parent process of such > abnormally terminated processes has been observed sometimes to wait forever, > with CPU% in the region of 0% or 120%, until killed manually (does not respond > to keyboard). > I have found several interesting bugs in the VM code and had several pointed out to me. The commits should happen sometime this weekend. I have had some emergencies at work causing some delays in testing. It is suprising that the code works as well as it does :-(. Please revert to older than the broken code for production work. John From owner-freebsd-current Fri Mar 8 10:19:39 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA03315 for current-outgoing; Fri, 8 Mar 1996 10:19:39 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA03310 Fri, 8 Mar 1996 10:19:36 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA17284; Fri, 8 Mar 1996 11:13:55 -0700 From: Terry Lambert Message-Id: <199603081813.LAA17284@phaeton.artisoft.com> Subject: Re: 2842 and the disappearing file-system :-( To: gibbs@freefall.freebsd.org (Justin T. Gibbs) Date: Fri, 8 Mar 1996 11:13:55 -0700 (MST) Cc: terry@lambert.org, imb@scgt.oz.au, stable@FreeBSD.org, current@FreeBSD.org In-Reply-To: <199603080316.TAA02977@freefall.freebsd.org> from "Justin T. Gibbs" at Mar 7, 96 07:16:52 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: owner-current@FreeBSD.ORG Precedence: bulk > Again you have decided that if you at first miss the target, to > choose a totally different target for your next attempt. Lets > remember what started this whole thread... I have to say that my subtext on this whole thing has always been the need for an orthoganal configuration management API. I would not have said anything, if I hadn't thought that it was going to hell. I wish I had known about the 2842 VLB being probed by the EISA probe code earlier, but we can't all know everything. This discussion was not intended to blow up out of proportion as it has done. > The 2842VLB SCSI card, a non PnP device, sticks its identifier in > the EISA slot address space for identification. FreeBSD currently > always looks for these IDs in the EISA slot address space even if > the EISA motherboard ID at 0x0C80 is not found so that it can detect > these cards. > > You complained that the EISA code should not probe the slot address > space if the motherboard ID was not found. And thus this argument > began. I still maintain this position. > Since then, you've tried to make this into an agument for a configuration > manager. Well, you have no argument from me for a configuration manager. > In fact I wrote eisaconf with the sole intention of making it a prototype > for a configuration manager that would encompass other device types. > > What you will, and have seen me argue against is the need to construct > additional mechanisms into how we probe devices to cover a single > VLB card that was designed to be probed like an EISA device. Having > more than one way to trigger a scan of the EISA slot address space > for devices is confusing at best, and leads to bugs at worst. The > probe for EISA devices has proven non-invasive on the 100s of machines > that currently have eisa0 in their config files and the same scan would > be required anyway to support the 2842, so there is no technical > reason to provide an alternate method for triggering the search. Let's stop here for a second. I don't think the major work of the probe for the VLB card is the scan of the EISA slot address space. It's getting the configuration information about the card, and that doesn't take EISA configuration data to do it. So I don't think the 2842 should be being found by triggering a scan of the EISA slot address space. To put this another way, I shouldn't have to have an eisa0 in my config file to use a VLB card. It's confusing -- as confusing as having the ability to option out the non-optional npx0 device. I think if we back up and agree that the probe [of configuration parameters associated with the card] should be seperate from the EISA slot scan, then we will have made progress. I don't *want* "an alternate method to trigger the search", I want to not do the slot search on non-EISA machines. Yes, this means that there is a need for some additional stub code to actually find the card, but it doesn't change how the configuration information is extracted from the card. > Furthermore, eisaconf must already properly report other ISA cards that > can be configured in "eisa compatibility mode" as living on the ISA > bus (the 3c509 for example) so it is already suited to the task of handing > the 2842 with absolutly no additional code or complexity: > > ahc1: at 0x7c00-0x7cff irq 12 on isa All things plugged into EISA slots are supposed to be configured, period. So it's a non-sequitur to talk about "can be configured" here. Everything that goes into an EISA slot is capable of having an EISA configuration file (I have a utility to generate these for ISA cards that came with my EISA machine; you must enter the IRQ, DRQ, I/O, and memory address ranges as part of the generation process). And if it is in an EISA slot, it *should* have an EISA config. > >No; I want a dup of the EISA process in the ISA PnP space so that it's > >just a case of making a reference to the routines (and *remove* the > >"eisa_" designations entirely). > > But the 2842 is not a PnP device and forcing the ISA PnP mechanism to > deal with non PnP hardware is a violation of layering in a configuration > manager scenario. The configuration manager should moderate between > the ISA PnP probe mechanism and the list of "possible probe locations" > provided by ISA devices and their "bus manager". The dup of the EISA process into the PnP space is an implementation detail on the implementation of ISA PnP. As part of the configuration management, you have to probe the non-relocatable devices for which you have drivers to determine the existance of "immobile" cards; then for all mobile cards, you relocate them. I think the 2842 is in the same category as the WD8013: it's a card that is software relocatable, but which is not PnP and thus should probably not be relocated. It's one of the base line devices that have a single graph vector for location. For a real EISA device, it's acceptable to relocate the thing, since EISA devices are configured per slot and each OS (or BIOS POST for DOS for the INT 13 hook). That means any OS that knows about dealing with EISA the correct way will find the relocated card. This isn't true of VLB cards, especially VLB cards for boot devices. I think that the 2842 needs to be probed later than the typical EISA, PCI, PCMCIA, and PnP ISA devices, like other non-relocatable devices. It think it needs to have an invariant configuration graph vector, *unlike* things which are found by the EISA probe. I think it is incorrect to probe the thing as an EISA device (are there any motherboards that have EISA and VLB at the same time? That would be a good counter-argument...). > >At the very least, we should admit that looking for EISA stuff on a > >non-EISA machine is a kludge. > > Complain to Adaptec. They didn't write the probe code. I have no problem with them assigning slot space for a VLB card (it's an artifact of the bus interface ASIC that they used anyway). What I do have a problem with is the implied probe order not treating it as a non-relocatable ISA device because it had been found in EISA space when we finally get to the point where we can do a graph reduction topology sort to relocate the relocatable cards. EISA cards are relocatable. Relocating ISA or VLB cards that aren't succeptable to ISA PnP drivers means that the cards could disappear from DOS or another OS with a hard-coded config.sys line for ATAPI for a CDROM on that controller, or whatever. > >Well, it doesn't seem that many people are thinking in terms of a unified > >configuration manager ala Windows95 and WindowsNT. I expect the number > >of people doing so to increase over time as people desire better > >autoconfiguration out of FreeBSD. > > Probing the 2842 as an EISA device does not preclude a configuration > manager aproach to solving our current device probe mess. Wrong. It identifies it as an EISA device, and EISA devices are fair game to be relocated by a PnP configuration manager. Look at the Windows95 PnP problems that FreeBSD has had with ethernet cards. Look at the IRQ 12 collisions that occur for PS/2 mice, still, on Windows95 hardware with PnP enabled. > Anyone who currently has eisa0 in there kernel is proving the point that > the probe of the eisa slot address space is non-invasive. The probe > can't tell if you have a VLB motherboard in order to prevent the probe, > and it can't know if you have a 2842 either without looking, so it always > does the scan. It can tell that you don't have an EISA motherboard, which is the same thing, by negative induction. The issue is not the invasiveness of the EISA probe; its with the classification of the card as an EISA card. And with the requirement that I have the EISA code configured into a kernel for a non-EISA system. > >The point is you *should* be *able* to call the same functions for ISA, > >and for PnP, which uses non-invasive probing (unless you have an old > >IBM manufactured parallel port card), you *can*. > > The match routines and forcing a scan of the eisa address space makes > no sense in a generic ISA probe (deals with non PnP hardware) configuration > sub-manager. I agree. Don't use the slot scan to locate the card; it isn't a substitute for the majority of the work done by the probe code anyway. Move the scan identification into an EISA-specific stub, and create an ISA specific stub for the non-relocatable VLB card. > >This is a *card* problem, not a generic problem resolved for anthing > >other than the Adaptec card by calling the EISA code. > > Exactly! The Adaptec card behaves like an eisa device so you either > have it use the EISA probe mechanism or you have it be an ISA probe > that does the scan itself since it would be a layering violation to > have it call into the EISA probe to force it to scan the slot address > space even if it wasn't an EISA machine, call the eisa match routine > to see if a proper ID was found, and then turn around and register itself > with the ISA device manager. I think you are stuck on using the fact that it exports EISA slot data to trigger the probe (the manority of which is not dependent on the fact that it's "EISA"). I think this is wrong, for the ordering reasons stated above. > >> What features does VLB have that make it of any use to differentiate > >> between VLB and ISA probes? > > > >A) Default settings for driver configurable bus-on times, since VLB > > steals DRAM refresh cycles. VLB on time needs to be agregated > > and adjusted *down* where necessary. > > This is a device driver issue, not a VLB bus issue, since only the > driver knows if it is talking to a VLB card. The VLB bus is not bridged. The agregate bus-on time for N VLB cards going in sequence is the issue for deciding to "tune" the VLB cards down. > >So the DMA argument doesn't support the EISA/VLB probe argument. > > It certainly doesn't support that there should be a separate VLB > probe. > 16MB dma problems transend busses. So call it a variant ISA probe. So call it writing a probe. Or abstract the "relocatable" attribute of the 2842 by virtue of detecting it's not really EISA (using the same code that would be required for an ISA probe stub), and increase the complexity of the EISA code by making it do a variant insertion in the configuration topology graph to tag it as non-relocatable (note: this last approach strikes me as singularly bogus, and is why I am against using the EISA code to detect the non-EISA card). > >No. I think it is incorrect to use the EISA slot space mechanism to > >probe the controller. > > Complain to Adaptec. Again... I think you are stuck on using the fact that it exports EISA slot data to trigger the probe (the manority of which is not dependent on the fact that it's "EISA"). I think this is wrong, for the ordering reasons stated above. > >The probe includes IRQ, DMA, and other info, > >that unless it's a real EISA card, isn't going to be in the EISA > >configuration space for VLB... even if such a space exists, the > >user didn't run the DOS EISA configuration utility for the card > >to set it. It is at least 75% of the way to an EISA-independent probe. > > For all of the EISA cards that I've added eisaconf probes for, the IRQ, > DMA and most other interresting information is availible in registers > initialized by the the EISA BIOS. The 2842 has the same registers > availible that the 2742 so it is not an issue. Think of the 2842 > as an EISA card that doesn't have an overlay file and so doesn't store > anything in configuration space. We can't even read configuration space > yet, but the eisaconf code will have to deal with devices that have > nothing set up there anyway which is simple since it will simply leave > it up to the device driver to interpret the data once the eisaconf code > can provide a means to access it. Precisely! Once you can manipulate the configuration space, EISA cards are as relocatable as ISA PnP cards! But this VLB ccard, which you lie and say is an EISA card by virtue of whose probe comes true, can *not* be relocated! You have to indirect all EISA configuration space code through the driver, and then call common routines for *all other drivers*, and for this one fake an immobile configuration space! Bletch! Talk about unnecessary complexity! > >As I said before, you will have to break it out and provide EISA > >specific stubs. For ISA, you have to search the allowable space > >(and that is a data issue, as long as the probe is non-invasive). > > What is the gain in doing this? EISA cards become relocatable within the conflict space. > No, with your assertion that having the ISA PnP support akin to > how eisaconf works, solves the 2842 issue. Coercing the 2842 to > fit into an ISA PnP model (it uses a dip switch block combined > with a "SCSI-Select" utility) is far worse than probing it as an > EISA device as the manufacturer intended. The manufacturer intended to avoid having to design VLB ASIC's when it already had EISA ASIC's. The manufacturer did not intend for the BIOS on the machine to use EISA configuration methods to handle VLB cards when the machine had no EISA slots and therefore doesn't have EISA-specific BIOS anyway. The "EISA-ness" of the 2842 is an artifact of sloppy design, not of engineering intent. Do you not agree that EISA cards should be relocatable by a resonable configuration manager that knows EISA? Or that the 2842, a VLB card, should *not* be relocatable because there is no standard mechanism for handling an EISA relocation of a non-EISA card? Or that the 2842 would have to have a fake configuration space, which would greatly complicate the configuration space manipulation for *real* EISA cards? Look, it's *fine* with me that you call my suggestion "writing an ISA probe" (even if I think it's possible to reuse most of the code), so long as the ability to relocate EISA cards is not adversly affected by the fact that the 2842 lies about being an EISA card. 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 Mar 8 11:01:56 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA05560 for current-outgoing; Fri, 8 Mar 1996 11:01:56 -0800 (PST) Received: from covina.lightside.com (covina.lightside.com [198.81.209.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA05553 for ; Fri, 8 Mar 1996 11:01:54 -0800 (PST) Received: by covina.lightside.com (Smail3.1.28.1 #6) id m0tv7QA-0004ITC; Fri, 8 Mar 96 11:01 PST Date: Fri, 8 Mar 1996 11:01:45 -0800 (PST) From: Jake Hamby To: current@FreeBSD.ORG cc: jkh@time.cdrom.com Subject: 3/3 SNAP needs bounce buffers? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: owner-current@FreeBSD.ORG Precedence: bulk I haven't received any response to my complaint that the 3/3 SNAP boot floppy crashes on my system with: panic: unwire: page not in pmap Syncing disks... I have 24MB of RAM and a combination of IDE and SCSI (Adaptec 2842 VLB). It appears that Jordan is not using the GENERIC kernel exactly (he's including ATAPI [which doesn't work for me] and there is no 15-second "Waiting for SCSI devices to settle" delay) so I'm wondering if you're including BOUNCE_BUFFERS too? I'm using the regular boot.flp not the 4MB version. I don't think my VLB card needs bounce buffers, but I do have 24MB of RAM, and have no idea why it crashes like this before sysinstall even starts! Help? In other news, I tried the 3/3 SNAP on a different machine (8MB RAM, AMI BIOS, 3 IDE drives, NE2000 Ethernet) that we threw together from crap parts. Anyway the install boots fine (wah!) but when we were playing with the emergency holographic shell, sh core dumped several times during the install (we saw sh.core in /, since the shell is not chroot'ed to /mnt) or at least the first 8k of the core dump before the MFS filesystem filled up. Also, when trying to fetch DES, it couldn't find the distribution, failed, and core dumped with a message like "Can't continue, I'm dead..." Please, will there be another snap this weekend (hopefully with more VM patches)? Thanks!!! ---Jake From owner-freebsd-current Fri Mar 8 11:04:28 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA05897 for current-outgoing; Fri, 8 Mar 1996 11:04:28 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id LAA05885 for ; Fri, 8 Mar 1996 11:04:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.4/8.6.9) with SMTP id LAA19602; Fri, 8 Mar 1996 11:04:04 -0800 (PST) To: Jake Hamby cc: current@FreeBSD.ORG Subject: Re: 3/3 SNAP needs bounce buffers? In-reply-to: Your message of "Fri, 08 Mar 1996 11:01:45 PST." Date: Fri, 08 Mar 1996 11:04:04 -0800 Message-ID: <19600.826311844@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.ORG X-Loop: owner-current@FreeBSD.ORG Precedence: bulk > Please, will there be another snap this weekend (hopefully with more VM > patches)? Thanks!!! I hope so - I'm certainly working on it! Jordan From owner-freebsd-current Fri Mar 8 13:16:53 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA13560 for current-outgoing; Fri, 8 Mar 1996 13:16:53 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA13536 for ; Fri, 8 Mar 1996 13:16:47 -0800 (PST) Received: from nervosa.com (root@nervosa.com [192.187.228.86]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id LAA29511 for ; Fri, 8 Mar 1996 11:28:39 -0800 Received: from nervosa.com (coredump@onyx.nervosa.com [10.0.0.1]) by nervosa.com (8.7.5/nervosa.com.2) with SMTP id LAA03413; Fri, 8 Mar 1996 11:21:30 -0800 (PST) Date: Fri, 8 Mar 1996 11:21:29 -0800 (PST) From: invalid opcode To: Satoshi Asami cc: rgrimes@GndRsh.aac.dev.com, current@FreeBSD.ORG Subject: Re: changes to /etc/ttys In-Reply-To: <199603081241.EAA20950@silvia.HIP.Berkeley.EDU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: owner-current@FreeBSD.ORG Precedence: bulk On Fri, 8 Mar 1996, Satoshi Asami wrote: > You seem to be generating lots of mails lately, and most of that seem > to be, well, not very well thought out and ends up wasting other > people's times. Maybe you can study the system a little before > starting to suggest "improvements"? > Satoshi Thanks, I'll make sure to consult the mighty Sastoshi before I say anything. Gimme a break. == Chris Layne ============================================================= == coredump@nervosa.com ================ http://www.nervosa.com/~coredump == From owner-freebsd-current Fri Mar 8 14:59:18 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA19273 for current-outgoing; Fri, 8 Mar 1996 14:59:18 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id OAA19267 for ; Fri, 8 Mar 1996 14:59:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.4/8.6.9) with SMTP id OAA20290; Fri, 8 Mar 1996 14:58:46 -0800 (PST) To: Jake Hamby cc: current@FreeBSD.ORG Subject: Re: 3/3 SNAP needs bounce buffers? In-reply-to: Your message of "Fri, 08 Mar 1996 11:01:45 PST." Date: Fri, 08 Mar 1996 14:58:46 -0800 Message-ID: <20288.826325926@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.ORG X-Loop: owner-current@FreeBSD.ORG Precedence: bulk > I have 24MB of RAM and a combination of IDE and SCSI (Adaptec 2842 VLB). > It appears that Jordan is not using the GENERIC kernel exactly (he's I am - and ATAPI is included in GENERIC now. > including ATAPI [which doesn't work for me] and there is no 15-second > "Waiting for SCSI devices to settle" delay) so I'm wondering if you're That's because someone apparently broke that recently.. :-) > including BOUNCE_BUFFERS too? I'm using the regular boot.flp not the 4MB I am indeed. > version. I don't think my VLB card needs bounce buffers, but I do have > 24MB of RAM, and have no idea why it crashes like this before sysinstall > even starts! Help? Weird! I unfortunately don't have a 2842 to test with, so this is kinda hard. I'm leaving for the post office right now with your Bt445C - I guess it's time I got off my butt and sent it, huh? :-) Jordan From owner-freebsd-current Fri Mar 8 15:09:13 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA20066 for current-outgoing; Fri, 8 Mar 1996 15:09:13 -0800 (PST) Received: from covina.lightside.com (covina.lightside.com [198.81.209.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA20061 for ; Fri, 8 Mar 1996 15:09:11 -0800 (PST) Received: by covina.lightside.com (Smail3.1.28.1 #6) id m0tvBHY-0004IbC; Fri, 8 Mar 96 15:09 PST Date: Fri, 8 Mar 1996 15:09:08 -0800 (PST) From: Jake Hamby To: "Jordan K. Hubbard" cc: current@FreeBSD.ORG Subject: Re: 3/3 SNAP needs bounce buffers? In-Reply-To: <20288.826325926@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: owner-current@FreeBSD.ORG Precedence: bulk On Fri, 8 Mar 1996, Jordan K. Hubbard wrote: > Weird! I unfortunately don't have a 2842 to test with, so this is > kinda hard. I'm leaving for the post office right now with your > Bt445C - I guess it's time I got off my butt and sent it, huh? :-) > > Jordan It could be just a weird VM problem, I dunno.. At any rate, thanks for sending the Bt445C, I can sure use it for the "Frankenstein" 486 we've got set up as a FreeBSD box right now at my university. Right now it has three IDE hard drives and a Mitsumi 2X CD-ROM, of all things, and a friend wanted to throw in an 8-bit (!) ISA Future Domain SCSI controller so he could plug in his SCSI Zip drive. I'll use your Buslogic instead, and then we'll have a decent SCSI controller and therefore the opportunity to plug in SCSI devices as we find (beg, borrow, or steal) them. :-) Belated thanks for your belated gift, I guess it's enough of a bribe for me to design those FreeBSD advertisement pages I've offered to do. :-) Also, in the propoganda area, I send some mail to Nicholas Petreley, who writes a weekly column in InfoWorld. He said that their Test Center, among other things, will: "try to find you the best Web server solution, regardless of the platform or combination of products we must use ... But we also consider it our charter to evaluate one or more of the low mind- and market-share platforms that may be cost-effective and competitive product combinations, such as the Macintosh OS or Linux." I told him that FreeBSD is exactly the kind of product they ought to look into (and/or its cousins NetBSD and BSDI). I pointed him to ftp.cdrom.com as a FreeBSD success story, the benchmarks at plastique.stanford.edu, and the FreeBSD Web page. I told him that once I finished the FreeBSD comparison Web page, I'd mail him the URL. I'll let you know what he replies. (crossing my fingers..) ---Jake From owner-freebsd-current Fri Mar 8 15:11:13 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA20273 for current-outgoing; Fri, 8 Mar 1996 15:11:13 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id PAA20264 for ; Fri, 8 Mar 1996 15:11:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.4/8.6.9) with SMTP id PAA20378; Fri, 8 Mar 1996 15:10:47 -0800 (PST) To: Jake Hamby cc: current@FreeBSD.ORG Subject: Re: 3/3 SNAP needs bounce buffers? In-reply-to: Your message of "Fri, 08 Mar 1996 15:09:08 PST." Date: Fri, 08 Mar 1996 15:10:47 -0800 Message-ID: <20376.826326647@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.ORG X-Loop: owner-current@FreeBSD.ORG Precedence: bulk > Also, in the propoganda area, I send some mail to Nicholas Petreley, who > writes a weekly column in InfoWorld. He said that their Test Center, > among other things, will: Excellent! This is exactly the kind of take-charge attitude I like to see.. :-) Jordan From owner-freebsd-current Fri Mar 8 15:16:07 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA20663 for current-outgoing; Fri, 8 Mar 1996 15:16:07 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA20607 for ; Fri, 8 Mar 1996 15:16:01 -0800 (PST) Received: from miller.cs.uwm.edu (miller.cs.uwm.edu [129.89.9.13]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id OAA02398 for ; Fri, 8 Mar 1996 14:39:25 -0800 Received: (from james@localhost) by miller.cs.uwm.edu (8.7.3/8.7.3) id QAA13075 for current@freebsd.org; Fri, 8 Mar 1996 16:39:14 -0600 Date: Fri, 8 Mar 1996 16:39:14 -0600 From: Jim Lowe Message-Id: <199603082239.QAA13075@miller.cs.uwm.edu> To: current@FreeBSD.ORG Subject: NCR disk controller, hp disk Sender: owner-current@FreeBSD.ORG X-Loop: owner-current@FreeBSD.ORG Precedence: bulk I have an NCR 825 PCI disk controller. I just attached a second disk to the controller and am trying to access it. The second disk works just fine under dos, but not freebsd-current. I am getting the following errors: sd1(ncr0:1:0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted , retries:4 sd1(ncr0:1:0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted , retries:3 sd1(ncr0:1:0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted , retries:2 sd1(ncr0:1:0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted , retries:1 sd1(ncr0:1:0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted , FAILURE sd1: error reading primary partition table reading fsbn 0 (sd1 bn 0; cn 0 tn 0 s n 0) Any clues as to what to try/do next? The boot up information follows. I am not sure why I am getting the probe0(ncr0:9:0) errors either. Termination? Thanks for any help, -Jim -------------------------------------------------------- CPU: Pentium (99.46-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x525 Stepping=5 Features=0x1bf real memory = 33554432 (32768K bytes) avail memory = 30138368 (29432K bytes) DEVFS: ready for devices Probing for devices on PCI bus 0: chip0 rev 2 on pci0:0 chip1 rev 2 on pci0:7 pci0:7: Intel Corporation, device=0x1230, class=storage (ide) [no driver assigned] meteor0 rev 0 int a irq 12 on pci0:9 meteor0: rev 0x1 ncr0 rev 2 int a irq 10 on pci0:10 (ncr0:0:0): "HP C2247-300 0BA4" type 0 fixed SCSI 2 sd0(ncr0:0:0): Direct-Access sd0(ncr0:0:0): FAST SCSI-2 100ns (10 Mb/sec) offset 8. 1003MB (2054864 512 byte sectors) sd0(ncr0:0:0): with 2051 cyls, 13 heads, and an average 77 sectors/track (ncr0:1:0): "HP C3724S 5153" type 0 fixed SCSI 2 sd1(ncr0:1:0): Direct-Access sd1(ncr0:1:0): FAST SCSI-2 100ns (10 Mb/sec) offset 8. 1149MB (2354660 512 byte sectors) sd1(ncr0:1:0): with 3703 cyls, 5 heads, and an average 127 sectors/track (ncr0:2:0): "TOSHIBA CD-ROM XM-3401TA 2873" type 5 removable SCSI 2 cd0(ncr0:2:0): CD-ROM cd0(ncr0:2:0): 250ns (4 Mb/sec) offset 8. cd0(ncr0:2:0): NOT READY asc:3a,0 Medium not present can't get the size probe0(ncr0:9:0): scsi_cmd probe0(ncr0:9:0): scsi_done (ncr0:9:0): command: 0,0,0,0,0,0-[0 bytes] probe0(ncr0:9:0): scsi_done (ncr0:9:0): command: 0,0,0,0,0,0-[0 bytes] probe0(ncr0:9:0): scsi_done (ncr0:9:0): command: 0,0,0,0,0,0-[0 bytes] probe0(ncr0:9:0): scsi_cmd probe0(ncr0:9:0): scsi_done (ncr0:9:0): command: 12,0,0,0,2c,0-[44 bytes] ------------------------------ 000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 016: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 032: 00 00 00 00 00 00 00 00 00 00 00 00 ------------------------------ probe0(ncr0:9:0): scsi_done (ncr0:9:0): command: 12,0,0,0,2c,0-[44 bytes] ------------------------------ 000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 016: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 032: 00 00 00 00 00 00 00 00 00 00 00 00 ------------------------------ probe0(ncr0:9:0): scsi_done (ncr0:9:0): command: 12,0,0,0,2c,0-[44 bytes] ------------------------------ 000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 016: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 032: 00 00 00 00 00 00 00 00 00 00 00 00 ------------------------------ de0 rev 17 int a irq 11 on pci0:11 de0: DC21140 [10-100Mb/s] pass 1.1 Ethernet address 00:00:c0:b3:d0:9a de0: enabling 100baseTX UTP port vga0 rev 0 on pci0:12 From owner-freebsd-current Fri Mar 8 15:17:05 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA21071 for current-outgoing; Fri, 8 Mar 1996 15:17:05 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA21053 for ; Fri, 8 Mar 1996 15:17:02 -0800 (PST) Received: from hauki.clinet.fi (hauki.clinet.fi [194.100.0.1]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id IAA27074 for ; Fri, 8 Mar 1996 08:47:02 -0800 Received: from cantina.clinet.fi (root@cantina.clinet.fi [194.100.0.15]) by hauki.clinet.fi (8.7.3/8.6.4) with ESMTP id SAA19359; Fri, 8 Mar 1996 18:45:51 +0200 (EET) Received: (hsu@localhost) by cantina.clinet.fi (8.7.3/8.6.4) id SAA15476; Fri, 8 Mar 1996 18:45:51 +0200 (EET) Date: Fri, 8 Mar 1996 18:45:51 +0200 (EET) Message-Id: <199603081645.SAA15476@cantina.clinet.fi> From: Heikki Suonsivu To: "Jordan K. Hubbard" Cc: freebsd-current@FreeBSD.ORG In-reply-to: "Jordan K. Hubbard"'s message of 8 Mar 1996 03:45:09 +0200 Subject: Re: New kernel option proposed.. Organization: Clinet Ltd, Espoo, Finland References: <15638.826244887@time.cdrom.com> Sender: owner-current@FreeBSD.ORG X-Loop: owner-current@FreeBSD.ORG Precedence: bulk From: "Jordan K. Hubbard" In former times we used the GENERIC keyword to do stuff like this, but that was clearly gross. Stefan and I have tossed the idea around and come up with the keyword FAILSAFE as a reasonable proposal. FAILSAFE sounds best to me, as it is quite obvious what it means. (And I would propose it to be made the default for example config files) -- Heikki Suonsivu, T{ysikuu 10 C 83/02210 Espoo/FINLAND, hsu@clinet.fi mobile +358-40-5519679 work +358-0-4375360 fax -4555276 home -8031121 From owner-freebsd-current Fri Mar 8 15:17:50 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA21348 for current-outgoing; Fri, 8 Mar 1996 15:17:50 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA21293 for ; Fri, 8 Mar 1996 15:17:36 -0800 (PST) Received: from Sisyphos (Sysiphos.MI.Uni-Koeln.DE [134.95.212.10]) by who.cdrom.com (8.6.12/8.6.11) with SMTP id FAA24908 for ; Fri, 8 Mar 1996 05:15:39 -0800 Received: by Sisyphos id AA09086 (5.67b/IDA-1.5 for freebsd-current@FreeBSD.ORG); Fri, 8 Mar 1996 14:15:18 +0100 Message-Id: <199603081315.AA09086@Sisyphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Fri, 8 Mar 1996 14:15:17 +0100 In-Reply-To: J Wunsch "Re: New kernel option proposed.." (Mar 8, 9:15) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Subject: Re: New kernel option proposed.. Cc: freebsd-current@FreeBSD.ORG (FreeBSD-current users) Sender: owner-current@FreeBSD.ORG X-Loop: owner-current@FreeBSD.ORG Precedence: bulk On Mar 8, 9:15, J Wunsch wrote: } Subject: Re: New kernel option proposed.. } As Jordan K. Hubbard wrote: } } > Stefan Esser would like an option which he can use to conditionalize } > code to be "conservative" in the case where you're first installing. } } Too many people run the GENERIC kernel as their normal one. I don't } have an idea which amount of code will be affected, but i'd rather } vote for a sysctl variable (perhaps defaulting to ``conservative'' in } the GENERIC kernel, and being turned off in /etc/rc later). I only want the FAILSAFE define for boot init code. The usage should be documented, and this is what I want it for currently: 1) NCR: No **active** synch. transfer negotiation for CDROM drives, which currently fails with the Chinon 525 and 535. 2) NCR: Have a default of NO tags for disk drives. This can be raised in the running system using "ncrcontrol". 3) NCR: use a default of 1 for MAX_LUN instead of the value of 8 in current kernels. 4) PCI: Possibly use a lower burst length limit. Documenting these effects of FAILSAVE being defined is VERY important, or nobody will understand why a custom kernel fails, when the GENERIC kernel worked. 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 Fri Mar 8 15:59:54 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA24411 for current-outgoing; Fri, 8 Mar 1996 15:59:54 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id PAA24404 for ; Fri, 8 Mar 1996 15:59:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.4/8.6.9) with SMTP id PAA20571; Fri, 8 Mar 1996 15:59:09 -0800 (PST) To: se@ZPR.Uni-Koeln.DE (Stefan Esser) cc: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch), freebsd-current@FreeBSD.ORG (FreeBSD-current users) Subject: Re: New kernel option proposed.. In-reply-to: Your message of "Fri, 08 Mar 1996 14:15:17 +0100." <199603081315.AA09086@Sisyphos> Date: Fri, 08 Mar 1996 15:59:09 -0800 Message-ID: <20569.826329549@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.ORG X-Loop: owner-current@FreeBSD.ORG Precedence: bulk > Documenting these effects of FAILSAVE being defined > is VERY important, or nobody will understand why a > custom kernel fails, when the GENERIC kernel worked. I don't disagree, but where would you suggest doing this? Dropping a multi-line comment into LINT for every possible consumer of FAILSAFE will probably eventually result in a comment-from-hell entry in the LINT file is what I'm afraid of. Jordan From owner-freebsd-current Fri Mar 8 16:40:11 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA28582 for current-outgoing; Fri, 8 Mar 1996 16:40:11 -0800 (PST) Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id QAA28573 for ; Fri, 8 Mar 1996 16:40:08 -0800 (PST) Received: from localhost.shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.4/8.7.3) with SMTP id QAA03842; Fri, 8 Mar 1996 16:38:53 -0800 (PST) Message-Id: <199603090038.QAA03842@precipice.shockwave.com> To: Wolfram Schneider cc: current@FreeBSD.ORG Subject: Re: _PATH_* In-reply-to: Your message of "Thu, 07 Mar 1996 23:33:38 +0100." <199603072233.XAA01854@campa.panke.de> Date: Fri, 08 Mar 1996 16:38:52 -0800 From: Paul Traina Sender: owner-current@FreeBSD.ORG X-Loop: owner-current@FreeBSD.ORG Precedence: bulk I think these make perfect sense. You could conceivably have shared versions of a /bin program in /usr/bin, which is why this was set this way in the first place. The second is for stupid compatibility, the final colon is curdir, as you already knew. I don't like it, but I don't want to break it either. From: Wolfram Schneider Subject: _PATH_* /usr/include/paths.h /* Default search path. */ #define _PATH_DEFPATH "/usr/bin:/bin" Why is /usr/bin before /bin? /* All standard utilities path. */ #define _PATH_STDPATH \ "/usr/bin:/bin:/usr/sbin:/sbin:" Same. And why the colon? Wolfram From owner-freebsd-current Fri Mar 8 18:04:03 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA05324 for current-outgoing; Fri, 8 Mar 1996 18:04:03 -0800 (PST) Received: from whisker.cdrom.com (jkh-Net.cdrom.com [192.216.222.224]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id SAA05305 Fri, 8 Mar 1996 18:03:58 -0800 (PST) Received: (from jkh@localhost) by whisker.cdrom.com (8.7.3/8.6.12) id SAA13518; Fri, 8 Mar 1996 18:03:36 -0800 (PST) Date: Fri, 8 Mar 1996 18:03:36 -0800 (PST) From: Jordan Hubbard Message-Id: <199603090203.SAA13518@whisker.cdrom.com> To: current@freebsd.org, davidg@freebsd.org, dyson@freebsd.org Subject: One really easy way to panic your -current system Sender: owner-current@freebsd.org X-Loop: owner-current@FreeBSD.ORG Precedence: bulk Mount the FreeBSD 2.1 CDROM (or any other, probably, this is just for this example) and do a: dd if=/cdrom/dists (e.g. try to read from the directory) panic: vmwakeup: neg numoutput eip is 0xf01b65f3 Jordan From owner-freebsd-current Fri Mar 8 18:08:36 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA05781 for current-outgoing; Fri, 8 Mar 1996 18:08:36 -0800 (PST) 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 SAA05755 for ; Fri, 8 Mar 1996 18:08:04 -0800 (PST) Received: from rabbit by mubo.augusta.de with uucp (Smail3.1.28.1 #1) id m0tvE4M-00011wC; Sat, 9 Mar 96 03:07 MEZ Received: by rabbit.augusta.de (Smail3.1.29.1 #1) id m0tuLfw-0003RdC; Wed, 6 Mar 96 17:02 MET Message-Id: X-Mailer: exmh version 1.6.5 12/11/95 To: current@freebsd.org Subject: Re: Some questions about compiling -current In-reply-to: Your message of "Mon, 04 Mar 1996 07:55:57 +0200." <199603040555.HAA16715@grumble.grondar.za> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Wed, 06 Mar 1996 17:02:52 +0100 From: Andreas Kohout Sender: owner-current@freebsd.org X-Loop: owner-current@FreeBSD.ORG Precedence: bulk Hi, > Yes. Having your maildir world writable is a _huge_ security hole. Do you > have your own smail, or did you build it from ports? I believe the one in > /usr/ports/mail/smail is OK. change to that directory and type "make". > (put your smail source tarball in /usr/ports/distfiles first). my smail ins from ports, but I try again ... thanx > > 4. When should I compile -current? Every SNAP-Release or earlier? > Up to you. I do it about once a week if there have been enough changes. I did it a few weeks ago and my filse lost there time-stamps like this: -r-sr-xr-x 1 root bin 241664 19 Feb 1996 /usr/local/bin/smail* -- Gruß, Andy -------------------------------------------------------------------------- Der Mensch hat die Atombombe erfunden, eine Maus würde niemals eine Mausefalle bauen! shanee@rabbit.augusta.de Zirbelnußtown __________________________________________________________________________ From owner-freebsd-current Fri Mar 8 19:14:13 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id TAA10781 for current-outgoing; Fri, 8 Mar 1996 19:14:13 -0800 (PST) Received: from sigma.che.tku.edu.tw (bear@sigma.che.tku.edu.tw [163.13.130.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id TAA10765 for ; Fri, 8 Mar 1996 19:14:02 -0800 (PST) Received: (from bear@localhost) by sigma.che.tku.edu.tw (8.6.10/8.6.9) id LAA08278 for current@freebsd.org; Sat, 9 Mar 1996 11:11:55 +0800 From: bear@sigma.che.tku.edu.tw (Bear df Hung) Message-Id: <199603090311.LAA08278@sigma.che.tku.edu.tw> Subject: 0303-snap GENERIC: panic: free: multiple free To: current@freebsd.org Date: Sat, 9 Mar 1996 11:11:55 +0800 (CST) Organization: Dep. Chemical Eng., TamKang University, Taiwan, R.O.C. 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: owner-current@FreeBSD.ORG Precedence: bulk can anybody give me some hints to slove this problem :) OS: FreeBSD 0303-SNAP Kernel: GERNERIC MB: ASUS TP4XE + AHA2940 + ST1510N*2 + 128MB RAM THANKS! -- Linux is one of the best Operation Systems, and it is FREE ! mr682350060 Dep. of Chemical Engineering, TamKang University ¬x²Ð¶¯ Bear df Hung bear@sigma.che.tku.edu.tw From owner-freebsd-current Fri Mar 8 19:47:38 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id TAA13051 for current-outgoing; Fri, 8 Mar 1996 19:47:38 -0800 (PST) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id TAA13042 for ; Fri, 8 Mar 1996 19:47:34 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.6.11/8.6.9) id WAA00188; Fri, 8 Mar 1996 22:41:09 GMT From: "John S. Dyson" Message-Id: <199603082241.WAA00188@dyson.iquest.net> Subject: Re: 0303-snap GENERIC: panic: free: multiple free To: bear@sigma.che.tku.edu.tw (Bear df Hung) Date: Fri, 8 Mar 1996 22:41:08 +0000 () Cc: current@freebsd.org In-Reply-To: <199603090311.LAA08278@sigma.che.tku.edu.tw> from "Bear df Hung" at Mar 9, 96 11:11:55 am X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: owner-current@FreeBSD.ORG Precedence: bulk > > > can anybody give me some hints to slove this problem :) > There is general evil in the VM code right now. Back off to a Mar 1 kernel or so. I have just one more bug to fix before commiting. SORRY :-(. John From owner-freebsd-current Fri Mar 8 21:46:50 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA22484 for current-outgoing; Fri, 8 Mar 1996 21:46:50 -0800 (PST) Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id VAA22456 Fri, 8 Mar 1996 21:46:44 -0800 (PST) Message-Id: <199603090546.VAA22456@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: Host localhost.cdrom.com [127.0.0.1] didn't use HELO protocol To: Terry Lambert cc: stable@FreeBSD.org, current@FreeBSD.org Subject: Re: The continueing 2842/eisaconf argument In-reply-to: Your message of "Fri, 08 Mar 1996 11:13:55 MST." <199603081813.LAA17284@phaeton.artisoft.com> Date: Fri, 08 Mar 1996 21:46:44 -0800 From: "Justin T. Gibbs" Sender: owner-current@FreeBSD.org X-Loop: owner-current@FreeBSD.ORG Precedence: bulk >I have to say that my subtext on this whole thing has always been >the need for an orthoganal configuration management API. I would >not have said anything, if I hadn't thought that it was going to >hell. > >I wish I had known about the 2842 VLB being probed by the EISA probe >code earlier, but we can't all know everything. This discussion was >not intended to blow up out of proportion as it has done. I maintain that the way that the 2842 is currently probed in no way gepordizes the ability to create a configuration management API. Much of what you say below is simply not true... >> What you will, and have seen me argue against is the need to construct >> additional mechanisms into how we probe devices to cover a single >> VLB card that was designed to be probed like an EISA device. Having >> more than one way to trigger a scan of the EISA slot address space >> for devices is confusing at best, and leads to bugs at worst. The >> probe for EISA devices has proven non-invasive on the 100s of machines >> that currently have eisa0 in their config files and the same scan would >> be required anyway to support the 2842, so there is no technical >> reason to provide an alternate method for triggering the search. > >Let's stop here for a second. > >I don't think the major work of the probe for the VLB card is the >scan of the EISA slot address space. It's getting the configuration >information about the card, and that doesn't take EISA configuration >data to do it. EISA configuration data (assuming you mean the stuff accessible through BIOS calls) is not used by any driver in FreeBSD. Even if it was accessible to FreeBSD (and there's no reason it can't be with VM86() or having the boot blocks save off the data) it would have to be interpreted by each individual driver in order to be of any use. So, although eisaconf may some day provide a mechanism for accessing this data, it certainly won't attempt processing it on its own. Every eisa card we support provides some other way for either read/write or write only access to the data the driver needs. >So I don't think the 2842 should be being found by triggering a scan >of the EISA slot address space. > >To put this another way, I shouldn't have to have an eisa0 in my config >file to use a VLB card. It's confusing -- as confusing as having the >ability to option out the non-optional npx0 device. > >I think if we back up and agree that the probe [of configuration >parameters associated with the card] should be seperate from the EISA >slot scan, then we will have made progress. It has to be up to each driver to request and then interpret this information if it makes sense for them to do so. Many cards could care less about what's up in configuration space. The 3c579 is one, the 2842 is another. If we have to support EISA devices that don't want configuration data we can also support VLB devices that doesn't use configuration space information with no additional complexity. Its really a question of capability and use. Just because the Win32 API provides 5 volumes of "capabilities" doesn't mean I use them all. >I don't *want* "an alternate method to trigger the search", I want to >not do the slot search on non-EISA machines. > >Yes, this means that there is a need for some additional stub code >to actually find the card, but it doesn't change how the configuration >information is extracted from the card. The 2742 and the 2842 will continue to get most of the information about the card in the exact same way regardless of the availibility of configuration space data. You're also not talking about stub code, but an additional probe that iterates through the slot address space since the 2842 can't reference the eisa code in your model since you don't want to have to have eisa0 in your config file. This is just like going back to the days when we didn't have an eisaconf and every eisa (or eisa like) driver duplicated this exact scan of the address space. Bug fixes to one probe didn't propogate to the others. I don't see forcing people to include eisa0 in their config files as a problem since config will eventually die a horrible death, and the aic7xxx lkm will export its lkm dependancy graph so that if you don't have the eisaconf lkm in your system for some strange reason, it gives you a nice warning message. If you can talk about eisa configuration space, I think its fair for me to say that config, in its present state, will go away. >> Furthermore, eisaconf must already properly report other ISA cards that >> can be configured in "eisa compatibility mode" as living on the ISA >> bus (the 3c509 for example) so it is already suited to the task of handing >> the 2842 with absolutly no additional code or complexity: >> >> ahc1: at 0x7c00-0x7cff irq 12 on isa > >All things plugged into EISA slots are supposed to be configured, >period. So it's a non-sequitur to talk about "can be configured" here. > >Everything that goes into an EISA slot is capable of having an EISA >configuration file (I have a utility to generate these for ISA cards >that came with my EISA machine; you must enter the IRQ, DRQ, I/O, and >memory address ranges as part of the generation process). And if it >is in an EISA slot, it *should* have an EISA config. Having an EISA config file doesn't mean that your ISA device responds to accesses at 0xzc80 and provides an EISA ID. THe 3c509 does when its installed in an EISA system and properly configured. The 1542 does not. Having the config file is simply a way of aiding the ECU in telling you where conflicts are or restricing your configuration settings. Once the ECU session is over, there's nothing their to tell FreeBSD about these ISA devices. >The dup of the EISA process into the PnP space is an implementation >detail on the implementation of ISA PnP. As part of the configuration >management, you have to probe the non-relocatable devices for which >you have drivers to determine the existance of "immobile" cards; then >for all mobile cards, you relocate them. > >I think the 2842 is in the same category as the WD8013: it's a card >that is software relocatable, but which is not PnP and thus should >probably not be relocated. It's one of the base line devices that >have a single graph vector for location. > >For a real EISA device, it's acceptable to relocate the thing, since >EISA devices are configured per slot and each OS (or BIOS POST for >DOS for the INT 13 hook). That means any OS that knows about dealing >with EISA the correct way will find the relocated card. > >This isn't true of VLB cards, especially VLB cards for boot devices. You can switch the dip switches on your 2842 all day, and FreeBSD will still find it. You can also move your 2742 from slot to slot all day and FreeBSD will still find it. Relocating the card doesn't prevent you from booting from it in either case so long as the card's bios is enabled. Booting is a BIOS issue. I can make a 2742 not bootable by disabling its BIOS too. >I think that the 2842 needs to be probed later than the typical >EISA, PCI, PCMCIA, and PnP ISA devices, like other non-relocatable >devices. It think it needs to have an invariant configuration graph >vector, *unlike* things which are found by the EISA probe. The 2742 is just as non-relocatable as the 2842. The 2742 locks out is irq register after the first time its written to (by the EISA configuration just after POST). Most EISA cards can't relocate their I/O range, but the Buslogic cards can relocate relocate their registers through a range of ISA compatibily areas. The point is that the way you deal with registering relocatability has to be generic so you can deal with devices that vary in their degrees of flexibility regardless of their bus type. >I think it is incorrect to probe the thing as an EISA device (are >there any motherboards that have EISA and VLB at the same time? >That would be a good counter-argument...). Many, many EISA 486 systems have VL and EISA slots. I own one of these systems. >> >At the very least, we should admit that looking for EISA stuff on a >> >non-EISA machine is a kludge. >> >> Complain to Adaptec. > >They didn't write the probe code. > >I have no problem with them assigning slot space for a VLB card (it's >an artifact of the bus interface ASIC that they used anyway). What >I do have a problem with is the implied probe order not treating it >as a non-relocatable ISA device because it had been found in EISA >space when we finally get to the point where we can do a graph >reduction topology sort to relocate the relocatable cards. Not all EISA devices are relocatable in the same ways. I can find plenty of EISA devices that have the same relocation deficiencies as the 2842. This is not a valid argument. >EISA cards are relocatable. Relocating ISA or VLB cards that aren't >succeptable to ISA PnP drivers means that the cards could disappear >from DOS or another OS with a hard-coded config.sys line for ATAPI >for a CDROM on that controller, or whatever. Not all EISA cards are relocatable after their first initialization. We have to deal with these anyway. >> Probing the 2842 as an EISA device does not preclude a configuration >> manager aproach to solving our current device probe mess. > >Wrong. It identifies it as an EISA device, and EISA devices are >fair game to be relocated by a PnP configuration manager. Look >at the Windows95 PnP problems that FreeBSD has had with ethernet >cards. Look at the IRQ 12 collisions that occur for PS/2 mice, >still, on Windows95 hardware with PnP enabled. No, it identifies it as an ISA device. And, some non PnP ISA cards just like some EISA cards (EISA is not PnP BTW), allow you to dynamically change the IRQ. So, what's your point? If we had a configuration manager we woudn't allow flexible devices to conflict with non-flexible ones which has absolutly nothing to do with the 2842 being probed through eisaconf. The 2842, just like all the other devices using eisaconf will have to register just what it is that they can have changed and what they cannot (and the range they can be configured to. Not all cards support all IRQs for example). >> Anyone who currently has eisa0 in there kernel is proving the point that >> the probe of the eisa slot address space is non-invasive. The probe >> can't tell if you have a VLB motherboard in order to prevent the probe, >> and it can't know if you have a 2842 either without looking, so it always >> does the scan. > >It can tell that you don't have an EISA motherboard, which is the same >thing, by negative induction. Assuming EISA and VLB are mutiually exclusive which they are not. >The issue is not the invasiveness of the EISA probe; its with the >classification of the card as an EISA card. And with the requirement >that I have the EISA code configured into a kernel for a non-EISA >system. The 3c509 in eisa configuration mode must be probed through eisaconf to be found. It is reported as an ISA device. The 2842 is also found through eisaconf and is reported as an ISA device. Both show up as ISA device in lsdev too since their kdc parents are kdc_isa. Where does the 2842 get classified as an EISA device? >> >The point is you *should* be *able* to call the same functions for ISA, >> >and for PnP, which uses non-invasive probing (unless you have an old >> >IBM manufactured parallel port card), you *can*. >> >> The match routines and forcing a scan of the eisa address space makes >> no sense in a generic ISA probe (deals with non PnP hardware) configuration >> sub-manager. > >I agree. Don't use the slot scan to locate the card; it isn't a >substitute for the majority of the work done by the probe code anyway. >Move the scan identification into an EISA-specific stub, and create >an ISA specific stub for the non-relocatable VLB card. And I either make it always be in your kernel, or make it part of "eisa0", or I duplicate it. What a waste. >> >This is a *card* problem, not a generic problem resolved for anthing >> >other than the Adaptec card by calling the EISA code. >> >> Exactly! The Adaptec card behaves like an eisa device so you either >> have it use the EISA probe mechanism or you have it be an ISA probe >> that does the scan itself since it would be a layering violation to >> have it call into the EISA probe to force it to scan the slot address >> space even if it wasn't an EISA machine, call the eisa match routine >> to see if a proper ID was found, and then turn around and register itself >> with the ISA device manager. > >I think you are stuck on using the fact that it exports EISA slot >data to trigger the probe (the manority of which is not dependent on >the fact that it's "EISA"). I think this is wrong, for the ordering >reasons stated above. The ordering reasons don't hold water. Nothing is gained by postponing the probe of the 2842. Its just as "relocatable" as other EISA devices and its probe is non-invasive (and already performed by the eisaconf code). >> >> What features does VLB have that make it of any use to differentiate >> >> between VLB and ISA probes? >> > >> >A) Default settings for driver configurable bus-on times, since VLB >> > steals DRAM refresh cycles. VLB on time needs to be agregated >> > and adjusted *down* where necessary. >> >> This is a device driver issue, not a VLB bus issue, since only the >> driver knows if it is talking to a VLB card. > >The VLB bus is not bridged. The agregate bus-on time for N VLB cards >going in sequence is the issue for deciding to "tune" the VLB cards >down. This as well as most tuning parameters should be left up to the user. I don't see FreeBSD trying to modify your DRAM refresh rates. Its counter intuitive for the user to go in and set the bus on time for their adapter using the vendor supplied tools for this purpose (EISA config utility for the 2742, SCSI-Select for the 2842) and not have the OS honor them. >> >So the DMA argument doesn't support the EISA/VLB probe argument. >> >> It certainly doesn't support that there should be a separate VLB >> probe. > 16MB dma problems transend busses. > >So call it a variant ISA probe. So call it writing a probe. Or >abstract the "relocatable" attribute of the 2842 by virtue of >detecting it's not really EISA (using the same code that would be >required for an ISA probe stub), and increase the complexity of the >EISA code by making it do a variant insertion in the configuration >topology graph to tag it as non-relocatable (note: this last approach >strikes me as singularly bogus, and is why I am against using the >EISA code to detect the non-EISA card). Your making up problems Terry. Probe order is determined by bus type. Resource allocation is determined by the relative flexibility of devices regardless of bus type. >> For all of the EISA cards that I've added eisaconf probes for, the IRQ, >> DMA and most other interresting information is availible in registers >> initialized by the the EISA BIOS. The 2842 has the same registers >> availible that the 2742 so it is not an issue. Think of the 2842 >> as an EISA card that doesn't have an overlay file and so doesn't store >> anything in configuration space. We can't even read configuration space >> yet, but the eisaconf code will have to deal with devices that have >> nothing set up there anyway which is simple since it will simply leave >> it up to the device driver to interpret the data once the eisaconf code >> can provide a means to access it. > >Precisely! > >Once you can manipulate the configuration space, EISA cards are as >relocatable as ISA PnP cards! But this VLB ccard, which you lie and >say is an EISA card by virtue of whose probe comes true, can *not* >be relocated! Bullshit! ISA PnP cards can relocate their I/O area most EISA cards can't. Some EISA cards do not allow relocation of anything after the EISA BIOS is done. Furthermore, the data up in configuration space doesn't control the settings of the card. You have to write to the cards own registers to do that which FreeBSD already has the capability to do without having access to configuration space. >You have to indirect all EISA configuration space code through the >driver, and then call common routines for *all other drivers*, and >for this one fake an immobile configuration space! Bletch! Talk >about unnecessary complexity! This just isn't true. All devices can call the same functions to register their resources, but it will only be at attach time that they will know if they have to change their settings and to what. >> What is the gain in doing this? > >EISA cards become relocatable within the conflict space. The 2842 doesn't prevent this. >Do you not agree that EISA cards should be relocatable by a resonable >configuration manager that knows EISA? Sure. Eisaconf is already poised to do this and the 2842 will fit right in there. >Or that the 2842, a VLB card, should *not* be relocatable because >there is no standard mechanism for handling an EISA relocation of >a non-EISA card? Hey, you can change the 2842's IRQ so it will tell that to the configuration manager. The 2742 cannot change its IRQ, and it will tell the configuration manager that. If you can handle one case, you can handle the other. >Or that the 2842 would have to have a fake configuration space, which >would greatly complicate the configuration space manipulation for >*real* EISA cards? eisaconf will never manipulate configuration space directly, ever. Its not needed to support dynamic configuration of EISA devices. The 2742 just like the 2842 will not be making any calls into eisaconf to retrieve information from configuration space, so it doesn't matter if there is or is not any configuration space data for the 2742 or the 2842. Other drivers may have different requirements. > Regards, > Terry Lambert > terry@lambert.org >--- >Any opinions in this posting are my own and not those of my present >or previous employers. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Fri Mar 8 22:31:11 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA24886 for current-outgoing; Fri, 8 Mar 1996 22:31:11 -0800 (PST) Received: from w2xo.pgh.pa.us (w2xo.pgh.pa.us [206.210.70.5]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id WAA24881 for ; Fri, 8 Mar 1996 22:31:06 -0800 (PST) Received: (from durham@localhost) by w2xo.pgh.pa.us (8.6.11/8.6.9) id BAA04346; Sat, 9 Mar 1996 01:21:35 -0500 Date: Sat, 9 Mar 1996 01:21:30 -0500 (EST) From: Jim Durham To: current@freebsd.org Subject: pty problems Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: owner-current@FreeBSD.ORG Precedence: bulk I had a need to use slattach with a pty to connect an application that understands SLIP to the kernel networking. It appears that the pty driver causes an error if ioctl's are sent to it that are meaningless to a pty, but needed for a serial port. Slattach will bomb with these errors. Is there some reason that the pty driver must return an error when it receives an ioctl that it cannot use? I tried to modify the source to just ignore meaningless ioctls, and managed to crash the kernel! Who is the person that maintains the pty driver? -regards -Jim Durham From owner-freebsd-current Fri Mar 8 23:18:18 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA29191 for current-outgoing; Fri, 8 Mar 1996 23:18:18 -0800 (PST) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA29186 for ; Fri, 8 Mar 1996 23:18:16 -0800 (PST) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id XAA09638; Fri, 8 Mar 1996 23:18:02 -0800 From: "Rodney W. Grimes" Message-Id: <199603090718.XAA09638@GndRsh.aac.dev.com> Subject: Re: NCR disk controller, hp disk To: james@miller.cs.uwm.edu (Jim Lowe) Date: Fri, 8 Mar 1996 23:18:02 -0800 (PST) Cc: current@FreeBSD.org In-Reply-To: <199603082239.QAA13075@miller.cs.uwm.edu> from "Jim Lowe" at Mar 8, 96 04:39:14 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: owner-current@FreeBSD.ORG Precedence: bulk > > > I have an NCR 825 PCI disk controller. I just attached a second disk > to the controller and am trying to access it. The second disk works > just fine under dos, but not freebsd-current. I am getting the following > errors: > > sd1(ncr0:1:0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted > , retries:4 > sd1(ncr0:1:0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted > , retries:3 > sd1(ncr0:1:0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted > , retries:2 > sd1(ncr0:1:0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted > , retries:1 > sd1(ncr0:1:0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted > , FAILURE > sd1: error reading primary partition table reading fsbn 0 (sd1 bn 0; cn 0 tn 0 s > n 0) > > Any clues as to what to try/do next? The boot up information follows. > I am not sure why I am getting the probe0(ncr0:9:0) errors either. > Termination? It seems that the HP C37xx series of SCSI disks are being tickled by the NCR scsi code in FreeBSD. I can duplicate your problem here using the model C3725 and either an NCR 53C810 or NCR 53C825. I suggest you switch to an aha2940, but you will probably have to backup/restore the entire system to do this due to geometry translation differences. We really need a SCSI expect to go rewrite the firmware for the NCR cards, what we have today has so many incompatibility problems it is getting hard to spec systes using it :-(. > Thanks for any help, Sorry, not much real help :-(. Stephan Esser may have a list of things you can turn off in the NCR code that gets it working... > -Jim -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Fri Mar 8 23:51:48 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA00486 for current-outgoing; Fri, 8 Mar 1996 23:51:48 -0800 (PST) Received: from omega.physik.fu-berlin.de (omega.physik.fu-berlin.de [130.133.3.51]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id XAA00475 for ; Fri, 8 Mar 1996 23:51:45 -0800 (PST) Received: from mordillo (lislip.physik.fu-berlin.de [130.133.3.126]) by omega.physik.fu-berlin.de (8.7.1/8.7.1) with ESMTP id IAA26195 for ; Sat, 9 Mar 1996 08:51:42 +0100 (MET) Received: (from news@localhost) by mordillo (8.6.12/8.6.12) id UAA09949; Fri, 8 Mar 1996 20:50:31 +0100 To: current@FreeBSD.org Path: graichen From: graichen@omega.physik.fu-berlin.de (Thomas Graichen) Newsgroups: local.freebsd-current Subject: Re: changes to /etc/csh.* Date: 8 Mar 1996 19:50:30 GMT Organization: his FreeBSD box :-) Lines: 25 Distribution: local Message-ID: <4hq326$1s9@mordillo.physik.fu-berlin.de> References: NNTP-Posting-Host: localhost.physik.fu-berlin.de X-Newsreader: TIN [version 1.2 PL2] Sender: owner-current@FreeBSD.org X-Loop: owner-current@FreeBSD.ORG Precedence: bulk invalid opcode (coredump@nervosa.com) wrote: : I'm submitting my versions of /etc/csh.{login,logout,cshrc} as a : potential new base. I suggest moving away from .cshrc, .login, .logout, : and implementing it into the system /etc/csh.* files. This way the user : can specify truly local options in .cshrc, .login, .etc instead of every : user having the same .cshrc and .login in their home dirs. how about also adding something like: if ( -x /usr/sbin/ispcvt ) then if { /usr/sbin/ispcvt } then setenv TERM vt220 endif endif this way you'll automatically get the right TERM if you are using syscons _or_ pcvt - just an idea - for me it works very nice t -- thomas graichen graichen@mail.physik.fu-berlin.de graichen@FreeBSD.org perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away antoine de saint-exupery From owner-freebsd-current Sat Mar 9 00:37:01 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA02571 for current-outgoing; Sat, 9 Mar 1996 00:37:01 -0800 (PST) Received: from maui.com (root@waena.mrtc.maui.com [199.4.33.17]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id AAA02565 Sat, 9 Mar 1996 00:36:58 -0800 (PST) Received: from caliban.dihelix.com (caliban.dihelix.com [199.4.33.251]) by maui.com (8.6.10/8.6.6) with ESMTP id WAA14054; Fri, 8 Mar 1996 22:36:49 -1000 Received: (from root@localhost) by caliban.dihelix.com (8.7.4/8.6.9) id WAA12485; Fri, 8 Mar 1996 22:36:53 -1000 (HST) Message-Id: <199603090836.WAA12485@caliban.dihelix.com> Subject: Re: One really easy way to panic your -current system To: jkh@whisker.cdrom.com (Jordan Hubbard) Date: Fri, 8 Mar 1996 22:36:52 -1000 (HST) From: "David Langford" Cc: current@FreeBSD.org, davidg@FreeBSD.org, dyson@FreeBSD.org In-Reply-To: <199603090203.SAA13518@whisker.cdrom.com> from "Jordan Hubbard" at Mar 8, 96 06:03:36 pm From: "David Langford" X-blank-line: This space intentionaly left blank. X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: owner-current@FreeBSD.ORG Precedence: bulk Jordan Hubbard > > >Mount the FreeBSD 2.1 CDROM (or any other, probably, this is just >for this example) and do a: > >dd if=/cdrom/dists > >(e.g. try to read from the directory) > >panic: vmwakeup: neg numoutput >eip is 0xf01b65f3 > > Jordan On a similar note shouldnt dd if=TEXTFILE of=/dev/st0 work? With my setup the machine hangs.... aic0 at 0x340-0x35f irq 9 on isa (aic0:2:0): "ARCHIVE Python 25588-XXX 2.96" type 1 removable SCSI 2 st0(aic0:2:0): Sequential-Access density code 0x13, drive empty From owner-freebsd-current Sat Mar 9 00:47:56 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA02799 for current-outgoing; Sat, 9 Mar 1996 00:47:56 -0800 (PST) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id AAA02778 for ; Sat, 9 Mar 1996 00:45:27 -0800 (PST) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) id JAA24850; Sat, 9 Mar 1996 09:30:24 +0100 (MET) Received: from knobel.gun.de (localhost [127.0.0.1]) by knobel.gun.de (8.7.4/8.7.3) with SMTP id JAA00669; Sat, 9 Mar 1996 09:26:41 +0100 (MET) Date: Sat, 9 Mar 1996 09:26:41 +0100 (MET) From: Andreas Klemm To: KATO Takenori cc: current@freebsd.org Subject: Re: panic after exiting X In-Reply-To: <199603061721.CAA00254@marble.eps.nagoya-u.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: owner-current@FreeBSD.ORG Precedence: bulk On Thu, 7 Mar 1996, KATO Takenori wrote: > My kernel panics after exiting X. (Someone reported same problem, but > I lost the log from mailbox.) This happened to me, too, about 1 week ago, when leaving X11 with CTRL-ALT-BACKSPACE After some days the situation went even worse, the system paniced when trying to mount MFS. Since some days the errors are away. -- 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 <<< "Ich bleibe bei der Aussage und trotze den Flames. :-)" Ulli Horlacher 02/96 From owner-freebsd-current Sat Mar 9 00:52:02 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA03032 for current-outgoing; Sat, 9 Mar 1996 00:52:02 -0800 (PST) Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id AAA02918 Sat, 9 Mar 1996 00:49:49 -0800 (PST) Received: by sequent.kiae.su id AA29070 (5.65.kiae-2 ); Sat, 9 Mar 1996 11:45:00 +0300 Received: by sequent.KIAE.su (UUMAIL/2.0); Sat, 9 Mar 96 11:44:59 +0300 Received: (from ache@localhost) by d133.z194-58-229.relcom.ru (8.7.4/8.7.3) id LAA02572; Sat, 9 Mar 1996 11:44:23 +0300 (MSK) Message-Id: <199603090844.LAA02572@d133.z194-58-229.relcom.ru> Subject: Pipes hits again, the same situation but different thing To: current@freebsd.org (FreeBSD-current) Date: Sat, 9 Mar 1996 11:44:22 +0300 (MSK) Cc: dyson@freebsd.org 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+ PL11 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: owner-current@FreeBSD.ORG Precedence: bulk Situation is almost same recently fixed: hang in ssh But now it occurse very rare and I can't reproduce it by wish. NOTE: file is small now < 2K. I am shure that network is alive because I ssh to freebsd.org on the next screen. Here is catched hang situation. 112 2530 167 0 -6 0 176 560 piperd I+ v2 0:00.06 scp -v /tmp/000 freebsd.org 0 2531 2530 0 2 0 640 1132 select I+ v2 0:00.65 /usr/local/bin/ssh -x -a -oFallBackToRsh -v freebsd.org scp -v -t . -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-current Sat Mar 9 01:41:25 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA05870 for current-outgoing; Sat, 9 Mar 1996 01:41:25 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id BAA05865 for ; Sat, 9 Mar 1996 01:41:21 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id UAA01522; Sat, 9 Mar 1996 20:38:48 +1100 Date: Sat, 9 Mar 1996 20:38:48 +1100 From: Bruce Evans Message-Id: <199603090938.UAA01522@godzilla.zeta.org.au> To: pst@shockwave.com, wosch@cs.tu-berlin.de Subject: Re: _PATH_* Cc: current@FreeBSD.org Sender: owner-current@FreeBSD.org X-Loop: owner-current@FreeBSD.ORG Precedence: bulk >I think these make perfect sense. You could conceivably have shared versions >of a /bin program in /usr/bin, which is why this was set this way in the first >place. The second is for stupid compatibility, the final colon is curdir, >as you already knew. I don't like it, but I don't want to break it either. > /* All standard utilities path. */ > #define _PATH_STDPATH \ > "/usr/bin:/bin:/usr/sbin:/sbin:" Grepping in /usr/src shows that _PATH_DEFPATH is only used for the USER_CS_PATH case of sysctl(3). USER_CS_PATH is only used for user.cs_path in sysctl(8), for the obsolete confstr(3) and for whereis(1). user.cs_path doesn't seem to be used. I think the final colon shouldn't be there. Bruce From owner-freebsd-current Sat Mar 9 04:48:02 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA18126 for current-outgoing; Sat, 9 Mar 1996 04:48:02 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id EAA18090 for ; Sat, 9 Mar 1996 04:48:00 -0800 (PST) Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by who.cdrom.com (8.6.12/8.6.11) with SMTP id EAA09802 for ; Sat, 9 Mar 1996 04:47:47 -0800 Received: by sequent.kiae.su id AA14619 (5.65.kiae-2 for current@freebsd.org); Sat, 9 Mar 1996 15:44:06 +0300 Received: by sequent.KIAE.su (UUMAIL/2.0); Sat, 9 Mar 96 15:44:05 +0300 Received: (from ache@localhost) by d133.z194-58-229.relcom.ru (8.7.4/8.7.3) id PAA00217 for current@freebsd.org; Sat, 9 Mar 1996 15:43:02 +0300 (MSK) Message-Id: <199603091243.PAA00217@d133.z194-58-229.relcom.ru> Subject: sysctl -a dumps core now To: current@freebsd.org (FreeBSD-current) Date: Sat, 9 Mar 1996 15:43:01 +0300 (MSK) 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+ PL11 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: owner-current@FreeBSD.ORG Precedence: bulk Script started on Sat Mar 9 15:41:43 1996 d133:/tmp 61_> sysctl -a kern.ostype: FreeBSD kern.osrelease: 2.2-CURRENT kern.osrevision: 199306 kern.version: FreeBSD 2.2-CURRENT #2: Sat Mar 9 12:45:58 MSK 1996 ache@d133.z194-58-229.relcom.ru:/usr/src/sys/compile/ASTRAL kern.maxvnodes: 1161 kern.maxproc: 180 kern.maxfiles: 360 kern.argmax: 65536 kern.securelevel: -1 kern.hostname: d133.z194-58-229.relcom.ru kern.hostid: 0 kern.clockrate: { hz = 100, tick = 10000, profhz = 1024, stathz = 128 } kern.posix1version: 198808 kern.ngroups: 16 kern.job_control: 1 kern.saved_ids: 1 kern.boottime: { sec = 826375187, usec = 110000 } Bus error Script done on Sat Mar 9 15:41:50 1996 -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-current Sat Mar 9 04:50:32 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA18339 for current-outgoing; Sat, 9 Mar 1996 04:50:32 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id EAA18331 for ; Sat, 9 Mar 1996 04:50:29 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id NAA20605 for ; Sat, 9 Mar 1996 13:50:18 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id NAA26864 for freebsd-current@FreeBSD.org; Sat, 9 Mar 1996 13:50:17 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id NAA26195 for freebsd-current@FreeBSD.org; Sat, 9 Mar 1996 13:31:35 +0100 (MET) From: J Wunsch Message-Id: <199603091231.NAA26195@uriah.heep.sax.de> Subject: Re: 2842 and the disappearing file-system :-( To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sat, 9 Mar 1996 13:31:35 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199603080316.TAA02977@freefall.freebsd.org> from "Justin T. Gibbs" at Mar 7, 96 07:16:52 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: owner-current@FreeBSD.ORG Precedence: bulk As Justin T. Gibbs wrote: > The 2842VLB SCSI card, a non PnP device, sticks its identifier in > the EISA slot address space for identification. FreeBSD currently > always looks for these IDs in the EISA slot address space even if > the EISA motherboard ID at 0x0C80 is not found so that it can detect > these cards. I generally agree with your argumentation. One very minor addendum: while the LINT file mentions that the 284X probes as an EISA card, there should perhaps be a warning in the GENERIC config file, telling: ``Don't remove the eisa0 controller if you're using an Adaptec 284X VLB controller.'' -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sat Mar 9 04:52:50 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA18594 for current-outgoing; Sat, 9 Mar 1996 04:52:50 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id EAA18588 for ; Sat, 9 Mar 1996 04:52:46 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id NAA20609; Sat, 9 Mar 1996 13:50:19 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id NAA26865; Sat, 9 Mar 1996 13:50:19 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id NAA26219; Sat, 9 Mar 1996 13:34:59 +0100 (MET) From: J Wunsch Message-Id: <199603091234.NAA26219@uriah.heep.sax.de> Subject: Re: 3/3 SNAP panic To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sat, 9 Mar 1996 13:34:59 +0100 (MET) Cc: alk@Think.COM (Tony Kimball) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199603080748.BAA00323@compound> from "Tony Kimball" at Mar 8, 96 01:48:21 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: owner-current@FreeBSD.ORG Precedence: bulk As Tony Kimball wrote: > > > FYI, and to whom it may concern: > > Booting the 960303 SNAP after install, I received a > fatal trap 1: privelidged insn fault in kernel mode > after the screenblank modload message. Privileged instruction faults should not happen in kernel mode. :-/ (The kernel is supposed to be privileged enough for everything.) What CPU do you have? -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sat Mar 9 06:21:25 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA26383 for current-outgoing; Sat, 9 Mar 1996 06:21:25 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id GAA26374 for ; Sat, 9 Mar 1996 06:21:20 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id PAA22242 for ; Sat, 9 Mar 1996 15:21:16 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id PAA27352 for freebsd-current@FreeBSD.org; Sat, 9 Mar 1996 15:21:15 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id OAA00930 for freebsd-current@FreeBSD.org; Sat, 9 Mar 1996 14:45:34 +0100 (MET) From: J Wunsch Message-Id: <199603091345.OAA00930@uriah.heep.sax.de> Subject: Re: changes to /etc/csh.* To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sat, 9 Mar 1996 14:45:34 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <4hq326$1s9@mordillo.physik.fu-berlin.de> from "Thomas Graichen" at Mar 8, 96 07:50:30 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: owner-current@FreeBSD.ORG Precedence: bulk As Thomas Graichen wrote: > how about also adding something like: > > if ( -x /usr/sbin/ispcvt ) then > if { /usr/sbin/ispcvt } then > setenv TERM vt220 > endif > endif > this way you'll automatically get the right TERM if you are using > syscons _or_ pcvt - just an idea - for me it works very nice This should go into /etc/ttys instead. (Though it's not automagic there.) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sat Mar 9 06:21:30 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA26408 for current-outgoing; Sat, 9 Mar 1996 06:21:30 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id GAA26398 for ; Sat, 9 Mar 1996 06:21:27 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id PAA22259; Sat, 9 Mar 1996 15:21:25 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id PAA27357; Sat, 9 Mar 1996 15:21:25 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id OAA01080; Sat, 9 Mar 1996 14:59:59 +0100 (MET) From: J Wunsch Message-Id: <199603091359.OAA01080@uriah.heep.sax.de> Subject: Re: More on the ffs_alloc: dup thingummy stuff To: sysseh@devetir.qld.gov.au (Stephen Hocking) Date: Sat, 9 Mar 1996 14:59:58 +0100 (MET) Cc: current@FreeBSD.ORG Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199603080723.HAA01712@netfl15a.devetir.qld.gov.au> from "Stephen Hocking" at Mar 8, 96 05:23:47 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: owner-current@FreeBSD.ORG Precedence: bulk As Stephen Hocking wrote: > I've backed out the most recent change to vm_map.c and still se the error > mentioned above. Can someone send me version 1.62 of swap_pager.c? [sent] -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sat Mar 9 07:37:45 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA03453 for current-outgoing; Sat, 9 Mar 1996 07:37:45 -0800 (PST) Received: from grumble.grondar.za (grumble.grondar.za [196.7.18.130]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id HAA02702 for ; Sat, 9 Mar 1996 07:32:33 -0800 (PST) Received: from grumble.grondar.za (mark@localhost [127.0.0.1]) by grumble.grondar.za (8.7.4/8.7.3) with ESMTP id RAA17462 for ; Sat, 9 Mar 1996 17:05:49 +0200 (SAT) Message-Id: <199603091505.RAA17462@grumble.grondar.za> To: current@freebsd.org Subject: HEADS UP! Please check... Date: Sat, 09 Mar 1996 17:05:48 +0200 From: Mark Murray Sender: owner-current@freebsd.org X-Loop: owner-current@FreeBSD.ORG Precedence: bulk Hi folks I have just committed a change to su(1) to better integrate Kerberos into it. BUT, this missive does not apply only to those of you with Kerberos/eBones. The result of this change is that a user will not be prompted for a password again if they get the Kerberos password wrong. As su(1) is abuse-able, please test this, hammer it, do what you can to try to break through, and if you find any bugs or problems please let me know. Those of you without Kerberos, please also test this to make sure I did not break anything. There was a bit of code reorganisation in there that affects you too. Thanks! 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 Sat Mar 9 09:04:26 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA10055 for current-outgoing; Sat, 9 Mar 1996 09:04:26 -0800 (PST) Received: from haywire.DIALix.COM (root@haywire.DIALix.COM [192.203.228.65]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id JAA10050 for ; Sat, 9 Mar 1996 09:04:21 -0800 (PST) Received: (from news@localhost) by haywire.DIALix.COM (8.7.4/8.6.12) id BAA22619 for freebsd-current@freebsd.org; Sun, 10 Mar 1996 01:06:37 +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: Sat, 9 Mar 1996 12:52:59 GMT From: mark@seeware.DIALix.oz.au (Mark Hannon) Message-ID: Organization: Private FreeBSD site Subject: panic: unwire: page not in pmap Sender: owner-current@freebsd.org X-Loop: owner-current@FreeBSD.ORG Precedence: bulk Hi! I tried to install the 0303 SNAP tonight. No luck, upon booting I get the error message shown above. Anybody got any ideas? System: AMD4/120, PCI, 3 IDE HD, NE2000 clone, Tseng ET4000/W32. /mark -- +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ | Mark Hannon,| FreeBSD - Free Unix for your PC| mark@seeware.DIALix.oz.au| | Melbourne, | PGP key available by fingering | epamha@epa.ericsson.se | | Australia | seeware@melbourne.DIALix.oz.au | | +-=-=-=-=-=-=-+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ From owner-freebsd-current Sat Mar 9 09:28:47 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA11269 for current-outgoing; Sat, 9 Mar 1996 09:28:47 -0800 (PST) Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA11264 Sat, 9 Mar 1996 09:28:45 -0800 (PST) Message-Id: <199603091728.JAA11264@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: Host localhost.cdrom.com [127.0.0.1] didn't use HELO protocol To: "David Langford" , "David Langford" cc: jkh@whisker.cdrom.com (Jordan Hubbard), current@FreeBSD.org, davidg@FreeBSD.org, dyson@FreeBSD.org Subject: Re: One really easy way to panic your -current system In-reply-to: Your message of "Fri, 08 Mar 1996 22:36:52 -1000." <199603090836.WAA12485@caliban.dihelix.com> Date: Sat, 09 Mar 1996 09:28:45 -0800 From: "Justin T. Gibbs" Sender: owner-current@FreeBSD.org X-Loop: owner-current@FreeBSD.ORG Precedence: bulk >Jordan Hubbard >> >> >>Mount the FreeBSD 2.1 CDROM (or any other, probably, this is just >>for this example) and do a: >> >>dd if=/cdrom/dists >> >>(e.g. try to read from the directory) >> >>panic: vmwakeup: neg numoutput >>eip is 0xf01b65f3 >> >> Jordan > >On a similar note shouldnt dd if=TEXTFILE of=/dev/st0 work? >With my setup the machine hangs.... > >aic0 at 0x340-0x35f irq 9 on isa >(aic0:2:0): "ARCHIVE Python 25588-XXX 2.96" type 1 removable SCSI 2 >st0(aic0:2:0): Sequential-Access density code 0x13, drive empty I would suggest looking into the improvements made to this driver in NetBSD and porting them back to FreeBSD. They've made a few bug fixes to the aic driver that we should have, but someone with the hardware has to do the integration. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Sat Mar 9 09:45:53 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA12098 for current-outgoing; Sat, 9 Mar 1996 09:45:53 -0800 (PST) Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA12093 Sat, 9 Mar 1996 09:45:50 -0800 (PST) Message-Id: <199603091745.JAA12093@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: Host localhost.cdrom.com [127.0.0.1] didn't use HELO protocol To: Mark Murray cc: current@freebsd.org Subject: Re: HEADS UP! Please check... In-reply-to: Your message of "Sat, 09 Mar 1996 17:05:48 +0200." <199603091505.RAA17462@grumble.grondar.za> Date: Sat, 09 Mar 1996 09:45:50 -0800 From: "Justin T. Gibbs" Sender: owner-current@freebsd.org X-Loop: owner-current@FreeBSD.ORG Precedence: bulk >Hi folks > >I have just committed a change to su(1) to better integrate Kerberos >into it. BUT, this missive does not apply only to those of you with >Kerberos/eBones. > >The result of this change is that a user will not be prompted for >a password again if they get the Kerberos password wrong. What happens if your network is down to your kerberos server and your user.root instance has a different password than your local root account? How do you know which password to give? >Thanks! > >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 -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Sat Mar 9 09:50:08 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA12327 for current-outgoing; Sat, 9 Mar 1996 09:50:08 -0800 (PST) Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA12322 Sat, 9 Mar 1996 09:50:05 -0800 (PST) Message-Id: <199603091750.JAA12322@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: Host localhost.cdrom.com [127.0.0.1] didn't use HELO protocol To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) cc: freebsd-current@FreeBSD.org (FreeBSD-current users) Subject: Re: 2842 and the disappearing file-system :-( In-reply-to: Your message of "Sat, 09 Mar 1996 13:31:35 +0100." <199603091231.NAA26195@uriah.heep.sax.de> Date: Sat, 09 Mar 1996 09:50:05 -0800 From: "Justin T. Gibbs" Sender: owner-current@FreeBSD.org X-Loop: owner-current@FreeBSD.ORG Precedence: bulk >As Justin T. Gibbs wrote: > >> The 2842VLB SCSI card, a non PnP device, sticks its identifier in >> the EISA slot address space for identification. FreeBSD currently >> always looks for these IDs in the EISA slot address space even if >> the EISA motherboard ID at 0x0C80 is not found so that it can detect >> these cards. > >I generally agree with your argumentation. > >One very minor addendum: while the LINT file mentions that the 284X >probes as an EISA card, there should perhaps be a warning in the >GENERIC config file, telling: ``Don't remove the eisa0 controller if >you're using an Adaptec 284X VLB controller.'' I'll do that sometime this weekend. >-- >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. ;-) -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Sat Mar 9 10:24:09 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA14382 for current-outgoing; Sat, 9 Mar 1996 10:24:09 -0800 (PST) Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA14373 for ; Sat, 9 Mar 1996 10:24:06 -0800 (PST) Message-Id: <199603091824.KAA14373@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: 3c5X9 working? Date: Sat, 09 Mar 1996 10:24:06 -0800 From: "Justin T. Gibbs" Sender: owner-current@FreeBSD.ORG X-Loop: owner-current@FreeBSD.ORG Precedence: bulk Are any of you having problems with 3c509 or 3c579 cards in current? I'd like to bring in the driver changes to -stable. Thanks, -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Sat Mar 9 12:55:50 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA22808 for current-outgoing; Sat, 9 Mar 1996 12:55:50 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA22790 Sat, 9 Mar 1996 12:55:47 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id MAA13067 ; Sat, 9 Mar 1996 12:36:38 -0800 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA21251; Sat, 9 Mar 1996 12:40:23 -0700 From: Terry Lambert Message-Id: <199603091940.MAA21251@phaeton.artisoft.com> Subject: Re: The continueing 2842/eisaconf argument To: gibbs@freefall.freebsd.org (Justin T. Gibbs) Date: Sat, 9 Mar 1996 12:40:23 -0700 (MST) Cc: terry@lambert.org, stable@FreeBSD.org, current@FreeBSD.org In-Reply-To: <199603090546.VAA22456@freefall.freebsd.org> from "Justin T. Gibbs" at Mar 8, 96 09:46:44 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: owner-current@FreeBSD.ORG Precedence: bulk > >I don't think the major work of the probe for the VLB card is the > >scan of the EISA slot address space. It's getting the configuration > >information about the card, and that doesn't take EISA configuration > >data to do it. > > EISA configuration data (assuming you mean the stuff accessible through > BIOS calls) is not used by any driver in FreeBSD. Even if it was > accessible to FreeBSD (and there's no reason it can't be with VM86() or > having the boot blocks save off the data) it would have to be interpreted > by each individual driver in order to be of any use. So, although eisaconf > may some day provide a mechanism for accessing this data, it certainly > won't attempt processing it on its own. Every eisa card we support > provides some other way for either read/write or write only access to > the data the driver needs. The *only* reason you need the BIOS is to determine the per slot CMOS area size. Other than that, all EISA information is accessable as a memory reference from protected mode. I think the ability to access/manipulate EISA data is a lot closer than the ever-out-of-reach-VM86(). If nothing else, the ram area size *could* be passed via the boot code. > It has to be up to each driver to request and then interpret this > information if it makes sense for them to do so. Many cards could > care less about what's up in configuration space. The 3c579 is one, > the 2842 is another. If we have to support EISA devices that don't > want configuration data we can also support VLB devices that doesn't > use configuration space information with no additional complexity. > Its really a question of capability and use. I think this assumes you use real mode/VM86 BIOS calls to get the configuration data per EISA slot. That way you would have a built in stop for non-EISA cards. If you access via memory reference, as I would hope would be done, since VM86() seems too far off, then the stop isn't there. > The 2742 and the 2842 will continue to get most of the information > about the card in the exact same way regardless of the availibility > of configuration space data. You're also not talking about > stub code, but an additional probe that iterates through the slot > address space since the 2842 can't reference the eisa code in your > model since you don't want to have to have eisa0 in your config file. Excuse me. You are saying that iterating through the slot address space is the only way to detect if the card is present or not? I know it is the method that happens to be used currently. I wasn't aware that the card was otherwise undetectable. > I don't see forcing people to include eisa0 in their > config files as a problem since config will eventually die a horrible > death, and the aic7xxx lkm will export its lkm dependancy graph so > that if you don't have the eisaconf lkm in your system for some > strange reason, it gives you a nice warning message. If you can > talk about eisa configuration space, I think its fair for me to say that > config, in its present state, will go away. The use of LKM's for boot drivers requires fallback drivers (in this case, using VM86(), in other cases using OpenFirmware or PPCBug or the Mac ROMs, etc.), which don't currently exist. Further, I think they require a move to COFF or ELF format so that there can be an associated segment identification, and the fallbacks can be paged out and the memory reclaimed, once the device-specific LKM has been loaded. I think given these dependencies, I think it is also fair for me to argue for an evolutionary step in that direction. > Having an EISA config file doesn't mean that your ISA device responds > to accesses at 0xzc80 and provides an EISA ID. Correct. I never claimed this. It does provide a graph entry so that you don't screw yourself by locating one ISA card in an EISA slot over top of another by forfeiture of the ability to detect the non-relocatable resources being used by the ISA card. That's really all I'd have it used for as well. > Having the config file is simply a way of aiding the ECU > in telling you where conflicts are or restricing your configuration > settings. Once the ECU session is over, there's nothing their to > tell FreeBSD about these ISA devices. I will agree with the caveat the we are talking about the *current* ECU code. I believe the information that it does not have an EISA ID is sufficient to indicate the cards existance and the need to probe fixed cards with potentially invasive probes, at least the first time the hardware is auto-configured. This would require storing deltas and running a configuration/probe log, ala Win95, which we need anyway for Lance, Floppy Tape, PS/2 mouse, and other devices which can't be non-invasively probed 100% of the time (maybe including SIO3 vs. Mach cards). > You can switch the dip switches on your 2842 all day, and FreeBSD will > still find it. You can also move your 2742 from slot to slot all day > and FreeBSD will still find it. Relocating the card doesn't prevent > you from booting from it in either case so long as the card's bios is > enabled. Booting is a BIOS issue. I can make a 2742 not bootable > by disabling its BIOS too. It does if I relocate something over top of its address space because it didn't have a graph entry warning me it was there. This is the reasoning that was put forth for the probe order changes, which *have* caused some problems, but have overall been the *right* thing to do. > >I think that the 2842 needs to be probed later than the typical > >EISA, PCI, PCMCIA, and PnP ISA devices, like other non-relocatable > >devices. It think it needs to have an invariant configuration graph > >vector, *unlike* things which are found by the EISA probe. > > The 2742 is just as non-relocatable as the 2842. The 2742 locks out is irq > register after the first time its written to (by the EISA configuration > just after POST). This is irrelevant. EISA supports resetting this, in any case, or the card would be impossible to reconfigure with the Adaptec tools. The point is that even if an EISA space card has only one potential space utilization topology, it is intrinsically *different* from an ISA card because the slot configuration data (which is only present on real EISA and is not used currently) can be consulted to determine allowable potential topologies. > Most EISA cards can't relocate their I/O range, but the > Buslogic cards can relocate relocate their registers through a range of ISA > compatibily areas. The point is that the way you deal with registering > relocatability has to be generic so you can deal with devices that vary in > their degrees of flexibility regardless of their bus type. I agree completely. But while the per slot data provides this information for true EISA cards, it does not do so for VLB cards pretending to be EISA cards. > >I think it is incorrect to probe the thing as an EISA device (are > >there any motherboards that have EISA and VLB at the same time? > >That would be a good counter-argument...). > > Many, many EISA 486 systems have VL and EISA slots. I own one of these > systems. This is seriously damning of my idea to use the EISA tag as a negative indicator. It means that there *would* need to be probe code for VLB cards that pretend to be EISA cards. But it does not mean that the probe would have to take the form of a slot iteration. BTW: I'm curious: how does the thing avoid slot configuration conflicts in a real EISA system? How is the VLB "fake-EISA" data exported so as to not conflict with the real thing? What if I plug two of these things into two VLB slots in the same machine? > Not all EISA devices are relocatable in the same ways. I can find > plenty of EISA devices that have the same relocation deficiencies > as the 2842. This is not a valid argument. No, but all *real* EISA devices are detectably relocatable using the slot configuration data that doesn't exist for VLB devices pretending to be EISA devices. This is what I meant when I said the configuration process would have to dereference this data through the driver so that the VLB card driver could fake the information that wouldn't exist if the config attempted to access it directly without the indirection. I think this will be a bigger problem than card detection. > Not all EISA cards are relocatable after their first initialization. > We have to deal with these anyway. We can. But to deal at all, we have to have an idea of the relocatability, as noted above, and VLB cards pretending to be EISA don't give that. > No, it identifies it as an ISA device. And, some non PnP ISA cards > just like some EISA cards (EISA is not PnP BTW), allow you to dynamically > change the IRQ. So, what's your point? If we had a configuration manager > we woudn't allow flexible devices to conflict with non-flexible ones > which has absolutly nothing to do with the 2842 being probed through > eisaconf. I agree with this... my point is that EISA configuration should be autonomously seperable from the rest of the configuration. The bus attach should be on a per bus basis, and the lines shouldn't be blurred by probes that cross over allowed boundries. I think it should work on the order of SCSI bus attachment, per bus. I think it has to for the DEC Alpha AXP/PCI boxes: their ISA is bridged from the PCI, not vice versa, and I know PReP/CHRP require this, so machines based on the Motorolla chips have the same issue. I expect there to be Intel based hardware with the same issues soon (if it doesn't already exist somewhere). > >It can tell that you don't have an EISA motherboard, which is the same > >thing, by negative induction. > > Assuming EISA and VLB are mutiually exclusive which they are not. Right. I blew it here. But this is still resolvable by knowing how EISA/VLB slot address space export works. Per my "BTW" questions, above, it should be possible to use knowledge of how the conflicts are dealt with to allow detection of the thing as a VLB card. Other cards don't care about VLB vs. ISA, except in terms of giving us a hint as to why the machine is failing that we can then passs on to the user in terms of bus-on time management. > The 3c509 in eisa configuration mode must be probed through eisaconf > to be found. It is reported as an ISA device. If it *must* use the EISA probe, then I'd call it a "short EISA device". That it can also be an ISA device via rejumpering is irrelevant. It should probably be reported as an EISA device. > The 2842 is also found through eisaconf and is reported as an ISA > device. I still think this is the wrong place to probe it. > Both show up as ISA device in lsdev too since their kdc parents > are kdc_isa. Where does the 2842 get classified as an EISA device? By virtue of who makes the graph entry for it. It has to do with the wrong guy making the call. I can make generic assumptions about real EISA devices based on the per slot memory which is currently ignored, but shouldn't be (you yourself admit that the current code can't be the final code). > >> The match routines and forcing a scan of the eisa address space makes > >> no sense in a generic ISA probe (deals with non PnP hardware) configuration > >> sub-manager. > > > >I agree. Don't use the slot scan to locate the card; it isn't a > >substitute for the majority of the work done by the probe code anyway. > >Move the scan identification into an EISA-specific stub, and create > >an ISA specific stub for the non-relocatable VLB card. > > And I either make it always be in your kernel, or make it part of > "eisa0", or I duplicate it. What a waste. It's not a part of your kernel if you leave ISA out. > >I think you are stuck on using the fact that it exports EISA slot > >data to trigger the probe (the manority of which is not dependent on > >the fact that it's "EISA"). I think this is wrong, for the ordering > >reasons stated above. > > The ordering reasons don't hold water. Nothing is gained by postponing > the probe of the 2842. Its just as "relocatable" as other EISA devices > and its probe is non-invasive (and already performed by the eisaconf code). No, the problem with having an ISA (VLB) device probed by the EISA code is that the EISA code must know it's an ISA device and call a different registration mechanism for it, since EISA devices will be known to be relocatable and ISA devices not, in a future version of the device registration code. And it is caller dependent, unless you call through the device code for the registration to allow it to be device dependent. > >The VLB bus is not bridged. The agregate bus-on time for N VLB cards > >going in sequence is the issue for deciding to "tune" the VLB cards > >down. > > This as well as most tuning parameters should be left up to the user. > I don't see FreeBSD trying to modify your DRAM refresh rates. Its > counter intuitive for the user to go in and set the bus on time for > their adapter using the vendor supplied tools for this purpose > (EISA config utility for the 2742, SCSI-Select for the 2842) and > not have the OS honor them. Windows95 sets defaults, and you use the "System Properties" dialog's "Device Manager" tab to do tuning. You don't use the vendor-supplied tools, because doing so would not provide a unified control model to the user. > Your making up problems Terry. Probe order is determined by bus type. Except for the 2842. Augh. > Resource allocation is determined by the relative flexibility of devices > regardless of bus type. Yes. And bus existance is seperable for the purposes of causing a bus attach to occur, and you don't need to attach an EISA bus (or have the code taking space in the kernel) when you don't have an EISA bus on your machine. Ideally, returning to the future you pointed at, the bus attach will probe the existance of the bus, and load the code for it using VM86() based I/O, then probe the EISA controller through which it made the VM86() calls to load the probe code, and then load the controller probe for the EISA controller (again using VM86()), probe it, and if there, attach it and unload the VM86() fallback driver. Subsequent devices will be loaded through the card-specific driver. > >Precisely! > > > >Once you can manipulate the configuration space, EISA cards are as > >relocatable as ISA PnP cards! But this VLB ccard, which you lie and > >say is an EISA card by virtue of whose probe comes true, can *not* > >be relocated! > > Bullshit! ISA PnP cards can relocate their I/O area most EISA cards can't. > Some EISA cards do not allow relocation of anything after the EISA BIOS is > done. Furthermore, the data up in configuration space doesn't control the > settings of the card. You have to write to the cards own registers to do > that which FreeBSD already has the capability to do without having access > to configuration space. This goes back to providing a unified device management view. There is nothing that says that an intervening reboot might not be required for the management changes to take effect, or even to allow the use of invase probes for otherwise unidentifiable hardware. The ability to change soft configurations on a card that is soft configurable belongs, properly, in the driver for that card, with a single common configuration API shared by all drivers and a flag for whether a reboot is required, etc.. The advantage to doing this type of relocation is that it is possible to have a relocatable-without-reboot card that conflicts with either a non-relocatable-card or a relocatable-with-reboot card in its two available locations. Better to be able to put up a message about the conflict and allow the user choose to allow the configuration manager to reboot the system than to lose 2 of 3 devices to conflicts. > >You have to indirect all EISA configuration space code through the > >driver, and then call common routines for *all other drivers*, and > >for this one fake an immobile configuration space! Bletch! Talk > >about unnecessary complexity! > > This just isn't true. All devices can call the same functions to > register their resources, but it will only be at attach time that > they will know if they have to change their settings and to what. Then you must make registration variant so that the EISA code registers the card as an ISA card. This defeats the ability to seperate out (and discard) the EISA bus attach code on machines without an EISA bus, in all cases. It also defeats the ability to detect a go/no-go for EISA configuration automatically (which you would otherwise do by looking for the EISA tag). This isn't a problem now, but will be a problem if we allow bus attachment to be demand-loaded via fallback drivers to cause every running kernel to be ideally configured for the hardware it is running on (for instance, I don't want to have EISA or ISA or PCI code in an MCA machine, and I certainly want the ability to have a "pure PCI" box). > >EISA cards become relocatable within the conflict space. > > The 2842 doesn't prevent this. Requiring the EISA code to probe it prevents discarding the EISA bus attach, or only performing the bus attach when the bus exists. 8-(. > >Do you not agree that EISA cards should be relocatable by a resonable > >configuration manager that knows EISA? > > Sure. Eisaconf is already poised to do this and the 2842 will > fit right in there. The problem with "just class the 2842 as an EISA card for purposes of probe" is still the EISA bus attach, which will be mandatory for all ISA machines, since they potentially have a VLB bus, and we are changing the meaning from "EISA bus attach" to "EISA or VLB bus attach". At least we can ignore the EISA bus attach because EISA is detectable by the ROM tag... IFF VLB devices are classed as a special case of ISA, not of EISA, in all cases (including the 2842). > >Or that the 2842, a VLB card, should *not* be relocatable because > >there is no standard mechanism for handling an EISA relocation of > >a non-EISA card? > > Hey, you can change the 2842's IRQ so it will tell that to the > configuration manager. The 2742 cannot change its IRQ, and it > will tell the configuration manager that. If you can handle one > case, you can handle the other. The 2742's ability to change it's IRQ is reflected in the data from the EISA slot. For this registration to be automatic rather than dependent on the driver, it's necessary to seperate the identity of EISA and VLB cards. > Its not needed to support dynamic configuration of EISA devices. > The 2742 just like the 2842 will not be making any calls into > eisaconf to retrieve information from configuration space, so > it doesn't matter if there is or is not any configuration space > data for the 2742 or the 2842. Other drivers may have different > requirements. I think the user configuration utility (if we even consult the user on conflict resoloutions requiring a reboot, which we probably should) will need to be able to access this data based on registration class for the device. This means making the class variant based on which bus interface registered it, or setting the same flag in a per driver basis by making the registration process go through the driver to occur. Isn't this an obvious consequence of having a non-EISA card registered by EISA bus interface code? Anyway, this discussion is getting into the arcane details of design of generic configuration management, and has so moved out of the scope of general interest (I think). If we want to discuss this further, we should probably take it offline. I'm more than happy to let you control the code. I only wanted to voice my concerns that I believe it is better to spend some extra code seperating the bus identification from the probe and driver code for the 2842. I believe that it will save problems later. 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 Sat Mar 9 13:58:38 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA28443 for current-outgoing; Sat, 9 Mar 1996 13:58:38 -0800 (PST) Received: from fw.ast.com (fw.ast.com [165.164.6.25]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA28438 for ; Sat, 9 Mar 1996 13:58:35 -0800 (PST) Received: from nemesis by fw.ast.com with uucp (Smail3.1.29.1 #2) id m0tvWZo-00084lC; Sat, 9 Mar 96 15:53 CST Received: by nemesis.lonestar.org (Smail3.1.27.1 #20) id m0tvWLb-000C0YC; Sat, 9 Mar 96 15:38 WET Message-Id: Date: Sat, 9 Mar 96 15:38 WET To: freebsd-current@freebsd.org From: uhclem@nemesis.lonestar.org (Frank Durda IV) Sent: Sat Mar 9 1996, 15:38:42 CST Subject: Re: New kernel Sender: owner-current@freebsd.org X-Loop: owner-current@FreeBSD.ORG Precedence: bulk [0]From: "Jordan K. Hubbard" [0]In former times we used the GENERIC keyword to do stuff like this, but [0]that was clearly gross. Stefan and I have tossed the idea around and [0]come up with the keyword FAILSAFE as a reasonable proposal. It sounds a bit like "Safe Mode" in Windows '95 but more intimidating. It is certainly more descriptive than GENERIC. It would be nice to avoid the use of the negative-sounding "FAIL" if possible... Frank Durda IV |"In skiing, there is this thing or uhclem%nemesis@rwsystr.nkn.net | called Reality. You will always | reach reality. The goal is to or ...letni!rwsys!nemesis!uhclem | avoid reaching it at a high rate of speed." (C) 1996 FDIV From owner-freebsd-current Sat Mar 9 15:35:22 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA04484 for current-outgoing; Sat, 9 Mar 1996 15:35:22 -0800 (PST) Received: from mail.cs.tu-berlin.de (root@mail.cs.tu-berlin.de [130.149.17.13]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id PAA04477 for ; Sat, 9 Mar 1996 15:35:18 -0800 (PST) Received: from ole.cs.tu-berlin.de (wosch@ole.cs.tu-berlin.de [130.149.22.3]) by mail.cs.tu-berlin.de (8.6.12/8.6.12) with ESMTP id AAA18588; Sun, 10 Mar 1996 00:35:13 +0100 Received: (from wosch@localhost) by campa.panke.de (8.6.9/8.6.9) id QAA00434; Sat, 9 Mar 1996 16:12:36 +0100 Date: Sat, 9 Mar 1996 16:12:36 +0100 From: Wolfram Schneider Message-Id: <199603091512.QAA00434@campa.panke.de> To: Paul Traina Cc: current@FreeBSD.org Subject: Re: _PATH_* In-Reply-To: <199603090038.QAA03842@precipice.shockwave.com> References: <199603072233.XAA01854@campa.panke.de> <199603090038.QAA03842@precipice.shockwave.com> Reply-to: Wolfram Schneider MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-current@FreeBSD.org X-Loop: owner-current@FreeBSD.ORG Precedence: bulk Paul Traina writes: >I think these make perfect sense. You could conceivably have shared versions >of a /bin program in /usr/bin, which is why this was set this way in the first >place. But this is an exception, not the common case. BTW, we use different PATH definitions: /usr/share/skel/dot.login set path = (/sbin /bin /usr/sbin /usr/bin /usr/games /usr/local/bin /usr/X11R6/bin $HOME/bin) /usr/share/skel/dot.profile PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/bin I prefer /bin:/usr/bin:/sbin:/usr/sbin:/usr/games:/usr/local/bin:/usr/X11/bin:$HOME/bin Wolfram From owner-freebsd-current Sat Mar 9 16:16:50 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA07551 for current-outgoing; Sat, 9 Mar 1996 16:16:50 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id QAA07545 for ; Sat, 9 Mar 1996 16:16:47 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id LAA30782; Sun, 10 Mar 1996 11:11:37 +1100 Date: Sun, 10 Mar 1996 11:11:37 +1100 From: Bruce Evans Message-Id: <199603100011.LAA30782@godzilla.zeta.org.au> To: current@FreeBSD.org, wosch@cs.tu-berlin.de Subject: Re: *.mk wishes Sender: owner-current@FreeBSD.org X-Loop: owner-current@FreeBSD.ORG Precedence: bulk >bsd.man.mk: >MANGRP, MANOWN, MANMODE, MANDIR already defined >in bsd.own.mk, should deleted >bsd.own.mk: >new variables DOCGRP, DOCOWN, DOCMODE, DOCDIR for documents I agree. It's convenient to have all the ownerships defined in a central place. Definitions of `OWN' variables are also duplicated in: bsd.lib.mk, bsd.port.subdir.mk, bsd.prog.mk, bsd.subdir.mk: BINOWN and some `OWN' variables aren't defined in bsd.own.mk: KMODOWN, LIBOWN. >sys.mk: >MMAP_RO: read only mmap, for programs like grep, groff, look etc. >MMAP_RW: write works (inn) I don't understand this. C macros should be defined in C headers. Don't add any more system macros to sys.mk. bsd.own.mk and (the system macros in) /etc/make.conf shouldn't be included in sys.mk because sys.mk always gets included by default. bsd.own.mk should be included only in the system `mk' files. Bruce From owner-freebsd-current Sat Mar 9 16:19:54 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA07714 for current-outgoing; Sat, 9 Mar 1996 16:19:54 -0800 (PST) Received: from localhost.indirect.com (s31.phxslip4.indirect.com [165.247.24.31]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id QAA07706 for ; Sat, 9 Mar 1996 16:19:51 -0800 (PST) Received: (from straka@localhost) by localhost.indirect.com (8.6.12/8.6.12) id RAA00782; Sat, 9 Mar 1996 17:18:12 -0700 Date: Sat, 9 Mar 1996 17:18:09 -0700 (MST) From: straka X-Sender: straka@localhost To: freebsd-current@FreeBSD.ORG Subject: panic: unwire: page not in pmap Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: owner-current@FreeBSD.ORG Precedence: bulk While booting from the boot floppy in 960303-SNAP, the kernel panics with the message panic: unwire: page not in pmap This occurs after all the hardware probes have been completed and the screen blanks just before bringing up the sysinstall menu. I tried booting from the 960226-SNAP boot floppy only to get exactly the same panic. My system consists of an AMD486DX4/100 on a PCI motherboard with an IDE harddrive. I tried both boot floppies on my other system which is an Intel 486DX2/66 on a VLB motherboard with an IDE harddrive and the sysinstall program executed properly with no panic. Seems like this problem may be due to the AMD processor. Any help on this would be greatly appreciated. Richard Straka straka@indirect.com From owner-freebsd-current Sat Mar 9 16:47:50 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA09558 for current-outgoing; Sat, 9 Mar 1996 16:47:50 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id QAA09552 for ; Sat, 9 Mar 1996 16:47:47 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id LAA32059; Sun, 10 Mar 1996 11:37:07 +1100 Date: Sun, 10 Mar 1996 11:37:07 +1100 From: Bruce Evans Message-Id: <199603100037.LAA32059@godzilla.zeta.org.au> To: kent@tfd.com, mark@grondar.za Subject: Re: `make -DCLOBBER world' fails Cc: freebsd-current@FreeBSD.org Sender: owner-current@FreeBSD.org X-Loop: owner-current@FreeBSD.ORG Precedence: bulk >> The problem is that programs are compiled & run to generate >> some libs before `crt0.o' is created. >> >> Examples include "gnu/lib/libgmp" and "lib/libmytinfo". >> >> This problem could be prevented by moving the >> >> cd ${.CURDIR}/lib/csu/i386 && >> ${MAKE} depend all install .... >> >> to the beginning of the lib make. >I agree with this. May I do it? The libraries CLOBBERing step is almost usless. I would just remove it. The point of it is to stop things getting linked with old static libraries and objects. However, many utilities are now linked before the libraries are CLOBBERed, so the CLOBBERing step only makes a difference for a couple of build utilities built before building csu. The utilities built before the libraries are installed only work if the new includes are not too inconsistent with the old shared libraries. The utilities built after CLOBBERing the old static libraries but before installing the new libraries only work if they are linked shared and the old shared libraries are not too inconsistent... Bruce From owner-freebsd-current Sat Mar 9 18:06:21 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA14301 for current-outgoing; Sat, 9 Mar 1996 18:06:21 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id SAA14296 for ; Sat, 9 Mar 1996 18:06:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.4/8.6.9) with SMTP id SAA09640; Sat, 9 Mar 1996 18:06:05 -0800 (PST) To: straka cc: freebsd-current@FreeBSD.ORG Subject: Re: panic: unwire: page not in pmap In-reply-to: Your message of "Sat, 09 Mar 1996 17:18:09 MST." Date: Sat, 09 Mar 1996 18:06:05 -0800 Message-ID: <9638.826423565@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.ORG X-Loop: owner-current@FreeBSD.ORG Precedence: bulk > While booting from the boot floppy in 960303-SNAP, the kernel panics with > the message > > panic: unwire: page not in pmap This one appears to be biting a lot of people, and I will hopefully be releasing a snapshot in the next couple of days with a number of fixes to the VM system (which I also hope fixes this). Jordan From owner-freebsd-current Sat Mar 9 18:49:57 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA17088 for current-outgoing; Sat, 9 Mar 1996 18:49:57 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id SAA17071 Sat, 9 Mar 1996 18:49:50 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id SAA15733 ; Sat, 9 Mar 1996 18:46:20 -0800 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA21251; Sat, 9 Mar 1996 12:40:23 -0700 From: Terry Lambert Message-Id: <199603091940.MAA21251@phaeton.artisoft.com> Subject: Re: The continueing 2842/eisaconf argument To: gibbs@freefall.freebsd.org (Justin T. Gibbs) Date: Sat, 9 Mar 1996 12:40:23 -0700 (MST) Cc: terry@lambert.org, stable@FreeBSD.ORG, current@FreeBSD.ORG In-Reply-To: <199603090546.VAA22456@freefall.freebsd.org> from "Justin T. Gibbs" at Mar 8, 96 09:46:44 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: owner-current@FreeBSD.ORG Precedence: bulk > >I don't think the major work of the probe for the VLB card is the > >scan of the EISA slot address space. It's getting the configuration > >information about the card, and that doesn't take EISA configuration > >data to do it. > > EISA configuration data (assuming you mean the stuff accessible through > BIOS calls) is not used by any driver in FreeBSD. Even if it was > accessible to FreeBSD (and there's no reason it can't be with VM86() or > having the boot blocks save off the data) it would have to be interpreted > by each individual driver in order to be of any use. So, although eisaconf > may some day provide a mechanism for accessing this data, it certainly > won't attempt processing it on its own. Every eisa card we support > provides some other way for either read/write or write only access to > the data the driver needs. The *only* reason you need the BIOS is to determine the per slot CMOS area size. Other than that, all EISA information is accessable as a memory reference from protected mode. I think the ability to access/manipulate EISA data is a lot closer than the ever-out-of-reach-VM86(). If nothing else, the ram area size *could* be passed via the boot code. > It has to be up to each driver to request and then interpret this > information if it makes sense for them to do so. Many cards could > care less about what's up in configuration space. The 3c579 is one, > the 2842 is another. If we have to support EISA devices that don't > want configuration data we can also support VLB devices that doesn't > use configuration space information with no additional complexity. > Its really a question of capability and use. I think this assumes you use real mode/VM86 BIOS calls to get the configuration data per EISA slot. That way you would have a built in stop for non-EISA cards. If you access via memory reference, as I would hope would be done, since VM86() seems too far off, then the stop isn't there. > The 2742 and the 2842 will continue to get most of the information > about the card in the exact same way regardless of the availibility > of configuration space data. You're also not talking about > stub code, but an additional probe that iterates through the slot > address space since the 2842 can't reference the eisa code in your > model since you don't want to have to have eisa0 in your config file. Excuse me. You are saying that iterating through the slot address space is the only way to detect if the card is present or not? I know it is the method that happens to be used currently. I wasn't aware that the card was otherwise undetectable. > I don't see forcing people to include eisa0 in their > config files as a problem since config will eventually die a horrible > death, and the aic7xxx lkm will export its lkm dependancy graph so > that if you don't have the eisaconf lkm in your system for some > strange reason, it gives you a nice warning message. If you can > talk about eisa configuration space, I think its fair for me to say that > config, in its present state, will go away. The use of LKM's for boot drivers requires fallback drivers (in this case, using VM86(), in other cases using OpenFirmware or PPCBug or the Mac ROMs, etc.), which don't currently exist. Further, I think they require a move to COFF or ELF format so that there can be an associated segment identification, and the fallbacks can be paged out and the memory reclaimed, once the device-specific LKM has been loaded. I think given these dependencies, I think it is also fair for me to argue for an evolutionary step in that direction. > Having an EISA config file doesn't mean that your ISA device responds > to accesses at 0xzc80 and provides an EISA ID. Correct. I never claimed this. It does provide a graph entry so that you don't screw yourself by locating one ISA card in an EISA slot over top of another by forfeiture of the ability to detect the non-relocatable resources being used by the ISA card. That's really all I'd have it used for as well. > Having the config file is simply a way of aiding the ECU > in telling you where conflicts are or restricing your configuration > settings. Once the ECU session is over, there's nothing their to > tell FreeBSD about these ISA devices. I will agree with the caveat the we are talking about the *current* ECU code. I believe the information that it does not have an EISA ID is sufficient to indicate the cards existance and the need to probe fixed cards with potentially invasive probes, at least the first time the hardware is auto-configured. This would require storing deltas and running a configuration/probe log, ala Win95, which we need anyway for Lance, Floppy Tape, PS/2 mouse, and other devices which can't be non-invasively probed 100% of the time (maybe including SIO3 vs. Mach cards). > You can switch the dip switches on your 2842 all day, and FreeBSD will > still find it. You can also move your 2742 from slot to slot all day > and FreeBSD will still find it. Relocating the card doesn't prevent > you from booting from it in either case so long as the card's bios is > enabled. Booting is a BIOS issue. I can make a 2742 not bootable > by disabling its BIOS too. It does if I relocate something over top of its address space because it didn't have a graph entry warning me it was there. This is the reasoning that was put forth for the probe order changes, which *have* caused some problems, but have overall been the *right* thing to do. > >I think that the 2842 needs to be probed later than the typical > >EISA, PCI, PCMCIA, and PnP ISA devices, like other non-relocatable > >devices. It think it needs to have an invariant configuration graph > >vector, *unlike* things which are found by the EISA probe. > > The 2742 is just as non-relocatable as the 2842. The 2742 locks out is irq > register after the first time its written to (by the EISA configuration > just after POST). This is irrelevant. EISA supports resetting this, in any case, or the card would be impossible to reconfigure with the Adaptec tools. The point is that even if an EISA space card has only one potential space utilization topology, it is intrinsically *different* from an ISA card because the slot configuration data (which is only present on real EISA and is not used currently) can be consulted to determine allowable potential topologies. > Most EISA cards can't relocate their I/O range, but the > Buslogic cards can relocate relocate their registers through a range of ISA > compatibily areas. The point is that the way you deal with registering > relocatability has to be generic so you can deal with devices that vary in > their degrees of flexibility regardless of their bus type. I agree completely. But while the per slot data provides this information for true EISA cards, it does not do so for VLB cards pretending to be EISA cards. > >I think it is incorrect to probe the thing as an EISA device (are > >there any motherboards that have EISA and VLB at the same time? > >That would be a good counter-argument...). > > Many, many EISA 486 systems have VL and EISA slots. I own one of these > systems. This is seriously damning of my idea to use the EISA tag as a negative indicator. It means that there *would* need to be probe code for VLB cards that pretend to be EISA cards. But it does not mean that the probe would have to take the form of a slot iteration. BTW: I'm curious: how does the thing avoid slot configuration conflicts in a real EISA system? How is the VLB "fake-EISA" data exported so as to not conflict with the real thing? What if I plug two of these things into two VLB slots in the same machine? > Not all EISA devices are relocatable in the same ways. I can find > plenty of EISA devices that have the same relocation deficiencies > as the 2842. This is not a valid argument. No, but all *real* EISA devices are detectably relocatable using the slot configuration data that doesn't exist for VLB devices pretending to be EISA devices. This is what I meant when I said the configuration process would have to dereference this data through the driver so that the VLB card driver could fake the information that wouldn't exist if the config attempted to access it directly without the indirection. I think this will be a bigger problem than card detection. > Not all EISA cards are relocatable after their first initialization. > We have to deal with these anyway. We can. But to deal at all, we have to have an idea of the relocatability, as noted above, and VLB cards pretending to be EISA don't give that. > No, it identifies it as an ISA device. And, some non PnP ISA cards > just like some EISA cards (EISA is not PnP BTW), allow you to dynamically > change the IRQ. So, what's your point? If we had a configuration manager > we woudn't allow flexible devices to conflict with non-flexible ones > which has absolutly nothing to do with the 2842 being probed through > eisaconf. I agree with this... my point is that EISA configuration should be autonomously seperable from the rest of the configuration. The bus attach should be on a per bus basis, and the lines shouldn't be blurred by probes that cross over allowed boundries. I think it should work on the order of SCSI bus attachment, per bus. I think it has to for the DEC Alpha AXP/PCI boxes: their ISA is bridged from the PCI, not vice versa, and I know PReP/CHRP require this, so machines based on the Motorolla chips have the same issue. I expect there to be Intel based hardware with the same issues soon (if it doesn't already exist somewhere). > >It can tell that you don't have an EISA motherboard, which is the same > >thing, by negative induction. > > Assuming EISA and VLB are mutiually exclusive which they are not. Right. I blew it here. But this is still resolvable by knowing how EISA/VLB slot address space export works. Per my "BTW" questions, above, it should be possible to use knowledge of how the conflicts are dealt with to allow detection of the thing as a VLB card. Other cards don't care about VLB vs. ISA, except in terms of giving us a hint as to why the machine is failing that we can then passs on to the user in terms of bus-on time management. > The 3c509 in eisa configuration mode must be probed through eisaconf > to be found. It is reported as an ISA device. If it *must* use the EISA probe, then I'd call it a "short EISA device". That it can also be an ISA device via rejumpering is irrelevant. It should probably be reported as an EISA device. > The 2842 is also found through eisaconf and is reported as an ISA > device. I still think this is the wrong place to probe it. > Both show up as ISA device in lsdev too since their kdc parents > are kdc_isa. Where does the 2842 get classified as an EISA device? By virtue of who makes the graph entry for it. It has to do with the wrong guy making the call. I can make generic assumptions about real EISA devices based on the per slot memory which is currently ignored, but shouldn't be (you yourself admit that the current code can't be the final code). > >> The match routines and forcing a scan of the eisa address space makes > >> no sense in a generic ISA probe (deals with non PnP hardware) configuration > >> sub-manager. > > > >I agree. Don't use the slot scan to locate the card; it isn't a > >substitute for the majority of the work done by the probe code anyway. > >Move the scan identification into an EISA-specific stub, and create > >an ISA specific stub for the non-relocatable VLB card. > > And I either make it always be in your kernel, or make it part of > "eisa0", or I duplicate it. What a waste. It's not a part of your kernel if you leave ISA out. > >I think you are stuck on using the fact that it exports EISA slot > >data to trigger the probe (the manority of which is not dependent on > >the fact that it's "EISA"). I think this is wrong, for the ordering > >reasons stated above. > > The ordering reasons don't hold water. Nothing is gained by postponing > the probe of the 2842. Its just as "relocatable" as other EISA devices > and its probe is non-invasive (and already performed by the eisaconf code). No, the problem with having an ISA (VLB) device probed by the EISA code is that the EISA code must know it's an ISA device and call a different registration mechanism for it, since EISA devices will be known to be relocatable and ISA devices not, in a future version of the device registration code. And it is caller dependent, unless you call through the device code for the registration to allow it to be device dependent. > >The VLB bus is not bridged. The agregate bus-on time for N VLB cards > >going in sequence is the issue for deciding to "tune" the VLB cards > >down. > > This as well as most tuning parameters should be left up to the user. > I don't see FreeBSD trying to modify your DRAM refresh rates. Its > counter intuitive for the user to go in and set the bus on time for > their adapter using the vendor supplied tools for this purpose > (EISA config utility for the 2742, SCSI-Select for the 2842) and > not have the OS honor them. Windows95 sets defaults, and you use the "System Properties" dialog's "Device Manager" tab to do tuning. You don't use the vendor-supplied tools, because doing so would not provide a unified control model to the user. > Your making up problems Terry. Probe order is determined by bus type. Except for the 2842. Augh. > Resource allocation is determined by the relative flexibility of devices > regardless of bus type. Yes. And bus existance is seperable for the purposes of causing a bus attach to occur, and you don't need to attach an EISA bus (or have the code taking space in the kernel) when you don't have an EISA bus on your machine. Ideally, returning to the future you pointed at, the bus attach will probe the existance of the bus, and load the code for it using VM86() based I/O, then probe the EISA controller through which it made the VM86() calls to load the probe code, and then load the controller probe for the EISA controller (again using VM86()), probe it, and if there, attach it and unload the VM86() fallback driver. Subsequent devices will be loaded through the card-specific driver. > >Precisely! > > > >Once you can manipulate the configuration space, EISA cards are as > >relocatable as ISA PnP cards! But this VLB ccard, which you lie and > >say is an EISA card by virtue of whose probe comes true, can *not* > >be relocated! > > Bullshit! ISA PnP cards can relocate their I/O area most EISA cards can't. > Some EISA cards do not allow relocation of anything after the EISA BIOS is > done. Furthermore, the data up in configuration space doesn't control the > settings of the card. You have to write to the cards own registers to do > that which FreeBSD already has the capability to do without having access > to configuration space. This goes back to providing a unified device management view. There is nothing that says that an intervening reboot might not be required for the management changes to take effect, or even to allow the use of invase probes for otherwise unidentifiable hardware. The ability to change soft configurations on a card that is soft configurable belongs, properly, in the driver for that card, with a single common configuration API shared by all drivers and a flag for whether a reboot is required, etc.. The advantage to doing this type of relocation is that it is possible to have a relocatable-without-reboot card that conflicts with either a non-relocatable-card or a relocatable-with-reboot card in its two available locations. Better to be able to put up a message about the conflict and allow the user choose to allow the configuration manager to reboot the system than to lose 2 of 3 devices to conflicts. > >You have to indirect all EISA configuration space code through the > >driver, and then call common routines for *all other drivers*, and > >for this one fake an immobile configuration space! Bletch! Talk > >about unnecessary complexity! > > This just isn't true. All devices can call the same functions to > register their resources, but it will only be at attach time that > they will know if they have to change their settings and to what. Then you must make registration variant so that the EISA code registers the card as an ISA card. This defeats the ability to seperate out (and discard) the EISA bus attach code on machines without an EISA bus, in all cases. It also defeats the ability to detect a go/no-go for EISA configuration automatically (which you would otherwise do by looking for the EISA tag). This isn't a problem now, but will be a problem if we allow bus attachment to be demand-loaded via fallback drivers to cause every running kernel to be ideally configured for the hardware it is running on (for instance, I don't want to have EISA or ISA or PCI code in an MCA machine, and I certainly want the ability to have a "pure PCI" box). > >EISA cards become relocatable within the conflict space. > > The 2842 doesn't prevent this. Requiring the EISA code to probe it prevents discarding the EISA bus attach, or only performing the bus attach when the bus exists. 8-(. > >Do you not agree that EISA cards should be relocatable by a resonable > >configuration manager that knows EISA? > > Sure. Eisaconf is already poised to do this and the 2842 will > fit right in there. The problem with "just class the 2842 as an EISA card for purposes of probe" is still the EISA bus attach, which will be mandatory for all ISA machines, since they potentially have a VLB bus, and we are changing the meaning from "EISA bus attach" to "EISA or VLB bus attach". At least we can ignore the EISA bus attach because EISA is detectable by the ROM tag... IFF VLB devices are classed as a special case of ISA, not of EISA, in all cases (including the 2842). > >Or that the 2842, a VLB card, should *not* be relocatable because > >there is no standard mechanism for handling an EISA relocation of > >a non-EISA card? > > Hey, you can change the 2842's IRQ so it will tell that to the > configuration manager. The 2742 cannot change its IRQ, and it > will tell the configuration manager that. If you can handle one > case, you can handle the other. The 2742's ability to change it's IRQ is reflected in the data from the EISA slot. For this registration to be automatic rather than dependent on the driver, it's necessary to seperate the identity of EISA and VLB cards. > Its not needed to support dynamic configuration of EISA devices. > The 2742 just like the 2842 will not be making any calls into > eisaconf to retrieve information from configuration space, so > it doesn't matter if there is or is not any configuration space > data for the 2742 or the 2842. Other drivers may have different > requirements. I think the user configuration utility (if we even consult the user on conflict resoloutions requiring a reboot, which we probably should) will need to be able to access this data based on registration class for the device. This means making the class variant based on which bus interface registered it, or setting the same flag in a per driver basis by making the registration process go through the driver to occur. Isn't this an obvious consequence of having a non-EISA card registered by EISA bus interface code? Anyway, this discussion is getting into the arcane details of design of generic configuration management, and has so moved out of the scope of general interest (I think). If we want to discuss this further, we should probably take it offline. I'm more than happy to let you control the code. I only wanted to voice my concerns that I believe it is better to spend some extra code seperating the bus identification from the probe and driver code for the 2842. I believe that it will save problems later. 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 Sat Mar 9 18:51:16 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA17208 for current-outgoing; Sat, 9 Mar 1996 18:51:16 -0800 (PST) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id SAA17202 for ; Sat, 9 Mar 1996 18:51:10 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.6.11/8.6.9) id VAA04140 for current@freebsd.org; Sat, 9 Mar 1996 21:47:12 GMT From: "John S. Dyson" Message-Id: <199603092147.VAA04140@dyson.iquest.net> Subject: Re: VM problems To: current@freebsd.org Date: Sat, 9 Mar 1996 21:47:11 +0000 () 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: owner-current@FreeBSD.ORG Precedence: bulk Howdy gang: I committed some changes on Fri night (should be available today for sup) to current. I think that the VM problems should be fixed. (INN still probably has problems -- that is later tonite and tomorrow work.) Please try the stuff out and give me feedback good or bad. I would appreciate it!!! Thanks John From owner-freebsd-current Sat Mar 9 19:01:40 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id TAA18103 for current-outgoing; Sat, 9 Mar 1996 19:01:40 -0800 (PST) Received: from covina.lightside.com (covina.lightside.com [198.81.209.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id TAA18094 for ; Sat, 9 Mar 1996 19:01:35 -0800 (PST) Received: by covina.lightside.com (Smail3.1.28.1 #6) id m0tvbMm-0004HvC; Sat, 9 Mar 96 19:00 PST Date: Sat, 9 Mar 1996 19:00:15 -0800 (PST) From: Jake Hamby To: current@FreeBSD.ORG cc: jkh@time.cdrom.com, toor@dyson.iquest.net Subject: AMD doesn't like SNAP! (panic: unwire: page not in pmap) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: owner-current@FreeBSD.ORG Precedence: bulk So far three people, including myself, have reported the above panic message when booting the 3/3 SNAP kernel. All three of us have AMD DX4 processors (100 and 120MHz). This has got to be the problem! John, Jordan, people working on the VM system, take note.. Thanks! ---Jake From owner-freebsd-current Sat Mar 9 20:46:10 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id UAA23517 for current-outgoing; Sat, 9 Mar 1996 20:46:10 -0800 (PST) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id UAA23509 for ; Sat, 9 Mar 1996 20:46:07 -0800 (PST) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id UAA10659; Sat, 9 Mar 1996 20:45:51 -0800 From: "Rodney W. Grimes" Message-Id: <199603100445.UAA10659@GndRsh.aac.dev.com> Subject: Re: AMD doesn't like SNAP! (panic: unwire: page not in pmap) To: jehamby@lightside.com (Jake Hamby) Date: Sat, 9 Mar 1996 20:45:51 -0800 (PST) Cc: current@FreeBSD.ORG, jkh@time.cdrom.com, toor@dyson.iquest.net In-Reply-To: from "Jake Hamby" at Mar 9, 96 07:00:15 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: owner-current@FreeBSD.ORG Precedence: bulk > > So far three people, including myself, have reported the above panic > message when booting the 3/3 SNAP kernel. All three of us have AMD DX4 > processors (100 and 120MHz). This has got to be the problem! John, > Jordan, people working on the VM system, take note.. Thanks! Can all three of you tell me if you have A80486DX4-100NV8T's or A80486DX4-100SV8B's? The difference is the SV8B is the write back enhanced DX4 and unless you have a motherboard that understands how to deal with this you are going to have a cache coherency problem between the internal and external cache. I have yet to see a MB deal with this correctly when faced with a bus master SCSI controller, though I have seen some that work fine as long as no bus mastering is occuring. Far more don't work than do work. If you don't have SV8B's or are not running them in WB mode, then I don't have any idea what has gone wrong... -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Sat Mar 9 21:04:56 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA24110 for current-outgoing; Sat, 9 Mar 1996 21:04:56 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id VAA24105 for ; Sat, 9 Mar 1996 21:04:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.4/8.6.9) with SMTP id VAA12056; Sat, 9 Mar 1996 21:04:27 -0800 (PST) To: "Rodney W. Grimes" cc: jehamby@lightside.com (Jake Hamby), current@FreeBSD.ORG, toor@dyson.iquest.net Subject: Re: AMD doesn't like SNAP! (panic: unwire: page not in pmap) In-reply-to: Your message of "Sat, 09 Mar 1996 20:45:51 PST." <199603100445.UAA10659@GndRsh.aac.dev.com> Date: Sat, 09 Mar 1996 21:04:27 -0800 Message-ID: <12054.826434267@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.ORG X-Loop: owner-current@FreeBSD.ORG Precedence: bulk > I have yet to see a MB deal with this correctly when faced with > a bus master SCSI controller, though I have seen some that work fine > as long as no bus mastering is occuring. Far more don't work than > do work. Sigh.. A Rod's Tips page at http://www.freebsd.org/handbook/hw.html SURE WOULD BE NICE, yup! Save lots of people lots of trouble.. :-) Jordan From owner-freebsd-current Sat Mar 9 21:58:15 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA25978 for current-outgoing; Sat, 9 Mar 1996 21:58:15 -0800 (PST) Received: from ter2.fl.net.au (root@ter2.fl.net.au [203.63.198.3]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id VAA25971 for ; Sat, 9 Mar 1996 21:58:10 -0800 (PST) Received: from tiger.fl.net.au (tiger.fl.net.au [203.63.198.11]) by ter2.fl.net.au (2.0/adf) with SMTP id QAA09199 for ; Sun, 10 Mar 1996 16:01:02 +1000 (EST) Message-Id: <2.2.32.19960311025700.00ebacb8@mail.fl.net.au> X-Sender: adf@mail.fl.net.au X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 10 Mar 1996 16:57:00 -1000 To: current@freebsd.org From: Andrew Foster Subject: top and 2.2-960303SNAP Sender: owner-current@freebsd.org X-Loop: owner-current@FreeBSD.ORG Precedence: bulk Hi, Just incase this hasn't be brought up before (just subscribed to this list), top gives 'interesting' results on this SNAP. Thanks, Andrew ----------- Andrew Foster Sydney, Australia From owner-freebsd-current Sat Mar 9 22:20:40 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA26910 for current-outgoing; Sat, 9 Mar 1996 22:20:40 -0800 (PST) Received: from woop.ereet.org ([204.177.198.123]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id WAA26899 for ; Sat, 9 Mar 1996 22:20:33 -0800 (PST) Received: (from b@localhost) by woop.ereet.org (8.6.12/8.6.12) id AAA00569; Sun, 10 Mar 1996 00:20:39 -0600 Date: Sun, 10 Mar 1996 00:20:38 -0600 (CST) From: bEE X-Sender: b@woop.ereet.org To: current@FreeBSD.ORG Subject: Re: AMD doesn't like SNAP! (panic: unwire: page not in pmap) 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 Sat, 9 Mar 1996, Jake Hamby wrote: > So far three people, including myself, have reported the above panic > message when booting the 3/3 SNAP kernel. All three of us have AMD DX4 > processors (100 and 120MHz). This has got to be the problem! John, > Jordan, people working on the VM system, take note.. Thanks! I am using an Intel 486/66 DX2 and I also have these problems. the AMD chip has nothing to do with it. b From owner-freebsd-current Sat Mar 9 23:50:55 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA00810 for current-outgoing; Sat, 9 Mar 1996 23:50:55 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id XAA00805 for ; Sat, 9 Mar 1996 23:50:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.4/8.6.9) with SMTP id XAA12321; Sat, 9 Mar 1996 23:50:30 -0800 (PST) To: Andrew Foster cc: current@freebsd.org Subject: Re: top and 2.2-960303SNAP In-reply-to: Your message of "Sun, 10 Mar 1996 16:57:00 -1000." <2.2.32.19960311025700.00ebacb8@mail.fl.net.au> Date: Sat, 09 Mar 1996 23:50:30 -0800 Message-ID: <12318.826444230@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Did you compile it from scratch? Jordan > Hi, > > Just incase this hasn't be brought up before (just subscribed to this list), > top gives 'interesting' results on this SNAP. > > Thanks, > Andrew > ----------- > Andrew Foster > Sydney, Australia >