From owner-freebsd-bugs Sun Mar 5 04:30:05 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id EAA04828 for bugs-outgoing; Sun, 5 Mar 1995 04:30:05 -0800 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id EAA04821; Sun, 5 Mar 1995 04:30:03 -0800 Date: Sun, 5 Mar 1995 04:30:03 -0800 Message-Id: <199503051230.EAA04821@freefall.cdrom.com> From: J Wunsch Reply-To: J Wunsch To: freebsd-bugs Subject: docs/232: the mandoc .St macro seems to be broken In-Reply-To: Your message of Sun, 5 Mar 1995 12:57:05 +0100 <199503051157.MAA11958@uriah.heep.sax.de> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 232 >Category: docs >Synopsis: The mandoc .St macro doesn't work or misses IEEE754 >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Mar 5 04:30:02 1995 >Originator: J Wunsch >Organization: >Release: FreeBSD 2.1.0-Development i386 >Environment: FreeBSD-2.0-950210-SNAP >Description: The manual page for copysign(3) contains the following lines: These functions are required or recommended by .St -ieee754 . The .St macro expands to a null string, however. >How-To-Repeat: man 3 copysign >Fix: dunno >Audit-Trail: >Unformatted: From owner-freebsd-bugs Sun Mar 5 04:30:03 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id EAA04817 for bugs-outgoing; Sun, 5 Mar 1995 04:30:03 -0800 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id EAA04807; Sun, 5 Mar 1995 04:30:02 -0800 Date: Sun, 5 Mar 1995 04:30:02 -0800 Message-Id: <199503051230.EAA04807@freefall.cdrom.com> From: J Wunsch Reply-To: J Wunsch To: freebsd-bugs Subject: gnu/231: send-pr loads .signature into the Organization field In-Reply-To: Your message of Sun, 5 Mar 1995 13:00:34 +0100 <199503051200.NAA12065@uriah.heep.sax.de> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 231 >Category: gnu >Synopsis: send-pr initializes Organization with ~/.signature >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Mar 5 04:30:01 1995 >Originator: J Wunsch >Organization: >Release: FreeBSD 2.1.0-Development i386 >Environment: FreeBSD-2.0-950210-SNAP >Description: send-pr(1) pre-initializes the Organization: field with the contents of ~/.signature, which appears to be bogus: || >Organization: cheers, J"org || || joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ || Never trust an operating system you don't have sources for. ;-) >How-To-Repeat: use send-pr >Fix: dunno >Audit-Trail: >Unformatted: From owner-freebsd-bugs Sun Mar 5 16:05:08 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id QAA11648 for bugs-outgoing; Sun, 5 Mar 1995 16:05:08 -0800 Received: from deadline.snafu.de (deadline.snafu.de [194.64.64.181]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id QAA11634 for ; Sun, 5 Mar 1995 16:04:58 -0800 Received: by deadline.snafu.de id m0rlQHs-000DVKC; Mon, 6 Mar 95 01:04 MET (/\oo/\ Smail3.1.29.1 #29.1) Message-Id: From: root@deadline.snafu.de (Andreas S. Wetzel) Subject: Re: A recent sup problem? To: bugs@FreeBSD.org Date: Mon, 6 Mar 1995 01:04:35 +0100 (MET) In-Reply-To: from "Eric M. Busalacchi" at Mar 2, 95 10:39:44 am Organization: -D-E-A-D-L-I-N-E- Public access UN*X system - 13347 Berlin. X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2916 Sender: bugs-owner@FreeBSD.org Precedence: bulk Hi! --- Eric M. Busalacchi writes: ] I did a sup 24 yesterday, and the proceeded to do a 'make ] world'. I did a sup again this morning at 9:00am Eastern Standard ] Time and when I went to compile my kernel I got two errors, the first had ] to do with sound: ] [...] Since a few day's I have the same problem, when trying to compile the kernel: loading kernel tty.o: Definition of symbol `_ttydefchars' (multiply defined) tcp_output.o: Definition of symbol `_tcp_outflags' (multiply defined) tcp_subr.o: Definition of symbol `_tcp_outflags' (multiply defined) scsiconf.o: Undefined symbol `_scsi_tinit' referenced from text segment scsiconf.o: Undefined symbol `_scsi_tinit' referenced from text segment scsiconf.o: Undefined symbol `_scsi_tinit' referenced from text segment scsiconf.o: Undefined symbol `_scsi_cinit' referenced from text segment scsiconf.o: Undefined symbol `_scsi_cinit' referenced from text segment scsiconf.o: Undefined symbol `_scsi_dinit' referenced from text segment scsiconf.o: Undefined symbol `_scsi_dinit' referenced from text segment scsiconf.o: Undefined symbol `_scsi_dinit' referenced from text segment scsiconf.o: Undefined symbol `_scsi_dinit' referenced from text segment scsiconf.o: Undefined symbol `_scsi_cinit' referenced from text segment scsiconf.o: Undefined symbol `_scsi_cinit' referenced from text segment scsiconf.o: Undefined symbol `_scsi_cinit' referenced from text segment scsiconf.o: Undefined symbol `_scsi_dinit' referenced from text segment scsiconf.o: Undefined symbol `_scsi_dinit' referenced from text segment scsiconf.o: Undefined symbol `_scsi_dinit' referenced from text segment scsiconf.o: Undefined symbol `_scsi_dinit' referenced from text segment scsiconf.o: More undefined symbol _scsi_dinit refs follow userconfig.o: Undefined symbol `_strncmp' referenced from text segment userconfig.o: Undefined symbol `_scsi_cinit' referenced from text segment userconfig.o: Undefined symbol `_scsi_cinit' referenced from text segment userconfig.o: Undefined symbol `_scsi_cinit' referenced from text segment sio.o: Definition of symbol `_ttydefchars' (multiply defined) ioconf.o: Undefined symbol `_sbintr' referenced from data segment ioconf.o: Undefined symbol `_sbintr' referenced from data segment *** Error code 1 Stop. Does anybody out there know, whats the problem with this ? Thanks in advance. Mickey -- ================================================================================ DIGESTED BENEFACTORS WHOSE | Andreas S. Wetzel | -D-E-A-D-L-I-N-E- SILENCE DEAFENS ANYTHING | Utrechter Strasse 41 | ALL OF WHOM DECEASE AND | 13347 Berlin | <+4930> 455 19 57 Data MISS TO PIERCE A POINT | Germany | <+4930> 456 81 68 Voice ================================================================================ E-mail: mickey@deadline.snafu.de WWW: http://deadline.snafu.de/ From owner-freebsd-bugs Sun Mar 5 16:34:09 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id QAA12676 for bugs-outgoing; Sun, 5 Mar 1995 16:34:09 -0800 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id QAA12668 for ; Sun, 5 Mar 1995 16:34:02 -0800 Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id RAA20782; Sun, 5 Mar 1995 17:37:37 -0700 Date: Sun, 5 Mar 1995 17:37:37 -0700 Message-Id: <199503060037.RAA20782@trout.sri.MT.net> To: root@deadline.snafu.de (Andreas S. Wetzel) Cc: bugs@FreeBSD.org Subject: Re: A recent sup problem? In-Reply-To: References: Reply-To: nate@sneezy.sri.com (Nate Williams) From: nate@sneezy.sri.com (Nate Williams) Sender: bugs-owner@FreeBSD.org Precedence: bulk > Since a few day's I have the same problem, when trying to compile the > kernel: > tcp_output.o: Definition of symbol `_tcp_outflags' (multiply defined) > tcp_subr.o: Definition of symbol `_tcp_outflags' (multiply defined) > tty.o: Definition of symbol `_ttydefchars' (multiply defined) It couldn't have been a few days for the above problems since the new ld code just went in yesterday. I'm in the processing of doing the correct fix now. > scsiconf.o: Undefined symbol `_scsi_tinit' referenced from text > segment Not sure about these errors. Peter would be the one to answer it, but it's probably something rebuilding config would solve. (Ie: when all else fails, rebuilt and re-install config) Nate From owner-freebsd-bugs Sun Mar 5 22:38:04 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA24139 for bugs-outgoing; Sun, 5 Mar 1995 22:38:04 -0800 Received: from mail06.mail.aol.com (mail06.mail.aol.com [152.163.172.108]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id WAA24133 for ; Sun, 5 Mar 1995 22:38:02 -0800 From: MarloweN@aol.com Received: by mail06.mail.aol.com (1.37.109.11/16.2) id AA291171830; Mon, 6 Mar 1995 01:37:10 -0500 Date: Mon, 6 Mar 1995 01:37:10 -0500 Message-Id: <950306013709_40511236@aol.com> To: bugs@FreeBSD.org Cc: XKY41771@genie.geis.com Subject: FreeBSD Installation - Not Sender: bugs-owner@FreeBSD.org Precedence: bulk So I made the floppies and did all the Fdisking since I have now two hard drives, the first full of DOS/Windows and stuff. So BSD starts to boot from hard drive 1 ( or 2 depending on which Fdisk you are using) but then, after a couple screens of system initialization messages, - - Panic: Cannot mount root And Alt-F1/Alt-F2 did not work after I hit a key to prevent automatic rebooting in 15 seconds. Thanks for the help. Marlowe Nortrom From owner-freebsd-bugs Sun Mar 5 22:56:27 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA24408 for bugs-outgoing; Sun, 5 Mar 1995 22:56:27 -0800 Received: from hda.com (hda.com [199.232.40.182]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id WAA24402 for ; Sun, 5 Mar 1995 22:56:25 -0800 Received: (dufault@localhost) by hda.com (8.6.9/8.3) id BAA01633; Mon, 6 Mar 1995 01:53:39 -0500 From: Peter Dufault Message-Id: <199503060653.BAA01633@hda.com> Subject: Re: A recent sup problem? To: root@deadline.snafu.de (Andreas S. Wetzel) Date: Mon, 6 Mar 1995 01:53:39 -0500 (EST) Cc: bugs@FreeBSD.org In-Reply-To: from "Andreas S. Wetzel" at Mar 6, 95 01:04:35 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1415 Sender: bugs-owner@FreeBSD.org Precedence: bulk Andreas S. Wetzel writes: > > Hi! > --- > > Eric M. Busalacchi writes: > > ] I did a sup 24 yesterday, and the proceeded to do a 'make > ] world'. I did a sup again this morning at 9:00am Eastern Standard > ] Time and when I went to compile my kernel I got two errors, the first had > ] to do with sound: > ] > [...] > > Since a few day's I have the same problem, when trying to compile the > kernel: > > loading kernel > tty.o: Definition of symbol `_ttydefchars' (multiply defined) > tcp_output.o: Definition of symbol `_tcp_outflags' (multiply defined) > tcp_subr.o: Definition of symbol `_tcp_outflags' (multiply defined) ld issue being fixed by Nate. > scsiconf.o: Undefined symbol `_scsi_cinit' referenced from text segment > scsiconf.o: Undefined symbol `_scsi_dinit' referenced from text segment > scsiconf.o: Undefined symbol `_scsi_tinit' referenced from text segment > scsiconf.o: More undefined symbol _scsi_dinit refs follow Rebuild usr/sbin/config and re-config your kernel > userconfig.o: Undefined symbol `_strncmp' referenced from text segment Rebuild libkern.a > ioconf.o: Undefined symbol `_sbintr' referenced from data segment > ioconf.o: Undefined symbol `_sbintr' referenced from data segment I don't know -- Peter Dufault Real Time Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 dufault@hda.com Fax: 508 433 5267 From owner-freebsd-bugs Mon Mar 6 00:26:23 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA26090 for bugs-outgoing; Mon, 6 Mar 1995 00:26:23 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id AAA26083 for ; Mon, 6 Mar 1995 00:26:05 -0800 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA02599; Mon, 6 Mar 1995 09:21:46 +0100 Received: by sax.sax.de (8.6.9/8.6.9-s1) with UUCP id JAA15703; Mon, 6 Mar 1995 09:21:26 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.9/8.6.9) id JAA04751; Mon, 6 Mar 1995 09:21:02 +0100 From: J Wunsch Message-Id: <199503060821.JAA04751@uriah.heep.sax.de> Subject: Re: FreeBSD Installation - Not To: MarloweN@aol.com Date: Mon, 6 Mar 1995 09:21:01 +0100 (MET) Cc: bugs@FreeBSD.org, XKY41771@genie.geis.com In-Reply-To: <950306013709_40511236@aol.com> from "MarloweN@aol.com" at Mar 6, 95 01:37:10 am Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 634 Sender: bugs-owner@FreeBSD.org Precedence: bulk As MarloweN@aol.com wrote: > Panic: Cannot mount > root Can you please describe what is happening _above_ the panic message? Which system version did you use? For version 2.0-RELEASE, the floppy disk driver had a bug that caused exactly your symptoms for (at least) any machine that has a NEC 72065B (or compatible) FDC chip. You will find something like fd0: hard error reading ... in the messages above the panic. This is fixed in newer versions, e.g. the 2.0-950210-SNAP. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-bugs Mon Mar 6 00:30:02 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA26153 for bugs-outgoing; Mon, 6 Mar 1995 00:30:02 -0800 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA26146; Mon, 6 Mar 1995 00:30:02 -0800 Date: Mon, 6 Mar 1995 00:30:02 -0800 Message-Id: <199503060830.AAA26146@freefall.cdrom.com> From: J Wunsch Reply-To: J Wunsch To: freebsd-bugs Subject: misc/233: CTM sometimes does not fully clean up internally In-Reply-To: Your message of Mon, 6 Mar 1995 09:15:22 +0100 <199503060815.JAA04706@uriah.heep.sax.de> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 233 >Category: misc >Synopsis: CTM sometimes does not fully clean up internally >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Mar 6 00:30:01 1995 >Originator: J Wunsch >Organization: >Release: FreeBSD 2.1.0-Development i386 >Environment: >Description: ctm(1) sometimes did not free up all used resources (open pipes and processes, heap memory). This happened whenever one of the passes ended prematurely, and it became very apparent when running it on a bunch of already applied deltas, resulting in a ``gunzip: resource temporarily unavailable'' due to the maxproc # exhausted. >How-To-Repeat: Run ctm(1) with a reasonable number of .gz input deltas and the default maxproc limit of 40. >Fix: Index: ctm.c =================================================================== RCS file: /usr/home/cvs/src/usr.sbin/ctm/ctm/ctm.c,v retrieving revision 1.8 diff -u -r1.8 ctm.c --- 1.8 1995/03/04 20:36:45 +++ ctm.c 1995/03/06 08:05:30 @@ -164,8 +164,8 @@ if(!p) rewind(f); - if((i=Pass1(f, applied))) - return i; + if((i=Pass1(f, applied))) + goto exit_and_close; if(!p) { rewind(f); @@ -187,16 +187,18 @@ if(i) { if((!Force) || (i & ~Exit_Forcible)) - return i; + goto exit_and_close; } if(CheckIt) { fprintf(stderr,"All checks out ok.\n"); - return Exit_Done; + i = Exit_Done; + goto exit_and_close; } i=Pass3(f); +exit_and_close: if(!p) { fclose(f); } else { >Audit-Trail: >Unformatted: From owner-freebsd-bugs Mon Mar 6 05:59:16 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id FAA05727 for bugs-outgoing; Mon, 6 Mar 1995 05:59:16 -0800 Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id FAA05721 for ; Mon, 6 Mar 1995 05:59:14 -0800 Received: by dg-rtp.dg.com (5.4R2.01/dg-rtp-v02) id AA25264; Mon, 6 Mar 1995 08:58:22 -0500 Received: from lakes (lakes [192.96.3.39]) by ponds.UUCP (8.6.9/8.6.5) with ESMTP id VAA15927; Sun, 5 Mar 1995 21:48:29 -0500 Received: (from rivers@localhost) by lakes (8.6.9/8.6.9) id VAA02588; Sun, 5 Mar 1995 21:57:36 -0500 Date: Sun, 5 Mar 1995 21:57:36 -0500 From: Thomas David Rivers Message-Id: <199503060257.VAA02588@lakes> To: hlew@genome.Stanford.EDU, starkhome!gene@sbstark.cs.sunysb.edu Subject: Re: 486 can't reboot with reboot or halt Cc: bugs@FreeBSD.org, genome.Stanford.EDU!hlew@sbstark.cs.sunysb.edu Sender: bugs-owner@FreeBSD.org Precedence: bulk > > > > On Thu, 9 Feb 1995, Gene Stark wrote: > > > >Hi! Has anyone had any problems with the reboot command or halt (and > > >then press a key to reboot) on a 486? > > > > I have seen this type of problem caused by improper jumpering for the > > CPU type on the motherboard, so that is something to check. > > > > - Gene Stark > > > > Yes, you are right. Thanks for your help. The 100 Mhz AMD jumpered as > an Intel DX4-100 was the source of the problem. Hmmm... I guess the AMD > CPU isn't an exact clone of the Intel one. > Hmmm... has anyone seen this problem with a 386? I've got a 386 that will simply say "syncing disks ...." and then just sit there.. (This is with 2.0R.) - Dave Rivers - From owner-freebsd-bugs Mon Mar 6 15:34:30 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id PAA22296 for bugs-outgoing; Mon, 6 Mar 1995 15:34:30 -0800 Received: from mail02.mail.aol.com (mail02.mail.aol.com [152.163.172.66]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id PAA22289 for ; Mon, 6 Mar 1995 15:34:26 -0800 From: MLDIERKER@aol.com Received: by mail02.mail.aol.com (1.37.109.11/16.2) id AA074192815; Mon, 6 Mar 1995 18:33:35 -0500 Date: Mon, 6 Mar 1995 18:33:35 -0500 Message-Id: <950306183335_41165370@aol.com> To: bugs@freebsd.org Subject: Adaptec 2940 Support ? Sender: bugs-owner@freebsd.org Precedence: bulk Hi, I am trying to run FreeBSD 2.x on a Packard Bell AXCEL 120CD with an Adaptec 2940 SCSI Card. I have downloaded the latest snapshot boot floppy image (from 950210-SNAP) and tried to boot. The PCI bus and Adaptec card are recognized, and the sequencer code is downloaded to the card. The next message I get is somehting like: "Waiting for SCSI bus to settle", after which the system just hangs. I need to hard reboot to get it back. The first time to reboot the Adaptec BIOS can not find the SCSI disk, and I need to reboot again - afterwards I can bring up DOS & Windows. A summary of my system configuration is as follows: System Summary CONFIGURATION SUMMARY Ultra-high Performance PC Intel Pentium, 60 mHz Integrated NPU 8 MB Memory BIOS Mfr: AMI Bus: ISA, PCI, SCSI VESA (2048K) VGA Color 1.44M(3 1/2") Floppy 425 MB Hard Drive 113 MB Available 1398 MB Hard Drive 317 MB Available 3 COM Ports 1 LPT Port PS/2 (2 button) Mouse Sound Blaster Compatible CD-ROM Drive Modem/FAX NETBIOS Network Please let me know if I can provide you with any other information. Thanks, mike dierker From owner-freebsd-bugs Tue Mar 7 02:14:47 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id CAA11847 for bugs-outgoing; Tue, 7 Mar 1995 02:14:47 -0800 Received: from gaja.ipan.lublin.pl (gaja.ipan.lublin.pl [193.59.19.151]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id CAA11818 for ; Tue, 7 Mar 1995 02:13:29 -0800 Received: (from henryk@localhost) by gaja.ipan.lublin.pl (8.6.8/8.6.6) id LAA00257 for freebsd-bugs@freebsd.org; Tue, 7 Mar 1995 11:32:11 +0100 Date: Tue, 7 Mar 1995 11:32:11 +0100 From: Henryk Sobczuk Message-Id: <199503071032.LAA00257@gaja.ipan.lublin.pl> To: freebsd-bugs@FreeBSD.org Subject: QIC-80 problem Sender: bugs-owner@FreeBSD.org Precedence: bulk Hi, I have a 486/66 with FreeBSD. I just bought a QIC 80 streamer and ftp'd an ft filter. It works quite well with tar but only with "B" option. When i try to use a "z" option for tar it hangs after some time. It would be nice to tar data in a compressed form. Is there anybody who knows how to deal with it? Regards, Henryk henryk@gaja.ipan.lublin.pl From owner-freebsd-bugs Tue Mar 7 08:51:51 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA18258 for bugs-outgoing; Tue, 7 Mar 1995 08:51:51 -0800 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id IAA18252 for ; Tue, 7 Mar 1995 08:51:49 -0800 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA24708; Tue, 7 Mar 95 09:43:57 MST From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9503071643.AA24708@cs.weber.edu> Subject: Re: QIC-80 problem To: henryk@gaja.ipan.lublin.pl (Henryk Sobczuk) Date: Tue, 7 Mar 95 9:43:56 MST Cc: freebsd-bugs@FreeBSD.org In-Reply-To: <199503071032.LAA00257@gaja.ipan.lublin.pl> from "Henryk Sobczuk" at Mar 7, 95 11:32:11 am X-Mailer: ELM [version 2.4dev PL52] Sender: bugs-owner@FreeBSD.org Precedence: bulk > I have a 486/66 with FreeBSD. > I just bought a QIC 80 streamer and ftp'd an ft filter. > It works quite well with tar but only with "B" option. > When i try to use a "z" option for tar it hangs after > some time. > > It would be nice to tar data in a compressed form. > > Is there anybody who knows how to deal with it? Precompress the data. Since the interface used by floppy tape drives is the floppy disk controller, and since the floppy disk controller does not have a buffer (or a detectable one, if you lucked into one of the new chips that almost no one uses) this means that it is sensitive in the extreme to missed I/O. The additional overhead of running the compressor gives it the opportunity to miss a communications window, and bam, you are screwed. If you want commpressed data on the tape, you must not try to compress it at the same time. Alternately, the kernel timer code, if used for an outcall on a retriggerable one shot, could be used to drive the floppy tape effectively in real time as a logical kernel thread at timer interrupt level. This would require fixing some timer issues that nobody agrees with me that they should be fixed and rewriting the floppy tape driver about 20%. If in the process, you added a 16k double buffer from user space, you would effectively close the 20ms and 200ms timing windows on getting commands to the tape drive in time, and you would probably be ominated for godhood (but since only 35% of all tape drives on UNIX class machines are floppy tapes, you'd probably lose out to Julian and Peter, who have been doing the SCSI stuff). Utilizing fixed timer code would mean that the driver would not need to buzz-loop to hit acceptable timing on the 20ms window, and would not depend on the user space process accessing the device within 20 full quanta (your compression problem) to hit the 200ms window. Closing the timing window using double buffering so you can repeat a write command instead of streaming if data is unavailable means that sometimes you wouldn't stream, but that's better than screwing up. Anything that works is better than anything that doesn't. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-bugs Tue Mar 7 09:16:04 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA19067 for bugs-outgoing; Tue, 7 Mar 1995 09:16:04 -0800 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id JAA19061 for ; Tue, 7 Mar 1995 09:16:02 -0800 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA24929; Tue, 7 Mar 95 10:09:39 MST From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9503071709.AA24929@cs.weber.edu> Subject: Reply to: Re: Reply to: Re: Problems with 950210-SNAP (fwd) To: bugs@FreeBSD.org Date: Tue, 7 Mar 95 10:09:38 MST X-Mailer: ELM [version 2.4dev PL52] Sender: bugs-owner@FreeBSD.org Precedence: bulk Forwarded message: > From Dave_Toth@DGC.ceo.dg.com Tue Mar 7 08:29:13 1995 > Date: Tue, 7 Mar 95 10:00:15 est > From: Dave_Toth@DGC.ceo.dg.com > Message-Id: <9503071500.AS00037@rtp41.rtp.dg.com> > To: (Terry Lambert) terry@cs.weber.edu > Subject: Reply to: Re: Reply to: Re: Problems with 950210-SNAP > > CEO comments: > From: Dave Toth:DGC > Date: ## 03/07/95 10:00 ## > continued... > > 2. AHA2940 locks on "waiting for devices to settle" > > I've found that enabling the "Video BIOS cacheable" option on the PC > causes the boot to lock 100% of the time at the above point. > Disabling ALL shadowing and cache results in lousy performance, but > better boot reliability... with everything disabled boot only locks > at the AHA2940 initialization about once every 10 or so reboots. > > Preceeding Message: > From: (Terry Lambert) terry@cs.weber.edu:dg-smtp > Date: ## 03/06/95 21:05 ## > See document for message. > > > > From owner-freebsd-bugs Tue Mar 7 12:04:34 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA23612 for bugs-outgoing; Tue, 7 Mar 1995 12:04:34 -0800 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id MAA23606 for ; Tue, 7 Mar 1995 12:04:31 -0800 Received: by halloran-eldar.lcs.mit.edu; id AA09995; Tue, 7 Mar 1995 15:02:42 -0500 Date: Tue, 7 Mar 1995 15:02:42 -0500 From: Garrett Wollman Message-Id: <9503072002.AA09995@halloran-eldar.lcs.mit.edu> To: henryk@gaja.ipan.lublin.pl (Henryk Sobczuk) Cc: freebsd-bugs@FreeBSD.org Subject: Re: QIC-80 problem In-Reply-To: <9503071643.AA24708@cs.weber.edu> References: <199503071032.LAA00257@gaja.ipan.lublin.pl> <9503071643.AA24708@cs.weber.edu> Sender: bugs-owner@FreeBSD.org Precedence: bulk >> I have a 486/66 with FreeBSD. >> I just bought a QIC 80 streamer and ftp'd an ft filter. >> It works quite well with tar but only with "B" option. >> When i try to use a "z" option for tar it hangs after >> some time. >> >> It would be nice to tar data in a compressed form. >> >> Is there anybody who knows how to deal with it? You need another option to `tar': --block-compress block the output of compression program for tapes From owner-freebsd-bugs Tue Mar 7 13:46:27 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id NAA27141 for bugs-outgoing; Tue, 7 Mar 1995 13:46:27 -0800 Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.20.4]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id NAA27129 for ; Tue, 7 Mar 1995 13:46:21 -0800 Received: by brasil.moneng.mei.com (4.1/SMI-4.1) id AA12068; Tue, 7 Mar 95 15:43:39 CST From: Joe Greco Message-Id: <9503072143.AA12068@brasil.moneng.mei.com> Subject: Re: 2.0R latest boot floppy bug(?) To: jhs@regent.e-technik.tu-muenchen.de (Julian Howard Stacey) Date: Tue, 7 Mar 1995 15:43:39 -0600 (CST) Cc: bde@zeta.org.au, bugs@FreeBSD.org In-Reply-To: <199503010101.CAA07329@vector.eikon.e-technik.tu-muenchen.de> from "Julian Howard Stacey" at Mar 1, 95 02:01:29 am X-Mailer: ELM [version 2.4beta PL9] Content-Type: text Content-Length: 1615 Sender: bugs-owner@FreeBSD.org Precedence: bulk > Re. > ---- > From: Bruce Evans > > >Fatal trap 18: integer divide fault while in kernel mode > > Did it once work? > > Apparently the geometry obtained from the BIOS is unreliable. > It seems to be 1023 cylinders (the driver adds 2 for bogus > reasons), 256 heads (physically impossible) and 0 sectors > (also physically impossible). > ------ > I have seen all manner of weird bugs since trying (& failing ) to install on > a friends 386 + 8M + FPU, ISA, no cd, no ether, no exotic hardware, > I have seen page fault in kernel mode, > I have seen dos fdisk (yeah sure, not ours, but part of my problem) > no able to cope with > 1023 cyls, > checkit (a dos .exe pack) also cant cope > 1023 > I have seen my ide maxtor repeatedly incremented from 1648 cyls to > about 1652 After repeatedly trying different things, including several different motherboards (one was a 486DX2/80 with *very* *recent* BIOS), I have temporarily given up hope for this poor little RLL disk. Since it works fine if you just go and use it, I am thinking that a possible "fix" for me would be to hardwire in the C/H/S values... somewhere... All of the systems come up with garbage for the probe values. I don't know for sure that the BIOS is lying, and find it hard to believe that several different BIOS'es would lie in the same manner. But I don't have time to futz with it for a few weeks, I think. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 From owner-freebsd-bugs Tue Mar 7 14:24:31 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA28285 for bugs-outgoing; Tue, 7 Mar 1995 14:24:31 -0800 Received: from deadline.snafu.de (deadline.snafu.de [194.64.64.181]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id OAA28269 for ; Tue, 7 Mar 1995 14:24:02 -0800 Received: by deadline.snafu.de id m0rm7ep-000DXEC; Tue, 7 Mar 95 23:23 MET (/\oo/\ Smail3.1.29.1 #29.1) Message-Id: From: root@deadline.snafu.de (Andreas S. Wetzel) Subject: Strange hangups when building shared m library ?! To: freebsd-bugs@FreeBSD.org Date: Tue, 7 Mar 1995 23:23:10 +0100 (MET) Organization: -D-E-A-D-L-I-N-E- Public access UN*X system - 13347 Berlin. X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4135 Sender: bugs-owner@FreeBSD.org Precedence: bulk Hi! --- Recently I found myself messed up with a crashed or hung up system while doing a "make world" on the current sources (07 Mar). building shared m library (version 2.0) e_acos.so: Definition of symbol `___ieee754_acos' (multiply defined) e_asin.so: Definition of symbol `___ieee754_asin' (multiply defined) e_atan2.so: Definition of symbol `___ieee754_atan2' (multiply defined) e_exp.so: Definition of symbol `___ieee754_exp' (multiply defined) e_fmod.so: Definition of symbol `___ieee754_fmod' (multiply defined) e_log.so: Definition of symbol `___ieee754_log' (multiply defined) e_log10.so: Definition of symbol `___ieee754_log10' (multiply defined) e_remainder.so: Definition of symbol `___ieee754_remainder' (multiply defined) e_scalb.so: Definition of symbol `___ieee754_scalb' (multiply defined) e_sqrt.so: Definition of symbol `___ieee754_sqrt' (multiply defined) s_atan.so: Definition of symbol `_atan' (multiply defined) s_ceil.so: Definition of symbol `_ceil' (multiply defined) s_copysign.so: Definition of symbol `_copysign' (multiply defined) s_cos.so: Definition of symbol `_cos' (multiply defined) s_finite.so: Definition of symbol `_finite' (multiply defined) s_floor.so: Definition of symbol `_floor' (multiply defined) s_ilogb.so: Definition of symbol `_ilogb' (multiply defined) s_log1p.so: Definition of symbol `_log1p' (multiply defined) s_logb.so: Definition of symbol `_logb' (multiply defined) s_rint.so: Definition of symbol `_rint' (multiply defined) s_scalbn.so: Definition of symbol `_scalbn' (multiply defined) s_significand.so: Definition of symbol `_significand' (multiply defined) s_sin.so: Definition of symbol `_sin' (multiply defined) s_tan.so: Definition of symbol `_tan' (multiply defined) e_acos.so: Definition of symbol `___ieee754_acos' (multiply defined) e_asin.so: Definition of symbol `___ieee754_asin' (multiply defined) e_atan2.so: Definition of symbol `___ieee754_atan2' (multiply defined) e_exp.so: Definition of symbol `___ieee754_exp' (multiply defined) e_fmod.so: Definition of symbol `___ieee754_fmod' (multiply defined) e_log.so: Definition of symbol `___ieee754_log' (multiply defined) e_log10.so: Definition of symbol `___ieee754_log10' (multiply defined) e_remainder.so: Definition of symbol `___ieee754_remainder' (multiply defined) e_scalb.so: Definition of symbol `___ieee754_scalb' (multiply defined) e_sqrt.so: Definition of symbol `___ieee754_sqrt' (multiply defined) s_atan.so: Definition of symbol `_atan' (multiply defined) s_ceil.so: Definition of symbol `_ceil' (multiply defined) s_copysign.so: Definition of symbol `_copysign' (multiply defined) s_cos.so: Definition of symbol `_cos' (multiply defined) s_finite.so: Definition of symbol `_finite' (multiply defined) s_floor.so: Definition of symbol `_floor' (multiply defined) s_ilogb.so: Definition of symbol `_ilogb' (multiply defined) s_log1p.so: Definition of symbol `_log1p' (multiply defined) s_logb.so: Definition of symbol `_logb' (multiply defined) s_rint.so: Definition of symbol `_rint' (multiply defined) s_scalbn.so: Definition of symbol `_scalbn' (multiply defined) s_significand.so: Definition of symbol `_significand' (multiply defined) s_sin.so: Definition of symbol `_sin' (multiply defined) s_tan.so: Definition of symbol `_tan' (multiply defined) *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. After saying so, the process hangs up and an attempt to get a process list of the system using a "ps" also hangs up. The first time I tried this, the system completely crashed and rebooted. Any suggestions ? Mickey -- ================================================================================ DIGESTED BENEFACTORS WHOSE | Andreas S. Wetzel | -D-E-A-D-L-I-N-E- SILENCE DEAFENS ANYTHING | Utrechter Strasse 41 | ALL OF WHOM DECEASE AND | 13347 Berlin | <+4930> 455 19 57 Data MISS TO PIERCE A POINT | Germany | <+4930> 456 81 68 Voice ================================================================================ E-mail: mickey@deadline.snafu.de WWW: http://deadline.snafu.de/ From owner-freebsd-bugs Tue Mar 7 16:45:31 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id QAA01454 for bugs-outgoing; Tue, 7 Mar 1995 16:45:31 -0800 Received: from mail02.mail.aol.com (mail02.mail.aol.com [152.163.172.66]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id QAA01448 for ; Tue, 7 Mar 1995 16:45:29 -0800 From: MarloweN@aol.com Received: by mail02.mail.aol.com (1.37.109.11/16.2) id AA201253474; Tue, 7 Mar 1995 19:44:34 -0500 Date: Tue, 7 Mar 1995 19:44:34 -0500 Message-Id: <950307194426_42441170@aol.com> To: bugs@FreeBSD.org Subject: FreeBSD Installation - Not Sender: bugs-owner@FreeBSD.org Precedence: bulk Here is more info for anyone who might help: Environment: I have just added a second hard drive. The first contains one primary active DOS partition which is full of Windows and apps. The second drive now includes first the FreeBSD partition followed by one DOS extended partition. (When I go into Fdisk to set up the BSD area, the DOS partition does not appear anywhere on the Disklabel screen. Is that significant?) So what messages do I see when booting? FreeBSD Booting @ 0x10000: . . .{ memory described } Boot: hd(1,a)/kernel Booting wd(0,a) . . . Text= . . . . Testing memory (8MB) . . . copyright statement . . . Regents of U of C. All rights reserved FreeBSD 2.0 Rel #2 Nov 22,1994 . . { I . can't . read . this . fast! } From owner-freebsd-bugs Tue Mar 7 17:15:48 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id RAA02026 for bugs-outgoing; Tue, 7 Mar 1995 17:15:48 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id RAA02014 for ; Tue, 7 Mar 1995 17:15:34 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id LAA30812; Wed, 8 Mar 1995 11:13:17 +1000 Date: Wed, 8 Mar 1995 11:13:17 +1000 From: Bruce Evans Message-Id: <199503080113.LAA30812@godzilla.zeta.org.au> To: henryk@gaja.ipan.lublin.pl, terry@cs.weber.edu Subject: Re: QIC-80 problem Cc: freebsd-bugs@FreeBSD.org Sender: bugs-owner@FreeBSD.org Precedence: bulk >Alternately, the kernel timer code, if used for an outcall on >a retriggerable one shot, could be used to drive the floppy >tape effectively in real time as a logical kernel thread at >timer interrupt level. >This would require fixing some timer issues that nobody agrees >with me that they should be fixed and rewriting the floppy tape >driver about 20%. I recently noticed that the standard timer code doesn't guarantee any upper bounds for timeouts. softclock() runs at a lower priority than all hardware interrupts. It is possible for a fast device on a slow interface to keep the system busy handling interrupts so that softclock() never runs. A fast EIDE drive using the old IDE interface can probably do this (unless the system isn't programmed well enough to keep the data streaming :-]). The one shot timer would have to be handled at a higher priority than softclock() or its resolution would be lost. It wouldn't necessarily work to use the same priority as the device that requested the timeout. The ft priority would have to be higher than the wd priority to avoid the above problem. This would require large reorganizations because the ft priority and the wd priority are currently identical (bio). Bruce From owner-freebsd-bugs Tue Mar 7 17:45:54 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id RAA02785 for bugs-outgoing; Tue, 7 Mar 1995 17:45:54 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id RAA02779 for ; Tue, 7 Mar 1995 17:45:46 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id LAA31369; Wed, 8 Mar 1995 11:44:39 +1000 Date: Wed, 8 Mar 1995 11:44:39 +1000 From: Bruce Evans Message-Id: <199503080144.LAA31369@godzilla.zeta.org.au> To: freebsd-bugs@FreeBSD.org, root@deadline.snafu.de Subject: Re: Strange hangups when building shared m library ?! Sender: bugs-owner@FreeBSD.org Precedence: bulk >Recently I found myself messed up with a crashed or hung up system >while doing a "make world" on the current sources (07 Mar). >building shared m library (version 2.0) >e_acos.so: Definition of symbol `___ieee754_acos' (multiply defined) >... Fixed a minute ago. >After saying so, the process hangs up and an attempt to get a process list of >the system using a "ps" also hangs up. >The first time I tried this, the system completely crashed and rebooted. This is a different problem. It may have been fixed a few hours ago. There were bugs in vm reference counting. Bruce From owner-freebsd-bugs Tue Mar 7 19:25:15 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id TAA04843 for bugs-outgoing; Tue, 7 Mar 1995 19:25:15 -0800 Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id TAA04827 for ; Tue, 7 Mar 1995 19:25:08 -0800 Received: by dg-rtp.dg.com (5.4R2.01/dg-rtp-v02) id AA20022; Tue, 7 Mar 1995 22:23:29 -0500 Received: from lakes (lakes [192.96.3.39]) by ponds.UUCP (8.6.9/8.6.5) with ESMTP id MAA02982; Mon, 6 Mar 1995 12:39:52 -0500 Received: (from rivers@localhost) by lakes (8.6.9/8.6.9) id MAA00617; Mon, 6 Mar 1995 12:48:30 -0500 Date: Mon, 6 Mar 1995 12:48:30 -0500 From: Thomas David Rivers Message-Id: <199503061748.MAA00617@lakes> To: jkh@FreeBSD.org, terry@cs.weber.edu Subject: Re: Bug. Cc: bugs@FreeBSD.org, dtynan@corrib.ilo.dec.com Sender: bugs-owner@FreeBSD.org Precedence: bulk terry@cs.weber.edu writes: > > > I have a 'slipd' process which fires off a SLIP connection at preset times, > > > and monitors the throughput using a weighted average thingy. When the > > > activity drops below a certain threshold for a certain time, it kills the > > > link. Very handy. RU interested in the kernel diffs?? > > > > Uh, no! That all sounds really gross, thank you very much! :-) > > This is of interest to those of us doomed to metered rate service > providers for anything over a minimum amount of time. Like all of us > in US West's area who are considering the new ISDN tarrif. > > > Terry Lambert > terry@cs.weber.edu Yes - I'm in *exactly* that position (although, he says jealously, not with ISDN, just SLIP.) I've been thinking about hacking shell scripts, etc... Another alternative is to simply set the modem to drop the line after one minute of non-activity, which is what I had planned to do. Anyway - please send me your stuff... - Dave Rivers - From owner-freebsd-bugs Tue Mar 7 20:27:31 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id UAA07526 for bugs-outgoing; Tue, 7 Mar 1995 20:27:31 -0800 Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id UAA07506 for ; Tue, 7 Mar 1995 20:27:24 -0800 Received: by dg-rtp.dg.com (5.4R2.01/dg-rtp-v02) id AA17750; Tue, 7 Mar 1995 23:25:56 -0500 Received: from lakes (lakes [192.96.3.39]) by ponds.UUCP (8.6.9/8.6.5) with ESMTP id VAA25689; Tue, 7 Mar 1995 21:14:17 -0500 Received: (from rivers@localhost) by lakes (8.6.9/8.6.9) id VAA02740; Tue, 7 Mar 1995 21:23:41 -0500 Date: Tue, 7 Mar 1995 21:23:41 -0500 From: Thomas David Rivers Message-Id: <199503080223.VAA02740@lakes> To: allen@ripley.radio.net, bugs@FreeBSD.org Subject: Re: Better check NFS server as well Sender: bugs-owner@FreeBSD.org Precedence: bulk > > It complains on startup about not finding /var/db/mountdtab. I get this message from 2.0R - in case anyone else hasn't seen it there. > > Also, check /etc/termcap. It is a symbolic link to something non- > existent in /usr/tmp/... > - Dave R. - From owner-freebsd-bugs Tue Mar 7 20:28:58 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id UAA07634 for bugs-outgoing; Tue, 7 Mar 1995 20:28:58 -0800 Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id UAA07624 for ; Tue, 7 Mar 1995 20:28:50 -0800 Received: by dg-rtp.dg.com (5.4R2.01/dg-rtp-v02) id AA19168; Tue, 7 Mar 1995 23:27:33 -0500 Received: from lakes (lakes [192.96.3.39]) by ponds.UUCP (8.6.9/8.6.5) with ESMTP id VAA25779; Tue, 7 Mar 1995 21:19:50 -0500 Received: (from rivers@localhost) by lakes (8.6.9/8.6.9) id VAA02778; Tue, 7 Mar 1995 21:29:13 -0500 Date: Tue, 7 Mar 1995 21:29:13 -0500 From: Thomas David Rivers Message-Id: <199503080229.VAA02778@lakes> To: allen@ripley.radio.net, gary@palmer.demon.co.uk Subject: Re: Better check NFS server as well Cc: bugs@FreeBSD.org Sender: bugs-owner@FreeBSD.org Precedence: bulk > > > It complains on startup about not finding /var/db/mountdtab. > > That's not a bug - it won't find it the first time as there has never been > a mountdtab 'cos NFSD has never been run. I don't think it's worth shipping > an empty just to quiet that one message. > Hmmm... I have nfs_client and nfs_server set to "YES" in /etc/netstart. I also have a file /etc/exports... And, as evidenced in the screen clipping, I'm running nfsd, etc.. So, my question is why to I continue to get the message? (At every reboot.) [ponds.water.net]$ ls -l /etc/exports -rw-r--r-- 1 root wheel 47 Dec 16 12:50 /etc/exports [ponds.water.net]$ /bin/ps -gax | grep nfsd 71 ?? IWs 0:00.06 nfsd-master (nfsd) 73 ?? IW 0:00.01 nfsd-srv (nfsd) 74 ?? IW 0:00.03 nfsd-srv (nfsd) 75 ?? IW 0:00.04 nfsd-srv (nfsd) 76 ?? IW 0:00.04 nfsd-srv (nfsd) 25770 p0 S+ 0:00.14 grep nfsd [ponds.water.net]$ - Dave Rivers - From owner-freebsd-bugs Tue Mar 7 21:09:48 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA12452 for bugs-outgoing; Tue, 7 Mar 1995 21:09:48 -0800 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id VAA12424 for ; Tue, 7 Mar 1995 21:09:40 -0800 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id VAA27234; Tue, 7 Mar 1995 21:07:55 -0800 From: "Rodney W. Grimes" Message-Id: <199503080507.VAA27234@gndrsh.aac.dev.com> Subject: Re: Better check NFS server as well To: ponds!rivers@dg-rtp.dg.com (Thomas David Rivers) Date: Tue, 7 Mar 1995 21:07:55 -0800 (PST) Cc: allen@ripley.radio.net, bugs@FreeBSD.org In-Reply-To: <199503080223.VAA02740@lakes> from "Thomas David Rivers" at Mar 7, 95 09:23:41 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1208 Sender: bugs-owner@FreeBSD.org Precedence: bulk > > > > > It complains on startup about not finding /var/db/mountdtab. > > I get this message from 2.0R - in case anyone else hasn't seen it there. > > > > > Also, check /etc/termcap. It is a symbolic link to something non- > > existent in /usr/tmp/... > > This is caused by the following change made by UCB for some reason to the mountd sources: [This is a clip out of a very large diff] 1.1.5.1 sources: ! if (((mlfile = fopen(_PATH_RMOUNTLIST, "r")) == NULL) && ! ((mlfile = fopen(_PATH_RMOUNTLIST, "w")) == NULL)) { ! syslog(LOG_WARNING, "Can't open %s", _PATH_RMOUNTLIST); 2.1-current sources: ! if ((mlfile = fopen(_PATH_RMOUNTLIST, "r")) == NULL) { ! syslog(LOG_ERR, "Can't open %s", _PATH_RMOUNTLIST); This may have been done as more than likely allowing mountd to create the file ends up with a file that has the wrong modes on it. [Having a world readable /var/db/mountdtab is not always a very good idea, it tells hackers where to go to attack you via NFS :-)] > - Dave R. - -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-bugs Tue Mar 7 23:31:55 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id XAA16356 for bugs-outgoing; Tue, 7 Mar 1995 23:31:55 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id XAA16347 for ; Tue, 7 Mar 1995 23:31:30 -0800 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA09473; Wed, 8 Mar 1995 08:20:29 +0100 Received: by sax.sax.de (8.6.9/8.6.9-s1) with UUCP id IAA04320; Wed, 8 Mar 1995 08:20:06 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.9/8.6.9) id IAA02037; Wed, 8 Mar 1995 08:03:36 +0100 From: J Wunsch Message-Id: <199503080703.IAA02037@uriah.heep.sax.de> Subject: Re: FreeBSD Installation - Not To: MarloweN@aol.com Date: Wed, 8 Mar 1995 08:03:35 +0100 (MET) Cc: bugs@FreeBSD.org In-Reply-To: <950307194426_42441170@aol.com> from "MarloweN@aol.com" at Mar 7, 95 07:44:34 pm Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 937 Sender: bugs-owner@FreeBSD.org Precedence: bulk As MarloweN@aol.com wrote: > > ... The second drive now includes first the > FreeBSD partition > followed by one DOS extended partition. (When I go into Fdisk to set up the > BSD area, the > DOS partition does not appear anywhere on the Disklabel screen. Is that > significant?) I don't think so, AFAIK the FreeBSD fdisk does only show primary partitions. > . { I > . can't > . read > . this > . fast! } > But you've been the guy with ``panic: cannot mount root'', haven't you? So the interesting lines must be to see when the panic happens. I'm not interested (not as much) in all the kernel messages that scroll by, only in that stuff that you can see at panic time. Especially any complaints/errors just above the panic. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-bugs Wed Mar 8 00:00:37 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA16829 for bugs-outgoing; Wed, 8 Mar 1995 00:00:37 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id AAA16821 for ; Wed, 8 Mar 1995 00:00:29 -0800 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA09451; Wed, 8 Mar 1995 08:20:06 +0100 Received: by sax.sax.de (8.6.9/8.6.9-s1) with UUCP id IAA04317; Wed, 8 Mar 1995 08:20:05 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.9/8.6.9) id HAA02015; Wed, 8 Mar 1995 07:58:33 +0100 From: J Wunsch Message-Id: <199503080658.HAA02015@uriah.heep.sax.de> Subject: Re: QIC-80 problem To: terry@cs.weber.edu (Terry Lambert) Date: Wed, 8 Mar 1995 07:58:33 +0100 (MET) Cc: henryk@gaja.ipan.lublin.pl, freebsd-bugs@FreeBSD.org In-Reply-To: <9503071643.AA24708@cs.weber.edu> from "Terry Lambert" at Mar 7, 95 09:43:56 am Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1229 Sender: bugs-owner@FreeBSD.org Precedence: bulk As Terry Lambert wrote: > > > I have a 486/66 with FreeBSD. > > I just bought a QIC 80 streamer and ftp'd an ft filter. > > It works quite well with tar but only with "B" option. > > When i try to use a "z" option for tar it hangs after > > some time. > Precompress the data. > > Since the interface used by floppy tape drives is the floppy disk > controller, and since the floppy disk controller does not have a > buffer (or a detectable one, if you lucked into one of the new > chips that almost no one uses) this means that it is sensitive > in the extreme to missed I/O. [A very long explanation deleted.] Terry, you might sometimes look as well at the recipient address. This one ended up in .pl, so i'm afraid your fine explanation might be a bit hard to understand... (it's even hard to understand for me, even after following this list for a long time now). But speaking of double-buffering, it should be possible to solve the problem by piping it through a program called ``team'', since it does N-buffering. Why did nobody make a FreeBSD port for ``team'' by now? ;-) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-bugs Wed Mar 8 00:38:49 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA17622 for bugs-outgoing; Wed, 8 Mar 1995 00:38:49 -0800 Received: from gaja.ipan.lublin.pl (gaja.ipan.lublin.pl [193.59.19.151]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id AAA17616 for ; Wed, 8 Mar 1995 00:38:38 -0800 Received: (from henryk@localhost) by gaja.ipan.lublin.pl (8.6.8/8.6.6) id JAA02709 for freebsd-bugs@freebsd.org; Wed, 8 Mar 1995 09:58:25 +0100 Date: Wed, 8 Mar 1995 09:58:25 +0100 From: Henryk Sobczuk Message-Id: <199503080858.JAA02709@gaja.ipan.lublin.pl> To: freebsd-bugs@FreeBSD.org Subject: QIC-80 problem Sender: bugs-owner@FreeBSD.org Precedence: bulk Ones I wrote: > > > I have a 486/66 with FreeBSD. > > I just bought a QIC 80 streamer and ftp'd an ft filter. > > It works quite well with tar but only with "B" option. > > When i try to use a "z" option for tar it hangs after > > some time. thanks for explaining me some aspects of my problem with QIC-80. I will try a few proposed methods to overcome the problem. Especially thanks to Terry Lambert for his deep explanation. I am not able to understand all the aspects of this explanation and in this sense I agree with J"org Wunsch who writes: >Terry, you might sometimes look as well at the recipient address. >This one ended up in .pl, so i'm afraid your fine explanation might be >a bit hard to understand... (it's even hard to understand for me, even >after following this list for a long time now) >From the other hand I fill this comment is a little bit unpolite. Henryk henryk@gaja.ipan.lublin.pl From owner-freebsd-bugs Wed Mar 8 02:39:38 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id CAA21570 for bugs-outgoing; Wed, 8 Mar 1995 02:39:38 -0800 Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id CAA21564; Wed, 8 Mar 1995 02:39:36 -0800 Received: from ilonet.ilo.dec.com by inet-gw-2.pa.dec.com (5.65/24Feb95) id AA05272; Wed, 8 Mar 95 02:34:35 -0800 Received: by ilonet.ilo.dec.com (5.65/MS-012594); id AA23807; Wed, 8 Mar 1995 10:36:34 GMT Received: (from dtynan@localhost) by corrib.ilo.dec.com (8.6.8/8.6.6) id KAA10197; Wed, 8 Mar 1995 10:34:22 GMT Date: Wed, 8 Mar 1995 10:34:22 GMT From: Dermot Tynan Message-Id: <199503081034.KAA10197@corrib.ilo.dec.com> To: jkh@FreeBSD.org, ponds!rivers@dg-rtp.dg.com, terry@cs.weber.edu Subject: Re: Bug. Cc: bugs@FreeBSD.org, dtynan@corrib.ilo.dec.com Sender: bugs-owner@FreeBSD.org Precedence: bulk > Yes - I'm in *exactly* that position (although, he says jealously, not > with ISDN, just SLIP.) > > I've been thinking about hacking shell scripts, etc... > > Another alternative is to simply set the modem to drop the line after > one minute of non-activity, which is what I had planned to do. > > Anyway - please send me your stuff... Well, I now have the thing running under FreeBSD-2.0 (SNAP 950210). I noticed an inconsistency in the SLIP/PPP network stuff in that the slip code keeps the byte count using sc_if.if_obytes (or something like that), whereas the PPP stuff has an entry in the sc structure along the lines of sc_bytessent. I added two new 'ioctls' to slip.h to return the bytes sent and the bytes received. I could probably have gone the same way as slstat but that required considerably more work and wasn't as clean an interface. Right now, slipd doesn't handle weird exceptions too well, and needs to be improved. Also, I want to use hylafax (aka flexfax) on the same line, and have an incoming getty, so I need to follow the UUCP convention for locking (not the greatest solution, as I remember). One other thing, slipd uses a library of mine called 'varlib'. All the stuff I write uses this library. It is a generic way of configuring applications and utilities, somewhat similar to the X-defaults stuff. The 'slipd' process reads a configuration file to determine the number to call, the login name and the password, as well as other things such as the decay algorithm, etc. The daemon is a long way from being a really general purpose utility, and has stuff hard-coded for Ireland Online. It was written purely for my own purposes. Anyway, when I iron out the remaining issues, I'll forward it to Jordan, who can throw it in the contrib section or something, along with varlib. - Der From owner-freebsd-bugs Wed Mar 8 08:41:10 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA18812 for bugs-outgoing; Wed, 8 Mar 1995 08:41:10 -0800 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id IAA18806 for ; Wed, 8 Mar 1995 08:41:08 -0800 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA00803; Wed, 8 Mar 95 09:33:49 MST From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9503081633.AA00803@cs.weber.edu> Subject: Re: QIC-80 problem To: bde@zeta.org.au (Bruce Evans) Date: Wed, 8 Mar 95 9:33:49 MST Cc: freebsd-bugs@FreeBSD.org In-Reply-To: <199503080113.LAA30812@godzilla.zeta.org.au> from "Bruce Evans" at Mar 8, 95 11:13:17 am X-Mailer: ELM [version 2.4dev PL52] Sender: bugs-owner@FreeBSD.org Precedence: bulk > I recently noticed that the standard timer code doesn't guarantee any > upper bounds for timeouts. softclock() runs at a lower priority than > all hardware interrupts. It is possible for a fast device on a slow > interface to keep the system busy handling interrupts so that > softclock() never runs. A fast EIDE drive using the old IDE interface > can probably do this (unless the system isn't programmed well enough to > keep the data streaming :-]). > > The one shot timer would have to be handled at a higher priority than > softclock() or its resolution would be lost. It wouldn't necessarily > work to use the same priority as the device that requested the timeout. > The ft priority would have to be higher than the wd priority to avoid > the above problem. This would require large reorganizations because > the ft priority and the wd priority are currently identical (bio). Right; putting the timer at a high priority is one of the things which is needed. Putting the floppy at nearly the highest priority is only logical, given that it has no buffers. A good example of "the right" priority levels is available by examining the SMP SCO Xenix (Corrollary version). Basically, any interface that doesn't have buffers on its I/O should be higher priority that any interface that does. I'd be tempted to put the floppy at just below the timer priority itself, and multithread things at a real low granularity -- ideally the buzz-loops in device drivers should be timer scheduled events, and any other approach to scheduling will have either everything running at the timer priority or will require helper processes like "update" to make things work. A real gross hack. When you consider wd vs ft/fd priority, you also need to consider that much of the I/O wait in the user program is reading from, for instance, the wd (or some other disk driver) to do the tape write in the first place. Unfortunately, I don't know of a software method of detecting the most offensive wd interface, an IDE without buffer chips on it... the only thing I can thing of is trying to run BSD and having it fail on you. 8-). The first thing one should do, probably, is to get the floppy tape reliability divorced from the need for a program in user space to get its quantum for it to be able to operate correctly, or any time anyone hits 90%+ on system load the thing is going to fail for sure. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-bugs Wed Mar 8 09:00:03 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA19407 for bugs-outgoing; Wed, 8 Mar 1995 09:00:03 -0800 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id JAA19393 for ; Wed, 8 Mar 1995 09:00:01 -0800 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA00888; Wed, 8 Mar 95 09:51:18 MST From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9503081651.AA00888@cs.weber.edu> Subject: Re: QIC-80 problem To: joerg_wunsch@uriah.heep.sax.de Date: Wed, 8 Mar 95 9:51:18 MST Cc: henryk@gaja.ipan.lublin.pl, freebsd-bugs@FreeBSD.org In-Reply-To: <199503080658.HAA02015@uriah.heep.sax.de> from "J Wunsch" at Mar 8, 95 07:58:33 am X-Mailer: ELM [version 2.4dev PL52] Sender: bugs-owner@FreeBSD.org Precedence: bulk > As Terry Lambert wrote: > > > > > I have a 486/66 with FreeBSD. > > > I just bought a QIC 80 streamer and ftp'd an ft filter. > > > It works quite well with tar but only with "B" option. > > > When i try to use a "z" option for tar it hangs after > > > some time. > > > Precompress the data. > > > > Since the interface used by floppy tape drives is the floppy disk > > controller, and since the floppy disk controller does not have a > > buffer (or a detectable one, if you lucked into one of the new > > chips that almost no one uses) this means that it is sensitive > > in the extreme to missed I/O. > > [A very long explanation deleted.] > > Terry, you might sometimes look as well at the recipient address. > This one ended up in .pl, so i'm afraid your fine explanation might be > a bit hard to understand... (it's even hard to understand for me, even > after following this list for a long time now). Never underestimate your audience. 8-). If nothing else, I put the meat first: precompress the data. Even if you are right and he can't understand the whole thing except as broad strokes, he can see that. Actually Vadim Antonov (Saw him on "The Internet Show" last night, 'crushing the coup against Gorbachev', they said...) who now works for SprintNet wrote the BSDI ft driver and resolved most of the issues. Since he was laid off over the lawsuit, maybe he'd rewrite the free driver if someone asked nicely. > But speaking of double-buffering, it should be possible to solve the > problem by piping it through a program called ``team'', since it does > N-buffering. > > Why did nobody make a FreeBSD port for ``team'' by now? ;-) Because team just compiles up, mostly. One drawback, though: team make some assumptions about signals and pipes that are bad. While it is higher performance than ddd when it works, you could argue that it isn't even writen in C. 8-). The problems with its assumptions manifest on MP Sun machines, among others, by causing "broken pipe" messages instead of dumping output. In any case, team is insufficient for the same reason the ft filter isn't working, which is that the ft driver require that the program that is writing to it get its process quantum sufficiently frequently that it doesn't miss it's smallest timing window (subquanta). When then compression is done, system loading is such that the ft program doesn't get to do its thing (team would not either -- all it does effectively is interleave the I/O, something a single process async I/O program could do). When that happens, the driver fails to hit the window and the tape loses sync. Actually, a filter that used multiple outstanding async reads and used async writes to dump the data would probably have significantly higher performance than team because it would avoid context switching. Anyone? I want credit in the comments. 8-). I suggest "super team" so it can have a cool name like "steam". Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-bugs Wed Mar 8 12:55:20 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA12490 for bugs-outgoing; Wed, 8 Mar 1995 12:55:20 -0800 Received: from sxpo.fdn.org (sxpo.fdn.org [193.55.4.40]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id MAA12406 for ; Wed, 8 Mar 1995 12:53:43 -0800 Received: by sxpo.fdn.org id AA13331 (5.65c8/IDA-1.4.4/FdN-1.0 for bugs@freebsd.org); Wed, 8 Mar 1995 21:52:30 +0100 Received: by v34.fdn.fr (Cray III experimental) id 006i for bugs@freebsd.org; Wed, 8 Mar 1995 21:43:44 +0100 From: ccouv@v34.fdn.fr (Christian Couvida) To: bugs@FreeBSD.org Subject: latest snapshot 10th february 1995 Date: Wed, 08 Mar 1995 21:43:43 +0100 X-Mailer: CrayMail 5.2 pl 26 experimental 1.2 Crypticode: 3990002060 Message-Id: <794717023.5333@v34.fdn.fr> Sender: bugs-owner@FreeBSD.org Precedence: bulk Hello, I've just tried to install this release on my 486. The checksums files in each distribution (for example bin) don't correspond to the files ! :((( I've checked several sites : ftp.freebsd.org & ftp.ibp.fr. Same problem. Did I miss something ? It seems very strange that this hasn't been modified since the 10th of February ! Has anyone installed this snapshot successfully ? If yes, from which site did you grab you snapshot ? Thanx From owner-freebsd-bugs Wed Mar 8 13:20:10 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id NAA14714 for bugs-outgoing; Wed, 8 Mar 1995 13:20:10 -0800 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id NAA14701; Wed, 8 Mar 1995 13:20:04 -0800 Date: Wed, 8 Mar 1995 13:20:04 -0800 Message-Id: <199503082120.NAA14701@freefall.cdrom.com> From: Mike Grupenhoff Reply-To: Mike Grupenhoff To: freebsd-bugs Subject: bin/234: suspending vipw hangs In-Reply-To: Your message of Wed, 8 Mar 1995 16:10:22 -0500 <199503082110.QAA23790@snarf.dorm.umd.edu> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 234 >Category: bin >Synopsis: suspending vipw hangs the whole process >Confidential: no >Severity: serious >Priority: low >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Mar 8 13:20:02 1995 >Originator: Mike Grupenhoff >Organization: >Release: FreeBSD 2.0-RELEASE i386 >Environment: 2.0 Release, i486DX2/50 >Description: Hitting ^Z while in vipw causes the whole mess to hang. vipw is not recognizing that the child has stopped, and waits forever. >How-To-Repeat: vipw ^Z >Fix: Here's how NetBSD fixed it: (/usr/src/usr.sbin/vipw/pw_util.c) --- 1.1 1995/03/08 20:42:03 +++ pw_util.c 1995/03/08 20:42:09 @@ -60,6 +60,17 @@ #include "pw_util.h" extern char *tempname; +static pid_t editpid = -1; +static int lockfd; + +void +pw_cont(sig) + int sig; +{ + + if (editpid != -1) + kill(editpid, sig); +} void pw_init() @@ -85,15 +96,12 @@ (void)signal(SIGPIPE, SIG_IGN); (void)signal(SIGQUIT, SIG_IGN); (void)signal(SIGTERM, SIG_IGN); - (void)signal(SIGTSTP, SIG_IGN); - (void)signal(SIGTTOU, SIG_IGN); + (void)signal(SIGCONT, pw_cont); /* Create with exact permissions. */ (void)umask(0); } -static int lockfd; - int pw_lock() { @@ -153,7 +161,6 @@ int notsetuid; { int pstat; - pid_t pid; char *p, *editor; if (!(editor = getenv("EDITOR"))) @@ -163,7 +170,7 @@ else p = editor; - if (!(pid = vfork())) { + if (!(editpid = vfork())) { if (notsetuid) { (void)setgid(getgid()); (void)setuid(getuid()); @@ -171,9 +178,18 @@ execlp(editor, p, tempname, NULL); _exit(1); } - pid = waitpid(pid, (int *)&pstat, 0); - if (pid == -1 || !WIFEXITED(pstat) || WEXITSTATUS(pstat) != 0) - pw_error(editor, 1, 1); + for (;;) { + editpid = waitpid(editpid, (int *)&pstat, WUNTRACED); + if (editpid == -1) + pw_error(editor, 1, 1); + else if (WIFSTOPPED(pstat)) + raise(WSTOPSIG(pstat)); + else if (WIFEXITED(pstat) && WEXITSTATUS(pstat) == 0) + break; + else + pw_error(editor, 1, 1); + } + editpid = -1; } void >Audit-Trail: >Unformatted: From owner-freebsd-bugs Wed Mar 8 15:00:58 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id PAA24753 for bugs-outgoing; Wed, 8 Mar 1995 15:00:58 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id OAA23926 for ; Wed, 8 Mar 1995 14:52:24 -0800 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA05129; Wed, 8 Mar 1995 23:46:43 +0100 Received: by sax.sax.de (8.6.9/8.6.9-s1) with UUCP id XAA09293; Wed, 8 Mar 1995 23:46:43 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.9/8.6.9) id XAA04117; Wed, 8 Mar 1995 23:36:48 +0100 From: J Wunsch Message-Id: <199503082236.XAA04117@uriah.heep.sax.de> Subject: Re: QIC-80 problem To: terry@cs.weber.edu (Terry Lambert) Date: Wed, 8 Mar 1995 23:36:47 +0100 (MET) Cc: henryk@gaja.ipan.lublin.pl, freebsd-bugs@FreeBSD.org In-Reply-To: <9503081651.AA00888@cs.weber.edu> from "Terry Lambert" at Mar 8, 95 09:51:18 am Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 781 Sender: bugs-owner@FreeBSD.org Precedence: bulk As Terry Lambert wrote: > > > Why did nobody make a FreeBSD port for ``team'' by now? ;-) > > Because team just compiles up, mostly. But that alone won't make it onto the CD. [Suggestion for why team perhaps won't work deleted -- though i think, a 486/66 might be fast enough] > Actually, a filter that used multiple outstanding async reads and > used async writes to dump the data would probably have significantly > higher performance than team because it would avoid context switching. > > Anyone? I want credit in the comments. 8-). > > I suggest "super team" so it can have a cool name like "steam". The name is nice. :^) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-bugs Wed Mar 8 15:58:59 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id PAA26819 for bugs-outgoing; Wed, 8 Mar 1995 15:58:59 -0800 Received: from netcom22.netcom.com (bakul@netcom22.netcom.com [192.100.81.136]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id PAA26813 for ; Wed, 8 Mar 1995 15:58:57 -0800 Received: from localhost by netcom22.netcom.com (8.6.10/Netcom) id PAA24741; Wed, 8 Mar 1995 15:35:53 -0800 Message-Id: <199503082335.PAA24741@netcom22.netcom.com> To: terry@cs.weber.edu (Terry Lambert) cc: joerg_wunsch@uriah.heep.sax.de, henryk@gaja.ipan.lublin.pl, freebsd-bugs@FreeBSD.org Subject: Re: QIC-80 problem In-reply-to: Your message of "Wed, 08 Mar 95 09:51:18 MST." <9503081651.AA00888@cs.weber.edu> Date: Wed, 08 Mar 95 15:35:49 -0800 From: Bakul Shah Sender: bugs-owner@FreeBSD.org Precedence: bulk > One drawback, though: team make some assumptions about signals and > pipes that are bad. Such as? > While it is higher performance than ddd when > it works, you could argue that it isn't even writen in C. 8-). You mean you don't like PierCarlo Grandi's use of cpp :-) Actually it is a whole sight better than the original Bourne shell's! > The problems with its assumptions manifest on MP Sun machines, > among others, by causing "broken pipe" messages instead of dumping > output. I have used team on MP SGI machines where it worked fine, and not MP Sun machines but this surprises me. team reads (multiple times if necessary) from the input until enough data is received to fill up blocksize buffer or until EOF. Similarly for output. Perhaps broken pipe is associated with something else? I am not doubting what you say but I'd like to know under what circumstances team does not work. > In any case, team is insufficient for the same reason the ft filter > isn't working, which is that the ft driver require that the program > that is writing to it get its process quantum sufficiently frequently > that it doesn't miss it's smallest timing window (subquanta). The same thing can happen with a uni-process program too. > Actually, a filter that used multiple outstanding async reads and > used async writes to dump the data would probably have significantly > higher performance than team because it would avoid context switching. But can you have *multiple* outstanding async reads on the same file/device from a *single* process? I didn't think so. > I suggest "super team" so it can have a cool name like "steam". Well, such program is not using a `team' (of processes) so any derivation of team would be even less appropriate. (`team' itself is not at all descriptive of what it does). Bakul Shah From owner-freebsd-bugs Wed Mar 8 17:03:50 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id RAA28584 for bugs-outgoing; Wed, 8 Mar 1995 17:03:50 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id QAA28472 for ; Wed, 8 Mar 1995 16:57:05 -0800 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA06157; Thu, 9 Mar 1995 00:47:56 +0100 Received: by sax.sax.de (8.6.9/8.6.9-s1) with UUCP id AAA09496; Thu, 9 Mar 1995 00:47:54 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.9/8.6.9) id AAA04557; Thu, 9 Mar 1995 00:36:15 +0100 From: J Wunsch Message-Id: <199503082336.AAA04557@uriah.heep.sax.de> Subject: Re: latest snapshot 10th february 1995 To: ccouv@v34.fdn.fr (Christian Couvida) Date: Thu, 9 Mar 1995 00:36:15 +0100 (MET) Cc: bugs@FreeBSD.org In-Reply-To: <794717023.5333@v34.fdn.fr> from "Christian Couvida" at Mar 8, 95 09:43:43 pm Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 594 Sender: bugs-owner@FreeBSD.org Precedence: bulk As Christian Couvida wrote: > > The checksums files in each distribution (for example bin) > don't correspond to the files ! :((( > > I've checked several sites : ftp.freebsd.org & ftp.ibp.fr. > Same problem. > > Has anyone installed this snapshot successfully ? > If yes, from which site did you grab you snapshot ? Yes, off a tape copy from ftp.inf.tu-dresden.de. Did you perchance forget to set ``type binary'' when ftp'ing the files by hand? -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-bugs Wed Mar 8 17:30:57 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id RAA00790 for bugs-outgoing; Wed, 8 Mar 1995 17:30:57 -0800 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id RAA00783 for ; Wed, 8 Mar 1995 17:30:54 -0800 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA03354; Wed, 8 Mar 95 18:18:04 MST From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9503090118.AA03354@cs.weber.edu> Subject: Re: QIC-80 problem To: bakul@netcom.com (Bakul Shah) Date: Wed, 8 Mar 95 18:18:04 MST Cc: joerg_wunsch@uriah.heep.sax.de, henryk@gaja.ipan.lublin.pl, freebsd-bugs@FreeBSD.org In-Reply-To: <199503082335.PAA24741@netcom22.netcom.com> from "Bakul Shah" at Mar 8, 95 03:35:49 pm X-Mailer: ELM [version 2.4dev PL52] Sender: bugs-owner@FreeBSD.org Precedence: bulk > > One drawback, though: team make some assumptions about signals and > > pipes that are bad. > > Such as? [ ... ] > > The problems with its assumptions manifest on MP Sun machines, > > among others, by causing "broken pipe" messages instead of dumping > > output. > > I have used team on MP SGI machines where it worked fine, > and not MP Sun machines but this surprises me. team reads > (multiple times if necessary) from the input until enough > data is received to fill up blocksize buffer or until EOF. > Similarly for output. Perhaps broken pipe is associated > with something else? > > I am not doubting what you say but I'd like to know under what > circumstances team does not work. Child process on another processor exits before the controlling process on the first processor. I haven't really tracked it further than that. Apparently the IPC delivery of SIGCHLD is "broken" for the way team is using it. With less, "creative" shall we say, use of the preprocessor this would be easier to track down. 8-). > The same thing can happen with a uni-process program too. Oh, yes -- it *is* what is happening with the tar tzf - XXX | ft that started this thread in the first place. But that's why interleaving the I/O to ft won't help if ft isn't running sufficiently frequently. Adding processes won't help: ft isn't not running for lack of input. > > Actually, a filter that used multiple outstanding async reads and > > used async writes to dump the data would probably have significantly > > higher performance than team because it would avoid context switching. > > But can you have *multiple* outstanding async reads on the > same file/device from a *single* process? I didn't think > so. Not on the same descriptor, that's true. You'd need to dup it. Or if you are using LWP semantics anyway, use pread/pwrite asynchronously so you can specify a seek offset. In reality, you'd on;y save ~ 40uS by keeping an outstanding call going on both the read and write (system call initation overhead for two calls). On the other hand, on a big file, this could add up. > > I suggest "super team" so it can have a cool name like "steam". > > Well, such program is not using a `team' (of processes) so > any derivation of team would be even less appropriate. > (`team' itself is not at all descriptive of what it does). It would be using a team of threads of control in a single process context instead of multiple processes or multiple threads. A pthreads implementation would have more complex context switching overhead so would probably not perform as well, since it would have to swap out stack and register sets and (potentially) flush the pipeline, if the processor was a good one (see 'User space threads and SPARC register windows', U of Washington CS department technical report). Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-bugs Wed Mar 8 18:42:34 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA03051 for bugs-outgoing; Wed, 8 Mar 1995 18:42:34 -0800 Received: from netcom21.netcom.com (bakul@netcom21.netcom.com [192.100.81.135]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id SAA03045 for ; Wed, 8 Mar 1995 18:42:33 -0800 Received: from localhost by netcom21.netcom.com (8.6.10/Netcom) id SAA18798; Wed, 8 Mar 1995 18:29:22 -0800 Message-Id: <199503090229.SAA18798@netcom21.netcom.com> To: terry@cs.weber.edu (Terry Lambert) cc: joerg_wunsch@uriah.heep.sax.de, henryk@gaja.ipan.lublin.pl, freebsd-bugs@FreeBSD.org Subject: Re: QIC-80 problem In-reply-to: Your message of "Wed, 08 Mar 95 18:18:04 MST." <9503090118.AA03354@cs.weber.edu> Date: Wed, 08 Mar 95 18:29:20 -0800 From: Bakul Shah Sender: bugs-owner@FreeBSD.org Precedence: bulk > Child process on another processor exits before the controlling process > on the first processor. I have asked the author of team to comment on this. Anyway, this problem should be easily fixable without breaking portability (e.g. by making sure none of the processes die until the process that first detected EOF on input receives back a STOP (or ABORT) message over its input command pipe). > Not on the same descriptor, that's true. You'd need to dup it. Okay, you can do this but how do you assure serializability? Say you are doing tar zcf - ... | steam > /dev/tape and steam dups fd 0 multiple times and starts async io on all of them. How can you figure out which fd has data from what offset? The offset where a read or write starts can really mess you up because you can not explicitly specify it with read/write. If you use LWP (nee threads) you have not gained much if any over team. Also, the overhead of context switch is pretty low these days: < 1ms, right? Even on a 250KB/s streamer tape, with 64KB block size you need no more than four switches for write (and four or more for reads). Go ahead and write (or urge others to write) a team replacement but I just wanted to point out that context switch is not a problem. If your system is so busy that it becomes a problem, a uni-process impl. will not really save you. Second, just because team breaks on Sun MP is no reason to throw it out on FreeBSD (well atleast until it runs on a MP system). > It would be using a team of threads of control in a single process > context instead of multiple processes or multiple threads. Okay, okay! Steam it is :-) From owner-freebsd-bugs Thu Mar 9 09:25:42 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA16452 for bugs-outgoing; Thu, 9 Mar 1995 09:25:42 -0800 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id JAA16446 for ; Thu, 9 Mar 1995 09:25:41 -0800 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA06567; Thu, 9 Mar 95 10:16:07 MST From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9503091716.AA06567@cs.weber.edu> Subject: Re: QIC-80 problem To: bakul@netcom.com (Bakul Shah) Date: Thu, 9 Mar 95 10:16:06 MST Cc: joerg_wunsch@uriah.heep.sax.de, henryk@gaja.ipan.lublin.pl, freebsd-bugs@FreeBSD.org In-Reply-To: <199503090229.SAA18798@netcom21.netcom.com> from "Bakul Shah" at Mar 8, 95 06:29:20 pm X-Mailer: ELM [version 2.4dev PL52] Sender: bugs-owner@FreeBSD.org Precedence: bulk > > Not on the same descriptor, that's true. You'd need to dup it. > > Okay, you can do this but how do you assure serializability? > Say you are doing > > tar zcf - ... | steam > /dev/tape > > and steam dups fd 0 multiple times and starts async io on > all of them. How can you figure out which fd has data from > what offset? The offset where a read or write starts can > really mess you up because you can not explicitly specify > it with read/write. Simple; serialization doesn't require that the reads be in any particular order, only that the writes be in order. All you really have to do is keep track of where the reads come from to make sure they are written in the right order; remember that it is the disk I/O on the read that you are trying to avoid, not the system call overhead. In reality, you probably don't need async I/O for the writes as long as O_SYNC isn't set, which it shouldn't be for this application (power failure during tape I/O is rarely recoverable in any case). > If you use LWP (nee threads) you have not gained much if any > over team. > > Also, the overhead of context switch is pretty low these days: > < 1ms, right? Even on a 250KB/s streamer tape, with 64KB block > size you need no more than four switches for write (and four > or more for reads). These two statements are synonymous. LWP, however, isn't threads; competitition for quanta occurs in a single process context. Using aio is much lighter weight than using LWP because you don't drag in the LWP scheduling abstraction with it, nor the register window flushing, stack swapping, FP state saving, nor signal and errno handling. > Go ahead and write (or urge others to write) a team replacement > but I just wanted to point out that context switch is not a > problem. If your system is so busy that it becomes a problem, > a uni-process impl. will not really save you. Second, just > because team breaks on Sun MP is no reason to throw it out on > FreeBSD (well at least until it runs on a MP system). Admittedly, the context switch issue is _relatively_ less of a problem (I won't say that it isn't a problem entirely). But there is also the issue of the token passing using pipes between the process, etc.. An implementation using aio in a single process context would avoid a lot of system call overhead as well as context switch overhead in the token passing, and also avoid things like pipe read/write latency, since team does NOT interleave that. Not that I would throw the baby out with the bath water, since the baby is actually the idea of interleaved I/O in the first place, not the code embodying the idea, but the overhead of pipe I/O and of context switching *is* non-zero, so it *could* be even faster. And since the problem in the ft case is competition for process quantum, not creating more than one competing process will aid in resolving the problem. Anyway, just an idea -- I'd prefer that the ft driver become immune to system load, actually -- it would put it a hell of a lot in advance of many commercial ft driver (some commercial UNIX implementations still don't even have an ft driver at all, let alone one that is robust under heavy system load. 8-). Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-bugs Thu Mar 9 13:54:28 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id NAA23529 for bugs-outgoing; Thu, 9 Mar 1995 13:54:28 -0800 Received: (from ache@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id NAA23515; Thu, 9 Mar 1995 13:54:25 -0800 Date: Thu, 9 Mar 1995 13:54:25 -0800 From: "Andrew A. Chernov" Message-Id: <199503092154.NAA23515@freefall.cdrom.com> To: ache, freebsd-bugs Subject: Changed information for PR bin/234 Sender: bugs-owner@FreeBSD.org Precedence: bulk Synopsis: suspending vipw hangs the whole process State-Changed-From-To: open-closed State-Changed-By: ache State-Changed-When: Thu Mar 9 13:53:28 PST 1995 State-Changed-Why: Fix applied. From owner-freebsd-bugs Thu Mar 9 14:20:27 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA24472 for bugs-outgoing; Thu, 9 Mar 1995 14:20:27 -0800 Received: from netcom17.netcom.com (bakul@netcom17.netcom.com [192.100.81.130]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id OAA24466 for ; Thu, 9 Mar 1995 14:20:25 -0800 Received: from localhost by netcom17.netcom.com (8.6.10/Netcom) id OAA20388; Thu, 9 Mar 1995 14:19:28 -0800 Message-Id: <199503092219.OAA20388@netcom17.netcom.com> To: terry@cs.weber.edu (Terry Lambert) Cc: freebsd-bugs@FreeBSD.org Subject: Re: QIC-80 problem In-reply-to: Your message of "Thu, 09 Mar 95 10:16:06 MST." <9503091716.AA06567@cs.weber.edu> Date: Thu, 09 Mar 95 14:19:28 -0800 From: Bakul Shah Sender: bugs-owner@FreeBSD.org Precedence: bulk > Simple; serialization doesn't require that the reads be in any > particular order, only that the writes be in order. All you > really have to do is keep track of where the reads come from > to make sure they are written in the right order; remember that > it is the disk I/O on the read that you are trying to avoid, > not the system call overhead. May be all that lack of sleep is making me especially slow but sorry, but I just don't see how. Let us look at my example again: tar zcf - ... | steam > /dev/tape There is only one input and one output to steam. Now *ideally* we'd like to say: put input block n in buffer 0, block n+1 in buffer 1, and so on, and oh, by the way, call me when a buffer is filled or eof is reached. Similarly for output side: when we are notified that block n is filled, we tell the output side to write it out in sequence and tell us when done so that we can recycle the buffer -- this is pretty much what we do at driver level if the controller supports queueing. But this is *not* what we can do at user level under Unix with any number of dups and O_ASYNC in a single process [actually O_ASYNC is a misnomer; it should really be called O_SIGIO or O_SIGNAL_ME_WHEN_IO_IS_POSSIBLE or something]. Or have you guys added real asyncio to FreeBSD while I was not looking? If so, that is great news!! > Admittedly, the context switch issue is _relatively_ less of a > problem (I won't say that it isn't a problem entirely). But > there is also the issue of the token passing using pipes between > the process, etc.. An implementation using aio in a single > process context would avoid a lot of system call overhead as > well as context switch overhead in the token passing, and also > avoid things like pipe read/write latency, since team does NOT > interleave that. team interleaves pipe IO *if* the incoming data or outgoing data is via pipes. team can not interleave read/write of control pipes because they are used for synchronization. The core loop for a team member is something like this: member[i]: loop { wait for a token from pipe[i]; // XXX I am ignoring eof or error processing... read from input[i]; send the read token to pipe[i mod n]; // n = number of members wait for write token from pipe[i]; write to output[i]; send the write token to pipe[i mod n]; } I grant your basic point that a single process implementation will avoid a lot of context switch and syscall overhead. But I just do not see how it can be done (even if we give up on portability). Note that all that context switching + syscall overhead is a problem only if the read/write quantum is so small that a tape device can do it in a few milliseconds. On my 25Mhz 486 ovehead of team is about 1.2ms *per* block of data (and *regardless* of the number of team processes). As long as your tape read/write takes atleast 10 times as long, you should be pretty safe on a lightly loaded system. I don't know the data rate of a QIC-80 but on a 4mm DAT that translates to a blocksize of 250KB/s*12ms or about 3KBytes on my machine! > Anyway, just an idea -- I'd prefer that the ft driver become > immune to system load, actually -- it would put it a hell of a > lot in advance of many commercial ft driver (some commercial > UNIX implementations still don't even have an ft driver at all, > let alone one that is robust under heavy system load. 8-). No disagreement here. From owner-freebsd-bugs Thu Mar 9 15:10:29 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id PAA25454 for bugs-outgoing; Thu, 9 Mar 1995 15:10:29 -0800 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id PAA25446 for ; Thu, 9 Mar 1995 15:10:22 -0800 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA08011; Thu, 9 Mar 95 16:03:57 MST From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9503092303.AA08011@cs.weber.edu> Subject: Re: QIC-80 problem To: bakul@netcom.com (Bakul Shah) Date: Thu, 9 Mar 95 16:03:57 MST Cc: freebsd-bugs@FreeBSD.org In-Reply-To: <199503092219.OAA20388@netcom17.netcom.com> from "Bakul Shah" at Mar 9, 95 02:19:28 pm X-Mailer: ELM [version 2.4dev PL52] Sender: bugs-owner@FreeBSD.org Precedence: bulk > There is only one input and one output to steam. Now > *ideally* we'd like to say: put input block n in buffer 0, > block n+1 in buffer 1, and so on, and oh, by the way, call > me when a buffer is filled or eof is reached. Similarly for > output side: when we are notified that block n is filled, we > tell the output side to write it out in sequence and tell us > when done so that we can recycle the buffer -- this is pretty > much what we do at driver level if the controller supports > queueing. > > But this is *not* what we can do at user level under Unix > with any number of dups and O_ASYNC in a single process > [actually O_ASYNC is a misnomer; it should really be called > O_SIGIO or O_SIGNAL_ME_WHEN_IO_IS_POSSIBLE or something]. > Or have you guys added real asyncio to FreeBSD while I was > not looking? If so, that is great news!! Yes, this was predicated on having aioread/aiowrite/aiowait/aiocancel primitives available to the program, just like on a Sun machine or on SVR4. Sorry if this wasn't clear; you're right that O_ASYNC is a bogosity that is not useful. There was recently a discussion by someone on the hackers list who was implementing real async I/O. I had the primitives implemented in the 386BSD 0.1+patchkit 2 days when I reimplemented Sun LWP first on Sun's primitives so I didn't have to deal with register winodws and stack switching and later brought the code over to 386BSD. That code is totally totally useless now that we are onto 4.4 and major changes to the SCSI and other disk I/O have taken place. In reality, you want to be able to do this with an alternate gate to make *any* potentially blocking system call async -- the work to do that is BTSOTD (Beyond The Scope Of This Discussion) 8-). It's actually the work needed prior to kernel multithreading, and kernel preemption is the work needed before SMP. I didn't expect the developement to be done (at least not done on FreeBSD ) by say next Tuesday. 8-). > > Admittedly, the context switch issue is _relatively_ less of a > > problem (I won't say that it isn't a problem entirely). But > > there is also the issue of the token passing using pipes between > > the process, etc.. An implementation using aio in a single > > process context would avoid a lot of system call overhead as > > well as context switch overhead in the token passing, and also > > avoid things like pipe read/write latency, since team does NOT > > interleave that. > > team interleaves pipe IO *if* the incoming data or outgoing data > is via pipes. team can not interleave read/write of control > pipes because they are used for synchronization. The core > loop for a team member is something like this: [ ... ] > I grant your basic point that a single process implementation > will avoid a lot of context switch and syscall overhead. But > I just do not see how it can be done (even if we give up > on portability). Like I said, I grant your point of the current async I/O in BSD using O_ASYNC being simply insufficient. > Note that all that context switching + syscall overhead is a > problem only if the read/write quantum is so small that a > tape device can do it in a few milliseconds. I don't understand this statement; the write has to run to completion in the calling processes context to allow the ft to run with a safe margin. The problem is that the next write *isn't* started sufficiently soon, either because of data unavailability (which ft supposedly fixes) or because of no quantum for ft to do its fixing. It's this second case that wants the low overhead soloution. Even so, such a soloution is just a bandaid on the real problem which is the ft driver. It's interesting to consider clever ways to apply the bandaid, and to note that these uses are universally applicable performance winds for the problem they are really intended to solve (ie: the bandaid is a side effect). Which is what got us onto this tangent in the first place. 8-). > On my 25Mhz 486 ovehead of team is about 1.2ms *per* block > of data (and *regardless* of the number of team processes). > As long as your tape read/write takes atleast 10 times as > long, you should be pretty safe on a lightly loaded system. > I don't know the data rate of a QIC-80 but on a 4mm DAT that > translates to a blocksize of 250KB/s*12ms or about 3KBytes > on my machine! Yeah, the key here is system loading and competition of the ft program for process quantum because of increased load because of the compress. I think adding competing processes (the better to rob ft of needed quanta) by using team is probably not the way you really want to go anyway. I think other than some minor semantic issues, we are in violent agreement!. 8-). Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-bugs Fri Mar 10 00:37:02 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA09658 for bugs-outgoing; Fri, 10 Mar 1995 00:37:02 -0800 Received: from lirmm.lirmm.fr (lirmm.lirmm.fr [193.49.104.10]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id AAA09652 for ; Fri, 10 Mar 1995 00:36:59 -0800 Received: from lirmm.fr (baobab.lirmm.fr [193.49.106.14]) by lirmm.lirmm.fr (8.6.10/8.6.4) with ESMTP id JAA25314 for ; Fri, 10 Mar 1995 09:36:43 +0100 Message-Id: <199503100836.JAA25314@lirmm.lirmm.fr> To: bugs@FreeBSD.org Subject: maninstall target Date: Fri, 10 Mar 1995 09:24:35 +0100 From: "Philippe Charnier" Sender: bugs-owner@FreeBSD.org Precedence: bulk Hello, Can you please add an empty maninstall target in bsd.doc.mk and bsd.info.mk then `make maninstall' can complete from /usr/src. -------- -------- Philippe Charnier charnier@lirmm.fr LIRMM, 161 rue Ada, 34392 Montpellier cedex 5 -- France ------------------------------------------------------------------------ From owner-freebsd-bugs Fri Mar 10 00:45:57 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA09938 for bugs-outgoing; Fri, 10 Mar 1995 00:45:57 -0800 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id AAA09932 for ; Fri, 10 Mar 1995 00:45:55 -0800 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id AAA01286; Fri, 10 Mar 1995 00:45:31 -0800 From: "Rodney W. Grimes" Message-Id: <199503100845.AAA01286@gndrsh.aac.dev.com> Subject: Re: maninstall target To: charnier@lirmm.fr (Philippe Charnier) Date: Fri, 10 Mar 1995 00:45:31 -0800 (PST) Cc: bugs@FreeBSD.org In-Reply-To: <199503100836.JAA25314@lirmm.lirmm.fr> from "Philippe Charnier" at Mar 10, 95 09:24:35 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 380 Sender: bugs-owner@FreeBSD.org Precedence: bulk > > Hello, > > Can you please add an empty maninstall target in bsd.doc.mk and bsd.info.mk > then `make maninstall' can complete from /usr/src. Working on that right now... I'll have it fixed in about 10 to 15 minutes... -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-bugs Fri Mar 10 09:38:11 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA19310 for bugs-outgoing; Fri, 10 Mar 1995 09:38:11 -0800 Received: from maroon.tc.umn.edu (root@maroon.tc.umn.edu [128.101.118.21]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id JAA19294 for ; Fri, 10 Mar 1995 09:37:59 -0800 From: pritc003@maroon.tc.umn.edu Received: by maroon.tc.umn.edu; Fri, 10 Mar 95 11:35:58 -0500 Message-Id: <2f608dfe74be002@maroon.tc.umn.edu> Subject: Parity error on SCSI tape causes panic w/Adaptec 2842 controller To: bugs@FreeBSD.org Date: Fri, 10 Mar 1995 11:35:56 -0600 (CST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3053 Sender: bugs-owner@FreeBSD.org Precedence: bulk To: FreeBSD-gnats-submit@freebsd.org Subject: From: pritc003@maroon.tc.umn.edu Reply-To: pritc003@maroon.tc.umn.edu >Submitter-Id: current-users >Originator: Mike Pritchard >Organization: None >Confidential: no >Synopsis: Parity error from SCSI tape cause panic w/Adaptec 2842 >Severity: serious >Priority: medium >Category: kern >Release: FreeBSD 2.0-950210-SNAP i386 >Class: sw-bug >Environment: Adaptec 2842VL SCSI controller Archive 2150S tape drive >Description: If a tape parity error is detected by the Adaptec 2842 driver software (sys/i386/scsi/aic7xxxx.c), the system will panic with the following messages: ahc1: parity error on channel A target 0, lun 0 ahc1: Unknown SCSIINT. Status = 0x17 panic: ahc1: brkaddrint, Illegal Host Access at seqaddr = 0x0 Examing the code shows that the parity error detection code incorrectly falls into the unknown scsiinit code, which eventually leads to the panic. A fix for this is attached, but that fix uncovers another problem that causes repeated scsi device timeouts on sd0. >How-To-Repeat: Find a QIC-150 tape with a parity error, and try reading the tape. The system will panic when the parity error is detected. >Fix: Here is a partial fix to the problem to help someone get started, but there is still some other underlying problem that shows up with this fix installed. With this fix installed, the parity error is detected, and the machine will not panic, but then it starts complaining about scsi device timeouts on sd0 and keeps doing that forever, so the machine hangs up anyways. I've seen the scsi device timeout problem a few other times before, so it probably does need to be addressed, although in this case it may just be happening because the parity error code is just plain broken in some fasion. I'm also willing to help test out any fixes. *** old/aic7xxx.c Fri Mar 10 10:53:44 1995 --- ./aic7xxx.c Fri Mar 10 10:56:42 1995 *************** *** 1141,1146 **** --- 1141,1155 ---- } xs = scb->xs; + if ((status & (SELTO | SCSIPERR | BUSFREE)) == 0) { + printf("ahc%d: Unknown SCSIINT. Status = 0x%x\n", + unit, status); + outb(CLRSINT1 + iobase, status); + UNPAUSE_SEQUENCER(ahc); + outb(CLRINT + iobase, CLRINTSTAT); + scb = NULL; + goto cmdcomplete; + } if (status & SELTO) { u_char active; u_char flags; *************** *** 1196,1209 **** #endif } - else { - printf("ahc%d: Unknown SCSIINT. Status = 0x%x\n", - unit, status); - outb(CLRSINT1 + iobase, status); - UNPAUSE_SEQUENCER(ahc); - outb(CLRINT + iobase, CLRINTSTAT); - scb = NULL; - } if(scb != NULL) { /* We want to process the command */ untimeout(ahc_timeout, (caddr_t)scb); --- 1205,1210 ---- From owner-freebsd-bugs Fri Mar 10 13:20:06 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id NAA24424 for bugs-outgoing; Fri, 10 Mar 1995 13:20:06 -0800 Received: from hutcs.cs.hut.fi (hutcs.cs.hut.fi [130.233.192.2]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id NAA24418 for ; Fri, 10 Mar 1995 13:20:02 -0800 Received: from shadows.cs.hut.fi by hutcs.cs.hut.fi with SMTP id AA00828 (5.65c8/HUTCS-S 1.4 for ); Fri, 10 Mar 1995 23:19:13 +0200 From: Heikki Suonsivu Received: (hsu@localhost) by shadows.cs.hut.fi (8.6.10/8.6.10) id XAA17444; Fri, 10 Mar 1995 23:19:14 +0200 Date: Fri, 10 Mar 1995 23:19:14 +0200 Message-Id: <199503102119.XAA17444@shadows.cs.hut.fi> To: freebsd-bugs@freefall.cdrom.com Subject: vt100 termcap entry hard-codes scrolling region of 24 lines Organization: Helsinki University of Technology, Otaniemi, Finland Sender: bugs-owner@FreeBSD.org Precedence: bulk vt100 termcap entry hard-codes scrolling region of 24 lines? Is this sensible? -- Heikki Suonsivu, T{ysikuu 10 C 83/02210 Espoo/FINLAND, hsu@cs.hut.fi home +358-0-8031121 work -4513377 fax -4555276 riippu SN From owner-freebsd-bugs Fri Mar 10 17:10:02 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id RAA27580 for bugs-outgoing; Fri, 10 Mar 1995 17:10:02 -0800 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id RAA27573; Fri, 10 Mar 1995 17:10:01 -0800 Date: Fri, 10 Mar 1995 17:10:01 -0800 Message-Id: <199503110110.RAA27573@freefall.cdrom.com> From: smp@clem.systemsix.com Reply-To: smp@clem.systemsix.com To: freebsd-bugs Subject: misc/236: bad extract.sh script in src In-Reply-To: Your message of Fri, 10 Mar 1995 18:10:01 -0700 <199503110110.SAA05798@rick.systemsix.com> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 236 >Category: misc >Synopsis: 2.0-950210-SNAP/src/extract.sh references "release" twice >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Mar 10 17:10:00 1995 >Originator: Steve Passe >Organization: New Ideas >Release: FreeBSD 2.1.0-Development i386 >Environment: >Description: 2.0-950210-SNAP/src/extract.sh references "release" twice. >How-To-Repeat: # cd src # sh extract.sh >Fix: remove 2nd reference to "release" 7c7: << release share sys usrbin usrsbin; do >> share sys usrbin usrsbin; do >Audit-Trail: >Unformatted: From owner-freebsd-bugs Fri Mar 10 17:52:10 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id RAA29237 for bugs-outgoing; Fri, 10 Mar 1995 17:52:10 -0800 Received: from ix2.ix.netcom.com (ix2.ix.netcom.com [199.182.120.3]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id RAA29231 for ; Fri, 10 Mar 1995 17:52:08 -0800 Received: from by ix2.ix.netcom.com (8.6.9/SMI-4.1/Netcom) id RAA05672; Fri, 10 Mar 1995 17:50:32 -0800 Date: Fri, 10 Mar 1995 17:50:32 -0800 Message-Id: <199503110150.RAA05672@ix2.ix.netcom.com> From: scottl@ix.netcom.com (scott long) Subject: 0210-SNAP To: bugs@FreeBSD.org Sender: bugs-owner@FreeBSD.org Precedence: bulk Please forgive me if I'm harping on known bugs. I think that the 0210 snapshot is excellent, but here are a few things that I noticed that might improve the 2.1 release: (btw, I have a U.S.Logic notebook, 486DX4-75, quantum IDE 244MB, 4MB ram, CT65540 color video, APM 1.1) 1: The bootmanager that can be installed from the fdisk program (on the 'boot' floppy) is flakey... I cannot always use the keyboard when the BSD boot prompt comes up, although the keyboard is active after the kernel gets loaded. MS-DOS shows no effects. Using os-bs 1.35 cured this. 2: The disklabel from the 'boot' floppy writes the fstab so that the MSDOS partition (wd0f) is mounted before the /usr partition (wd0e). This causes problems if the MS-DOS code is an LKM (get errors of 'ld not found') 3: The lnc0 probe in the kernel reboots the system. I don't own any hardware that could use this driver, but it made installing the system a pain. 4: I don't know if the APM code is supposed to work, but the section of the attach code that queries the system for an apm 1.1 link reboots the system. Commenting this out cured it, but I am stuck with a 1.0 link =-(. Other than that, it seems to work great! Hope this is helpfull! Thank you for all the effort, and I can't wait to see 2.1! Scott Long From owner-freebsd-bugs Fri Mar 10 18:45:16 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA01971 for bugs-outgoing; Fri, 10 Mar 1995 18:45:16 -0800 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id SAA01965 for ; Fri, 10 Mar 1995 18:45:14 -0800 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA00654; Fri, 10 Mar 95 19:38:53 MST From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9503110238.AA00654@cs.weber.edu> Subject: Re: vt100 termcap entry hard-codes scrolling region of 24 lines To: hsu@cs.hut.fi (Heikki Suonsivu) Date: Fri, 10 Mar 95 19:38:53 MST Cc: freebsd-bugs@freefall.cdrom.com In-Reply-To: <199503102119.XAA17444@shadows.cs.hut.fi> from "Heikki Suonsivu" at Mar 10, 95 11:19:14 pm X-Mailer: ELM [version 2.4dev PL52] Sender: bugs-owner@FreeBSD.org Precedence: bulk > vt100 termcap entry hard-codes scrolling region of 24 lines? Is this > sensible? It does this because by default the VT100 does not have insert/delete line (that is, a *real* VT100 doesn't). It uses the 'sr' to set a region for line insertion/deletion as a scroll side effect. Real curses is cool. 8-). Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-bugs Sat Mar 11 01:50:06 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id BAA25814 for bugs-outgoing; Sat, 11 Mar 1995 01:50:06 -0800 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id BAA25804; Sat, 11 Mar 1995 01:50:04 -0800 Date: Sat, 11 Mar 1995 01:50:04 -0800 Message-Id: <199503110950.BAA25804@freefall.cdrom.com> From: smp@clem.systemsix.com Reply-To: smp@clem.systemsix.com To: freebsd-bugs Subject: bin/237: m4 syscmd() bug In-Reply-To: Your message of Fri, 10 Mar 1995 20:00:42 -0700 <199503110300.UAA00334@rick.systemsix.com> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 237 >Category: bin >Synopsis: m4 syscmd() function's output out of sync >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Mar 11 01:50:02 1995 >Originator: Steve Passe >Organization: New Ideas >Release: FreeBSD 2.1.0-Development i386 >Environment: 2.0-950210-SNAP >Description: when an m4 program uses the syscmd() function the output of the system() call made by syscmd() is out of sync with the data stream of m4. >How-To-Repeat: run m4 on a file containing the following: define(MACRO, `syscmd(echo -n foo)') some text with "MACRO" in it << END OF SAMPLE INPUT this will produce: foosome text with "" in it but should produce: some text with "foo" in it >Fix: patch src/usr.bin/m4/eval.c as follows: diff eval.c.orig eval.c 173c173,177 < */ --- > */ > /* Make sure m4 output is NOT interrupted */ > fflush(stdout); > fflush(stderr); > >Audit-Trail: >Unformatted: From owner-freebsd-bugs Sat Mar 11 08:59:10 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA10973 for bugs-outgoing; Sat, 11 Mar 1995 08:59:10 -0800 Received: (from ache@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA10958; Sat, 11 Mar 1995 08:59:09 -0800 Date: Sat, 11 Mar 1995 08:59:09 -0800 From: "Andrew A. Chernov" Message-Id: <199503111659.IAA10958@freefall.cdrom.com> To: ache, freebsd-bugs Subject: Changed information for PR bin/237 Sender: bugs-owner@FreeBSD.org Precedence: bulk Synopsis: m4 syscmd() function's output out of sync State-Changed-From-To: open-closed State-Changed-By: ache State-Changed-When: Sat Mar 11 08:58:41 PST 1995 State-Changed-Why: Fix applied. From owner-freebsd-bugs Sat Mar 11 10:40:01 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA14358 for bugs-outgoing; Sat, 11 Mar 1995 10:40:01 -0800 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA14351; Sat, 11 Mar 1995 10:40:01 -0800 Date: Sat, 11 Mar 1995 10:40:01 -0800 Message-Id: <199503111840.KAA14351@freefall.cdrom.com> From: oli@devsoft.com Reply-To: oli@devsoft.com To: freebsd-bugs Subject: kern/238: failed assertion in ncr.c --> no more scsi disk access In-Reply-To: Your message of Sat, 11 Mar 1995 19:40:12 -0000 <95Mar11.194021met.7430@devsoft.devsoft.com> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 238 >Category: kern >Synopsis: failed assertion in ncr.c --> no more scsi disk access >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Mar 11 10:40:00 1995 >Originator: Oliver Adler & >Organization: no current org >Release: FreeBSD 2.0-RELEASE i386 also in current snapshot >Environment: The hardware: ASUS PCI/I-486SP3G Intel 486 DX 4 100 32MB Ram 70ns in two sims WD8003EP AT-BUS Adaptec AHA1542CF with disabled Floppy and disabled BIOS ELSA Winner100pro PCI 2MB QUANTUM Empire 2100S Target 0 on ncr bus "QUANTUM EMPIRE_2100S 1200" WANG DAT 3400 Target 3 on ncr bus "WangDAT Model 3400DX 1.10" >Description: If you try to access /dev/rst0.0 with dd bs=128k if=/dev/rst0.0 you get on the first access: Mar 10 09:00:28 boheme kernel: st0: bad request, must be between 0 and 0 (I think this message doesn't do any harm. It also starts the first access on the adaptec and does no harm there.) If you try a second time you get the following: st0: ncr.c assertion "cp = np->header.cp" line 5171 failed st0: ncr.c assertion "cp" line 5172 failed . . ncr0: restart . . sd0: unit attention sd0: oops not qeued This sequence repeats 2-times. There is no more recovery of the scsi subsytem. No more access to the harddisk. I had to reset. Because there is no more disk access I have no exact copy of all kernel messages. But I suppose I got the most important messages. >How-To-Repeat: see description above >Fix: My only work-around was to put the DAT tape to the scsi Bus of the adaptec. Then there is no problem in accessing the DAT after the message st0: bad request, must be between 0 and 0 I took care of the proper termination in both setups. I also tried the DAT in SCSI1 and SCSI2 mode. Sorry that I can't help more. Thank you and the whole FreeBSD team for providing us with the very BEST unix available. Oliver >Audit-Trail: >Unformatted: From owner-freebsd-bugs Sat Mar 11 11:05:42 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA14358 for bugs-outgoing; Sat, 11 Mar 1995 10:40:01 -0800 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA14351; Sat, 11 Mar 1995 10:40:01 -0800 Date: Sat, 11 Mar 1995 10:40:01 -0800 Message-Id: <199503111840.KAA14351@freefall.cdrom.com> From: oli@devsoft.com Reply-To: oli@devsoft.com To: freebsd-bugs Subject: kern/238: failed assertion in ncr.c --> no more scsi disk access In-Reply-To: Your message of Sat, 11 Mar 1995 19:40:12 -0000 <95Mar11.194021met.7430@devsoft.devsoft.com> Sender: bugs-owner@FreeBSD.ORG Precedence: bulk >Number: 238 >Category: kern >Synopsis: failed assertion in ncr.c --> no more scsi disk access >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Mar 11 10:40:00 1995 >Originator: Oliver Adler & >Organization: no current org >Release: FreeBSD 2.0-RELEASE i386 also in current snapshot >Environment: The hardware: ASUS PCI/I-486SP3G Intel 486 DX 4 100 32MB Ram 70ns in two sims WD8003EP AT-BUS Adaptec AHA1542CF with disabled Floppy and disabled BIOS ELSA Winner100pro PCI 2MB QUANTUM Empire 2100S Target 0 on ncr bus "QUANTUM EMPIRE_2100S 1200" WANG DAT 3400 Target 3 on ncr bus "WangDAT Model 3400DX 1.10" >Description: If you try to access /dev/rst0.0 with dd bs=128k if=/dev/rst0.0 you get on the first access: Mar 10 09:00:28 boheme kernel: st0: bad request, must be between 0 and 0 (I think this message doesn't do any harm. It also starts the first access on the adaptec and does no harm there.) If you try a second time you get the following: st0: ncr.c assertion "cp = np->header.cp" line 5171 failed st0: ncr.c assertion "cp" line 5172 failed . . ncr0: restart . . sd0: unit attention sd0: oops not qeued This sequence repeats 2-times. There is no more recovery of the scsi subsytem. No more access to the harddisk. I had to reset. Because there is no more disk access I have no exact copy of all kernel messages. But I suppose I got the most important messages. >How-To-Repeat: see description above >Fix: My only work-around was to put the DAT tape to the scsi Bus of the adaptec. Then there is no problem in accessing the DAT after the message st0: bad request, must be between 0 and 0 I took care of the proper termination in both setups. I also tried the DAT in SCSI1 and SCSI2 mode. Sorry that I can't help more. Thank you and the whole FreeBSD team for providing us with the very BEST unix available. Oliver >Audit-Trail: >Unformatted: From owner-freebsd-bugs Sat Mar 11 11:23:17 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA00575 for bugs-outgoing; Sat, 11 Mar 1995 11:23:17 -0800 Received: from phoenix.csc.calpoly.edu (phoenix.csc.calpoly.edu [129.65.17.14]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id LAA00569 for ; Sat, 11 Mar 1995 11:23:16 -0800 Received: from statler.CalPoly.Edu (statler.csc.calpoly.edu [129.65.128.18]) by phoenix.csc.calpoly.edu (8.6.10) with SMTP id LAA04549 for ; Sat, 11 Mar 1995 11:23:14 -0800 Received: by statler.CalPoly.Edu (5.x/SMI-SVR4) id AA02942; Sat, 11 Mar 1995 11:23:11 -0800 Date: Sat, 11 Mar 1995 11:23:11 -0800 From: nlawson@statler.csc.calpoly.edu (Nathan Lawson) Message-Id: <9503111923.AA02942@statler.CalPoly.Edu> To: bugs@FreeBSD.org Subject: MSDOS fs problems/panic Sender: bugs-owner@FreeBSD.org Precedence: bulk I get a panic while trying to move a file from a ufs partition to an msdos partition. My guess is that the different kernel routines try to do some kind of incompatible operation on the msdos partition. This is in the 2-10 snap, but not the 2.0 release version Thanks, Nate From owner-freebsd-bugs Sat Mar 11 14:26:31 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA00568 for bugs-outgoing; Sat, 11 Mar 1995 14:26:31 -0800 Received: from isc.sjsu.edu (sparta.SJSU.EDU [130.65.3.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id OAA00562 for ; Sat, 11 Mar 1995 14:26:30 -0800 Received: from panza (EV52-dynamic-246.Stanford.EDU) by isc.sjsu.edu (4.1/25-eef) id AA26688; Sat, 11 Mar 95 14:25:46 PST Message-Id: <9503112225.AA26688@isc.sjsu.edu> X-Sender: simek@sparta.sjsu.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 11 Mar 1995 14:23:17 -0800 To: bugs@FreeBSD.org From: simek@sparta.sjsu.edu (Michal Simek) Subject: Problem with 2.0 installation X-Mailer: Sender: bugs-owner@FreeBSD.org Precedence: bulk After I finish slicing and labeling, it tries to write the system to disk, gives me an error, and reboots. On the normal screen it says: Exec /stand/fsck failed code=9216 On the debug screen it says: Progress write error: 40950 wtfs: Invalid Argument That is if I do full install, if I try the fixit mode without sanity checks, i get this: On the normal screen it says: Exec /stand/fsck failed code=8 On the debug screen it says: Progress ** /dev/rsd1a BAD SUPER BLOCK: MAGIC NUMBER WRONG Do you have any advice as to what I might be doing wrong based on what it is telling me, or do you need to know something more? From owner-freebsd-bugs Sat Mar 11 14:30:02 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA00713 for bugs-outgoing; Sat, 11 Mar 1995 14:30:02 -0800 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA00704; Sat, 11 Mar 1995 14:30:01 -0800 Date: Sat, 11 Mar 1995 14:30:01 -0800 Message-Id: <199503112230.OAA00704@freefall.cdrom.com> From: Mark Murray Reply-To: Mark Murray To: freebsd-bugs Subject: bin/239: Multiply defined symbols in the libraries In-Reply-To: Your message of Sat, 11 Mar 1995 23:47:05 +0200 <199503112147.XAA24638@grunt.grondar.za> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 239 >Category: bin >Synopsis: Multiply defined symbols in the libraries >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Mar 11 14:30:01 1995 >Originator: Mark Murray >Organization: GTA >Release: FreeBSD 2.1.0-Development i386 >Environment: FreeBSD - very current. >Description: Making world breaks in gnu/usr.bin/gdb with: Script started on Sat Mar 11 23:36:45 1995 bash# make ===> bfd ===> libiberty ===> mmalloc ===> gdb cc -O2 -I/a/src/gnu/usr.bin/gdb/gdb/. -I/usr/include/readliner -I/a/src/gnu/usr.bin/gdb/gdb/../bfd -o gdb [snip/snip] (MY FORMATTING) -lreadline -ltermcap -lgnuregex -L/a/src/gnu/usr.bin/gdb/gdb/../libiberty/obj -liberty -L/a/src/gnu/usr.bin/gdb/gdb/../bfd/obj -lbfd -L/a/src/gnu/usr.bin/gdb/gdb/../mmalloc/obj -lmmalloc -lcompat /usr/lib/libgnuregex.so.2.0: Definition of symbol `_regerror' (multiply defined) /usr/lib/libcompat.a(regerror.o): Definition of symbol `_regerror' (multiply defined) /usr/lib/libcompat.a(regex.o): Definition of symbol `_regerror' (multiply defined) /usr/lib/libc.so.2.0: Definition of symbol `_regerror' (multiply defined) *** Error code 1 Stop. *** Error code 1 Stop. bash# exit exit Script done on Sat Mar 11 23:37:22 1995 >How-To-Repeat: make world. wait. >Fix: Nuke whichever regerrors are the least relevant. >Audit-Trail: >Unformatted: :Mark Murray From owner-freebsd-bugs Sat Mar 11 15:36:01 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA00575 for bugs-outgoing; Sat, 11 Mar 1995 11:23:17 -0800 Received: from phoenix.csc.calpoly.edu (phoenix.csc.calpoly.edu [129.65.17.14]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id LAA00569 for ; Sat, 11 Mar 1995 11:23:16 -0800 Received: from statler.CalPoly.Edu (statler.csc.calpoly.edu [129.65.128.18]) by phoenix.csc.calpoly.edu (8.6.10) with SMTP id LAA04549 for ; Sat, 11 Mar 1995 11:23:14 -0800 Received: by statler.CalPoly.Edu (5.x/SMI-SVR4) id AA02942; Sat, 11 Mar 1995 11:23:11 -0800 Date: Sat, 11 Mar 1995 11:23:11 -0800 From: nlawson@statler.csc.calpoly.edu (Nathan Lawson) Message-Id: <9503111923.AA02942@statler.CalPoly.Edu> To: bugs@freebsd.org Subject: MSDOS fs problems/panic Sender: bugs-owner@freebsd.org Precedence: bulk I get a panic while trying to move a file from a ufs partition to an msdos partition. My guess is that the different kernel routines try to do some kind of incompatible operation on the msdos partition. This is in the 2-10 snap, but not the 2.0 release version Thanks, Nate From owner-freebsd-bugs Sat Mar 11 18:17:25 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA03068 for bugs-outgoing; Sat, 11 Mar 1995 18:17:25 -0800 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id SAA03060 for ; Sat, 11 Mar 1995 18:17:19 -0800 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id SAA04715; Sat, 11 Mar 1995 18:16:23 -0800 From: "Rodney W. Grimes" Message-Id: <199503120216.SAA04715@gndrsh.aac.dev.com> Subject: Re: bin/239: Multiply defined symbols in the libraries To: mark@grondar.za Date: Sat, 11 Mar 1995 18:16:22 -0800 (PST) Cc: freebsd-bugs@freefall.cdrom.com In-Reply-To: <199503112230.OAA00704@freefall.cdrom.com> from "Mark Murray" at Mar 11, 95 02:30:01 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1049 Sender: bugs-owner@FreeBSD.org Precedence: bulk If you where reading the correct mailling lists (freebsd-current) you would know that we all know about this bug and work is being done to fix it. Please do not run -current if you are not going to read the mailling lists it will cause both you and us grief. Or if you are not going to read the mailling lists please don't ask for help and please don't file bug reports about build problems. > >Number: 239 > >Category: bin > >Synopsis: Multiply defined symbols in the libraries ... > ===> gdb > cc -O2 -I/a/src/gnu/usr.bin/gdb/gdb/. -I/usr/include/readliner > -I/a/src/gnu/usr.bin/gdb/gdb/../bfd -o gdb [snip/snip] (MY FORMATTING) > -lreadline -ltermcap -lgnuregex > -L/a/src/gnu/usr.bin/gdb/gdb/../libiberty/obj -liberty > -L/a/src/gnu/usr.bin/gdb/gdb/../bfd/obj -lbfd > -L/a/src/gnu/usr.bin/gdb/gdb/../mmalloc/obj -lmmalloc -lcompat ... -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-bugs Sat Mar 11 18:29:36 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA03292 for bugs-outgoing; Sat, 11 Mar 1995 18:29:36 -0800 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id SAA03286 for ; Sat, 11 Mar 1995 18:29:32 -0800 Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id TAA21374; Sat, 11 Mar 1995 19:32:19 -0700 Date: Sat, 11 Mar 1995 19:32:19 -0700 From: Nate Williams Message-Id: <199503120232.TAA21374@trout.sri.MT.net> In-Reply-To: "Rodney W. Grimes" "Re: bin/239: Multiply defined symbols in the libraries" (Mar 11, 6:16pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: "Rodney W. Grimes" , mark@grondar.za Subject: Re: bin/239: Multiply defined symbols in the libraries Cc: freebsd-bugs@freefall.cdrom.com Sender: bugs-owner@FreeBSD.org Precedence: bulk > If you where reading the correct mailling lists (freebsd-current) you > would know that we all know about this bug and work is being done to > fix it. Actually, in defense of Mark I'd like to point out that I'd rather see too many bug reports than too few. If I understood GNATS better I would have set the bug report to 'analyzed', but at this time my time is better spent trying to fix it than trying to figure out GNATS. By submitting things as bug reports things don't get lost in the cracks. Nate ps. Rod, remember he doesn't see the messages I've sent to the core list describing the status of the bug. From owner-freebsd-bugs Sat Mar 11 22:30:02 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA07964 for bugs-outgoing; Sat, 11 Mar 1995 22:30:02 -0800 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA07957; Sat, 11 Mar 1995 22:30:01 -0800 Date: Sat, 11 Mar 1995 22:30:01 -0800 Message-Id: <199503120630.WAA07957@freefall.cdrom.com> From: dave@prlng.co.uk Reply-To: dave@prlng.co.uk To: freebsd-bugs Subject: gnu/240: Fix for gdb to read stack from core dump In-Reply-To: Your message of Sat, 11 Mar 1995 16:02:08 GMT <199503111602.QAA01388@severn.prolingua.co.uk> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 240 >Category: gnu >Synopsis: gdb does not correctly find the stack in a core dump >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Mar 11 22:30:01 1995 >Originator: Dave Matthews >Organization: Prolingua Ltd >Release: FreeBSD 2.0-RELEASE i386 >Environment: >Description: Gdb was using the wrong addresses for the location of the stack when examining a core dump, so it wasn't possible to see a proper stack trace. >How-To-Repeat: >Fix: Apply the diffs below. The previous values were right, I think, for older versions of FreeBSD, but these new ones seem correct for FreeBSD 2.0. diff -c /usr/src/gnu/usr.bin/gdb/bfd/sysdep.h{.ORIG,} *** /usr/src/gnu/usr.bin/gdb/bfd/sysdep.h.ORIG Thu Mar 2 19:45:51 1995 --- /usr/src/gnu/usr.bin/gdb/bfd/sysdep.h Thu Mar 2 21:14:02 1995 *************** *** 27,34 **** (u.u_kproc.kp_eproc.e_vm.vm_maxsaddr + MAXSSIZ), which should work on both BSDI and 386BSD, but that is believed not to work for BSD 4.4. */ ! #ifdef __bsdi__ /* This seems to be the right thing for BSDI. */ #define HOST_STACK_END_ADDR USRSTACK #else /* This seems to be the right thing for 386BSD release 0.1. */ --- 27,35 ---- (u.u_kproc.kp_eproc.e_vm.vm_maxsaddr + MAXSSIZ), which should work on both BSDI and 386BSD, but that is believed not to work for BSD 4.4. */ ! #if (defined(__bsdi__) | defined(__FreeBSD__)) /* This seems to be the right thing for BSDI. */ + /* ..and also for FreeBSD, at least FreeBSD > 2. */ #define HOST_STACK_END_ADDR USRSTACK #else /* This seems to be the right thing for 386BSD release 0.1. */ diff -c /usr/src/gnu/usr.bin/gdb/bfd/trad-core.c{.ORIG,} *** /usr/src/gnu/usr.bin/gdb/bfd/trad-core.c.ORIG Fri Jun 10 14:33:39 1994 --- /usr/src/gnu/usr.bin/gdb/bfd/trad-core.c Thu Mar 2 22:11:17 1995 *************** *** 192,198 **** --- 192,200 ---- #else core_datasec (abfd)->vma = HOST_TEXT_START_ADDR + (NBPG * u.u_tsize); #endif + #ifndef __FreeBSD__ /* a hack, but it works for FreeBSD !! */ + /* Actually, it's not needed for FreeBSD 2.0, only for older versions. */ #include /* this should really be in , but somebody forgot it */ #ifndef vm_page_size *************** *** 200,205 **** --- 202,209 ---- #endif #define HOST_STACK_START_ADDR trunc_page(u.u_kproc.kp_eproc.e_vm.vm_maxsaddr \ + MAXSSIZ - ctob(u.u_ssize)) + #endif + #ifdef HOST_STACK_START_ADDR core_stacksec (abfd)->vma = HOST_STACK_START_ADDR; #else >Audit-Trail: >Unformatted: From owner-freebsd-bugs Sat Mar 11 23:27:52 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id XAA08721 for bugs-outgoing; Sat, 11 Mar 1995 23:27:52 -0800 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id XAA08714 for ; Sat, 11 Mar 1995 23:27:40 -0800 Received: from localhost (localhost [127.0.0.1]) by grunt.grondar.za (8.6.10/8.6.9) with SMTP id JAA26133; Sun, 12 Mar 1995 09:26:49 +0200 Message-Id: <199503120726.JAA26133@grunt.grondar.za> X-Authentication-Warning: grunt.grondar.za: Host localhost didn't use HELO protocol To: "Rodney W. Grimes" cc: mark@grondar.za, freebsd-bugs@freefall.cdrom.com Subject: Re: bin/239: Multiply defined symbols in the libraries Date: Sun, 12 Mar 1995 09:26:49 +0200 From: Mark Murray Sender: bugs-owner@FreeBSD.org Precedence: bulk > If you where reading the correct mailling lists (freebsd-current) you > would know that we all know about this bug and work is being done to > fix it. I _do_ read current. I was just a bit out of sync with this one. I remember the report, but I thought I also saw a fix. I was reporting that it was (here anyway) still broken. Apologies. > Please do not run -current if you are not going to read the mailling > lists it will cause both you and us grief. Or if you are not going > to read the mailling lists please don't ask for help and please don't > file bug reports about build problems. I am _very_ aware of this, as my track record (usually) shows. M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 From owner-freebsd-bugs Sat Mar 11 23:30:48 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id XAA08768 for bugs-outgoing; Sat, 11 Mar 1995 23:30:48 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id XAA08761 for ; Sat, 11 Mar 1995 23:30:38 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id RAA06963; Sun, 12 Mar 1995 17:29:53 +1000 Date: Sun, 12 Mar 1995 17:29:53 +1000 From: Bruce Evans Message-Id: <199503120729.RAA06963@godzilla.zeta.org.au> To: dave@prlng.co.uk, freebsd-bugs@freefall.cdrom.com Subject: Re: gnu/240: Fix for gdb to read stack from core dump Sender: bugs-owner@FreeBSD.org Precedence: bulk >>Synopsis: gdb does not correctly find the stack in a core dump This should already be fixed in FreeBSD-current. >--- /usr/src/gnu/usr.bin/gdb/bfd/sysdep.h Thu Mar 2 21:14:02 1995 > ... >! #if (defined(__bsdi__) | defined(__FreeBSD__)) > /* This seems to be the right thing for BSDI. */ >+ /* ..and also for FreeBSD, at least FreeBSD > 2. */ > #define HOST_STACK_END_ADDR USRSTACK Same fix in -current. >--- /usr/src/gnu/usr.bin/gdb/bfd/trad-core.c Thu Mar 2 22:11:17 1995 >... >+ #ifndef __FreeBSD__ > /* a hack, but it works for FreeBSD !! */ >+ /* Actually, it's not needed for FreeBSD 2.0, only for older versions. */ > #include > /* this should really be in , but somebody forgot it */ > #ifndef vm_page_size >*************** >*** 200,205 **** >--- 202,209 ---- > #endif > #define HOST_STACK_START_ADDR trunc_page(u.u_kproc.kp_eproc.e_vm.vm_maxsaddr \ > + MAXSSIZ - ctob(u.u_ssize)) >+ #endif >+ > #ifdef HOST_STACK_START_ADDR > core_stacksec (abfd)->vma = HOST_STACK_START_ADDR; > #else Was apparently fixed by switching to gdb-4.13 and forgetting about the hack. Bruce