From owner-freebsd-bugs Sun May 7 00:00:43 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA08550 for bugs-outgoing; Sun, 7 May 1995 00:00:43 -0700 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 AAA08524 for ; Sun, 7 May 1995 00:00:32 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA12986; Sun, 7 May 1995 09:00:28 +0200 Received: by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA26300 for freebsd-bugs@FreeBSD.org; Sun, 7 May 1995 09:00:28 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id IAA07462 for freebsd-bugs@FreeBSD.org; Sun, 7 May 1995 08:55:53 +0200 From: J Wunsch Message-Id: <199505070655.IAA07462@uriah.heep.sax.de> Subject: Re: bin/386: *s field width specification doesn't seem to work for printf To: freebsd-bugs@FreeBSD.org Date: Sun, 7 May 1995 08:55:51 +0200 (MET DST) Reply-To: freebsd-bugs@FreeBSD.org In-Reply-To: from "j" at May 7, 95 05:24:08 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: 1148 Sender: bugs-owner@FreeBSD.org Precedence: bulk As j wrote (that's me, ain't it? :): > "foobarblatt" ain't a valid int. printf(1) misses an argument in that > case. It expected two args (for the * and for the s) and got only > one. The least one could expect is it loudly complains about this. I think i've fixed it now. printf did a very lax syntax checking. Digits and the asterisk have been treated equally in a fieldwidth/ precision string, resulting in "8*" being believed to be valid. The paragraph o If the leading character is a single or double quote, or not a digit, plus, or minus sign, the value is the ASCII code of the next character. however explains why "foobarblatt" is considered to be the valid number 102 (the ASCII value of "f"). It's weird, but intention. Jordan: for your intention (to _limit_ the output width, if i understood you right), you need to specify the precision, not the field width: printf "%.8s" foobarblatt or printf "%.*s" ${FIELD_LENGTH} foobarblatt -- 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 Sun May 7 00:06:56 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA08731 for bugs-outgoing; Sun, 7 May 1995 00:06:56 -0700 Received: (from joerg@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA08716 ; Sun, 7 May 1995 09:06:55 +0200 Date: Sun, 7 May 1995 09:06:55 +0200 From: Joerg Wunsch Message-Id: <199505070706.JAA08716@freefall.cdrom.com> To: jkh@time.cdrom.com, joerg, freebsd-bugs Subject: Changed information for PR bin/386 Sender: bugs-owner@FreeBSD.org Precedence: bulk Synopsis: *s field width specification for printf seems to loop State-Changed-From-To: open-closed State-Changed-By: joerg State-Changed-When: Sun May 7 09:04:22 MET DST 1995 State-Changed-Why: Mostly pilot error; the syntax checking for the argument string has been made more strict with version 1.2 of printf.c, so "%*8s" is no longer considered to be a valid format string. From owner-freebsd-bugs Sun May 7 00:16:22 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA08862 for bugs-outgoing; Sun, 7 May 1995 00:16:22 -0700 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 AAA08856 for ; Sun, 7 May 1995 00:16:08 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA13224; Sun, 7 May 1995 09:15:53 +0200 Received: by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA26348 for freebsd-bugs@FreeBSD.org; Sun, 7 May 1995 09:15:53 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id JAA07653 for freebsd-bugs@FreeBSD.org; Sun, 7 May 1995 09:11:18 +0200 From: J Wunsch Message-Id: <199505070711.JAA07653@uriah.heep.sax.de> Subject: Re: 950412-SNAP To: freebsd-bugs@FreeBSD.org (FreeBSD bugs list) Date: Sun, 7 May 1995 09:11:18 +0200 (MET DST) Reply-To: freebsd-bugs@FreeBSD.org (FreeBSD bugs list) In-Reply-To: <9505070451.AA27293@cs.weber.edu> from "Terry Lambert" at May 6, 95 10:51:53 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: 542 Sender: bugs-owner@FreeBSD.org Precedence: bulk As Terry Lambert wrote: > > > Anyway, the question was related to FreeBSD, i believe. :) > > Yeah. I was pointing out that it boiled down to "why isn't FreeBSD > like System V" when he asked "Why didn't I get this expected behaviour" > and got as a response "Are you from the moon? That's *never* been > expected". But that are *your* words. :-) I've attempted to express it more politely... -- 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 Sun May 7 00:17:30 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA08871 for bugs-outgoing; Sun, 7 May 1995 00:17:30 -0700 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 AAA08865 for ; Sun, 7 May 1995 00:17:14 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA13216; Sun, 7 May 1995 09:15:51 +0200 Received: by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA26341 for freebsd-bugs@FreeBSD.org; Sun, 7 May 1995 09:15:50 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id JAA07597 for freebsd-bugs@FreeBSD.org; Sun, 7 May 1995 09:03:03 +0200 From: J Wunsch Message-Id: <199505070703.JAA07597@uriah.heep.sax.de> Subject: Re: bin/386: *s field width specification doesn't seem to work for printf To: freebsd-bugs@FreeBSD.org (FreeBSD bugs list) Date: Sun, 7 May 1995 09:03:03 +0200 (MET DST) Reply-To: freebsd-bugs@FreeBSD.org (FreeBSD bugs list) In-Reply-To: <199505070445.OAA02207@godzilla.zeta.org.au> from "Bruce Evans" at May 7, 95 02:45:47 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: 445 Sender: bugs-owner@FreeBSD.org Precedence: bulk As Bruce Evans wrote: > > printf(1) doesn't seem to do any more error checking than printf(3). Yes, but it should (since it's a user program, and not only a function provided to developers). > No, the 8 is the (minimum) field width. > > printf "%.*s" 8 foobarblatt I remembered this later, too. -- 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 Sun May 7 02:12:39 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id CAA12181 for bugs-outgoing; Sun, 7 May 1995 02:12:39 -0700 Received: (from bde@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id CAA12112 ; Sun, 7 May 1995 02:11:13 -0700 Date: Sun, 7 May 1995 02:11:13 -0700 From: Bruce Evans Message-Id: <199505070911.CAA12112@freefall.cdrom.com> To: pb@fasterix.freenix.fr, bde, freebsd-bugs Subject: Changed information for PR kern/363 Sender: bugs-owner@FreeBSD.org Precedence: bulk Synopsis: page fault in sio.c soon after boot (+ suggested fix) State-Changed-From-To: open-closed State-Changed-By: bde State-Changed-When: Sun May 7 02:09:10 PDT 1995 State-Changed-Why: Already fixed in revision 1.92 of sio.c on 1995/04/13. From owner-freebsd-bugs Sun May 7 02:18:14 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id CAA12562 for bugs-outgoing; Sun, 7 May 1995 02:18:14 -0700 Received: (from bde@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id CAA12545 ; Sun, 7 May 1995 02:18:11 -0700 Date: Sun, 7 May 1995 02:18:11 -0700 From: Bruce Evans Message-Id: <199505070918.CAA12545@freefall.cdrom.com> To: ted@wiz.plymouth.edu, bde, freebsd-bugs Subject: Changed information for PR bin/381 Sender: bugs-owner@FreeBSD.org Precedence: bulk Synopsis: Quota commands (repquota/edquota/quota) not giving correct info. State-Changed-From-To: open-closed State-Changed-By: bde State-Changed-When: Sun May 7 02:14:32 PDT 1995 State-Changed-Why: Fixed in rev.1.2 of quota.c, rev.1.3 of edquota.c and rev.1.2 of repquota.c. The problem was actually mismatched printf format args. From owner-freebsd-bugs Sun May 7 02:24:21 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id CAA12688 for bugs-outgoing; Sun, 7 May 1995 02:24:21 -0700 Received: (from davidg@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id CAA12673 ; Sun, 7 May 1995 02:24:14 -0700 Date: Sun, 7 May 1995 02:24:14 -0700 From: David Greenman Message-Id: <199505070924.CAA12673@freefall.cdrom.com> To: curt@emergent.com, davidg, freebsd-bugs Subject: Changed information for PR kern/360 Sender: bugs-owner@FreeBSD.org Precedence: bulk Synopsis: filesystem deadlock trivial to produce State-Changed-From-To: open-closed State-Changed-By: davidg State-Changed-When: Sun May 7 02:17:22 PDT 1995 State-Changed-Why: The bug was caused by a deadlock between the VM system and the buffer I/O system trying to acquire the same lock. Fixed in rev 1.21/1.22 of ufs_lock.c. From owner-freebsd-bugs Sun May 7 02:43:19 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id CAA13108 for bugs-outgoing; Sun, 7 May 1995 02:43:19 -0700 Received: from mail.barrnet.net (mail.BARRNET.NET [131.119.246.7]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id CAA13102 for ; Sun, 7 May 1995 02:43:17 -0700 Received: from unlisys.unlisys.NET (unlisys.unlisys.net [194.64.15.1]) by mail.barrnet.net (8.6.10/MAIL-RELAY-LEN) with SMTP id CAA02190 for ; Sun, 7 May 1995 02:40:27 -0700 Received: by unlisys.unlisys.NET from deadline.snafu.de with smtp (Smail3.1.28.1 [@@]) id m0s82p4-0000IzC; Sun, 7 May 95 11:40 MET DST Received: by deadline.snafu.de id m0s82p1-000IucC; Sun, 7 May 95 11:40 MET DST (/\oo/\ Smail3.1.29.1 #29.1) Message-Id: From: root@deadline.snafu.de (Andreas S. Wetzel) Subject: Where has my sliplogin gone? To: freebsd-bugs@FreeBSD.org Date: Sun, 7 May 1995 11:40:19 +0200 (MET DST) Organization: -D-E-A-D-L-I-N-E- Public access UN*X system - 13347 Berlin. X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 728 Sender: bugs-owner@FreeBSD.org Precedence: bulk Hi! --- Here's a little thing I'm noticing since yesterday with kernel BUILT-19950427: I have a SLIP line, which is connected via sliplogin on my side, but since about yesterday there's no utmp entry showing up for it anymore. The line is still fully operational, and everything works fine, but no utmp entry saying that there is a sliplogin? Any ideas where it could have gone? Mickey -- (__) (@@) Andreas S. Wetzel E-mail: mickey@deadline.snafu.de /-------\/ Utrechter Strasse 41 Web: http://deadline.snafu.de/ / | || 13347 Berlin Voice: <+4930> 456 81 68 * ||----|| Germany Fax/Data: <+4930> 455 19 57 ~~ ~~ From owner-freebsd-bugs Sun May 7 03:30:04 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id DAA14453 for bugs-outgoing; Sun, 7 May 1995 03:30:04 -0700 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id DAA14446 ; Sun, 7 May 1995 03:30:03 -0700 Date: Sun, 7 May 1995 03:30:03 -0700 Message-Id: <199505071030.DAA14446@freefall.cdrom.com> From: Peter Dufault Reply-To: Peter Dufault To: freebsd-bugs Subject: kern/387: scsistrategy doesn't use bounce buffers In-Reply-To: Your message of Sun, 7 May 1995 06:25:53 -0400 <199505071025.GAA17670@hda.com> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 387 >Category: kern >Synopsis: scsistrategy doesn't use bounce buffers >Confidential: no >Severity: serious >Priority: low >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun May 7 03:30:01 1995 >Originator: Peter & >Organization: Peter Dufault Real Time Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 dufault@hda.com Fax: 508 433 5267 >Release: FreeBSD 2.1.0-Development i386 >Environment: >Description: The scsistrategy function used by the user ioctl doesn't allocate bounce buffers. I don't understand what the BOUNCE code in scsi_scsi_cmd is doing, so I'm not just going to add in a call to vm_bounce_alloc until I have the time to look at it. >How-To-Repeat: >Fix: Probably add /* * Use a bounce buffer if necessary */ #ifdef BOUNCE_BUFFERS if (sc_link->flags & SDEV_BOUNCE) vm_bounce_alloc(bp); #endif before scsi_scsi_cmd in scsi_ioctl.c >Audit-Trail: >Unformatted: From owner-freebsd-bugs Sun May 7 13:34:59 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id NAA00170 for bugs-outgoing; Sun, 7 May 1995 13:34:59 -0700 Received: from mramirez.sy.yale.edu (mramirez.sy.yale.edu [130.132.57.207]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id NAA00164 for ; Sun, 7 May 1995 13:34:43 -0700 Received: (from mrami@localhost) by mramirez.sy.yale.edu (8.6.11/8.6.9) id QAA10369; Sun, 7 May 1995 16:33:58 -0400 Date: Sun, 7 May 1995 16:33:58 -0400 (EDT) From: Marc Ramirez Reply-To: mrami@minerva.cis.yale.edu To: Jim Bryant cc: joerg_wunsch@uriah.heep.sax.de, freebsd-bugs@FreeBSD.org Subject: Re: HELP! QIC-80 tape drive not probed by kernel In-Reply-To: <199505061206.HAA03032@news.iadfw.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: bugs-owner@FreeBSD.org Precedence: bulk I had this problem a while back on a Gateway 2000. Steve Gerakines sent me the following solution: On Tue, 4 Apr 1995, Steve Gerakines wrote: > I think I've pinpointed the problem. Take a look at the ft.c driver around > line 1481. There should be a DELAY(100) in there. Bump up the delay to > 200 and change the retries count in the loop to 20000 and recompile. This > should hopefully take care of your problem. Marc. On Sat, 6 May 1995, Jim Bryant wrote: > In reply: > > Date: Fri, 5 May 1995 09:46:14 +0200 > > From: j@narcisa.sax.de (J Wunsch) > > To: freebsd-bugs@FreeBSD.org, steve2@FreeBSD.org > > Subject: Re: HELP! QIC-80 tape drive not probed by kernel > > > > Since this came up over and over again in Usenet (and i don't have an > > apparent solution since i don't have a floppy tape), here a forward: > > > > In article <3o74s1$hoa@charnel.ecst.csuchico.edu> you write: > > >In article <1995May2.112336.3104@wisipc.weizmann.ac.il>, > > >Serge S. Maleyev wrote: > > >>Rafael Araujo (Rafael_Araujo@p128.f151.n5020.z2.fidonet.org) wrote: > > > > > >>: controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr > > >> ^ > > >> | > > >> flags 0x1 > > >> Just add this. > > > > > >He did: > > > > > >>: controller fdc0 at isa? port "IO_FD1" bio flags 0x1 irq 6 drq 2 vector fdintr > > > > > >I'm having this same problem. The flags argument to the controller doesn't > > >work in all cases apparently. And to the number of people who emailed me, > > >*YES* I did config, compile, and boot the new kernel, I'm not a moron. > > > > > >There's something up here, and nobody seems to know what it is. > > > > > >*Sigh* > > > > > >Someday I'll be able to back up my system. > > > > > >Shawn > > > > > >-- > > >Shawn Brown | shawnb@ecst.csuchico.edu | California State University, Chico > > >Shawn's Chaosphere is here > > > > > > -- > > cheers, J"org private: joerg_wunsch@uriah.heep.sax.de > > http://www.sax.de/~joerg/ > > > > Never trust an operating system you don't have sources for. ;-) > > i had this problem on one system before, pentium/pci[ncr pci, ncr scsi]... > > pissed me off.. had to do a floppy install of 950210.. > > so far as i can tell, only one of four machines [2 pentium/pci's, > 486 isa/vesa, and a 486 isa] that i have installed freebsd on have had this > problem. > > Jim > -- > All opinions expressed are mine, if you | "I will not be pushed, stamped, > think otherwise, then go jump into turbid | briefed, debriefed, indexed, or > radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" > jbryant@server.iadfw.net, System administrator, Internet America > -- You couldn't get a clue during the clue mating season in a field full of horny clues if you smeared your body with clue musk and did the clue mating dance. - Edward Flaherty From owner-freebsd-bugs Sun May 7 15:44:18 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id PAA05024 for bugs-outgoing; Sun, 7 May 1995 15:44:18 -0700 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 PAA05018 for ; Sun, 7 May 1995 15:44:14 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA29547; Sun, 7 May 95 16:37:44 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9505072237.AA29547@cs.weber.edu> Subject: Re: 950412-SNAP To: freebsd-bugs@FreeBSD.org Date: Sun, 7 May 95 16:37:44 MDT In-Reply-To: <199505070711.JAA07653@uriah.heep.sax.de> from "J Wunsch" at May 7, 95 09:11:18 am X-Mailer: ELM [version 2.4dev PL52] Sender: bugs-owner@FreeBSD.org Precedence: bulk > > Yeah. I was pointing out that it boiled down to "why isn't FreeBSD > > like System V" when he asked "Why didn't I get this expected behaviour" > > and got as a response "Are you from the moon? That's *never* been > > expected". > > But that are *your* words. :-) I've attempted to express it more > politely... Hey, *I* never thought it was unexpected. If it were up to me, it'd be a mount option. I have delusions of passing SVVS, you see. 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 Sun May 7 23:07:44 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id XAA19896 for bugs-outgoing; Sun, 7 May 1995 23:07:44 -0700 Received: from balboa.eng.uci.edu (balboa.eng.uci.edu [128.200.61.2]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id XAA19889 for ; Sun, 7 May 1995 23:07:42 -0700 Received: from newport.ece.uci.edu by balboa.eng.uci.edu with SMTP id AA25666 (5.65c/IDA-1.4.4 for freebsd-bugs@freebsd.org); Sun, 7 May 1995 23:07:39 -0700 Received: from localhost by newport.ece.uci.edu (5.x) id AA03672; Sun, 7 May 1995 23:07:38 -0700 Message-Id: <9505080607.AA03672@newport.ece.uci.edu> To: davidg@freefall.cdrom.com Cc: freebsd-bugs@FreeBSD.org Subject: freeze up Date: Sun, 07 May 1995 23:07:37 -0700 From: Steven Wallace Sender: bugs-owner@FreeBSD.org Precedence: bulk I just had one of my freeze up agains and something different happened this time.... One difference is that I have been using an older kernel that worked fine for me b4 my probs - April 22nd kernel. My problems started after I upgraded my system from a 2.0R binaries using a 2.1-Devel kernel to the last 2.1 SNAPshot release (end of april I think). So my suspisions have been that new some binary (cc) or library has been showing probs with the kernel not seen before. For the past two weeks my computer has frozen about every two days usually after trying to compile something with cc (once it happened on a man command). Today with my older kernel I had just d/l some new source and was compiling it with cc. When the makefile started the first cc, nothing happened. In addition, ALL commands I typed in my other X shells would freeze, until I hit control-C in the xterm that was running cc. This happened repeatedly three times. Then I made a msitake of putting the compile in the background and not being able to send ^C signal to it. Even kill commands would freeze. Then I moved my mouse down to the next virtual desktop. It started redrawing the new screen then froze w/o being able to do anything. So I found this experience very odd because existing processes continued to run fine until they ran into something that blocked them from continuing anymore while new commands (ls, kill, ps I tried) would freeze right away - until I terminated this cc process. Any ideas on what this could be? What should I do if I experience this freeze with a partial lock-up? Thanks, Steven From owner-freebsd-bugs Mon May 8 00:06:28 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA20730 for bugs-outgoing; Mon, 8 May 1995 00:06:28 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id AAA20715 for ; Mon, 8 May 1995 00:06:26 -0700 Received: from corbin.Root.COM (corbin.Root.COM [198.145.90.18]) by Root.COM (8.6.8/8.6.5) with ESMTP id AAA01186; Mon, 8 May 1995 00:09:27 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.11/8.6.5) with SMTP id AAA00158; Mon, 8 May 1995 00:06:24 -0700 Message-Id: <199505080706.AAA00158@corbin.Root.COM> To: Steven Wallace cc: freebsd-bugs@FreeBSD.org Subject: Re: freeze up In-reply-to: Your message of "Sun, 07 May 95 23:07:37 PDT." <9505080607.AA03672@newport.ece.uci.edu> From: David Greenman Reply-To: davidg@Root.COM Date: Mon, 08 May 1995 00:06:22 -0700 Sender: bugs-owner@FreeBSD.org Precedence: bulk >So I found this experience very odd because existing processes continued >to run fine until they ran into something that blocked them from continuing >anymore while new commands (ls, kill, ps I tried) would freeze right >away - until I terminated this cc process. Any ideas on what this could >be? What should I do if I experience this freeze with a partial lock-up? Sounds like a vnode locking problem that eventually leads to locking the root directory (at which point your dead). I don't know what could be causing it, though. wcarchive is running -current from about 3 days ago and has been up running fine since (and this is with 250-300 users and mild paging) and I haven't seen the problem on my own machines. We did have problems like this a month or so ago, but the causes of those have been fixed. As far as what to do next time it happens...hmmm, if you can get to the console vty, you could escape to the debugger and do a 'ps' to find out what the processes are all sleeping on. Since your windows appear to still be mostly alive, you might try typing "ctrl-T" and noting the wmesg (the part in brackets that comes after the PID). This would provide more clues, perhaps. -DG From owner-freebsd-bugs Mon May 8 01:23:26 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id BAA21499 for bugs-outgoing; Mon, 8 May 1995 01:23:26 -0700 Received: from balboa.eng.uci.edu (balboa.eng.uci.edu [128.200.61.2]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id BAA21492 for ; Mon, 8 May 1995 01:23:22 -0700 Received: from newport.ece.uci.edu by balboa.eng.uci.edu with SMTP id AA00775 (5.65c/IDA-1.4.4 for freebsd-bugs@freebsd.org); Mon, 8 May 1995 01:23:18 -0700 Received: from localhost by newport.ece.uci.edu (5.x) id AA06479; Mon, 8 May 1995 01:23:16 -0700 Message-Id: <9505080823.AA06479@newport.ece.uci.edu> To: davidg@Root.COM Cc: freebsd-bugs@FreeBSD.org Subject: Re: freeze up In-Reply-To: Your message of "Mon, 08 May 1995 00:06:22 PDT." <199505080706.AAA00158@corbin.Root.COM> Date: Mon, 08 May 1995 01:23:15 -0700 From: Steven Wallace Sender: bugs-owner@FreeBSD.org Precedence: bulk >>So I found this experience very odd because existing processes continued >>to run fine until they ran into something that blocked them from continuing >>anymore while new commands (ls, kill, ps I tried) would freeze right >>away - until I terminated this cc process. Any ideas on what this could >>be? What should I do if I experience this freeze with a partial lock-up? > > Sounds like a vnode locking problem that eventually leads to locking the > root directory (at which point your dead). I don't know what could be causing > it, though. wcarchive is running -current from about 3 days ago and has been > up running fine since (and this is with 250-300 users and mild paging) and I > haven't seen the problem on my own machines. We did have problems like this > a month or so ago, but the causes of those have been fixed. As far as what to > do next time it happens...hmmm, if you can get to the console vty, you could > escape to the debugger and do a 'ps' to find out what the processes are all > sleeping on. Since your windows appear to still be mostly alive, you might try > typing "ctrl-T" and noting the wmesg (the part in brackets that comes after > the PID). This would provide more clues, perhaps. > Okay, I am writing you live with a vnode lockup (again) :) One other factor I didn't mention is the last two weeks I have been working on my application that used shared memory mapping frequently. This time the lockup seems to hinting toward a memory mapped prob. Take a look at what I did: pal-r32-a07b-gs >> fg textscr ebank ^C pal-r32-a07b-gs >> fg shr ebank 12000 ^C pal-r32-a07b-gs >> rmf ebank ^C^C^C The two programs textscr and shr share the file named ebank. I quit those two programs leaving nothing using the resource any longer. Then the filesystem hung when attempting to remove the file. Perhaps there were some dirty pages in there and it had a problem writing it back or something along those lines. Here is my ps listing. I think I will go to sleep now. I will check my email in the morning if you have any other commands you wish me to type before I reboot. I have one shell in which to put commands in the background. Steven pal-r32-a07b-gs >> ps -a & [5] 539 pal-r32-a07b-gs >> PID TT STAT TIME COMMAND 200 p0 IWs+ 0:00.23 -csh (tcsh) 199 p1 IWs+ 0:00.42 -csh (tcsh) 198 p2 IWs+ 0:00.27 -csh (tcsh) 238 p3 Is 0:00.63 -csh (tcsh) 512 p3 D+ 0:00.01 /bin/rm -f ebank 241 p4 Ss+ 0:00.92 -csh (tcsh) 513 p4 D 0:00.01 ls -CF 517 p4 D 0:00.01 ls -CF / 518 p4 D 0:00.01 ls -CF /tmp 523 p4 S 0:00.37 xterm -T free -n free -e rlogin free 527 p4 S 0:00.29 xterm -T newport -n newport -e rlogin newport 533 p4 I 0:00.24 xterm 539 p4 R 0:00.00 ps -a 245 p5 IWs+ 0:00.79 rlogin newport 248 p5 IW+ 0:00.53 rlogin newport 524 p6 Is+ 0:00.11 rlogin free 525 p6 I+ 0:00.03 rlogin free 528 p7 Is+ 0:00.09 rlogin newport 529 p7 I+ 0:00.01 rlogin newport 534 p8 Ds+ 0:00.04 tcsh 168 v0 IWs 0:00.31 -tcsh (tcsh) 178 v0 IW+ 0:00.09 xinit 180 v0 S 0:09.35 fvwm -display :0 186 v0 IW 0:00.67 xterm -fn 9x15 -geometry 80x24+0+34 #+0+0 -s -sb -n << 188 v0 S 0:04.39 xclock -digital -geometry 185x24+0+0 -bw 1 -update 1 190 v0 IW 0:00.96 xterm -sb -fn 9x15 -geometry 80x30+0-0 -title Shell -n 192 v0 IW 0:00.30 xterm -sb -fn fixed -geometry 80x65-0+0 -title Shell - 196 v0 IN 2:02.33 xearth -nice 10 197 v0 I 0:00.22 /usr/X11R6/lib/X11/fvwm/GoodStuff 8 5 /users/swallace/ 237 v0 I 0:01.18 xterm -n Shell 240 v0 R 0:28.32 xterm -n Shell 244 v0 IW 0:02.74 xterm -T newport -n newport -e rlogin newport 247 v0 I 0:24.09 emacs 374 v0 IW 0:00.38 hexcalc 169 v1 IWs+ 0:00.02 /usr/libexec/getty Pc ttyv1 170 v2 IWs+ 0:00.02 /usr/libexec/getty Pc ttyv2 171 v3 IWs+ 0:00.02 /usr/libexec/getty Pc ttyv3 172 v4 IWs+ 0:00.02 /usr/libexec/getty Pc ttyv4 173 v5 IWs+ 0:00.02 /usr/libexec/getty Pc ttyv5 208 a0 IWs+ 0:00.01 slattach -l -s 38400 /dev/cuaa0 From owner-freebsd-bugs Mon May 8 01:44:08 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id BAA21911 for bugs-outgoing; Mon, 8 May 1995 01:44:08 -0700 Received: from thoth.mch.sni.de (thoth.mch.sni.de [192.35.17.2]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id BAA21905 for ; Mon, 8 May 1995 01:44:05 -0700 Received: from hathor.mch.sni.de by thoth.mch.sni.de with SMTP id AA10508 (5.67a/IDA-1.5 for <@mail.mch.sni.de:bugs@FreeBSD.org>); Mon, 8 May 1995 10:43:31 +0200 Received: by hathor.mch.sni.de (931110.SGI/930416.SGI.AUTO) for @mail.mch.sni.de:bugs@FreeBSD.org id AA05668; Mon, 8 May 95 10:45:08 +0200 From: Hans.Wander@mch.sni.de (Hans Wander) Message-Id: <9505080845.AA05668@hathor.mch.sni.de> Subject: bug in pkd_add To: bugs@FreeBSD.org Date: Mon, 8 May 1995 10:45:07 +0200 (MDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 504 Sender: bugs-owner@FreeBSD.org Precedence: bulk Hi folks, I'v found a bug in the sources of pkg_add: in the file perform.c, line 215-216 the function call execl("/usr/sbin/mtree",....) is not terminated with a NULL pointer it should be: execl("/usr/sbin/mtree",....,NULL) Hans PS: pkg_manage crashes with segmentation fault and dumps a core; PPS: I'm using the 041595-SNAP release. -- Siemens-Nixdorf Informationssysteme Carl Wery Str. 22, 81739 Muenchen, Germany Tel.: + 49 (89) 636-43496, FAX: + 49 (89) 636-40926 e-mail: Hans.Wander@mch.sni.de From owner-freebsd-bugs Mon May 8 02:34:51 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id CAA23933 for bugs-outgoing; Mon, 8 May 1995 02:34:51 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id CAA23924 for ; Mon, 8 May 1995 02:34:45 -0700 Received: from corbin.Root.COM (corbin.Root.COM [198.145.90.18]) by Root.COM (8.6.8/8.6.5) with ESMTP id CAA00216; Mon, 8 May 1995 02:37:46 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.11/8.6.5) with SMTP id CAA00191; Mon, 8 May 1995 02:34:43 -0700 Message-Id: <199505080934.CAA00191@corbin.Root.COM> To: Steven Wallace cc: freebsd-bugs@FreeBSD.org Subject: Re: freeze up In-reply-to: Your message of "Mon, 08 May 95 01:23:15 PDT." <9505080823.AA06479@newport.ece.uci.edu> From: David Greenman Reply-To: davidg@Root.COM Date: Mon, 08 May 1995 02:34:41 -0700 Sender: bugs-owner@FreeBSD.org Precedence: bulk >One other factor I didn't mention is the last two weeks I have been working >on my application that used shared memory mapping frequently. Ah. Yeah, shared memory is broken - this is a known problem and it does cause problems just like you're describing. >pal-r32-a07b-gs >> ps -a & >[5] 539 >pal-r32-a07b-gs >> PID TT STAT TIME COMMAND This is useless without "-l". I need to know the "WCHAN". -DG From owner-freebsd-bugs Mon May 8 02:43:49 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id CAA24636 for bugs-outgoing; Mon, 8 May 1995 02:43:49 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id CAA24615 for ; Mon, 8 May 1995 02:43:45 -0700 Received: from corbin.Root.COM (corbin.Root.COM [198.145.90.18]) by Root.COM (8.6.8/8.6.5) with ESMTP id CAA00233; Mon, 8 May 1995 02:46:47 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.11/8.6.5) with SMTP id CAA00209; Mon, 8 May 1995 02:43:43 -0700 Message-Id: <199505080943.CAA00209@corbin.Root.COM> To: Steven Wallace cc: freebsd-bugs@FreeBSD.org Subject: Re: freeze up In-reply-to: Your message of "Mon, 08 May 95 02:34:41 PDT." <199505080934.CAA00191@corbin.Root.COM> From: David Greenman Reply-To: davidg@Root.COM Date: Mon, 08 May 1995 02:43:43 -0700 Sender: bugs-owner@FreeBSD.org Precedence: bulk >>One other factor I didn't mention is the last two weeks I have been working >>on my application that used shared memory mapping frequently. > > Ah. Yeah, shared memory is broken - this is a known problem and it does >cause problems just like you're describing. ...just a clarification: I meant "SYSV shared memory is broken". MAP_SHARED with mmap() should work fine. -DG From owner-freebsd-bugs Mon May 8 09:12:53 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA03553 for bugs-outgoing; Mon, 8 May 1995 09:12:53 -0700 Received: from webserv1.buffnet.net (webserv1.buffnet.net [198.3.120.15]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id JAA03547 for ; Mon, 8 May 1995 09:12:47 -0700 Received: (from root@localhost) by webserv1.buffnet.net (8.6.9/8.6.9) id KAA02872 for bugs@FreeBSD.org; Mon, 8 May 1995 10:12:42 GMT Date: Mon, 8 May 1995 10:12:42 GMT From: User Shovey Message-Id: <199505081012.KAA02872@webserv1.buffnet.net> To: bugs@FreeBSD.org Subject: strange tcpip problems Sender: bugs-owner@FreeBSD.org Precedence: bulk I have a number of servers on my network. 3 are SCO machines with multiple digiboard term servers 2 are linux boxes 2 are freebsd 2 boxes I can telnet into my termservers to do maintenance from sco or linux but if I try from a frebsd box, the telnet hangs. and WORSE the sco bozes lose their connection to the term servers and all my TR lights go out, and the sco's gen humugous errors  From owner-freebsd-bugs Mon May 8 10:12:45 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA05149 for bugs-outgoing; Mon, 8 May 1995 10:12:45 -0700 Received: from silver.sdsmt.edu (root@silver.sdsmt.edu [151.159.1.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id KAA05141 for ; Mon, 8 May 1995 10:12:41 -0700 Received: from msmail.sdsmt.edu (msmail.sdsmt.edu [151.159.1.43]) by silver.sdsmt.edu (8.6.12/8.6.12) with SMTP id LAA35338 for ; Mon, 8 May 1995 11:12:38 -0600 Received: by msmail.sdsmt.edu with Microsoft Mail id <2FAE5106@msmail.sdsmt.edu>; Mon, 08 May 95 11:12:38 MDT From: "Unser, Danny" To: "'FreeBSD - Bugs'" Subject: pkg_installs & 2.0-950412-SNAP Date: Mon, 08 May 95 11:09:00 MDT Message-ID: <2FAE5106@msmail.sdsmt.edu> Encoding: 7 TEXT X-Mailer: Microsoft Mail V3.0 Sender: bugs-owner@FreeBSD.org Precedence: bulk All of the new packages I've grabbed cannot get extracted by using pkg_add or pkg_manage. The mtree always gives an error of "Error status 1 from mtree." Dan dunser@msmailgw.sdsmt.edu From owner-freebsd-bugs Mon May 8 10:45:08 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA05934 for bugs-outgoing; Mon, 8 May 1995 10:45:08 -0700 Received: from gw2.att.com (gw1.att.com [192.20.239.133]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id KAA05925 for ; Mon, 8 May 1995 10:45:04 -0700 From: sung!imdave@iwcs.att.com Received: from iwcs!sung.UUCP by ig1.att.att.com id AA06077; Mon, 8 May 95 13:45:08 EDT Message-Id: <9505081745.AA06077@ig1.att.att.com> Date: 8 May 95 12:43:00 -0500 To: freebsd-bugs@FreeBSD.org Original-To: iwcs!att!FreeBSD.org!freebsd-bugs Subject: Process hangs sleeping in ufslk2 Content-Type: text Sender: bugs-owner@FreeBSD.org Precedence: bulk Hi, Using the Apr SNAP, I tried installing pdksh 5.1.3 When I run the configure script, it gets to the point where it is "testing for a working mmap". At this point it hangs. A ps shows it's sleeping on "ufslk2" which I assume has something to do with the UFS fs. This would explain why a ls of the pdksh directory also hangs... The process is unkillable, and a reboot is required. If necessary I can include the source for the mmap test program that the pdksh configure script is running. Dave Bodenstab ...att!iwcs!imdave PS. I had previously installed pdksh 5.1.2 on FreeBSD 2.0 from last Dec and it installed with no problems... of course I don't know if it checked for mmap at that time... From owner-freebsd-bugs Mon May 8 10:59:06 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA06197 for bugs-outgoing; Mon, 8 May 1995 10:59:06 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id KAA06191 for ; Mon, 8 May 1995 10:59:04 -0700 Received: (dyson@localhost) by Root.COM (8.6.8/8.6.5) id LAA00848; Mon, 8 May 1995 11:01:59 -0700 Date: Mon, 8 May 1995 11:01:59 -0700 From: John Dyson Message-Id: <199505081801.LAA00848@Root.COM> To: freebsd-bugs@FreeBSD.org, sung!imdave@iwcs.att.com Subject: Re: Process hangs sleeping in ufslk2 Sender: bugs-owner@FreeBSD.org Precedence: bulk When installing pdksh on the April snapshot, you are likely to run into this problem. It comes about because of a bug in the merged VM/Buffer cache code. (Specifically, that version of the code could not deal with I/O to/from an mmaped region to the file that the mmaped region represents.) Something like this: fd = open("evilfile", O_RDWR); addr = mmap(...,fd,...) write(fd, addr, size); -- you hang here. This problem has been fixed in the -current and in the 2.0.5 release coming up. It is very likely that many of the "mysterious" ufslk2 hangs had been due to this. Personal note: Dave, I am at Lisle (810-6136...) John dyson@root.com From owner-freebsd-bugs Mon May 8 12:01:21 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA07722 for bugs-outgoing; Mon, 8 May 1995 12:01:21 -0700 Received: from largo.remailer.net ([204.94.187.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id MAA07716 for ; Mon, 8 May 1995 12:01:18 -0700 Received: (from eric@localhost) by largo.remailer.net (8.6.8/8.6.6) id MAA00350; Mon, 8 May 1995 12:01:12 -0700 Date: Mon, 8 May 1995 12:01:12 -0700 Message-Id: <199505081901.MAA00350@largo.remailer.net> To: bugs@FreeBSD.org Subject: installation error From: eric@remailer.net (Eric Hughes) Sender: bugs-owner@FreeBSD.org Precedence: bulk I'm getting a panic during installation from floppy/cdrom of FreeBSD 2.0. It's happening right after this line: sysinstall/stage2.c:90: TellEm("unzipping /stand/sysinstall onto hard disk"); That's the last message I get on the debug screen. Immediately after that, I get another message, whose source I've located: kern/vfs_bio.c:379: panic("getnewbuf: inconsistent EMPTY queue"); I get this message when I don't write-protect the boot floppy. When I write-protect the boot floppy, the system just reboots after a pause. I'm doing the installation on a brand new hard disk I bought just so that I wouldn't have to fuck up my existing system, a caution I am glad I took and unhappy that I had to. Eric From owner-freebsd-bugs Mon May 8 12:31:09 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA08116 for bugs-outgoing; Mon, 8 May 1995 12:31:09 -0700 Received: from crete.doc.ic.ac.uk (crete.doc.ic.ac.uk [146.169.21.30]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id MAA07981 for ; Mon, 8 May 1995 12:20:56 -0700 Received: by crete.doc.ic.ac.uk (Smail3.1.28.1 #7) id m0s8Tt4-0005tlC; Mon, 8 May 95 15:34 BST Message-Id: Date: Mon, 8 May 95 15:34 BST From: kd@doc.ic.ac.uk (Kostis Dryllerakis) To: bugs@FreeBSD.org Subject: [Bug]: Machine reset with ppp/route (reproducible) Sender: bugs-owner@FreeBSD.org Precedence: bulk Hi, I stumbled across the next interesting situation which causes a soft reset to my machine. To reproduce it do the following Boot without any network configuration (e.g. single user) enter the commands: ifconfig ppp0 inet 200.200.21.21 200.200.21.30 netmask 0xffffff00 route add default 200.200.21.1 and then finger @200.200.2.1 (or any other command trying to get out of the router) ----- The IP addresses ofcourse are NOT real and they only serve as an example. Any ideas what is causing the problems and what the cure is? As far as I can tell it was also present in the previous SNAP as well as the latest one (FreeBSD 2.0.950412-SNAP). I have also had resets at funny moments after disconnecting the ppp service -but I doubt it if these are reproducible. Kostis Dryllerakis ------------------------------------------------------------------------------- K J Dryllerakis Deparment of Computing Logic Programming Group Imperial College, LONDON Tel: +44(171)594 8216 http://www-lp.doc.ic.ac.uk/~kd/ Fax: +44(71)581 8024 Uucp : kd@icdoc.UUCP Internet: kd@doc.ic.ac.uk ------------------------------------------------------------------------------- From owner-freebsd-bugs Mon May 8 13:21:18 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id NAA09178 for bugs-outgoing; Mon, 8 May 1995 13:21:18 -0700 Received: from wc.cdrom.com (wc.cdrom.com [192.216.223.37]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id NAA09172 for ; Mon, 8 May 1995 13:21:15 -0700 Received: from crete.doc.ic.ac.uk (crete.doc.ic.ac.uk [146.169.21.30]) by wc.cdrom.com (8.6.12/8.6.12) with SMTP id NAA09005 for ; Mon, 8 May 1995 13:18:53 -0700 Received: by crete.doc.ic.ac.uk (Smail3.1.28.1 #7) id m0s8Tt4-0005tlC; Mon, 8 May 95 15:34 BST Message-Id: Date: Mon, 8 May 95 15:34 BST From: kd@doc.ic.ac.uk (Kostis Dryllerakis) To: bugs@FreeBSD.org Subject: [Bug]: Machine reset with ppp/route (reproducible) Sender: bugs-owner@FreeBSD.org Precedence: bulk Hi, I stumbled across the next interesting situation which causes a soft reset to my machine. To reproduce it do the following Boot without any network configuration (e.g. single user) enter the commands: ifconfig ppp0 inet 200.200.21.21 200.200.21.30 netmask 0xffffff00 route add default 200.200.21.1 and then finger @200.200.2.1 (or any other command trying to get out of the router) ----- The IP addresses ofcourse are NOT real and they only serve as an example. Any ideas what is causing the problems and what the cure is? As far as I can tell it was also present in the previous SNAP as well as the latest one (FreeBSD 2.0.950412-SNAP). I have also had resets at funny moments after disconnecting the ppp service -but I doubt it if these are reproducible. Kostis Dryllerakis ------------------------------------------------------------------------------- K J Dryllerakis Deparment of Computing Logic Programming Group Imperial College, LONDON Tel: +44(171)594 8216 http://www-lp.doc.ic.ac.uk/~kd/ Fax: +44(71)581 8024 Uucp : kd@icdoc.UUCP Internet: kd@doc.ic.ac.uk ------------------------------------------------------------------------------- From owner-freebsd-bugs Mon May 8 20:30:21 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id UAA01994 for bugs-outgoing; Mon, 8 May 1995 20:30:21 -0700 Received: from mail.holonet.net (root@guardian.holonet.net [198.207.169.11]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id UAA01988 for ; Mon, 8 May 1995 20:30:20 -0700 From: sysop@cantec.com Received: from cantec (root@localhost) by mail.holonet.net with UUCP id UAA13326; Mon, 8 May 1995 20:19:19 -0700 Received: by cantec.com id 0W646001 Mon, 08 May 95 22:53:58 -0400 Message-ID: <9505082253.0W64600@cantec.com> Organization: CanTec Associates X-Mailer: TBBS/PIMP v3.35 Date: Mon, 08 May 95 22:53:58 -0400 Subject: Intstallation bugs To: bugs@FreeBSD.org Sender: bugs-owner@FreeBSD.org Precedence: bulk All of the installation material indicates that time is accounted for when the offset from GMT or Universal Time is known. I have repeatedly tried to set the time to local time and have been met with wrong times. In my time zone, and in my opinion, the time routine just does not work. Dave Bigham dbigham@cantec.com From owner-freebsd-bugs Mon May 8 21:00:01 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA02512 for bugs-outgoing; Mon, 8 May 1995 21:00:01 -0700 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA02505 ; Mon, 8 May 1995 21:00:00 -0700 Date: Mon, 8 May 1995 21:00:00 -0700 Message-Id: <199505090400.VAA02505@freefall.cdrom.com> From: bpk@kern.com Reply-To: bpk@kern.com To: freebsd-bugs Subject: kern/388: Printing extremely slow when printing with a Deskjet 540. In-Reply-To: Your message of Mon, 8 May 1995 20:34:58 -0700 <199505090334.UAA00560@tortoise.kern.com> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 388 >Category: kern >Synopsis: Printing extremely slow when printing with a Deskjet 540. >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 May 8 21:00:00 1995 >Originator: Brian Koehmstedt >Organization: Kern Internet Services -- Bakersfield, CA bpk@kern.com >Release: FreeBSD 2.1.0-Development i386 >Environment: Observed with HP Deskjet 540 printer. Using printer on LPT1 (/dev/lpt0). >Description: When I dump anything (tried both cat and lpr) to the printer device the following things occur: #1) Printer immediately loads up the paper as it normally would to begin printing. #2) Pauses without printing a single character for roughly 3-5 minutes. #3) Prints a line or two. Pauses for a long amount of time. An average pause seems to be around 10-15 minutes. I have a feeling it pauses longer with longer files. Then prints another line or two. Continues looping in this fashion. I'm sure this isn't a problem with my printer. This exact printer has worked previously under NetBSD, Linux, and DOS. Seems to me this might be some kind of buffer problem in the kernel code. I've tried printing both raw text and PCL formatted files and both had the same problem described above. >How-To-Repeat: Using a HP Deskjet 540 printer (or possibly others too): cat > /dev/lpt0 >Fix: >Audit-Trail: >Unformatted: From owner-freebsd-bugs Mon May 8 21:20:01 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA03231 for bugs-outgoing; Mon, 8 May 1995 21:20:01 -0700 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA03224 ; Mon, 8 May 1995 21:20:01 -0700 Date: Mon, 8 May 1995 21:20:01 -0700 Message-Id: <199505090420.VAA03224@freefall.cdrom.com> From: uhclem@nemesis.lonestar.org (Frank Durda IV) Reply-To: uhclem@nemesis.lonestar.org (Frank Durda IV) To: freebsd-bugs Subject: bin/389: Problem #FDIV024 In-Reply-To: Your message of Mon, 8 May 95 23:05 CDT Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 389 >Category: bin >Synopsis: Simultaneous creation/deletion of dirs corrupts filesystem [FDIV024] >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon May 8 21:20:00 1995 >Originator: Frank Durda IV >Organization: >Release: FreeBSD 2.0.950412-SNAP i386 and FreeBSD 1.1.5.1 >Environment: [FDIV024] FreeBSD 2.0.950412-SNAP i386 Stock kernel, "make world" kernel, or custom kernel. Problem also noted in FreeBSD 1.1.5.1 on stock and custom kernel. >Description: On my 1.1.5.1, I discovered that I frequently ended-up with directories that could not be deleted in my news partition. The reason rmdir refused to delete the directories was due to bad link counts. Running fsck at least two times would correct the link counts so that the directories could be deleted. I recently discovered that I could cause bogus link counts on demand, simply by trying to remove files and directories while other processes were trying to create files and directories in the same tree. In my case, I was doing some rm -rf commands on selected portions of the newsgroups to obtain space, but at the same time the cnews system was injecting new articles and re-creating some of the directories I was deleting. Note that the partition DOES NOT have to be low on space to create the problem. I reproduced it on a root filesystem that had 7.7Meg free worst case. I tested the latest snapshot and determined the problem still exists. >How-To-Repeat: By using tar and rm I can reproduce the problem on the latest SNAP or 1.1.5.1. In my case, I created a tar file containing about 6 Meg of a heavily expired alt.* tree using cd /usr/spool/news/alt tar cvf /tmp/news.tar * FYI, the alt tree consisted of 538 directories and 1684 files. It seems more important to have a large number of directories than it is to have lots of files. Using the news tree provided this but the failure can probably be caused by using other distribution trees that have lots of directories and small files. Now login on the system to test on at least two screens as root. On screen 1, cd / mkdir test cd test Now, ftp news.tar file from remote system to this location. DO NOT USE /tmp in place of /test! (If you crash - you lose things) mkdir scramble cd scramble tar xvf ../news.tar sync You can fsck here to verify things are sane at this point if you want. Now that the news tree is extracted, begin to exercise the system. The numbers indicate which virtual screen to use for the commands: 1 tar xvf ../news.tar & 2 rm -rf [l-r]* & 2 rm -rf [a-k]* & 2 rm -rf [0-9]* & 2 rm -rf [s-z]* & Now monitor on screen 1 until the tar is about half-way through (by directory), and then repeat all of the above commands. Now wait until both tars complete and wait for all of the rm's to finish. Then issue: rm -rf * and note any "Directory not removed..." messages. If the rm finishes and you didn't get any error messages, start over, and maybe start three cycles of extract and rm running at once. [WARNING - Doing too many extract/rm pairs at once caused the processes to hang with no disk I/O. Characters were echoed (for a while) and CAPS LOCK toggles. Then the system output a message indicating that syslogd had terminated and that it was syncing disks. However it just hung there and never halted. This only happened once and may be related to the VNODE lock problem. I think this lock/shutdown is unrelated to the problem I am reporting. My systems have between 8 and 12 Meg of RAM] Using the above procedure, I eventually ended up with the following undeletable directories: ls -aliR total 5 9032 drwxrwxr-x 4 root bin 3072 May 8 21:55 . 142 drwxrwxr-x 3 root wheel 512 May 8 21:55 .. 13788 drwxrwxr-x 5 news news 512 May 8 21:49 politics 13524 drwxrwxr-x 10 news news 512 May 8 21:49 society scramble/politics: total 4 13788 drwxrwxr-x 5 news news 512 May 8 21:49 . 9032 drwxrwxr-x 4 root bin 3072 May 8 21:55 .. scramble/society: total 4 13524 drwxrwxr-x 10 news news 512 May 8 21:49 . 9032 drwxrwxr-x 4 root bin 3072 May 8 21:55 .. I then sync'ed and halted the system. On reboot, I ran fsck with these results: fsck -y /dev/wd0a ** /dev/rwd0a ** Last Mounted on / ** Root file system ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity UNREF DIR I=13581 OWNER=news MODE=40775 SIZE=512 MTIME=May 8 21:43 1995 RECONNECT? [yn] DIR I=13581 CONNECTED. PARENT WAS I=13524 UNREF DIR I=13578 OWNER=news MODE=40775 SIZE=512 MTIME=May 8 21:43 1995 RECONNECT? [yn] DIR I=13578 CONNECTED. PARENT WAS I=13524 UNREF DIR I=13544 OWNER=news MODE=40775 SIZE=512 MTIME=May 8 21:43 1995 RECONNECT? [yn] DIR I=13544 CONNECTED. PARENT WAS I=13524 UNREF DIR I=13792 OWNER=news MODE=40775 SIZE=512 MTIME=May 8 21:47 1995 RECONNECT? [yn] DIR I=13792 CONNECTED. PARENT WAS I=13788 UNREF DIR I=13539 OWNER=news MODE=40775 SIZE=512 MTIME=May 8 21:43 1995 RECONNECT? [yn] DIR I=13539 CONNECTED. PARENT WAS I=13524 UNREF DIR I=13555 OWNER=news MODE=40775 SIZE=512 MTIME=May 8 21:43 1995 RECONNECT? [yn] DIR I=13555 CONNECTED. PARENT WAS I=13524 UNREF DIR I=13536 OWNER=news MODE=40775 SIZE=512 MTIME=May 8 21:43 1995 RECONNECT? [yn] DIR I=13536 CONNECTED. PARENT WAS I=13524 UNREF DIR I=9037 OWNER=news MODE=40775 SIZE=512 MTIME=May 8 21:43 1995 RECONNECT? [yn] DIR I=9037 CONNECTED. PARENT WAS I=13524 UNREF DIR I=399 OWNER=news MODE=40775 SIZE=512 MTIME=May 8 21:47 1995 RECONNECT? [yn] DIR I=399 CONNECTED. PARENT WAS I=13788 UNREF DIR I=4892 OWNER=news MODE=40775 SIZE=512 MTIME=May 8 21:47 1995 RECONNECT? [yn] DIR I=4892 CONNECTED. PARENT WAS I=13788 UNREF DIR I=166 OWNER=news MODE=40775 SIZE=512 MTIME=May 8 21:43 1995 RECONNECT? [yn] DIR I=166 CONNECTED. PARENT WAS I=13524 ** Phase 4 - Check Reference Counts LINK COUNT DIR I=166 OWNER=news MODE=40775 SIZE=512 MTIME=May 8 21:43 1995 COUNT 1 SHOULD BE 2 ADJUST? [yn] LINK COUNT DIR I=399 OWNER=news MODE=40775 SIZE=512 MTIME=May 8 21:47 1995 COUNT 2 SHOULD BE 3 ADJUST? [yn] LINK COUNT DIR I=4892 OWNER=news MODE=40775 SIZE=512 MTIME=May 8 21:47 1995 COUNT 1 SHOULD BE 2 ADJUST? [yn] LINK COUNT DIR I=9037 OWNER=news MODE=40775 SIZE=512 MTIME=May 8 21:43 1995 COUNT 1 SHOULD BE 2 ADJUST? [yn] LINK COUNT DIR I=13536 OWNER=news MODE=40775 SIZE=512 MTIME=May 8 21:43 1995 COUNT 1 SHOULD BE 2 ADJUST? [yn] LINK COUNT DIR I=13539 OWNER=news MODE=40775 SIZE=512 MTIME=May 8 21:43 1995 COUNT 1 SHOULD BE 2 ADJUST? [yn] LINK COUNT DIR I=13544 OWNER=news MODE=40775 SIZE=512 MTIME=May 8 21:43 1995 COUNT 1 SHOULD BE 2 ADJUST? [yn] LINK COUNT DIR I=13555 OWNER=news MODE=40775 SIZE=512 MTIME=May 8 21:43 1995 COUNT 1 SHOULD BE 2 ADJUST? [yn] LINK COUNT DIR I=13578 OWNER=news MODE=40775 SIZE=512 MTIME=May 8 21:43 1995 COUNT 1 SHOULD BE 2 ADJUST? [yn] LINK COUNT DIR I=13581 OWNER=news MODE=40775 SIZE=512 MTIME=May 8 21:43 1995 COUNT 1 SHOULD BE 2 ADJUST? [yn] LINK COUNT DIR I=13792 OWNER=news MODE=40775 SIZE=512 MTIME=May 8 21:47 1995 COUNT 1 SHOULD BE 2 ADJUST? [yn] ** Phase 5 - Check Cyl groups CLEAN FLAG NOT SET IN SUPERBLOCK FIX? [yn] 924 files, 43271 used, 32792 free (272 frags, 4065 blocks, 0.4% fragmentation) ***** FILE SYSTEM WAS MODIFIED ***** ***** REBOOT NOW ***** Now I re-ran fsck because in the past it always took multiple passes to really correct the problems: fsck -y /dev/wd0a ** /dev/rwd0a ** Last Mounted on / ** Root file system ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts LINK COUNT DIR I=13524 OWNER=news MODE=40775 SIZE=512 MTIME=May 8 21:49 1995 COUNT 10 SHOULD BE 2 ADJUST? [yn] LINK COUNT DIR I=13788 OWNER=news MODE=40775 SIZE=512 MTIME=May 8 21:49 1995 COUNT 5 SHOULD BE 2 ADJUST? [yn] ** Phase 5 - Check Cyl groups 924 files, 43271 used, 32792 free (272 frags, 4065 blocks, 0.4% fragmentation) ***** FILE SYSTEM WAS MODIFIED ***** ***** REBOOT NOW ***** Finally, I re-ran fsck a third time: ** /dev/rwd0a ** Last Mounted on / ** Root file system ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 924 files, 43271 used, 32792 free (272 frags, 4065 blocks, 0.4% fragmentation) Ok, now here is what the directory looks like now: total 6102 142 drwxrwxr-x 3 root wheel 512 May 8 22:04 . 2 drwxr-xr-x 17 root wheel 512 May 8 21:55 .. 143 -rw-rw-r-- 1 root wheel 505 May 8 21:55 sample1 * 145 -rw-rw-r-- 1 root wheel 3135 May 8 22:01 sample2 * 146 -rw-rw-r-- 1 root wheel 588 May 8 22:02 sample3 * 147 -rw-rw-r-- 1 root wheel 297 May 8 22:02 sample4 * 148 -rw-rw-r-- 1 root wheel 0 May 8 22:04 sample5 * 9032 drwxrwxr-x 4 root bin 3072 May 8 21:55 scramble 144 -rw-rw-r-- 1 root wheel 6225920 May 8 21:55 news.tar ./scramble: total 5 9032 drwxrwxr-x 4 root bin 3072 May 8 21:55 . 142 drwxrwxr-x 3 root wheel 512 May 8 22:04 .. 13788 drwxrwxr-x 2 news news 512 May 8 21:49 politics 13524 drwxrwxr-x 2 news news 512 May 8 21:49 society ./scramble/politics: total 4 13788 drwxrwxr-x 2 news news 512 May 8 21:49 . 9032 drwxrwxr-x 4 root bin 3072 May 8 21:55 .. ./scramble/society: total 4 13524 drwxrwxr-x 2 news news 512 May 8 21:49 . 9032 drwxrwxr-x 4 root bin 3072 May 8 21:55 .. * are the "tee" logs of fsck and ls" for the bug report. They were written to a different partition and moved back to this location after the fscks completed and the system was rebooted. At this point, "politics" and "society" could be deleted with rmdir. (The directories and their files reconnected by fsck land in lost+found.) >Fix: Not known. *END* >Audit-Trail: >Unformatted: From: uhclem%nemesis@fw.ast.com cc: uhclem Reply-To: uhclem%nemesis@fw.ast.com X-send-pr-version: 3.2 From owner-freebsd-bugs Mon May 8 22:11:51 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA03794 for bugs-outgoing; Mon, 8 May 1995 22:11:51 -0700 Received: from RosedeLima.Vir.com (RosedeLima.Vir.com [199.84.154.65]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id WAA03779 ; Mon, 8 May 1995 22:10:07 -0700 Received: from ipdyne3.vir.com by Vir.com (8.6.10/2.0) id AAA30852; Tue, 9 May 1995 00:01:23 -0500 Date: Tue, 9 May 1995 00:01:23 -0500 Message-Id: <199505090501.AAA30852@Vir.com> X-Sender: procecorjb@vir.com X-Mailer: Windows Eudora Version 1.4.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: bugs@FreeBSD.org From: procecorjb@Vir.com (Robert Burns) Subject: Pine Bug Cc: questions@FreeBSD.org Sender: bugs-owner@FreeBSD.org Precedence: bulk I have recently compiled Pine after downloading the most current port and I have have experienced the following problem: I connect to my host {vir.com/pop3} and after logging in, I get a message that I have x messages in my "inbox". Then when I try to open my inbox, after loading a few messages, pine aborts with the message: Bug in Pine detected: "Recieved abort signal". Exiting Pine When extracting and reading news however, all is fine. I've tried both the "popper" and "ipop3d" POP interfaces and there is no difference. Has this been reported before, is there a fix? Robert Burns procecorjb@vir.com mtl,ca From owner-freebsd-bugs Mon May 8 23:43:50 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id XAA05082 for bugs-outgoing; Mon, 8 May 1995 23:43:50 -0700 Received: from quicknet.transport.com (quicknet.transport.com [204.119.17.160]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id XAA05076 for ; Mon, 8 May 1995 23:43:48 -0700 Received: (from timb@localhost) by quicknet.transport.com (8.6.9/8.6.9) id XAA00445 for bugs@freebsd.org; Mon, 8 May 1995 23:33:41 -0700 Date: Mon, 8 May 1995 23:33:41 -0700 From: Email or /msg me for information on how to get accounts Message-Id: <199505090633.XAA00445@quicknet.transport.com> To: bugs@FreeBSD.org Sender: bugs-owner@FreeBSD.org Precedence: bulk Subject:Reboot's under latest snap and latest sup I installed the latest snap and it's been doing ok for a while.. Recently i get reboot 's when using slip and the latest kernel and the latest snap.. Tried them both..Was hoping maybe the problem was fixed later .. Apparently it wasn't so.. I don't know what is causing the reboot's but people have been online doing thing's when it happens.. Just not sure what.. Doesnt seem to happen to often...Often enough to be a problem though.. Don't know if this will help but i am running a 486 dx 66 8 meg's of ram 3 internal 28.8 modem's Adaptect SCSI card with 3.6 gig micropolis drive.. One of the time's it happend somebody was online and all i did was switch virtual consoles. Oh yeah and i am running pcvt also.. Anyone got any clues on this?. Is this a known problem? From owner-freebsd-bugs Tue May 9 01:45:48 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id BAA06652 for bugs-outgoing; Tue, 9 May 1995 01:45:48 -0700 Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id BAA06646 for ; Tue, 9 May 1995 01:45:41 -0700 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.11/8.6.9) id BAA28063; Tue, 9 May 1995 01:45:34 -0700 Date: Tue, 9 May 1995 01:45:34 -0700 Message-Id: <199505090845.BAA28063@silvia.HIP.Berkeley.EDU> To: dunser@msmailgw.sdsmt.edu CC: bugs@FreeBSD.org In-reply-to: <2FAE5106@msmail.sdsmt.edu> (dunser@msmailgw.sdsmt.edu) Subject: Re: pkg_installs & 2.0-950412-SNAP From: asami@CS.Berkeley.EDU (Satoshi Asami | =?ISO-2022-JP?B?GyRCQHUbKEI=?= =?ISO-2022-JP?B?GyRCOCsbKEIgGyRCOC0bKEI=?=) Sender: bugs-owner@FreeBSD.org Precedence: bulk * All of the new packages I've grabbed cannot get extracted by using * pkg_add or pkg_manage. The mtree always gives an error of "Error status * 1 from mtree." I belive you need to get updated versions of pkg_add and pkg_manage, as well as libdialog (and maybe something else). Sorry, this part of the tree is changing rapidly now. Satoshi From owner-freebsd-bugs Tue May 9 01:48:25 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id BAA06674 for bugs-outgoing; Tue, 9 May 1995 01:48:25 -0700 Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id BAA06668 for ; Tue, 9 May 1995 01:48:22 -0700 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.11/8.6.9) id BAA28076; Tue, 9 May 1995 01:48:04 -0700 Date: Tue, 9 May 1995 01:48:04 -0700 Message-Id: <199505090848.BAA28076@silvia.HIP.Berkeley.EDU> To: Hans.Wander@mch.sni.de CC: bugs@FreeBSD.org In-reply-to: <9505080845.AA05668@hathor.mch.sni.de> (Hans.Wander@mch.sni.de) Subject: Re: bug in pkd_add From: asami@CS.Berkeley.EDU (Satoshi Asami | =?ISO-2022-JP?B?GyRCQHUbKEI=?= =?ISO-2022-JP?B?GyRCOCsbKEIgGyRCOC0bKEI=?=) Sender: bugs-owner@FreeBSD.org Precedence: bulk * I'v found a bug in the sources of pkg_add: * in the file perform.c, line 215-216 the function call * execl("/usr/sbin/mtree",....) is not terminated with a NULL pointer * it should be: * execl("/usr/sbin/mtree",....,NULL) This problem is already fixed as we use vsystem() for that purpose now. Thanks for the report though. Satoshi From owner-freebsd-bugs Tue May 9 09:57:26 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA19455 for bugs-outgoing; Tue, 9 May 1995 09:57:26 -0700 Received: (from ache@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA19440 ; Tue, 9 May 1995 09:57:24 -0700 Date: Tue, 9 May 1995 09:57:24 -0700 From: "Andrey A. Chernov" Message-Id: <199505091657.JAA19440@freefall.cdrom.com> To: edward@edcom.com, ache, freebsd-bugs Subject: Changed information for PR bin/351 Sender: bugs-owner@FreeBSD.org Precedence: bulk Synopsis: long mail messages overflow line-count field State-Changed-From-To: open-closed State-Changed-By: ache State-Changed-When: Tue May 9 09:56:36 PDT 1995 State-Changed-Why: Fixed in v1.2 def.h From owner-freebsd-bugs Tue May 9 10:21:04 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA20004 for bugs-outgoing; Tue, 9 May 1995 10:21:04 -0700 Received: from CRASH.ECO.TWG.COM (crash.eco.twg.com [143.172.16.201]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id KAA19998 for ; Tue, 9 May 1995 10:21:01 -0700 Message-Id: <199505091721.KAA19998@freefall.cdrom.com> Received: from CRASH.ECO.TWG.COM via Pony Express VMS Mail FPI (v9.5.0-moe002); Tue, 9 May 95 13:20:36 EDT Date: Tue, 9 May 95 13:20:36 EDT From: "Reece R. Pollack" To: freebsd-bugs@FreeBSD.org Cc: reece@eco.twg.com Subject: DES Key generation bug X-Vms-To: pony%"FreeBSD-bugs@freebsd.org" X-Vms-Cc: REECE Sender: bugs-owner@FreeBSD.org Precedence: bulk FreeBSD version: 2.0-950412-SNAP It appears that the function des_random_key() (in eBones/des/rand_key.c) does not consistantly generate keys with odd byte parity. The MIT Kerberos V4-PL10 code (function des_key_sched() in lib/des/key_sched.c) checks session keys for odd byte parity, and returns an error if the check fails. This causes the FreeBSD eBones implementation to be unusable as a Kerberos V4 ticket server when MIT Kerberos V4-PL10 systems are present in the realm. Adding an additional invocation of des_set_odd_parity() corrects this problem: des_set_odd_parity((des_cblock *)key); des_cbc_cksum((des_cblock *)key,(des_cblock *)key, (long)sizeof(key),ks,(des_cblock *)data); des_set_odd_parity((des_cblock *)key); /* <-- new line */ bcopy(key,ret,sizeof(key)); I'm new to the Unix world, but I understand it's customary to supply the output of 'diff' for changes. A 'diff -e' comparison reports the following: 38a des_set_odd_parity((des_cblock *)key); From owner-freebsd-bugs Tue May 9 12:40:02 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA23884 for bugs-outgoing; Tue, 9 May 1995 12:40:02 -0700 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA23877 ; Tue, 9 May 1995 12:40:01 -0700 Date: Tue, 9 May 1995 12:40:01 -0700 Message-Id: <199505091940.MAA23877@freefall.cdrom.com> From: "DI. Christian Gusenbauer" Reply-To: "DI. Christian Gusenbauer" To: freebsd-bugs Subject: i386/390: /sys/i386/boot/kzipboot/boot.c bug In-Reply-To: Your message of Tue, 9 May 1995 21:28:40 +0200 <199505091928.VAA00461@scotty> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 390 >Category: i386 >Synopsis: missing parameter in function "boot" >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue May 9 12:40:01 1995 >Originator: DI. Christian Gusenbauer >Organization: >Release: FreeBSD 2.0-BUILT-19950505 i386 >Environment: using kzip'ed kernels >Description: The bootstrap loader starts the kernel and passes one argument "howto" to the kernel. This is also true when using kzip'ed kernels, but in "/sys/i386/boot/kzipboot/head.S" the function "_boot" is called which puts another int on the stack, so the parameter "howto" of the function "boot" refers to the wrong address. >How-To-Repeat: Just boot a kzip'ed kernel. >Fix: Add a dummy-parameter to the function "boot", like: void boot (int dummy, int howto) >Audit-Trail: >Unformatted: From owner-freebsd-bugs Tue May 9 13:46:08 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id NAA25547 for bugs-outgoing; Tue, 9 May 1995 13:46:08 -0700 Received: from mail.Germany.EU.net (mail.Germany.EU.net [192.76.144.65]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id NAA25540 for ; Tue, 9 May 1995 13:46:04 -0700 From: Bernard.Steiner@Germany.EU.net Received: by mail.Germany.EU.net with ESMTP (8.6.5:29/EUnetD-2.5.1.f) via EUnet id WAA25870; Tue, 9 May 1995 22:47:43 +0200 Message-Id: <199505092047.WAA17816@qwerty.Germany.EU.net> Received: from localhost.Germany.EU.net by qwerty.Germany.EU.net with SMTP (8.6.4/EUnetDlan-1.14-1.2.0) via EUnet for [mail.germany.eu.net] id WAA17816; Tue, 9 May 1995 22:47:42 +0200 To: freebsd-bugs@FreeBSD.org Subject: strange symlinks Date: Tue, 09 May 1995 22:47:40 +0200 Sender: bugs-owner@FreeBSD.org Precedence: bulk Folks, while playing with my FreeBSD 2.0R I came across the following oddity: Assumption: directory /tmp exits, owned by bin.bin mode 1777 then ln -s /tmp/foo /tmp/bar produces symlink /tmp/bar *owned* by bin regardless of who issued the symlink command, and subsequent rm /tmp/bar is refused for non-owner, i.e. any normal user except for bin and root. This is bogus. The next one may be a general 4.4 problem... assumption: /tmp/foo does not exist, /tmp/bar is a symlink to /tmp/foo. chdir("/tmp/bar") fails with ENOENT, but at the same time mkdir("/tmp/bar", 0x777) fails with EEXIST. Okay, so that is as per the specs in the PRM (and, thusly, probably POSIX). However, it seems sort of stranke, doesn't it ? IMHO the mkdir ought to produce a directory /tmp/foo and not fail. Third, whatever happened to the fchdir() syscall that I vaguely remember having had in (at least) 386BSD0.1 ? Thanks, Bernard From owner-freebsd-bugs Tue May 9 13:47:32 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id NAA25579 for bugs-outgoing; Tue, 9 May 1995 13:47:32 -0700 Received: from arl-img-4.compuserve.com (arl-img-4.compuserve.com [198.4.7.4]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id NAA25573 for ; Tue, 9 May 1995 13:47:30 -0700 Received: by arl-img-4.compuserve.com (8.6.10/5.941228sam) id QAA26761; Tue, 9 May 1995 16:46:53 -0400 Date: 09 May 95 16:34:45 EDT From: Charles Brill <76220.424@compuserve.com> To: All Subject: Mitsumi Install Message-ID: <950509203445_76220.424_CHK57-1@CompuServe.COM> Sender: bugs-owner@FreeBSD.org Precedence: bulk Having trouble with a Mitsumi Double speed. While trying to install BSD from it it times out when it comes to reading and writing during the actual transfer of anything important, like the whole system :) It gets past verifying the checksums and then when it begins to actually work it begins timing out. The -c is used on boot as its on irq5 and I set everything i could just to be safe and it seems to recognize the thing fine untill it has to actually do any work. I can transfer things in dos to the hard drive and install that way but the drive isn't large enough for the filesystem dirs so I thought I would see if there were any suggestions before I sitck in a bigger drive. thanks From owner-freebsd-bugs Tue May 9 14:19:50 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA26508 for bugs-outgoing; Tue, 9 May 1995 14:19:50 -0700 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 OAA26502 for ; Tue, 9 May 1995 14:19:44 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id OAA05612; Tue, 9 May 1995 14:19:28 -0700 From: "Rodney W. Grimes" Message-Id: <199505092119.OAA05612@gndrsh.aac.dev.com> Subject: Re: strange symlinks To: Bernard.Steiner@Germany.EU.net Date: Tue, 9 May 1995 14:19:28 -0700 (PDT) Cc: freebsd-bugs@FreeBSD.org In-Reply-To: <199505092047.WAA17816@qwerty.Germany.EU.net> from "Bernard.Steiner@Germany.EU.net" at May 9, 95 10:47:40 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1673 Sender: bugs-owner@FreeBSD.org Precedence: bulk > > Folks, > while playing with my FreeBSD 2.0R I came across the following oddity: > > Assumption: directory /tmp exits, owned by bin.bin mode 1777 > then ln -s /tmp/foo /tmp/bar produces symlink /tmp/bar *owned* by bin > regardless of who issued the symlink command, and subsequent rm /tmp/bar > is refused for non-owner, i.e. any normal user except for bin and root. > > This is bogus. EEEkkkksss.. this has been around for a long time, it has to do with the changes in BSD 4.4 on who owns symbolic links, this is part of the POSIX changes. Basically all symbolic links have the owner of the directory that holds them. Also true for the time stamps. Kirk McKusik sent us a patch for his proposal to fix it, and now that I go back and look at the mail he sent it to just David Greenman and myself. I though it had gone to the whole -arch mailling list :-(. I'll go test this patch out and if it makes things better I will apply it. > The next one may be a general 4.4 problem... > assumption: /tmp/foo does not exist, /tmp/bar is a symlink to /tmp/foo. > chdir("/tmp/bar") fails with ENOENT, but at the same time > mkdir("/tmp/bar", 0x777) fails with EEXIST. > > Okay, so that is as per the specs in the PRM (and, thusly, probably POSIX). > However, it seems sort of stranke, doesn't it ? > IMHO the mkdir ought to produce a directory /tmp/foo and not fail. > > Third, whatever happened to the fchdir() syscall that I vaguely remember > having had in (at least) 386BSD0.1 ? > > Thanks, > Bernard > -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-bugs Tue May 9 15:23:08 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id PAA27038 for bugs-outgoing; Tue, 9 May 1995 15:23:08 -0700 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 PAA27031 for ; Tue, 9 May 1995 15:23:02 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA19830; Tue, 9 May 95 16:14:49 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9505092214.AA19830@cs.weber.edu> Subject: Re: strange symlinks To: Bernard.Steiner@Germany.EU.net Date: Tue, 9 May 95 16:14:48 MDT Cc: freebsd-bugs@FreeBSD.org In-Reply-To: <199505092047.WAA17816@qwerty.Germany.EU.net> from "Bernard.Steiner@Germany.EU.net" at May 9, 95 10:47:40 pm X-Mailer: ELM [version 2.4dev PL52] Sender: bugs-owner@FreeBSD.org Precedence: bulk > Assumption: directory /tmp exits, owned by bin.bin mode 1777 > then ln -s /tmp/foo /tmp/bar produces symlink /tmp/bar *owned* by bin > regardless of who issued the symlink command, and subsequent rm /tmp/bar > is refused for non-owner, i.e. any normal user except for bin and root. > > This is bogus. It's a generic 4.4 problem with making symlinks in the directory entries themselves. Probably when the sticky bit is set, it ought to make the old-style links instead. > The next one may be a general 4.4 problem... > assumption: /tmp/foo does not exist, /tmp/bar is a symlink to /tmp/foo. > chdir("/tmp/bar") fails with ENOENT, but at the same time > mkdir("/tmp/bar", 0x777) fails with EEXIST. I think this is a generic result of the path component item evaluation order. I guess the only thing to say is that "according to the code, this is correct behaviour" 8-). > Third, whatever happened to the fchdir() syscall that I vaguely remember > having had in (at least) 386BSD0.1 ? It had *better* still be there! I've been using it with a couple of minor code changes to get about a 15% performance increase out of Samba by keeping an open descriptor for the exported file system to make all opens relative instead of having to traverse every component up to the path on the volume itself. 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 May 9 16:01:33 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id QAA28295 for bugs-outgoing; Tue, 9 May 1995 16:01:33 -0700 Received: from odabree.sdsmt.edu (odabree.sdsmt.edu [151.159.9.50]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id QAA28289 for ; Tue, 9 May 1995 16:01:31 -0700 Received: (from dunser@localhost) by odabree.sdsmt.edu (8.6.11/8.6.9) id PAA11802; Tue, 9 May 1995 15:58:44 GMT Date: Tue, 9 May 1995 15:58:44 GMT From: User Dunser Message-Id: <199505091558.PAA11802@odabree.sdsmt.edu> To: dunser@odabree.sdsmt.edu, rgrimes@gndrsh.aac.dev.com Subject: Re: MTREE Cc: bugs@FreeBSD.org Sender: bugs-owner@FreeBSD.org Precedence: bulk 2.0-950412-SNAP From owner-freebsd-bugs Tue May 9 16:40:08 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id QAA29566 for bugs-outgoing; Tue, 9 May 1995 16:40:08 -0700 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id QAA29559 ; Tue, 9 May 1995 16:40:05 -0700 Date: Tue, 9 May 1995 16:40:05 -0700 Message-Id: <199505092340.QAA29559@freefall.cdrom.com> From: Stephen McKay Reply-To: Stephen McKay To: freebsd-bugs Subject: bin/391: usr.sbin/xten only compiles when in /usr/src In-Reply-To: Your message of Tue, 9 May 1995 19:52:48 +1000 <199505090952.TAA19339@stupid.devetir.qld.gov.au> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 391 >Category: bin >Synopsis: usr.sbin/xten/Makefile references absolute /usr/src path. >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: Tue May 9 16:40:02 1995 >Originator: Stephen McKay >Organization: None today, thank you. I'm on a diet. >Release: FreeBSD 2.1.0-Development i386 >Environment: -current as at 1995-05-09 03:32:01 (src-cur ctm#601) 386SX16, 4Mb ram, 80Mb IDE disk, src + obj via NFS (Whole ensemble running just fine, thanks for asking!) >Description: usr.sbin/xten/Makefile references absolute path: /usr/src/libexec/xtend When doing a full grep of Makefiles to look for more villains, I found the following bit of old debugging cruft at line 18 of gnu/usr.bin/kgdb/ngdb.i386/Makefile: -I/usr/src/sys.newvm \ >How-To-Repeat: Install your sources somewhere other than /usr/src. >Fix: --- usr.sbin/xten/Makefile Mon Apr 24 17:36:52 1995 +++ usr.sbin/xten/Makefile.good Tue May 9 19:03:09 1995 @@ -2,7 +2,7 @@ PROG= xten SRCS= xten.c -CFLAGS+=-I. -I/usr/src/libexec/xtend +CFLAGS+=-I. -I${.CURDIR}/../../libexec/xtend MAN1= xten.1 Stephen (first time send-pr, so be gentle!) >Audit-Trail: >Unformatted: From owner-freebsd-bugs Tue May 9 16:51:44 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id QAA00122 for bugs-outgoing; Tue, 9 May 1995 16:51:44 -0700 Received: (from jkh@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id QAA00100 ; Tue, 9 May 1995 16:51:43 -0700 Date: Tue, 9 May 1995 16:51:43 -0700 From: "Jordan K. Hubbard" Message-Id: <199505092351.QAA00100@freefall.cdrom.com> To: syssgm@devetir.qld.gov.au, jkh, freebsd-bugs Subject: Changed information for PR bin/391 Sender: bugs-owner@FreeBSD.org Precedence: bulk Synopsis: usr.sbin/xten/Makefile references absolute /usr/src path. State-Changed-From-To: open-closed State-Changed-By: jkh State-Changed-When: Tue May 9 16:49:20 PDT 1995 State-Changed-Why: Provided fix was applied. From owner-freebsd-bugs Tue May 9 18:18:22 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA02685 for bugs-outgoing; Tue, 9 May 1995 18:18:22 -0700 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 SAA02676 for ; Tue, 9 May 1995 18:18:18 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id SAA06009; Tue, 9 May 1995 18:17:59 -0700 From: "Rodney W. Grimes" Message-Id: <199505100117.SAA06009@gndrsh.aac.dev.com> Subject: Re: strange symlinks To: terry@cs.weber.edu (Terry Lambert) Date: Tue, 9 May 1995 18:17:58 -0700 (PDT) Cc: Bernard.Steiner@Germany.EU.net, freebsd-bugs@FreeBSD.org In-Reply-To: <9505092214.AA19830@cs.weber.edu> from "Terry Lambert" at May 9, 95 04:14:48 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1640 Sender: bugs-owner@FreeBSD.org Precedence: bulk > > > Assumption: directory /tmp exits, owned by bin.bin mode 1777 > > then ln -s /tmp/foo /tmp/bar produces symlink /tmp/bar *owned* by bin > > regardless of who issued the symlink command, and subsequent rm /tmp/bar > > is refused for non-owner, i.e. any normal user except for bin and root. > > > > This is bogus. > > It's a generic 4.4 problem with making symlinks in the directory entries > themselves. Probably when the sticky bit is set, it ought to make the > old-style links instead. > > > The next one may be a general 4.4 problem... > > assumption: /tmp/foo does not exist, /tmp/bar is a symlink to /tmp/foo. > > chdir("/tmp/bar") fails with ENOENT, but at the same time > > mkdir("/tmp/bar", 0x777) fails with EEXIST. > > I think this is a generic result of the path component item evaluation > order. I guess the only thing to say is that "according to the code, > this is correct behaviour" 8-). > > > Third, whatever happened to the fchdir() syscall that I vaguely remember > > having had in (at least) 386BSD0.1 ? > > It had *better* still be there! I've been using it with a couple of > minor code changes to get about a 15% performance increase out of > Samba by keeping an open descriptor for the exported file system to > make all opens relative instead of having to traverse every component > up to the path on the volume itself. It should be there, from my 2.0-current system: gndrsh# locate fchdir /usr/share/man/man2/fchdir.2 It is a system call. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-bugs Tue May 9 18:28:37 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA03086 for bugs-outgoing; Tue, 9 May 1995 18:28:37 -0700 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 SAA03080 for ; Tue, 9 May 1995 18:28:34 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id SAA06039; Tue, 9 May 1995 18:28:21 -0700 From: "Rodney W. Grimes" Message-Id: <199505100128.SAA06039@gndrsh.aac.dev.com> Subject: Re: MTREE To: dunser@odabree.sdsmt.edu (User Dunser) Date: Tue, 9 May 1995 18:28:20 -0700 (PDT) Cc: dunser@odabree.sdsmt.edu, bugs@FreeBSD.org In-Reply-To: <199505091558.PAA11802@odabree.sdsmt.edu> from "User Dunser" at May 9, 95 03:58:44 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 275 Sender: bugs-owner@FreeBSD.org Precedence: bulk > > 2.0-950412-SNAP > This message does not have enough context with it for me to figure out what it is about :-(. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-bugs Tue May 9 18:48:26 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA03564 for bugs-outgoing; Tue, 9 May 1995 18:48:26 -0700 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 SAA03553 for ; Tue, 9 May 1995 18:48:21 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id SAA06180; Tue, 9 May 1995 18:47:51 -0700 From: "Rodney W. Grimes" Message-Id: <199505100147.SAA06180@gndrsh.aac.dev.com> Subject: Re: bin/391: usr.sbin/xten only compiles when in /usr/src To: syssgm@devetir.qld.gov.au Date: Tue, 9 May 1995 18:47:51 -0700 (PDT) Cc: freebsd-bugs@freefall.cdrom.com In-Reply-To: <199505092340.QAA29559@freefall.cdrom.com> from "Stephen McKay" at May 9, 95 04:40:05 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2682 Sender: bugs-owner@FreeBSD.org Precedence: bulk Something is seriously wrong with your copy of the source tree, this was fixed long agao: gndrsh# cvs rlog Makefile |& more RCS file: /home/ncvs/src/usr.sbin/xten/Makefile,v Working file: Makefile ... ---------------------------- revision 1.2 date: 1995/01/17 15:07:13; author: jkh; state: Exp; lines: +1 -1 Make Makefile take a relative path for CFLAGS. Submitted by: Remy Card ---------------------------- ... gndrsh# cvs diff -c -r1.1 -r1.2 Makefile Index: Makefile =================================================================== RCS file: /home/ncvs/src/usr.sbin/xten/Makefile,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** 1.1 1994/10/22 09:55:42 --- 1.2 1995/01/17 15:07:13 *************** *** 2,8 **** PROG= xten SRCS= xten.c ! CFLAGS+=-I. -I/usr/src/libexec/xtend MAN1= xten.1 --- 2,8 ---- PROG= xten SRCS= xten.c ! CFLAGS+=-I. -I${.CURDIR}/../../libexec/xtend MAN1= xten.1 > > > >Number: 391 > >Category: bin > >Synopsis: usr.sbin/xten/Makefile references absolute /usr/src path. > >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: Tue May 9 16:40:02 1995 > >Originator: Stephen McKay > >Organization: > None today, thank you. I'm on a diet. > >Release: FreeBSD 2.1.0-Development i386 > >Environment: > > -current as at 1995-05-09 03:32:01 (src-cur ctm#601) > > 386SX16, 4Mb ram, 80Mb IDE disk, src + obj via NFS > (Whole ensemble running just fine, thanks for asking!) > > >Description: > > usr.sbin/xten/Makefile references absolute path: /usr/src/libexec/xtend > > When doing a full grep of Makefiles to look for more villains, > I found the following bit of old debugging cruft at line 18 of > gnu/usr.bin/kgdb/ngdb.i386/Makefile: > > -I/usr/src/sys.newvm \ This still exists... I am about to commit the fix for it... > > >How-To-Repeat: > > Install your sources somewhere other than /usr/src. > > >Fix: > > --- usr.sbin/xten/Makefile Mon Apr 24 17:36:52 1995 > +++ usr.sbin/xten/Makefile.good Tue May 9 19:03:09 1995 > @@ -2,7 +2,7 @@ > > PROG= xten > SRCS= xten.c > -CFLAGS+=-I. -I/usr/src/libexec/xtend > +CFLAGS+=-I. -I${.CURDIR}/../../libexec/xtend > > MAN1= xten.1 > > > Stephen (first time send-pr, so be gentle!) > >Audit-Trail: > >Unformatted: > > > -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-bugs Tue May 9 19:10:20 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id TAA04205 for bugs-outgoing; Tue, 9 May 1995 19:10:20 -0700 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 TAA04199 for ; Tue, 9 May 1995 19:10:15 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id TAA06496; Tue, 9 May 1995 19:09:57 -0700 From: "Rodney W. Grimes" Message-Id: <199505100209.TAA06496@gndrsh.aac.dev.com> Subject: Re: bin/391: usr.sbin/xten only compiles when in /usr/src To: rgrimes@gndrsh.aac.dev.com (Rodney W. Grimes) Date: Tue, 9 May 1995 19:09:57 -0700 (PDT) Cc: syssgm@devetir.qld.gov.au, freebsd-bugs@freefall.cdrom.com In-Reply-To: <199505100147.SAA06180@gndrsh.aac.dev.com> from "Rodney W. Grimes" at May 9, 95 06:47:51 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 936 Sender: bugs-owner@FreeBSD.org Precedence: bulk > > Something is seriously wrong with your copy of the source tree, > this was fixed long agao: > gndrsh# cvs rlog Makefile |& more > > RCS file: /home/ncvs/src/usr.sbin/xten/Makefile,v > Working file: Makefile ... Sorry folks, Rod was being stupid. I was looking in my last stable build tree instead of my -current tree. Should have done a cvs status as it would have clearly told me: gndrsh# cvs status Makefile =================================================================== File: Makefile Status: Needs Checkout Working revision: 1.2 Tue Jan 17 15:07:13 1995 Repository revision: 1.3 /home/ncvs/src/usr.sbin/xten/Makefile,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) Pass me the hat <:-) -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-bugs Tue May 9 20:47:15 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id UAA07038 for bugs-outgoing; Tue, 9 May 1995 20:47:15 -0700 Received: from bunyip.cc.uq.oz.au (bunyip.cc.uq.oz.au [130.102.2.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id UAA07032 for ; Tue, 9 May 1995 20:47:11 -0700 Received: from cc.uq.oz.au by bunyip.cc.uq.oz.au id <25628-0@bunyip.cc.uq.oz.au>; Wed, 10 May 1995 13:46:45 +1000 Received: from orion.devetir.qld.gov.au by pandora.devetir.qld.gov.au (8.6.10/DEVETIR-E0.3a) with ESMTP id NAA23464; Wed, 10 May 1995 13:50:27 +1000 Received: by orion.devetir.qld.gov.au (8.6.10/DEVETIR-0.2a) id NAA06632; Wed, 10 May 1995 13:48:27 +1000 Date: Wed, 10 May 1995 13:48:27 +1000 From: Stephen McKay Message-Id: <199505100348.NAA06632@orion.devetir.qld.gov.au> To: freebsd-bugs@FreeBSD.org cc: "Rodney W. Grimes" , syssgm@devetir.qld.gov.au Subject: Re: bin/391: usr.sbin/xten only compiles when in /usr/src Sender: bugs-owner@FreeBSD.org Precedence: bulk "Rodney W. Grimes" wrote: >> Something is seriously wrong with your copy of the source tree, >> this was fixed long agao: >> gndrsh# cvs rlog Makefile |& more >> >> RCS file: /home/ncvs/src/usr.sbin/xten/Makefile,v >> Working file: Makefile >> ---------------------------- >> revision 1.2 >> date: 1995/01/17 15:07:13; author: jkh; state: Exp; lines: +1 -1 >> Make Makefile take a relative path for CFLAGS. >> Submitted by: Remy Card >> ---------------------------- > >Sorry folks, Rod was being stupid. I was looking in my last stable >build tree instead of my -current tree. Looking back over my old CTM deltas shows that this was fixed, but was re-broken when a new version of xten was imported on or before 1995-04-18. >Pass me the hat <:-) It was almost mine, phew! I think it might be Jordan's turn, but I'm willing to forgive him. :-) Stephen. From owner-freebsd-bugs Tue May 9 21:30:01 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA08343 for bugs-outgoing; Tue, 9 May 1995 21:30:01 -0700 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA08336 ; Tue, 9 May 1995 21:30:01 -0700 Date: Tue, 9 May 1995 21:30:01 -0700 Message-Id: <199505100430.VAA08336@freefall.cdrom.com> From: uhclem%nemesis@fw.ast.com (Frank Durda IV) Reply-To: uhclem%nemesis@fw.ast.com (Frank Durda IV) To: freebsd-bugs Subject: bin/392: Problem #FDIV025 In-Reply-To: Your message of Tue, 9 May 95 23:17 CDT Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 392 >Category: bin >Synopsis: Simultaneous cp and ls of files on dos f/s hangs procs [FDIV025] >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue May 9 21:30:00 1995 >Originator: Frank Durda IV >Organization: >Release: FreeBSD 2.0.950412-SNAP i386 >Environment: [FDIV025] FreeBSD 2.0.950412-SNAP i386 Stock kernel, "make world" kernel, or custom kernel. >Description: If you are copying files to a freshly-formatted MS-DOS floppy (6.2.2) and on a second process you do a ls -R of the same floppy, sometimes the ls process will hang, and then the cp process may also hang. Other types of filesystem reads will substitute for ls and probably other programs can be used to put files on the floppy. >How-To-Repeat: To easily repeat the problem: Take a freshly formatted MS-DOS floppy and mount it as /mnt: mount -t msdos /dev/fd0a /mnt cd / mkdir test2 cd test2 create 26 files named a thru z of non-zero length. I used date > a thru date > z (the script to automate this is left to the observer) mkdir z1 mkdir z2 mkdir z3 cp * z1/. cp * z2/. cp * z3/. sync You should have 104 files and three directories in the test2 tree.. At this point, I suggest making a tar image of test2 so you can restore it if you lose it in the next steps. Make sure you are logged-in on at least three virtual terminals cd to /test2 on all virtual terminals On screen 1, issue the command: cp -R * /mnt/. On screen 2, issue the command ls -R /mnt continue to repeat (!!) the ls command, waiting for the prompt each time. Eventually the ls command will not terminate. At this point you may hear floppy I/O continue for another 15 seconds or so, and then the drive light will go off. Switch to screen 1 and verify that the cp command is hung. If the cp command finished normally and ls didn't hang up, rm -rf /mnt/. and repeat the above commands. For me it always hung during the first cp command. On the third screen, you can do a ps -alxw and should see results like this UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND 0 0 0 0 -18 0 0 0 sched DLs ?? 0:00.00 (swapper) 0 1 0 2 10 0 412 176 wait Is ?? 0:00.05 /sbin/init -- 0 2 0 0 -18 0 0 12 psleep DL ?? 0:00.00 (pagedaemon) 0 3 0 0 28 0 0 12 psleep DL ?? 0:00.00 (vmdaemon) 0 4 0 0 -6 0 0 12 update DL ?? 0:00.12 (update) 0 19 1 23 18 0 212 88 pause Is ?? 0:00.02 adjkerntz -i 0 41 1 0 2 0 180 228 select Is ?? 0:00.03 routed -q 0 57 1 0 2 0 180 296 select Ss ?? 0:00.43 syslogd 1 63 1 75 2 0 176 220 select Is ?? 0:00.02 portmap 0 72 1 18 2 0 208 312 select Is ?? 0:00.84 inetd 0 79 1 0 18 0 264 332 pause Is ?? 0:00.09 cron 0 81 1 25 2 0 184 284 select Is ?? 0:00.13 lpd 0 84 1 22 2 0 404 328 netcon Is ?? 0:00.04 sendmail: accepting connections (sendmail) 0 124 1 0 3 0 476 276 ttyin Ss+ v0 0:01.08 -csh (csh) 0 192 124 0 -6 0 252 132 getblk D v0 0:00.30 cp -R a b c d e f g h i j k l m n o p q r s t u v w x y z z1 z2 z 0 125 1 0 18 0 472 336 pause Is v1 0:00.59 -csh (csh) 0 212 125 0 -14 0 352 196 msdhgt D+ v1 0:00.07 ls -g -k -R /mnt 0 126 1 0 18 0 472 332 pause Ss v2 0:00.40 -csh (csh) 0 216 126 6 29 0 440 180 - R+ v2 0:00.04 ps -alxw (The wait channel of the ls and cp is always the same as above.) At this point, you can't kill the above processes, but you might be able to do selected operations on the same floppy file system. In one case I was able to do a ls /mnt and got results and a prompt, but then I attempted a ls -alR and that hung up. Another time I was able to rm -rf /mnt/* all the files on the floppy without incident even though the other processes were still hung. >Fix: No idea. However, the order of directories copied seems important. When I used subdirectories named "one", "two" and "three" I could not get a failure. Another interesting thing is the order in which the repeated ls commands show files being copied, almost a reverse alphabetic order. *END* >Audit-Trail: >Unformatted: From owner-freebsd-bugs Tue May 9 21:40:02 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA08476 for bugs-outgoing; Tue, 9 May 1995 21:40:02 -0700 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA08468 ; Tue, 9 May 1995 21:40:01 -0700 Date: Tue, 9 May 1995 21:40:01 -0700 Message-Id: <199505100440.VAA08468@freefall.cdrom.com> From: uhclem%nemesis@fw.ast.com Reply-To: uhclem%nemesis@fw.ast.com To: freebsd-bugs Subject: bin/393: Problem #FDIV025 In-Reply-To: Your message of Tue, 9 May 95 23:23 CDT Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 393 >Category: bin >Synopsis: Simultaneous cp and ls of files on dos f/s hangs procs [FDIV025] >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue May 9 21:40:00 1995 >Originator: Frank Durda IV >Organization: >Release: FreeBSD 2.0.950412-SNAP i386 >Environment: [FDIV025] FreeBSD 2.0.950412-SNAP i386 Stock kernel, "make world" kernel, or custom kernel. >Description: If you are copying files to a freshly-formatted MS-DOS floppy (6.2.2) and on a second process you do a ls -R of the same floppy, sometimes the ls process will hang, and then the cp process may also hang. Other types of filesystem reads will substitute for ls and probably other programs can be used to put files on the floppy. >How-To-Repeat: To easily repeat the problem: Take a freshly formatted MS-DOS floppy and mount it as /mnt: mount -t msdos /dev/fd0a /mnt cd / mkdir test2 cd test2 create 26 files named a thru z of non-zero length. I used date > a thru date > z (the script to automate this is left to the observer) mkdir z1 mkdir z2 mkdir z3 cp * z1/. cp * z2/. cp * z3/. sync You should have 104 files and three directories in the test2 tree.. At this point, I suggest making a tar image of test2 so you can restore it if you lose it in the next steps. Make sure you are logged-in on at least three virtual terminals cd to /test2 on all virtual terminals On screen 1, issue the command: cp -R * /mnt/. On screen 2, issue the command ls -R /mnt continue to repeat (!!) the ls command, waiting for the prompt each time. Eventually the ls command will not terminate. At this point you may hear floppy I/O continue for another 15 seconds or so, and then the drive light will go off. Switch to screen 1 and verify that the cp command is hung. If the cp command finished normally and ls didn't hang up, rm -rf /mnt/. and repeat the above commands. For me it always hung during the first cp command. On the third screen, you can do a ps -alxw and should see results like this UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND 0 0 0 0 -18 0 0 0 sched DLs ?? 0:00.00 (swapper) 0 1 0 2 10 0 412 176 wait Is ?? 0:00.05 /sbin/init -- 0 2 0 0 -18 0 0 12 psleep DL ?? 0:00.00 (pagedaemon) 0 3 0 0 28 0 0 12 psleep DL ?? 0:00.00 (vmdaemon) 0 4 0 0 -6 0 0 12 update DL ?? 0:00.12 (update) 0 19 1 23 18 0 212 88 pause Is ?? 0:00.02 adjkerntz -i 0 41 1 0 2 0 180 228 select Is ?? 0:00.03 routed -q 0 57 1 0 2 0 180 296 select Ss ?? 0:00.43 syslogd 1 63 1 75 2 0 176 220 select Is ?? 0:00.02 portmap 0 72 1 18 2 0 208 312 select Is ?? 0:00.84 inetd 0 79 1 0 18 0 264 332 pause Is ?? 0:00.09 cron 0 81 1 25 2 0 184 284 select Is ?? 0:00.13 lpd 0 84 1 22 2 0 404 328 netcon Is ?? 0:00.04 sendmail: accepting connections (sendmail) 0 124 1 0 3 0 476 276 ttyin Ss+ v0 0:01.08 -csh (csh) 0 192 124 0 -6 0 252 132 getblk D v0 0:00.30 cp -R a b c d e f g h i j k l m n o p q r s t u v w x y z z1 z2 z 0 125 1 0 18 0 472 336 pause Is v1 0:00.59 -csh (csh) 0 212 125 0 -14 0 352 196 msdhgt D+ v1 0:00.07 ls -g -k -R /mnt 0 126 1 0 18 0 472 332 pause Ss v2 0:00.40 -csh (csh) 0 216 126 6 29 0 440 180 - R+ v2 0:00.04 ps -alxw (The wait channel of the ls and cp is always the same as above.) At this point, you can't kill the above processes, but you might be able to do selected operations on the same floppy file system. In one case I was able to do a ls /mnt and got results and a prompt, but then I attempted a ls -alR and that hung up. Another time I was able to rm -rf /mnt/* all the files on the floppy without incident even though the other processes were still hung. >Fix: No idea. However, the order of directories copied seems important. When I used subdirectories named "one", "two" and "three" I could not get a failure. Another interesting thing is the order in which the repeated ls commands show files being copied, almost a reverse alphabetic order. *END* >Audit-Trail: >Unformatted: From owner-freebsd-bugs Tue May 9 21:56:33 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA08629 for bugs-outgoing; Tue, 9 May 1995 21:56:33 -0700 Received: from todonix.ping.de (root@todonix.ping.de [193.100.14.43]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id VAA08623 for ; Tue, 9 May 1995 21:56:26 -0700 Received: by todonix.ping.de (Smail3.1.28.1 #1) id m0s93oL-000Gu7C; Wed, 10 May 95 06:55 MET DST Message-Id: From: jan@todonix.ping.de (Jan Wedekind) Subject: SNAP-0412 boot: init not found! To: bugs@FreeBSD.org Date: Wed, 10 May 1995 06:55:49 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 858 Sender: bugs-owner@FreeBSD.org Precedence: bulk Hi, i just got an older 386 and tried FreeBSD on it, when i got some unexpected Problems: with the SNAP-0323 i got a kernel Trap while booting the boot disk. with the SNAP-0412 i got the following: wd0: changing size of d from 10404 to 208696 (comment: it is a 102MB hard disk, with an 5 MB DOS Partition for tests.) WARNING no swap Output=0 Inflate_error=2 igz.error=0 error2=0 where=0 exec /stand/sysinstall: error 8 init: not found panic: no init (rebooting ...) Any suggestions ? Thanks, Jan PS: i just compared the file (boot.flp) with that on the nearest mirror-site (ftp.fb9dv.uni-duisburg.de). they are identical! -- PING e.V. Jan Wedekind (Kassenwart) jan@ping.de Emil-Figge-Str. 85 Lindemannstr. 12 kasse@ping.de 44227 Dortmund 44137 Dortmund vorstand@ping.de Tel.: 0231 / 97 91 - 0 Tel.: +49 (231) 13 44 04 info@ping.de From owner-freebsd-bugs Tue May 9 22:33:55 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA09790 for bugs-outgoing; Tue, 9 May 1995 22:33:55 -0700 Received: from localhost (localhost [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id WAA09783 ; Tue, 9 May 1995 22:33:53 -0700 X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol To: jan@todonix.ping.de (Jan Wedekind) cc: bugs@FreeBSD.org Subject: Re: SNAP-0412 boot: init not found! In-reply-to: Your message of "Wed, 10 May 95 06:55:49 +0200." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 09 May 1995 22:33:53 -0700 Message-ID: <9782.800084033@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: bugs-owner@FreeBSD.org Precedence: bulk > Hi, > > i just got an older 386 and tried FreeBSD on it, > when i got some unexpected Problems: How much memory? At least 4MB, right? That's our published minimum! Jordan From owner-freebsd-bugs Tue May 9 23:25:58 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id XAA10737 for bugs-outgoing; Tue, 9 May 1995 23:25:58 -0700 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 XAA10730 for ; Tue, 9 May 1995 23:25:47 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id QAA01050; Wed, 10 May 1995 16:22:23 +1000 Date: Wed, 10 May 1995 16:22:23 +1000 From: Bruce Evans Message-Id: <199505100622.QAA01050@godzilla.zeta.org.au> To: Bernard.Steiner@Germany.EU.net, terry@cs.weber.edu Subject: Re: strange symlinks Cc: freebsd-bugs@FreeBSD.org Sender: bugs-owner@FreeBSD.org Precedence: bulk >> The next one may be a general 4.4 problem... >> assumption: /tmp/foo does not exist, /tmp/bar is a symlink to /tmp/foo. >> chdir("/tmp/bar") fails with ENOENT, but at the same time >> mkdir("/tmp/bar", 0x777) fails with EEXIST. >I think this is a generic result of the path component item evaluation >order. I guess the only thing to say is that "according to the code, >this is correct behaviour" 8-). It's because chdir follows symlinks but mkdir doesn't. chdir operates on directories while mkdir operates on directory entries. The directory /tmp/foo doesn't exist so the error for chdir is ENOENT but the directory entry /tmp/bar exists so the error for mkdir is EEXIST. >> Third, whatever happened to the fchdir() syscall that I vaguely remember >> having had in (at least) 386BSD0.1 ? >It had *better* still be there! I've been using it with a couple of It hasn't changed. See `man fchdir'. Bruce From owner-freebsd-bugs Wed May 10 00:50:00 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA11971 for bugs-outgoing; Wed, 10 May 1995 00:50:00 -0700 Received: from sbstark.cs.sunysb.edu (sbstark.cs.sunysb.edu [130.245.1.47]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id AAA11965 for ; Wed, 10 May 1995 00:49:58 -0700 Received: (from root@localhost) by sbstark.cs.sunysb.edu (8.6.12/8.6.9) with UUCP id DAA21055; Wed, 10 May 1995 03:49:21 -0400 Received: (from gene@localhost) by starkhome.cs.sunysb.edu (8.6.11/8.6.9) id DAA08408; Wed, 10 May 1995 03:44:37 -0400 Date: Wed, 10 May 1995 03:44:37 -0400 From: Gene Stark Message-Id: <199505100744.DAA08408@starkhome.cs.sunysb.edu> To: Stephen McKay Cc: bugs@FreeBSD.org In-reply-to: Stephen McKay's message of Wed, 10 May 1995 13:48:27 +1000 Subject: Re: bin/391: usr.sbin/xten only compiles when in /usr/src Sender: bugs-owner@FreeBSD.org Precedence: bulk >Looking back over my old CTM deltas shows that this was fixed, but was >re-broken when a new version of xten was imported on or before 1995-04-18. It's probably partly my fault, because I did not sync up the Makefile from the current tree with my own xten sources before generating the new version I sent Jordan awhile back. I will sync them up now, so I don't cause the same problem again in the future. - Gene From owner-freebsd-bugs Wed May 10 00:50:13 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA11988 for bugs-outgoing; Wed, 10 May 1995 00:50:13 -0700 Received: from sbstark.cs.sunysb.edu (sbstark.cs.sunysb.edu [130.245.1.47]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id AAA11980 for ; Wed, 10 May 1995 00:50:11 -0700 Received: (from root@localhost) by sbstark.cs.sunysb.edu (8.6.12/8.6.9) with UUCP id DAA21052; Wed, 10 May 1995 03:49:20 -0400 Received: (from gene@localhost) by starkhome.cs.sunysb.edu (8.6.11/8.6.9) id DAA08397; Wed, 10 May 1995 03:39:47 -0400 Date: Wed, 10 May 1995 03:39:47 -0400 From: Gene Stark Message-Id: <199505100739.DAA08397@starkhome.cs.sunysb.edu> To: Stephen McKay Cc: bugs@FreeBSD.org In-reply-to: Stephen McKay's message of Tue, 9 May 1995 16:40:05 -0700 Subject: bin/391: usr.sbin/xten only compiles when in /usr/src Sender: bugs-owner@FreeBSD.org Precedence: bulk > PROG= xten > SRCS= xten.c >-CFLAGS+=-I. -I/usr/src/libexec/xtend >+CFLAGS+=-I. -I${.CURDIR}/../../libexec/xtend It's OK with me if somebody with commit privileges applies this. - Gene Stark From owner-freebsd-bugs Wed May 10 01:04:31 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id BAA12239 for bugs-outgoing; Wed, 10 May 1995 01:04:31 -0700 Received: from hq.sonet.kemerovo.su (hq.sonet.kemerovo.su [193.124.188.65]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id BAA12190 for ; Wed, 10 May 1995 01:03:48 -0700 Received: by hq.sonet.kemerovo.su id PAA06172; (8.6.9/vak/1.8r) Wed, 10 May 1995 15:51:18 +0800 To: paulus@cs.anu.edu.au Cc: freebsd-bugs@FreeBSD.org Message-ID: Organization: SoNet Systems Co., Ltd. From: vvdav@hq.sonet.kemerovo.su (Vladimir V. Davydoff) Date: Wed, 10 May 95 15:51:15 +0800 X-Mailer: BML [UNIX Beauty Mail v.1.39] Subject: pppd & proxyarp & BSD Sender: bugs-owner@FreeBSD.org Precedence: bulk A little :-) bug was found in ppp-2.1.2/sys-bsd.c. It prevents 'proxyarp' options to work. Bug is in get_ether_address(), in getting interface netmask. Netmask is got from kernel, but doesn't used. --- ppp-2.1.2/sys-bsd.c 685,693 --- > /* > * Get its netmask and check that it's on the right subnet. > */ > if (ioctl(s, SIOCGIFNETMASK, &ifreq) < 0) > continue; Now we get right netmask of ethernet. > mask = ((struct sockaddr_in *) &ifr->ifr_addr)->sin_addr.s_addr; ^^^^^^ Now we use not netmask, but the ethernet address. Need '&ifreq.'. > if ((ipaddr & mask) != (ina & mask)) > continue; Some addresses work but some not, has infinitive loop. Depend on result of AND operation between two addresses :-) Load average up, pppd doesn't die after disconnecting... Sorry for my English. From owner-freebsd-bugs Wed May 10 03:38:38 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id DAA16503 for bugs-outgoing; Wed, 10 May 1995 03:38:38 -0700 Received: from mail.Germany.EU.net (mail.Germany.EU.net [192.76.144.65]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id DAA16496 for ; Wed, 10 May 1995 03:38:32 -0700 From: Bernard.Steiner@Germany.EU.net Received: by mail.Germany.EU.net with ESMTP (8.6.5:29/EUnetD-2.5.1.f) via EUnet id MAA00943; Wed, 10 May 1995 12:40:13 +0200 Message-Id: <199505101040.MAA18416@qwerty.Germany.EU.net> Received: from localhost.Germany.EU.net by qwerty.Germany.EU.net with SMTP (8.6.4/EUnetDlan-1.14-1.2.0) via EUnet for [mail.germany.eu.net] id MAA18416; Wed, 10 May 1995 12:40:11 +0200 To: terry@cs.weber.edu (Terry Lambert) cc: freebsd-bugs@FreeBSD.org Subject: Re: strange symlinks In-reply-to: Your message of Tue, 09 May 1995 16:14:48 MDT. <9505092214.AA19830@cs.weber.edu> Date: Wed, 10 May 1995 12:39:28 +0200 Sender: bugs-owner@FreeBSD.org Precedence: bulk > The next one may be a general 4.4 problem... > assumption: /tmp/foo does not exist, /tmp/bar is a symlink to /tmp/foo. > chdir("/tmp/bar") fails with ENOENT, but at the same time > mkdir("/tmp/bar", 0x777) fails with EEXIST. I think this is a generic result of the path component item evaluation order. I guess the only thing to say is that "according to the code, this is correct behaviour" 8-). Yeah. There's more to this, actually. If you do an open(O_CREAT) (on SunOS4.1.3; haven't got the FreeBSD box with me now) you get a normal open file that the symlink points to. IN the light of the mkdir, this is a wee bit inconsistent, isn't it ? > Third, whatever happened to the fchdir() syscall that I vaguely remember > having had in (at least) 386BSD0.1 ? Sorry - please delete all my ranting on this one. Bernard From owner-freebsd-bugs Wed May 10 05:39:25 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id FAA18781 for bugs-outgoing; Wed, 10 May 1995 05:39:25 -0700 Received: from irbs.irbs.com (irbs.com [199.182.75.129]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id FAA18775 for ; Wed, 10 May 1995 05:39:20 -0700 Received: (from jc@localhost) by irbs.irbs.com (8.6.11/8.6.6) id IAA21612 for freebsd-bugs@freebsd.org; Wed, 10 May 1995 08:39:00 -0400 From: John Capo Message-Id: <199505101239.IAA21612@irbs.irbs.com> Subject: Re: pppd & proxyarp & BSD To: freebsd-bugs@FreeBSD.org Date: Wed, 10 May 1995 08:38:59 -0400 (EDT) In-Reply-To: from "Vladimir V. Davydoff" at May 10, 95 03:51:15 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1494 Sender: bugs-owner@FreeBSD.org Precedence: bulk Vladimir V. Davydoff writes: > > A little :-) bug was found in ppp-2.1.2/sys-bsd.c. It prevents > 'proxyarp' options to work. Bug is in get_ether_address(), in getting > interface netmask. Netmask is got from kernel, but doesn't used. > --- ppp-2.1.2/sys-bsd.c 685,693 --- > > /* > > * Get its netmask and check that it's on the right subnet. > > */ > > if (ioctl(s, SIOCGIFNETMASK, &ifreq) < 0) > > continue; > Now we get right netmask of ethernet. > > mask = ((struct sockaddr_in *) &ifr->ifr_addr)->sin_addr.s_addr; > ^^^^^^ > Now we use not netmask, but the ethernet address. Need '&ifreq.'. > > if ((ipaddr & mask) != (ina & mask)) > > continue; > Some addresses work but some not, has infinitive loop. Depend on result > of AND operation between two addresses :-) Load average up, pppd doesn't > die after disconnecting... > This has been reported numerous times. The loop at line 671 in sys-bsd.c _will not_ terminate once a continue statement is hit since the increment part of the loop is after the continues. The address obtained at line 690 is the interface address and not the netmask. This code will work for some people. It depends on the number of interfaces and the order that they are marked up. If someone can show me how the for loop terminates once a continue is hit, I will shut up and take the hat for a while. John Capo From owner-freebsd-bugs Wed May 10 11:26:52 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA29385 for bugs-outgoing; Wed, 10 May 1995 11:26:52 -0700 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 LAA29375 for ; Wed, 10 May 1995 11:26:50 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA26150; Wed, 10 May 95 12:20:11 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9505101820.AA26150@cs.weber.edu> Subject: Re: strange symlinks To: Bernard.Steiner@Germany.EU.net Date: Wed, 10 May 95 12:20:11 MDT Cc: freebsd-bugs@FreeBSD.org In-Reply-To: <199505101040.MAA18416@qwerty.Germany.EU.net> from "Bernard.Steiner@Germany.EU.net" at May 10, 95 12:39:28 pm X-Mailer: ELM [version 2.4dev PL52] Sender: bugs-owner@FreeBSD.org Precedence: bulk > > The next one may be a general 4.4 problem... > > assumption: /tmp/foo does not exist, /tmp/bar is a symlink to /tmp/foo. > > chdir("/tmp/bar") fails with ENOENT, but at the same time > > mkdir("/tmp/bar", 0x777) fails with EEXIST. > > I think this is a generic result of the path component item evaluation > order. I guess the only thing to say is that "according to the code, > this is correct behaviour" 8-). > > Yeah. There's more to this, actually. If you do an open(O_CREAT) > (on SunOS4.1.3; haven't got the FreeBSD box with me now) you get a normal open > file that the symlink points to. IN the light of the mkdir, this is a wee bit > inconsistent, isn't it ? Depends. A symlink is a directory entry reference, not a path reference with the current code semantics. Arguably, either is legal under POSIX. I'd prefer that it be consistent between files and directories, but there isn't a requirement that it be. If someone eventually adds variant symbolic links that can point to directories, then the "fix" for this will just fall out, since the path name parsing will have to treat symbolic link contents as normal path components (which you could mkdir). Is there something you have that depends on this behaviour right now? 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 May 10 14:37:37 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA05605 for bugs-outgoing; Wed, 10 May 1995 14:37:37 -0700 Received: from todonix.ping.de (root@todonix.ping.de [193.100.14.43]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id OAA05594 for ; Wed, 10 May 1995 14:37:31 -0700 Received: by todonix.ping.de (Smail3.1.28.1 #1) id m0s9JQw-0006yOC; Wed, 10 May 95 23:36 MET DST Message-Id: From: jan@todonix.ping.de (Jan Wedekind) Subject: SNAP-0412 boot: init not found! (fwd) To: bugs@FreeBSD.org Date: Wed, 10 May 1995 23:36:41 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 725 Sender: bugs-owner@FreeBSD.org Precedence: bulk Hello, just some more Information and things I found for the following problem i mentioned yesterday: > with the SNAP-0412 i got the following: > > WARNING no swap > Output=0 Inflate_error=2 igz.error=0 error2=0 where=0 > exec /stand/sysinstall: error 8 > init: not found > panic: no init > Well, could the missing NPU cause the trouble, because of a bug in the emulation code or something else ? Or could it be the AMD 386-40 CPU ? (Because there was the question: Yes, of course i have more than 4 (8) MB memory.) > Any suggestions ? Mmh, so far i tried different video cards and Network-Adapters; eventually i'll get an other HD-controlle tommorow. Any other idea's ? thanks for your answers in advance, Jan From owner-freebsd-bugs Thu May 11 03:46:55 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id DAA26243 for bugs-outgoing; Thu, 11 May 1995 03:46:55 -0700 Received: from jp-gate.wide.ad.jp (jp-gate.wide.ad.jp [133.4.1.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id DAA26237 for ; Thu, 11 May 1995 03:46:52 -0700 From: ohki@gssm.otsuka.tsukuba.ac.jp Received: from utogw.gssm.otsuka.tsukuba.ac by jp-gate.wide.ad.jp (8.6.4+2.2W/2.8Wb-jp-gate/1.2) with SMTP id TAA24081; Thu, 11 May 1995 19:46:28 +0900 Received: from [192.50.17.160] by utogw.gssm.otsuka.tsukuba.ac.jp (5.64/6.4J.6-gssm-2.0) id AA09348; Thu, 11 May 95 19:45:27 +0900 Received: from localhost by smri01.gssm.otsuka.tsukuba.ac.jp (8.6.11/SMI-4.1) id TAA00285; Thu, 11 May 1995 19:45:27 +0900 Message-Id: <199505111045.TAA00285@smri01.gssm.otsuka.tsukuba.ac.jp> To: freebsd-bugs@FreeBSD.org Cc: ohki@gssm.otsuka.tsukuba.ac.jp Subject: problem for reading old CD-ROM Mime-Version: 1.0 Content-Type: text/plain;charset="US-ASCII" Date: Thu, 11 May 1995 19:45:26 +0900 Sender: bugs-owner@FreeBSD.org Precedence: bulk Dear folks I have a problem to read my old DOS CD-ROMs with FreeBSD 2.0. My CD-ROMs are 512-byte logical block size, and this causes sys/scsi/cd.c to fail reading 512-byte blocks which are not aligned on 2KB boundaries. Beside this, routines in sys/isofs/cd9660 do not work correctly, since my CD-ROMs has directory entries which cross 512-byte block boundaries. I hacked i) sys/scsi/cd.c to allow unalinged 512-byte block I/O, ii) sys/isofs/cd9660 routines to allow directory entries which cross 512-byte block boundaries if its logical block size is not 2048. This is done mainly with iso_blkatoff() routine. I.e. if its logical block size is not 2048, iso_blkatoff() always read one logical block with the next 512-byte block. Following context diffs are patches I make. I'm sure there will be more smart solutions. For example, make bread() handle block I/O which is not aligned for underlaying devices. #------------------------------------------------------------------------ --- sys/isofs/cd9660/cd9660_lookup.c-ORIG Mon Jan 16 12:14:00 1995 +++ sys/isofs/cd9660/cd9660_lookup.c-ohki Thu May 11 12:37:37 1995 @@ -240,6 +240,19 @@ searchloop: while (dp->i_offset < endsearch) { /* + * Take care of cross boundaries + */ + if (iso_blkoff(imp, entryoffsetinblock) + != entryoffsetinblock) { + entryoffsetinblock = iso_blkoff(imp, entryoffsetinblock); + if (bp != NULL) + brelse(bp); + if ((error = iso_blkatoff(dp, + dp->i_offset - entryoffsetinblock, + &bp))) + return (error); + } + /* * If offset is on a block boundary, * read the next directory block. * Release previous if it exists. @@ -262,6 +275,8 @@ /* skip to next block, if any */ dp->i_offset = roundup(dp->i_offset, imp->logical_block_size); + if (entryoffsetinblock == 0) + dp->i_offset += imp->logical_block_size; continue; } @@ -269,7 +284,7 @@ /* illegal entry, stop */ break; - if (entryoffsetinblock + reclen > imp->logical_block_size) + if (entryoffsetinblock + reclen > bp->b_bcount) /* entries are not allowed to cross boundaries */ break; @@ -461,6 +476,9 @@ int bsize = iso_blksize(imp,ip,lbn); struct buf *bp; int error; + + if (offset >= 0 && bsize < ISO_DEFAULT_BLOCK_SIZE) + bsize += 512; if ((error = bread(ITOV(ip),lbn,bsize,NOCRED,&bp))) { brelse(bp); --- sys/isofs/cd9660/cd9660_node.c-ORIG Thu Mar 16 12:16:00 1995 +++ sys/isofs/cd9660/cd9660_node.c-ohki Thu May 11 10:06:26 1995 @@ -267,7 +267,9 @@ default: /* ISO_FTYPE_9660 || ISO_FTYPE_HIGH_SIERRA */ if ((imp->im_flags&ISOFSMNT_EXTATT) && isonum_711(isodir->ext_attr_length)) - iso_blkatoff(ip,-isonum_711(isodir->ext_attr_length), + iso_blkatoff(ip, + -isonum_711(isodir->ext_attr_length) + * imp->logical_block_size, &bp2); cd9660_defattr(isodir,ip,bp2,imp->iso_ftype ); cd9660_deftstamp(isodir,ip,bp2,imp->iso_ftype ); --- sys/isofs/cd9660/cd9660_vnops.c-ORIG Tue Mar 28 00:14:00 1995 +++ sys/isofs/cd9660/cd9660_vnops.c-ohki Thu May 11 12:39:15 1995 @@ -516,6 +516,19 @@ while (idp->curroff < endsearch) { /* + * Take care of cross boundaries + */ + if (iso_blkoff(imp, entryoffsetinblock) + != entryoffsetinblock) { + entryoffsetinblock = iso_blkoff(imp, entryoffsetinblock); + if (bp != NULL) + brelse(bp); + if ((error = iso_blkatoff(ip, + idp->curroff - entryoffsetinblock, + &bp))) + return (error); + } + /* * If offset is on a block boundary, * read the next directory block. * Release previous if it exists. @@ -536,12 +549,12 @@ (bp->b_un.b_addr + entryoffsetinblock); reclen = isonum_711 (ep->length); - isoflags = isonum_711(imp->iso_ftype == ISO_FTYPE_HIGH_SIERRA? - &ep->date[6]: ep->flags); if (reclen == 0) { /* skip to next block, if any */ idp->curroff = roundup (idp->curroff, imp->logical_block_size); + if (entryoffsetinblock == 0) + idp->curroff += imp->logical_block_size; continue; } @@ -551,11 +564,13 @@ break; } - if (entryoffsetinblock + reclen > imp->logical_block_size) { + if (entryoffsetinblock + reclen > bp->b_bcount) { error = EINVAL; /* illegal directory, so stop looking */ break; } + isoflags = isonum_711(imp->iso_ftype == ISO_FTYPE_HIGH_SIERRA? + &ep->date[6]: ep->flags); /* XXX: be more intelligent if we can */ idp->current.d_type = DT_UNKNOWN; --- sys/scsi/cd.c-ORIG Thu May 4 02:43:00 1995 +++ sys/scsi/cd.c-ohki Thu May 11 19:12:09 1995 @@ -350,6 +350,47 @@ return (0); } +/* + * for unaligned I/O + */ +static void +cd_ul_strategy(struct buf *bp, struct scsi_link *sc_link) +{ + u_int32 unit = CDUNIT((bp->b_dev)); + u_int32 blkoff, nblk; + struct scsi_data *cd = sc_link->sd; + + struct buf *tbp; + + blkoff = bp->b_blkno % (cd->params.blksize / 512); + nblk = (bp->b_bcount + blkoff*512 + (cd->params.blksize - 1)) + / (cd->params.blksize); + + tbp = malloc(sizeof(struct buf), M_TEMP, M_WAITOK); + bzero(tbp, sizeof(struct buf)); + + tbp->b_flags = B_INVAL | B_MALLOC | B_READ; + tbp->b_blkno = bp->b_blkno - blkoff; + tbp->b_dev = bp->b_dev; + tbp->b_resid = tbp->b_bcount = tbp->b_bufsize = nblk * cd->params.blksize; + tbp->b_un.b_addr = malloc(tbp->b_bufsize, M_TEMP, M_WAITOK); + + cd_strategy(tbp, sc_link); + biowait(tbp); + + if ((tbp->b_flags&B_ERROR) == 0 && tbp->b_resid == 0) { + bcopy(tbp->b_un.b_addr + blkoff*512, bp->b_un.b_addr, bp->b_bcount); + bp->b_resid = 0; + } else { + bp->b_flags |= B_ERROR; + bp->b_error = EIO; + bp->b_resid = bp->b_bcount; + } + free(tbp->b_un.b_addr, M_TEMP); + free(tbp, M_TEMP); + biodone(bp); +} + /* * Actually translate the requested transfer into one the physical driver can @@ -395,6 +436,16 @@ bp->b_pblkno = bp->b_blkno; bp->b_resid = 0; } + /* + * take care of unaligned I/O + */ + if (1) { + if ( bp->b_blkno % (cd->params.blksize / 512) ) { + cd_ul_strategy(bp, sc_link); + return; + } + } + opri = SPLCD(); dp = &cd->buf_queue; From owner-freebsd-bugs Thu May 11 08:20:43 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA02156 for bugs-outgoing; Thu, 11 May 1995 08:20:43 -0700 Received: from ns1.win.net (ns1.win.net [204.215.209.3]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id IAA02150 for ; Thu, 11 May 1995 08:20:41 -0700 Received: (from bugs@localhost) by ns1.win.net (8.6.11/8.6.9) id LAA24386 for bugs@freebsd.org; Thu, 11 May 1995 11:22:57 -0400 From: Mark Hittinger Message-Id: <199505111522.LAA24386@ns1.win.net> Subject: boot hang since may01 To: bugs@FreeBSD.org Date: Thu, 11 May 1995 11:22:55 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 839 Sender: bugs-owner@FreeBSD.org Precedence: bulk FYI: I've not been able to boot -current since may01. I am in the process of chasing this down - printf city. The problem appears in the diskslice code. The booting kernel from the may01 sup will change root device, then make what appears to be three passes through the slices. Then it executes a swapon and things are happy. The non-booting kernel's since may02 will only make two passes through the slices and will hang before making a third pass. Today's sup hangs also (may11). I have a p90/bt946c/2gig seagate with the whole disk used by freebsd, and an p60/eisa2740/1gig hp with partition 1 nt and partition 2 freebsd. I will spend more time with this today and try to narrow things down a little more. I just wanted to put out the word since I've not seen anyone else say anything. Regards, Mark Hittinger bugs@win.net From owner-freebsd-bugs Thu May 11 10:56:59 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA08557 for bugs-outgoing; Thu, 11 May 1995 10:56:59 -0700 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 KAA08551 for ; Thu, 11 May 1995 10:56:55 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id KAA10636; Thu, 11 May 1995 10:56:30 -0700 From: "Rodney W. Grimes" Message-Id: <199505111756.KAA10636@gndrsh.aac.dev.com> Subject: Re: problem for reading old CD-ROM To: ohki@gssm.otsuka.tsukuba.ac.jp Date: Thu, 11 May 1995 10:56:30 -0700 (PDT) Cc: freebsd-bugs@FreeBSD.org In-Reply-To: <199505111045.TAA00285@smri01.gssm.otsuka.tsukuba.ac.jp> from "ohki@gssm.otsuka.tsukuba.ac.jp" at May 11, 95 07:45:26 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1323 Sender: bugs-owner@FreeBSD.org Precedence: bulk > > Dear folks > > I have a problem to read my old DOS CD-ROMs with FreeBSD 2.0. > > My CD-ROMs are 512-byte logical block size, > and this causes sys/scsi/cd.c to fail reading 512-byte blocks > which are not aligned on 2KB boundaries. > Beside this, routines in sys/isofs/cd9660 do not work correctly, > since my CD-ROMs has directory entries which cross 512-byte block boundaries. > > I hacked > i) sys/scsi/cd.c to allow unalinged 512-byte block I/O, > ii) sys/isofs/cd9660 routines to allow directory entries which > cross 512-byte block boundaries if its logical block size is not 2048. > This is done mainly with iso_blkatoff() routine. > I.e. if its logical block size is not 2048, > iso_blkatoff() always read one logical block with > the next 512-byte block. > > Following context diffs are patches I make. ... I am not sure, I need to go check my iso 9660 spec, but it seems to me that 512 byte logical blocks are a violation of of the spec. Changing the cd9660 code to read non-conformat cd-roms, IMHO, is an ugly hack at best. Changing block device code to do unaligned block transfers is even worse :-(. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-bugs Thu May 11 11:09:52 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA08793 for bugs-outgoing; Thu, 11 May 1995 11:09:52 -0700 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 LAA08781 for ; Thu, 11 May 1995 11:09:49 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA00919; Thu, 11 May 95 12:02:56 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9505111802.AA00919@cs.weber.edu> Subject: Re: problem for reading old CD-ROM To: rgrimes@gndrsh.aac.dev.com (Rodney W. Grimes) Date: Thu, 11 May 95 12:02:56 MDT Cc: ohki@gssm.otsuka.tsukuba.ac.jp, freebsd-bugs@FreeBSD.org In-Reply-To: <199505111756.KAA10636@gndrsh.aac.dev.com> from "Rodney W. Grimes" at May 11, 95 10:56:30 am X-Mailer: ELM [version 2.4dev PL52] Sender: bugs-owner@FreeBSD.org Precedence: bulk > I am not sure, I need to go check my iso 9660 spec, but it seems to me > that 512 byte logical blocks are a violation of of the spec. Changing > the cd9660 code to read non-conformat cd-roms, IMHO, is an ugly hack > at best. I disagree about the ability to read non-conformant CDROMs. Unfortunately, there's not a sticker that they can only display if they conform, and the public doesn't only buy them if they conform. > Changing block device code to do unaligned block transfers is even > worse :-(. This I definitely agree with; if the code is going to be bastardized, better to do the deed in the FS specific code by buffering more than necessary in and hanging it off the in core version of the vnode after translation instead of hanging it off the vnode in the normal place. This is the same type of hack that's needed for a block compressing file system. 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 May 11 11:13:43 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA09021 for bugs-outgoing; Thu, 11 May 1995 11:13:43 -0700 Received: from todonix.ping.de (root@todonix.ping.de [193.100.14.43]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id LAA09012 for ; Thu, 11 May 1995 11:13:37 -0700 Received: by todonix.ping.de (Smail3.1.28.1 #1) id m0s9cjO-000709C; Thu, 11 May 95 20:13 MET DST Message-Id: From: jan@todonix.ping.de (Jan Wedekind) Subject: SNAP-0412 boot: init not found! (fwd) To: bugs@FreeBSD.org Date: Thu, 11 May 1995 20:13:01 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 590 Sender: bugs-owner@FreeBSD.org Precedence: bulk Hello, just some more Information and things I found for the following problem i mentioned: > > > with the SNAP-0412 i got the following: > > > > WARNING no swap > > Output=0 Inflate_error=2 igz.error=0 error2=0 where=0 > > exec /stand/sysinstall: error 8 > > init: not found > > panic: no init > > > > Well, could the missing NPU cause the trouble, because > of a bug in the emulation code or something else ? > Or could it be the AMD 386-40 CPU ? > Well, it was NOT the missing NPU; I got one and tried the 0412 and 0323-SNAP: both with the described effect! Greetings, Jan From owner-freebsd-bugs Thu May 11 12:10:03 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA10235 for bugs-outgoing; Thu, 11 May 1995 12:10:03 -0700 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 MAA10222 ; Thu, 11 May 1995 12:09:59 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id MAA10840; Thu, 11 May 1995 12:09:46 -0700 From: "Rodney W. Grimes" Message-Id: <199505111909.MAA10840@gndrsh.aac.dev.com> Subject: Re: misc/292: rfc1323 and rfc1644 support can confuse terminal servers w/SLIP To: wollman@halloran-eldar.lcs.mit.edu (Garrett Wollman) Date: Thu, 11 May 1995 12:09:46 -0700 (PDT) Cc: jkh@freefall.cdrom.com, gibbs@estienne.cs.berkeley.edu, freebsd-bugs@freefall.cdrom.com In-Reply-To: <9504032019.AA22793@halloran-eldar.lcs.mit.edu> from "Garrett Wollman" at Apr 3, 95 04:19:17 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1007 Sender: bugs-owner@FreeBSD.org Precedence: bulk > > < said: > > > Maybe these need to be switched on and off inside netstart using > > sysconfig variables? Suggestions? > > I think it's not unreasonable to do: > > # > # Some broken implementations can't handle the RFC 1323 and RFC 1644 > # TCP options. If TCP connections randomly hang, try enabling this, > # and bug the vendor of the losing equipment. > # > if [ "x$disable_tcp_extensions" == "xYES" ]; then > sysctl -nw net.inet.tcp.rfc1323=0 > sysctl -nw net.inet.tcp.rfc1644=0 > fi I have now implemented something similiar to this, those who had problems here please test out the new /etc/netstart and /etc/sysconfig files. You will have to set ``tcp_extensions=NO'' in /etc/sysconfig if your site has problem with the extensions. The default is YES. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-bugs Thu May 11 13:26:26 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id NAA12622 for bugs-outgoing; Thu, 11 May 1995 13:26:26 -0700 Received: from qcunix.acc.qc.edu (qcunix.acc.qc.edu [149.4.2.7]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id NAA12609 for ; Thu, 11 May 1995 13:26:20 -0700 Received: by qcunix.acc.qc.edu (5.57/Ultrix3.0-C) id AA12736; Thu, 11 May 95 16:23:29 -0400 Date: Thu, 11 May 1995 16:23:28 -0400 (EDT) From: YING KEVIN To: bugs@FreeBSD.org Subject: 1st install boot hangs Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: bugs-owner@FreeBSD.org Precedence: bulk Dear FreeBSD experts! I newly bought a pentium 90 with 1GB SCSI HD for freeBSD. I tried to install FreeBSD 2.0 with Walnut CD distribution. Installation boot hangs before the initial welcome screen shows. Could you help me out here?! Kevin error message is as following: boot FreeBSD from boot disk: ... pci0: scanning device 0..31, mechanism=1 pci0:0: INTEL CORPORATION, device=0x122d, class=bridge [not supported] pci0:7: INTEL CORPORATION, device=0x122e, class=bridge [not supported] graphics0 on pci0:18 changing root device to fd0c ...........(/*it hangs right here*/) /*After Ctrl+Alt+Del was hit*/ Fatal trap 12: page fault while in kernel mode fault virtual address = 0x29 fault code = supervisor read, page not present instruction pointer = 0x8: 0xf010e491 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres1, def32 1, gran 1 processor eflags = interrupt enabled, resume, 10PL=0 current process = 0 () interrupt mask = net tty panic: page fault hit reset please. From owner-freebsd-bugs Thu May 11 14:10:04 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA13828 for bugs-outgoing; Thu, 11 May 1995 14:10:04 -0700 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA13821 ; Thu, 11 May 1995 14:10:02 -0700 Date: Thu, 11 May 1995 14:10:02 -0700 Message-Id: <199505112110.OAA13821@freefall.cdrom.com> From: widmer@cisco.com Reply-To: widmer@cisco.com To: freebsd-bugs Subject: i386/394: ip multicast in ep driver In-Reply-To: Your message of Thu, 11 May 1995 14:04:09 -0700 <199505112104.OAA00764@lazy8.cisco.com> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 394 >Category: i386 >Synopsis: IP multicast not supported by ep driver >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu May 11 14:10:01 1995 >Originator: Rob Widmer >Organization: Cisco Systems, Inc. >Release: FreeBSD 2.0-RELEASE i386 >Environment: PC with 3Com 3c509 Combo >Description: ep driver for 3c509 doesn't support IP multicast >How-To-Repeat: Try running sd using 3c509 gives error message IP_ADD_MEMBERSHIP: Can't assign requested address >Fix: The following diff to /usr/src/sys/i386/isa/if_ep.c *** 559,564 **** --- 559,565 ---- ifp->if_name = "ep"; ifp->if_mtu = ETHERMTU; ifp->if_flags = IFF_BROADCAST | IFF_SIMPLEX | IFF_NOTRAILERS; + ifp->if_flags |= IFF_MULTICAST; ifp->if_init = epinit; ifp->if_output = ether_output; ifp->if_start = epstart; *************** *** 1336,1341 **** --- 1337,1363 ---- ifp->if_mtu = ifr->ifr_mtu; } break; + + case SIOCADDMULTI: + case SIOCDELMULTI: + /* + * Update our multicast listeners + */ + if (cmd == SIOCADDMULTI) { + ether_addmulti(ifr, &sc->arpcom); + } else { + ether_delmulti(ifr, &sc->arpcom); + } + + if (error == ENETRESET) { + /* + * Multicast list has changed; set the + * hardware filter accordingly + */ + epreset(ifp->if_unit); + error = 0; + } + break; default: error = EINVAL; >Audit-Trail: >Unformatted: From owner-freebsd-bugs Thu May 11 15:26:12 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id PAA16789 for bugs-outgoing; Thu, 11 May 1995 15:26:12 -0700 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 PAA16783 for ; Thu, 11 May 1995 15:26:09 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id PAA13385; Thu, 11 May 1995 15:25:42 -0700 From: "Rodney W. Grimes" Message-Id: <199505112225.PAA13385@gndrsh.aac.dev.com> Subject: Re: 1st install boot hangs To: l3pqc@qcunix.acc.qc.edu (YING KEVIN) Date: Thu, 11 May 1995 15:25:41 -0700 (PDT) Cc: bugs@FreeBSD.org In-Reply-To: from "YING KEVIN" at May 11, 95 04:23:28 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1315 Sender: bugs-owner@FreeBSD.org Precedence: bulk > > Dear FreeBSD experts! > > I newly bought a pentium 90 with 1GB SCSI HD for freeBSD. I tried to > install FreeBSD 2.0 with Walnut CD distribution. Installation boot > hangs before the initial welcome screen shows. Could you help me out > here?! This looks like an Intel Triton chip set, is this the ASUS PCI/I-P54TP4 motherboard? Or is it the SuperMicro or Intel Zappa board? Also have you done anthing in the BIOS setup values like set the floppy swap drives?? Try setting the BIOS vales to ``setup defaults''. > Kevin > > > error message is as following: > > boot FreeBSD from boot disk: > ... > pci0: scanning device 0..31, mechanism=1 > pci0:0: INTEL CORPORATION, device=0x122d, class=bridge [not supported] > pci0:7: INTEL CORPORATION, device=0x122e, class=bridge [not supported] > graphics0 on pci0:18 > changing root device to fd0c > ...........(/*it hangs right here*/) > > /*After Ctrl+Alt+Del was hit*/ > Fatal trap 12: page fault while in kernel mode This happens if the system has not started the init process yet :-(, the kernel attempts to deliver a signal to pid 1, which does not exist at this time :-(. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-bugs Thu May 11 16:40:03 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id QAA19471 for bugs-outgoing; Thu, 11 May 1995 16:40:03 -0700 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id QAA19464 ; Thu, 11 May 1995 16:40:02 -0700 Date: Thu, 11 May 1995 16:40:02 -0700 Message-Id: <199505112340.QAA19464@freefall.cdrom.com> From: Tatu Ylonen Reply-To: Tatu Ylonen To: freebsd-bugs Subject: i386/395: CRITICAL PROBLEM: spl functions implemented incorrectly In-Reply-To: Your message of Fri, 12 May 1995 02:41:07 GMT <199505120241.CAA00890@fx7.cs.hut.fi> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 395 >Category: i386 >Synopsis: All spl functions implemented incorrectly in both FreeBSD and NetBSD >Confidential: no >Severity: critical >Priority: high >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu May 11 16:40:01 1995 >Originator: Tatu Ylonen >Organization: Helsinki University of Technology, FInland >Release: FreeBSD 2.1.0-Development i386 >Environment: FreeBSD 2.1.0-Development i386 (Supped May 5, 1995). Recent NetBSD has similar problems. >Description: Spl functions (splbio, splclock, splhigh, splimp, splnet, splsoftclock, splsofttty, splstatclock, spltty, spl0, splx) are defined in /usr/src/sys/i386/include/spl.h as inline functions that modify the ordinary variable cpl (extern unsigned cpl in the same header). This means that the compiler has full knowledge about the semantics, side-effects, and dependencies of these functions. The compiler inlines these functions, and can mix (reorder) the resulting code with other code in the function that calls the spl function. - The value may not get actually written to cpl until the end of the function calling the spl function, or when a function with unknown dependencies is called. This may be *after* the protected code is executed, or the compiler might even entirely optimize the code out because splx assigns the value later in the function. - It would not help to simply make cpl volatile, because the compiler would still be allowed to cache intermediate values or results of common subexpressions in registers across the lock/unlock requests. A simple solution is to make the spl functions real functions stored in a separate file, and only have prototypes in spl.h. This way, the compiler does not know anything about the function, and will have to assume the worst: it might access or modify any memory, which means the compiler will have to flush any modifications to memory before the call, and not make any assumptions about common subexpressions being preserved across the call. There is a slight performance penalty due to the real call, but it is not significant and not easy to avoid reliably. Also, be aware that if the OS is ever to be ported to a multiprocessor, the functions will need to be rewritten. The instructions they now use are not atomic in a multiprocessor environment. >How-To-Repeat: The real effects of this problem are not predictable or deterministic. They may depend on compiler version or optimization levels. General unreliability, mysterious problems, and random panics are all likely. I started to wonder about this because sysv message queues were losing messages (that's another story - I'll write about it later). This could also explain inode lockups problems I had with an earlier release. Actually, I am surprised the kernel works at all, even fairly well. >Fix: Move all spl functions (splbio, splclock, splhigh, splimp, splnet, splsoftclock, splsofttty, splstatclock, spltty, spl0, splx) away from spl.h, make them real (global) functions, and leave only prototypes in spl.h. It might not be a bad idea to make cpl volatile to be sure; I am not sure if it is necessary. My quick fix is as follows; someone else can do it more cleanly (I think the spl code could be in a separate .c file, but I simply stored it in a random .c file). i386/include/spl.h: - Move the GENSPL macro and its uses, and spl0 and splx to i386/386/sys_machdep.c. Edit the macro and functions to make them normal non-static, non-inline functions. - Add the following prototypes: int splbio(void); int splclock(void); int splhigh(void); int splimp(void); int splnet(void); int splsoftclock(void); int splsofttty(void); int splstatclock(void); int spltty(void); void spl0(void); void splx(int old); i386/i386/sys_machdep.c: - I moved the spl code here. I think it would be cleaner to have a separate .c file for it. >Audit-Trail: >Unformatted: From owner-freebsd-bugs Thu May 11 17:10:03 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id RAA20186 for bugs-outgoing; Thu, 11 May 1995 17:10:03 -0700 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id RAA20179 ; Thu, 11 May 1995 17:10:02 -0700 Date: Thu, 11 May 1995 17:10:02 -0700 Message-Id: <199505120010.RAA20179@freefall.cdrom.com> From: Charles Henrich Reply-To: Charles Henrich To: freebsd-bugs Subject: bin/396: telnetd problems. In-Reply-To: Your message of Thu, 11 May 1995 20:01:59 -0400 <199505120001.UAA08320@fubar.cl.msu.edu> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 396 >Category: bin >Synopsis: telnetd problems. >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu May 11 17:10:01 1995 >Originator: Charles Henrich >Organization: Michigan State University Charles Henrich Michigan State University henrich@crh.cl.msu.edu http://rs560.msu.edu/~henrich/ >Release: FreeBSD 2.1.0-Development i386 (950412-SNAP) >Environment: This bug is encountered on all FreeBSD systems running 950412-SNAP as well as 950210-SNAP, probably on all 2.x versions. The other half is any PeeCee running FTP Software's PCTCP v2.x or v3.x >Description: Whenever a user presses return whilst using PCTCP the return is (apparently) interpreted twice by telnetd, causing double returns on every key press. This does not occur with PCTCP and telnetd on the following systems: HPUX, IRIX, OSF/1, Solaris, SunOS, AIX, or Linux. Could it possibly be different telnetd defaults are being used by FreeBSD than other operating systems, so that if no negotiation is done things are weird? >How-To-Repeat: use FTP Software's PCTCP to tn to a FreeBSD host and press return. :) >Fix: >Audit-Trail: >Unformatted: From owner-freebsd-bugs Thu May 11 18:24:18 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA22691 for bugs-outgoing; Thu, 11 May 1995 18:24:18 -0700 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 SAA22685 for ; Thu, 11 May 1995 18:24:15 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id SAA13705; Thu, 11 May 1995 18:23:53 -0700 From: "Rodney W. Grimes" Message-Id: <199505120123.SAA13705@gndrsh.aac.dev.com> Subject: Re: bin/396: telnetd problems. To: henrich@fubar.cl.msu.edu Date: Thu, 11 May 1995 18:23:53 -0700 (PDT) Cc: freebsd-bugs@freefall.cdrom.com In-Reply-To: <199505120010.RAA20179@freefall.cdrom.com> from "Charles Henrich" at May 11, 95 05:10:02 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1183 Sender: bugs-owner@FreeBSD.org Precedence: bulk > > > >Number: 396 > >Category: bin > >Synopsis: telnetd problems. > >Confidential: no > >Severity: serious > >Priority: medium > >Responsible: freebsd-bugs (FreeBSD bugs mailing list) > >State: open > >Class: sw-bug > >Submitter-Id: current-users > >Arrival-Date: Thu May 11 17:10:01 1995 > >Originator: Charles Henrich > >Organization: > Michigan State University > Charles Henrich Michigan State University henrich@crh.cl.msu.edu > > http://rs560.msu.edu/~henrich/ > >Release: FreeBSD 2.1.0-Development i386 (950412-SNAP) > >Environment: > > > This bug is encountered on all FreeBSD systems running 950412-SNAP as > well as 950210-SNAP, probably on all 2.x versions. Probably on all 4.4 based OS's. Did you also open a bug report with FTP software?? They use to base there code on BSD 4.2 / Net/2 and it probably still has the bugs from that generation of code. NCSA Telnet also seems to have this problem.... -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-bugs Thu May 11 18:29:43 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA22790 for bugs-outgoing; Thu, 11 May 1995 18:29:43 -0700 Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id SAA22784 for ; Thu, 11 May 1995 18:29:40 -0700 Message-Id: <199505120129.SAA22784@freefall.cdrom.com> Received: by crh.cl.msu.edu (1.38.193.4/16.2) id AA01275; Thu, 11 May 1995 21:29:37 -0400 Date: Thu, 11 May 1995 21:29:37 -0400 From: Charles Henrich Apparently-To: freebsd-bugs@freefall.cdrom.com Sender: bugs-owner@FreeBSD.org Precedence: bulk >From henrich Thu May 11 21:28:57 1995 remote from crh Subject: Re: bin/396: telnetd problems. To: rgrimes@gndrsh.aac.dev.com (Rodney W. Grimes) Date: Thu, 11 May 1995 21:28:57 -0400 (EDT) In-Reply-To: <199505120123.SAA13705@gndrsh.aac.dev.com> from "Rodney W. Grimes" at May 11, 95 06:23:53 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 727 Sender: henrich > > > > This bug is encountered on all FreeBSD systems running 950412-SNAP as > > well as 950210-SNAP, probably on all 2.x versions. > > Probably on all 4.4 based OS's. Did you also open a bug report with FTP > software?? They use to base there code on BSD 4.2 / Net/2 and it probably > still has the bugs from that generation of code. > > NCSA Telnet also seems to have this problem.... No, but I just "fixed" it. If you compile telnetd without the LINEMODE code, all works well on all systems. And on top of it, the system feels crisper. Perhaps this should be the default? -Crh Charles Henrich Michigan State University henrich@crh.cl.msu.edu http://rs560.msu.edu/~henrich/ From owner-freebsd-bugs Thu May 11 18:45:38 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA23429 for bugs-outgoing; Thu, 11 May 1995 18:45:38 -0700 Received: from jp-gate.wide.ad.jp (jp-gate.wide.ad.jp [133.4.1.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id SAA23421 for ; Thu, 11 May 1995 18:45:36 -0700 From: ohki@gssm.otsuka.tsukuba.ac.jp Received: from utogw.gssm.otsuka.tsukuba.ac by jp-gate.wide.ad.jp (8.6.4+2.2W/2.8Wb-jp-gate/1.2) with SMTP id KAA00838; Fri, 12 May 1995 10:45:14 +0900 Received: from [192.50.17.160] by utogw.gssm.otsuka.tsukuba.ac.jp (5.64/6.4J.6-gssm-2.0) id AA14652; Fri, 12 May 95 10:44:15 +0900 Received: from localhost by smri01.gssm.otsuka.tsukuba.ac.jp (8.6.11/SMI-4.1) id KAA00248; Fri, 12 May 1995 10:44:14 +0900 Message-Id: <199505120144.KAA00248@smri01.gssm.otsuka.tsukuba.ac.jp> To: terry@cs.weber.edu (Terry Lambert) Cc: rgrimes@gndrsh.aac.dev.com (Rodney W. Grimes), freebsd-bugs@FreeBSD.org Subject: Re: problem for reading old CD-ROM In-Reply-To: Your message of "Thu, 11 May 1995 12:02:56 MDT" References: <9505111802.AA00919@cs.weber.edu> Mime-Version: 1.0 Content-Type: text/plain;charset="US-ASCII" Date: Fri, 12 May 1995 10:44:14 +0900 Sender: bugs-owner@FreeBSD.org Precedence: bulk rgrimes>> I am not sure, I need to go check my iso 9660 spec, rgrimes>> but it seems to me rgrimes>> that 512 byte logical blocks are a violation of of the spec. rgrimes>> Changing rgrimes>> the cd9660 code to read non-conformat cd-roms, IMHO, is an ugly hack rgrimes>> at best. terry> I disagree about the ability to read non-conformant CDROMs. terry> Unfortunately, terry> there's not a sticker that they can only display if they conform, and terry> the public doesn't only buy them if they conform. rgrimes>> Changing block device code to do unaligned block transfers is even rgrimes>> worse :-(. terry> This I definitely agree with; if the code is going to be bastardized, terry> better to do the deed in the FS specific code by buffering more than terry> necessary in and hanging it off the in core version of the vnode after terry> translation instead of hanging it off the vnode in the normal place. I know my hacking is not a good one, and I wanted to hear opinions about handling of non-conformat cd-roms from members. The cd-rom I tried to read is labled as "This disc was mastered to ISO 9660 Standard. Level 1", so I thought this is confomat cd-rom. (Is this not true?) From owner-freebsd-bugs Thu May 11 18:58:56 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA23707 for bugs-outgoing; Thu, 11 May 1995 18:58:56 -0700 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 SAA23701 for ; Thu, 11 May 1995 18:58:52 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id SAA13806; Thu, 11 May 1995 18:58:29 -0700 From: "Rodney W. Grimes" Message-Id: <199505120158.SAA13806@gndrsh.aac.dev.com> Subject: Re: problem for reading old CD-ROM To: ohki@gssm.otsuka.tsukuba.ac.jp Date: Thu, 11 May 1995 18:58:28 -0700 (PDT) Cc: terry@cs.weber.edu, freebsd-bugs@FreeBSD.org In-Reply-To: <199505120144.KAA00248@smri01.gssm.otsuka.tsukuba.ac.jp> from "ohki@gssm.otsuka.tsukuba.ac.jp" at May 12, 95 10:44:14 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1867 Sender: bugs-owner@FreeBSD.org Precedence: bulk > > > rgrimes>> I am not sure, I need to go check my iso 9660 spec, > rgrimes>> but it seems to me > rgrimes>> that 512 byte logical blocks are a violation of of the spec. > rgrimes>> Changing > rgrimes>> the cd9660 code to read non-conformat cd-roms, IMHO, is an ugly hack > rgrimes>> at best. > > terry> I disagree about the ability to read non-conformant CDROMs. > terry> Unfortunately, > terry> there's not a sticker that they can only display if they conform, and > terry> the public doesn't only buy them if they conform. > > rgrimes>> Changing block device code to do unaligned block transfers is even > rgrimes>> worse :-(. > > terry> This I definitely agree with; if the code is going to be bastardized, > terry> better to do the deed in the FS specific code by buffering more than > terry> necessary in and hanging it off the in core version of the vnode after > terry> translation instead of hanging it off the vnode in the normal place. > > I know my hacking is not a good one, and I wanted to hear opinions > about handling of non-conformat cd-roms from members. > > The cd-rom I tried to read is labled as > "This disc was mastered to ISO 9660 Standard. Level 1", > so I thought this is confomat cd-rom. (Is this not true?) Refering to ISO 9660 : 1988 (E) sections 6.1.2 and 6.2.2 tell me that a Logical Sector and Logical Block are of size 2^(n+9) meaning 2048 bytes or longer, thus a 512 byte logical block is infact a violation of ISO 9660 : 1988 (E). You should be able to ftp a copy of that spec from ftp.cdrom.com:/pub/cdrom some place. Check the faq, they might have a pointer in there to the location of the iso spec. Or maybe it is only the RRIP spec you can get online. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-bugs Thu May 11 19:13:30 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id TAA24130 for bugs-outgoing; Thu, 11 May 1995 19:13:30 -0700 Received: from relay3.UU.NET (relay3.UU.NET [192.48.96.8]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id TAA24120 for ; Thu, 11 May 1995 19:13:25 -0700 Received: from ast.com by relay3.UU.NET with SMTP id QQypim27824; Thu, 11 May 1995 22:13:22 -0400 Received: from trsvax.fw.ast.com (fw.ast.com) by ast.com with SMTP id AA16767 (5.67b/IDA-1.5 for uunet!FreeBSD.org!freebsd-bugs); Thu, 11 May 1995 19:13:29 -0700 Received: by trsvax.fw.ast.com (/\=-/\ Smail3.1.18.1 #18.1) id ; Thu, 11 May 95 21:10 CDT Received: by nemesis.lonestar.org (Smail3.1.27.1 #18) id m0s9k98-0004vxC; Thu, 11 May 95 21:08 CDT Message-Id: Date: Thu, 11 May 95 21:08 CDT To: rgrimes@gndrsh.aac.dev.com, freebsd-bugs@FreeBSD.org From: uhclem%nemesis@fw.ast.com (Frank Durda IV) Sent: Thu May 11 1995, 21:08:05 CDT Subject: Re: problem for reading old CD-ROM Sender: bugs-owner@FreeBSD.org Precedence: bulk [1]I am not sure, I need to go check my iso 9660 spec, but it seems to me [1]that 512 byte logical blocks are a violation of of the spec. Changing [1]the cd9660 code to read non-conformat cd-roms, IMHO, is an ugly hack [1]at best. ISO 9660 6.1.2 (Page 3 of the standard) says: "The sectors of a volume shall be organized into Logical Sectors. Each Logical Sector shall consist of a number of bytes equal to 2048 or 2^n, whichever is larger, where n is the largest integer such that s^n is less than, or equal to, the number of bytes in the Data Field of any sector recorded on the volume." And more to the point of the question at hand: (also from 6.1.2) "If the number of bytes of the Data Field of each sector recorded on the volume is less than 2,048, a Logical Sector shall comprise more than one sector, and the set of the Physical Addresses of its constituent sectors shall form a consecutive ascending sequence. The data of the Logical Sector shall be recorded in the Data Fields of its constituent sectors." So, ISO9660 does allow you to use smaller blocks (say 512 or even 256 bytes) to make up 2048 byte ISO 9660 Logical Sectors. BUT, 512 byte blocks on CDs are not compliant with any Red, Orange (Part II CD-WO), Yellow, Green, (including Kodak Variants), Blue and probably not allowed by the White book either. In CDs, a block is "a unity of 2352 bytes as described in the Yellow Book, (page 100)" - 1.4.1 CD-WO description. Of that 2352 bytes, 2048 is considered to be the Data Area for nearly all non-audio formats on CD. The ISO allowance for non-2048 byte sectors is to allow the 9660 format to exist on other types of media, such as hard disks, Magneto-Optical media, Minidisc, etc. But the Sony/Philips CD standard do not allow non-2048 byte data sectors. [1]Changing block device code to do unaligned block transfers is even [1]worse :-(. Agreed. In fact the ISO specification is quite clear that you must always read and write (during mastering) in 2048 byte Logical Sectors. No fractional reads or writes, even on non-2048 byte data. The entire directory and path look-up strategy relies on this. Frank Durda IV |"The Knights who say "LETNi" or uhclem%nemesis@fw.ast.com (Fastest Route)| demand... A SEGMENT REGISTER!!!" ...letni!rwsys!nemesis!uhclem |"A what?" ...decvax!fw.ast.com!nemesis!uhclem |"LETNi! LETNi! LETNi!" - 1983 From owner-freebsd-bugs Thu May 11 19:17:23 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id TAA24313 for bugs-outgoing; Thu, 11 May 1995 19:17:23 -0700 Received: from jp-gate.wide.ad.jp (jp-gate.wide.ad.jp [133.4.1.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id TAA24302 for ; Thu, 11 May 1995 19:17:17 -0700 From: ohki@gssm.otsuka.tsukuba.ac.jp Received: from utogw.gssm.otsuka.tsukuba.ac by jp-gate.wide.ad.jp (8.6.4+2.2W/2.8Wb-jp-gate/1.2) with SMTP id LAA01089; Fri, 12 May 1995 11:17:00 +0900 Received: from [192.50.17.160] by utogw.gssm.otsuka.tsukuba.ac.jp (5.64/6.4J.6-gssm-2.0) id AA14751; Fri, 12 May 95 11:16:02 +0900 Received: from localhost by smri01.gssm.otsuka.tsukuba.ac.jp (8.6.11/SMI-4.1) id LAA00408; Fri, 12 May 1995 11:16:01 +0900 Message-Id: <199505120216.LAA00408@smri01.gssm.otsuka.tsukuba.ac.jp> To: "Rodney W. Grimes" Cc: terry@cs.weber.edu, freebsd-bugs@FreeBSD.org Subject: Re: problem for reading old CD-ROM In-Reply-To: Your message of "Thu, 11 May 1995 18:58:28 MST" References: <199505120158.SAA13806@gndrsh.aac.dev.com> Mime-Version: 1.0 Content-Type: text/plain;charset="US-ASCII" Date: Fri, 12 May 1995 11:16:00 +0900 Sender: bugs-owner@FreeBSD.org Precedence: bulk "Rodney W. Grimes" writes: > > The cd-rom I tried to read is labled as > > "This disc was mastered to ISO 9660 Standard. Level 1", > > so I thought this is confomat cd-rom. (Is this not true?) > > Refering to ISO 9660 : 1988 (E) sections 6.1.2 and 6.2.2 tell me that > a Logical Sector and Logical Block are of size 2^(n+9) meaning 2048 > bytes or longer, thus a 512 byte logical block is infact a violation > of ISO 9660 : 1988 (E). Can't `n' be 0, in that case, 2^(n+9) ==> 512 (I'm sorry I can't find iso spec online from ftp.cdrom.co:/pub/cdrom, so I might be wrong.) Thank you for your time. From owner-freebsd-bugs Thu May 11 19:20:05 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id TAA24450 for bugs-outgoing; Thu, 11 May 1995 19:20:05 -0700 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id TAA24443 ; Thu, 11 May 1995 19:20:04 -0700 Date: Thu, 11 May 1995 19:20:04 -0700 Message-Id: <199505120220.TAA24443@freefall.cdrom.com> From: Charles Henrich Reply-To: Charles Henrich To: freebsd-bugs Subject: gnu/397: man spews worthless information In-Reply-To: Your message of Thu, 11 May 1995 22:18:26 -0400 <199505120218.WAA08811@fubar.cl.msu.edu> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 397 >Category: gnu >Synopsis: man spews worthless information >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: change-request >Submitter-Id: current-users >Arrival-Date: Thu May 11 19:20:02 1995 >Originator: Charles Henrich >Organization: Michigan State University >Release: FreeBSD 2.1.0-Development i386 >Environment: FreeBSD 950412-SNAP >Description: Man as shipped with FreeBSD spews a message for each directory that is in the manpath but not on disk (i.e.: Warning: couldn't stat file /usr/man! Warning: couldn't stat file /usr/share/catman! Warning: couldn't stat file /usr/catman! Warning: couldn't stat file /usr/local/X11R6/man! Warning: couldn't stat file /usr/X11R5/man! Warning: couldn't stat file /usr/local/X11R5/man! Warning: couldn't stat file /usr/local/AF/man! A) no other man on the planet gives these warnings. B) Because no other man on the planet gives these warnings lots of folks just create a huge manpath that will work on all systems they have a shared home directory on. C) Because shared home directories are prevelent at Universities and other large organizations these worthless messages should be stomped. >How-To-Repeat: Run man with an "invalid" manpath. >Fix: /usr/src/gnu/usr.bin/man/man/man.c *** man.c Tue Apr 11 18:01:53 1995 --- man.new.c Thu May 11 22:10:47 1995 *************** *** 269,283 **** status = is_directory (p); ! if (status < 0) ! { ! fprintf (stderr, "Warning: couldn't stat file %s!\n", p); ! } ! else if (status == 0) ! { ! fprintf (stderr, "Warning: %s isn't a directory!\n", p); ! } ! else if (status == 1) { if (debug) fprintf (stderr, "adding %s to manpathlist\n", p); --- 269,275 ---- status = is_directory (p); ! if (status == 1) { if (debug) fprintf (stderr, "adding %s to manpathlist\n", p); >Audit-Trail: >Unformatted: From owner-freebsd-bugs Thu May 11 19:21:57 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id TAA24520 for bugs-outgoing; Thu, 11 May 1995 19:21:57 -0700 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 TAA24509 for ; Thu, 11 May 1995 19:21:53 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id TAA13855; Thu, 11 May 1995 19:21:31 -0700 From: "Rodney W. Grimes" Message-Id: <199505120221.TAA13855@gndrsh.aac.dev.com> Subject: Re: problem for reading old CD-ROM To: ohki@gssm.otsuka.tsukuba.ac.jp Date: Thu, 11 May 1995 19:21:31 -0700 (PDT) Cc: terry@cs.weber.edu, freebsd-bugs@FreeBSD.org In-Reply-To: <199505120216.LAA00408@smri01.gssm.otsuka.tsukuba.ac.jp> from "ohki@gssm.otsuka.tsukuba.ac.jp" at May 12, 95 11:16:00 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1086 Sender: bugs-owner@FreeBSD.org Precedence: bulk > > "Rodney W. Grimes" writes: > > > The cd-rom I tried to read is labled as > > > "This disc was mastered to ISO 9660 Standard. Level 1", > > > so I thought this is confomat cd-rom. (Is this not true?) > > > > Refering to ISO 9660 : 1988 (E) sections 6.1.2 and 6.2.2 tell me that > > a Logical Sector and Logical Block are of size 2^(n+9) meaning 2048 > > bytes or longer, thus a 512 byte logical block is infact a violation > > of ISO 9660 : 1988 (E). > > Can't `n' be 0, in that case, 2^(n+9) ==> 512 > (I'm sorry I can't find iso spec online from ftp.cdrom.co:/pub/cdrom, > so I might be wrong.) Your right, but see other mail from Frank D.(sp). I dropped a few things when I summarized above. Did you look in /pub/cdrom/faq/*, read those files there are probably pointers to many of the specs in there. Or send mail to rab@cdrom.com if all else fails, I am sure he can point you to the source for the specs. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-bugs Thu May 11 19:37:31 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id TAA25307 for bugs-outgoing; Thu, 11 May 1995 19:37:31 -0700 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 TAA25293 for ; Thu, 11 May 1995 19:37:27 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id TAA13900; Thu, 11 May 1995 19:37:05 -0700 From: "Rodney W. Grimes" Message-Id: <199505120237.TAA13900@gndrsh.aac.dev.com> Subject: Re: gnu/397: man spews worthless information To: henrich@fubar.cl.msu.edu Date: Thu, 11 May 1995 19:37:04 -0700 (PDT) Cc: freebsd-bugs@freefall.cdrom.com In-Reply-To: <199505120220.TAA24443@freefall.cdrom.com> from "Charles Henrich" at May 11, 95 07:20:04 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1095 Sender: bugs-owner@FreeBSD.org Precedence: bulk How about a better patch... > > >Number: 397 > >Category: gnu > >Synopsis: man spews worthless information ... > /usr/src/gnu/usr.bin/man/man/man.c > > *** man.c Tue Apr 11 18:01:53 1995 > --- man.new.c Thu May 11 22:10:47 1995 > *************** > *** 269,283 **** > > status = is_directory (p); > > ! if (status < 0) if (status < 0 && debug) > ! { > ! fprintf (stderr, "Warning: couldn't stat file %s!\n", p); > ! } > ! else if (status == 0) else if (status == 0 && debug) > ! { > ! fprintf (stderr, "Warning: %s isn't a directory!\n", p); > ! } > ! else if (status == 1) > { > if (debug) > fprintf (stderr, "adding %s to manpathlist\n", p); > --- 269,275 ---- > > status = is_directory (p); > > ! if (status == 1) > { > if (debug) > fprintf (stderr, "adding %s to manpathlist\n", p); Or inclose the block in if (debug) -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-bugs Thu May 11 21:02:22 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA28926 for bugs-outgoing; Thu, 11 May 1995 21:02:22 -0700 Received: from localhost (localhost [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id VAA28919 ; Thu, 11 May 1995 21:02:21 -0700 X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol To: "Rodney W. Grimes" cc: henrich@fubar.cl.msu.edu, freebsd-bugs@freefall.cdrom.com Subject: Re: gnu/397: man spews worthless information In-reply-to: Your message of "Thu, 11 May 95 19:37:04 PDT." <199505120237.TAA13900@gndrsh.aac.dev.com> Date: Thu, 11 May 1995 21:02:21 -0700 Message-ID: <28918.800251341@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: bugs-owner@FreeBSD.org Precedence: bulk > How about a better patch... Either is fine with me. Why don't you guys agree on one and Rod can commit it? The man spew has annoyed me in the past as well! Jordan From owner-freebsd-bugs Thu May 11 21:05:00 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA29038 for bugs-outgoing; Thu, 11 May 1995 21:05:00 -0700 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 VAA29032 ; Thu, 11 May 1995 21:04:56 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id VAA14040; Thu, 11 May 1995 21:04:48 -0700 From: "Rodney W. Grimes" Message-Id: <199505120404.VAA14040@gndrsh.aac.dev.com> Subject: Re: gnu/397: man spews worthless information To: jkh@freefall.cdrom.com (Jordan K. Hubbard) Date: Thu, 11 May 1995 21:04:48 -0700 (PDT) Cc: henrich@fubar.cl.msu.edu, freebsd-bugs@freefall.cdrom.com In-Reply-To: <28918.800251341@freefall.cdrom.com> from "Jordan K. Hubbard" at May 11, 95 09:02:21 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 422 Sender: bugs-owner@FreeBSD.org Precedence: bulk > > > How about a better patch... > > Either is fine with me. Why don't you guys agree on one and Rod can > commit it? The man spew has annoyed me in the past as well! > Well do, I saved the gnats bug report and was waiting for responses to my proposed change. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-bugs Thu May 11 21:24:46 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA29652 for bugs-outgoing; Thu, 11 May 1995 21:24:46 -0700 Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id VAA29646 for ; Thu, 11 May 1995 21:24:44 -0700 Message-Id: <199505120424.VAA29646@freefall.cdrom.com> Received: by crh.cl.msu.edu (1.38.193.4/16.2) id AA01800; Fri, 12 May 1995 00:24:25 -0400 From: Charles Henrich Subject: Re: gnu/397: man spews worthless information To: rgrimes@gndrsh.aac.dev.com (Rodney W. Grimes) Date: Fri, 12 May 1995 00:24:25 -0400 (EDT) Cc: freebsd-bugs@FreeBSD.org In-Reply-To: <199505120404.VAA14040@gndrsh.aac.dev.com> from "Rodney W. Grimes" at May 11, 95 09:04:48 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 524 Sender: bugs-owner@FreeBSD.org Precedence: bulk > > Either is fine with me. Why don't you guys agree on one and Rod can > > commit it? The man spew has annoyed me in the past as well! > > > > Well do, I saved the gnats bug report and was waiting for responses > to my proposed change. I dont care either way, seemed to be mostly worthless information, hence the deletions. Do whatever you like Rod, Im happy as long as its gone :) -Crh Charles Henrich Michigan State University henrich@crh.cl.msu.edu http://rs560.msu.edu/~henrich/ From owner-freebsd-bugs Thu May 11 21:57:28 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA00268 for bugs-outgoing; Thu, 11 May 1995 21:57:28 -0700 Received: (from rgrimes@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA00254 ; Thu, 11 May 1995 21:57:27 -0700 Date: Thu, 11 May 1995 21:57:27 -0700 From: "Rodney W. Grimes" Message-Id: <199505120457.VAA00254@freefall.cdrom.com> To: henrich@crh.cl.msu.edu, rgrimes, freebsd-bugs Subject: Changed information for PR gnu/397 Sender: bugs-owner@FreeBSD.org Precedence: bulk Synopsis: man spews worthless information State-Changed-From-To: open-closed State-Changed-By: rgrimes State-Changed-When: Thu May 11 21:56:42 PDT 1995 State-Changed-Why: /home/ncvs/src/gnu/usr.bin/man/man/man.c,v <-- man.c new revision: 1.12; previous revision: 1.11 From owner-freebsd-bugs Thu May 11 21:58:57 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA00294 for bugs-outgoing; Thu, 11 May 1995 21:58:57 -0700 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 VAA00288 ; Thu, 11 May 1995 21:58:54 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id VAA15555; Thu, 11 May 1995 21:58:46 -0700 From: "Rodney W. Grimes" Message-Id: <199505120458.VAA15555@gndrsh.aac.dev.com> Subject: Re: Changed information for PR gnu/397 To: rgrimes@freefall.cdrom.com (Rodney W. Grimes) Date: Thu, 11 May 1995 21:58:45 -0700 (PDT) Cc: henrich@crh.cl.msu.edu, rgrimes@freefall.cdrom.com, freebsd-bugs@freefall.cdrom.com In-Reply-To: <199505120457.VAA00254@freefall.cdrom.com> from "Rodney W. Grimes" at May 11, 95 09:57:27 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 712 Sender: bugs-owner@FreeBSD.org Precedence: bulk > > Synopsis: man spews worthless information > > State-Changed-From-To: open-closed > State-Changed-By: rgrimes > State-Changed-When: Thu May 11 21:56:42 PDT 1995 > State-Changed-Why: > /home/ncvs/src/gnu/usr.bin/man/man/man.c,v <-- man.c > new revision: 1.12; previous revision: 1.11 > What do you folks think about what I just used for the reason for changing the status? Basically that is a cut and paste of the output from the cvs commit. I think this is what we should be doing instead of manually saying ``fixed in revision blah of blah''. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-bugs Thu May 11 22:28:04 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA00946 for bugs-outgoing; Thu, 11 May 1995 22:28:04 -0700 Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id WAA00929 for ; Thu, 11 May 1995 22:27:59 -0700 Message-Id: <199505120527.WAA00929@freefall.cdrom.com> Received: by crh.cl.msu.edu (1.38.193.4/16.2) id AA02046; Fri, 12 May 1995 01:27:55 -0400 Date: Fri, 12 May 1995 01:27:55 -0400 From: Charles Henrich Apparently-To: freebsd-bugs@FreeBSD.org Sender: bugs-owner@FreeBSD.org Precedence: bulk >From henrich Fri May 12 01:26:57 1995 remote from crh Subject: Re: Changed information for PR gnu/397 To: rgrimes@gndrsh.aac.dev.com (Rodney W. Grimes) Date: Fri, 12 May 1995 01:26:57 -0400 (EDT) In-Reply-To: <199505120458.VAA15555@gndrsh.aac.dev.com> from "Rodney W. Grimes" at May 11, 95 09:58:45 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 775 Sender: henrich > > State-Changed-Why: > > /home/ncvs/src/gnu/usr.bin/man/man/man.c,v <-- man.c > > new revision: 1.12; previous revision: 1.11 > > > > What do you folks think about what I just used for the reason for > changing the status? Basically that is a cut and paste of the > output from the cvs commit. I think this is what we should be > doing instead of manually saying ``fixed in revision blah of blah''. Works for me, although it may be construed as being a tad vague. I.e. in all cases does the above mean that the changes were made, or have been made previously, or ? What exactly (for boneheads like me) does that statement mean? -Crh Charles Henrich Michigan State University henrich@crh.cl.msu.edu http://rs560.msu.edu/~henrich/ From owner-freebsd-bugs Thu May 11 23:03:47 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id XAA07090 for bugs-outgoing; Thu, 11 May 1995 23:03:47 -0700 Received: from redwood.CS.Berkeley.EDU (redwood.CS.Berkeley.EDU [128.32.36.44]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id XAA07081 for ; Thu, 11 May 1995 23:03:46 -0700 Received: from redwood.CS.Berkeley.EDU (localhost.Berkeley.EDU [127.0.0.1]) by redwood.CS.Berkeley.EDU (8.6.11/8.6.9) with ESMTP id XAA13119; Thu, 11 May 1995 23:06:32 -0700 From: William Maddox Message-Id: <199505120606.XAA13119@redwood.CS.Berkeley.EDU> X-Mailer: exmh version 1.6 4/21/95 To: Tatu Ylonen cc: freebsd-bugs@freefall.cdrom.com, maddox@redwood.CS.Berkeley.EDU Subject: Re: i386/395: CRITICAL PROBLEM: spl functions implemented incorrectly In-reply-to: Your message of "Thu, 11 May 1995 16:40:02 PDT." <199505112340.QAA19464@freefall.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 11 May 1995 23:06:22 -0700 Sender: bugs-owner@FreeBSD.org Precedence: bulk You recently reported a bug in "spl.h" : > Spl functions (splbio, splclock, splhigh, splimp, splnet, > splsoftclock, splsofttty, splstatclock, spltty, spl0, splx) > are defined in /usr/src/sys/i386/include/spl.h as inline > functions that modify the ordinary variable cpl (extern > unsigned cpl in the same header). > > This means that the compiler has full knowledge about the > semantics, side-effects, and dependencies of these functions. > The compiler inlines these functions, and can mix (reorder) the > resulting code with other code in the function that calls the > spl function. ... >Fix: ... > i386/include/spl.h: > - Move the GENSPL macro and its uses, and spl0 and splx to > i386/386/sys_machdep.c. Edit the macro and functions to > make them normal non-static, non-inline functions. .... I think there is another potential problem lurking in spl.h, in the following: /* * ipending has to be volatile so that it is read every time it is accessed * in splx() and spl0(), but we don't want it to be read nonatomically when * it is changed. Pretending that ipending is a plain int happens to give * suitable atomic code for "ipending |= constant;". */ #define setdelayed() (*(unsigned *)&ipending |= loadandclear(&idelayed)) #define setsoftast() (*(unsigned *)&ipending |= SWI_AST_PENDING) #define setsoftclock() (*(unsigned *)&ipending |= SWI_CLOCK_PENDING) #define setsoftnet() (*(unsigned *)&ipending |= SWI_NET_PENDING) #define setsofttty() (*(unsigned *)&ipending |= SWI_TTY_PENDING) I assume that the remark above regarding "suitable atomic code" means that the bits are set in place in memory, using a single instruction. Just because GCC happens to do this today doesn't mean it will tomorrow. As the internal execution mechanisms of new-generation x86 processors become more heavily parallel and RISC-like, instruction sequences involving architecturally unnecessary register temporaries may turn out to be faster. I wouldn't bet on the stability of a compiler's choice of instructions in future releases, and I doubt that anyone is going to check this each time a new version of GCC is integrated into FreeBSD. I would suggest defining these functions as in-line assembly-language functions. In any case, this is the sort of thing that should be done in assembler, not C. --Bill From owner-freebsd-bugs Fri May 12 01:35:32 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id BAA17273 for bugs-outgoing; Fri, 12 May 1995 01:35:32 -0700 Received: from ghpc6.ihf.rwth-aachen.de (ghpc6.ihf.RWTH-Aachen.DE [134.130.90.6]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id BAA17265 for ; Fri, 12 May 1995 01:35:25 -0700 Received: (from thomas@localhost) by ghpc6.ihf.rwth-aachen.de (8.6.8/8.6.6) id KAA29933 for bugs@freebsd.org; Fri, 12 May 1995 10:35:21 +0200 From: Thomas Gellekum Message-Id: <199505120835.KAA29933@ghpc6.ihf.rwth-aachen.de> Subject: missing header files in libg++ To: bugs@FreeBSD.org Date: Fri, 12 May 1995 10:35:19 +0200 (MET DST) Organization: Institut f. Hochfrequenztechnik, RWTH Aachen 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: 269 Sender: bugs-owner@FreeBSD.org Precedence: bulk Moin moin, while porting the latest version of ACS I noticed that complex.h from libg++ was omitted in the FreeBSD src. This seems to be in libg++ for compatibility with AT&T's idea of the class. Could you please leave it in the distribution for 2.0.5? Thanks. tg From owner-freebsd-bugs Fri May 12 02:36:11 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id CAA20537 for bugs-outgoing; Fri, 12 May 1995 02:36:11 -0700 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 CAA20495 for ; Fri, 12 May 1995 02:35:39 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id TAA20816; Fri, 12 May 1995 19:32:58 +1000 Date: Fri, 12 May 1995 19:32:58 +1000 From: Bruce Evans Message-Id: <199505120932.TAA20816@godzilla.zeta.org.au> To: maddox@CS.Berkeley.EDU, ylo@fx7.cs.hut.fi Subject: Re: i386/395: CRITICAL PROBLEM: spl functions implemented incorrectly Cc: freebsd-bugs@freefall.cdrom.com, maddox@redwood.CS.Berkeley.EDU Sender: bugs-owner@FreeBSD.org Precedence: bulk >You recently reported a bug in "spl.h" : >> ... >> This means that the compiler has full knowledge about the >> semantics, side-effects, and dependencies of these functions. >> The compiler inlines these functions, and can mix (reorder) the >> resulting code with other code in the function that calls the >> spl function. No it can't. `static inline' functions have the same semantics as ordinary static functions. They aren't equivalent to macros. Reordering is severely limited by the C Standard. The ISO version section 5.1.2.3 says: "Accessing a volatile object, modifying an object, modifying a file, or calling a function that does any of these operations are all _side effects_. At ... _sequence points_, all side effects of previous evaluations shall be complete and no side effects of subsequent evaluations shall have taken place". Note that static [inline] functions are not special. spl*() all modify the (non-volatile) object `cpl', so the above applies to them. Making `cpl' volatile wouldn't affect this and would be wrong (it isn't volatile as far as C routines can tell since interrupt handlers preserve it). > ... >>Fix: > ... >> i386/include/spl.h: >> - Move the GENSPL macro and its uses, and spl0 and splx to >> i386/386/sys_machdep.c. Edit the macro and functions to >> make them normal non-static, non-inline functions. > .... This makes optimizations harder but doesn't stop them. The linker is allowed to do global optimizations. The standard also allows entire expressions, function calls and even accesses to volatile objects to be optimized away if it can be shown that the side effects are not needed. This is the usual "as if" rule explictly stated. The current implementation of spl*() only relies on the compiler not being able to show if the assignments to cpl are neeeded. If it can show that then it is broken :-) (they are needed for interrupt handling). It would take a global optimizer noticing that there are no Standard C signal handlers in the kernel to think it can prove that any global variable is not needed. When we have a global optimizer then this will be easy to fix by using `cpl' in a dummy signal handler. The average device driver probably depends on non-reordering in many other places, but probably has more bugs from not declaring enough variables as volatile. >I think there is another potential problem lurking in spl.h, in the following: > /* > * ipending has to be volatile so that it is read every time it is accessed > * in splx() and spl0(), but we don't want it to be read nonatomically when > * it is changed. Pretending that ipending is a plain int happens to give > * suitable atomic code for "ipending |= constant;". > */ > #define setdelayed() (*(unsigned *)&ipending |= loadandclear(&idelayed)) > #define setsoftast() (*(unsigned *)&ipending |= SWI_AST_PENDING) >... >I assume that the remark above regarding "suitable atomic code" means >that the bits are set in place in memory, using a single instruction. >Just because GCC happens to do this today doesn't mean it will tomorrow. Yes. I'm willing to examine the generated code. I would be more concerned about this if all the drivers were careful about it. >As the internal execution mechanisms of new-generation x86 processors become >more heavily parallel and RISC-like, instruction sequences involving >architecturally >unnecessary register temporaries may turn out to be faster. I wouldn't bet on It already has the same speed on a 486 (one cycle to load, 1 to OR, 1 to store), but it clobbers a register, so ORing directly into memory is the best possible on i386's and i486's. >the stability >of a compiler's choice of instructions in future releases, and I doubt that >anyone is >going to check this each time a new version of GCC is integrated into FreeBSD. I always read the diffs for i386.md. >I would suggest defining these functions as in-line assembly-language >functions. >In any case, this is the sort of thing that should be done in assembler, not C. I agree about this for setting `ipending', but not for spl*() on a uniprocessor. spl*() really can be written in C in this case. On multiprocessors many other things will break. The setting of `ipending' is modeled on the setting of `netisr' in : #define schednetisr(anisr) { netisr |= 1<<(anisr); setsoftnet(); } `netisr' is volatile, so this is guaranteed to go through a register and lose any bits that have been set by interrupt handlers. This may not be a problem in practice - it is safe iff schednetisr() is always done at ipl >= imp so that it can't be interrupted by net interrupt handlers. More care is required setting `ipending' since interrupts can occur, e.g., setsoftast() is potentially interruptable by setsofttty(). Bruce From owner-freebsd-bugs Fri May 12 03:47:35 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id DAA25012 for bugs-outgoing; Fri, 12 May 1995 03:47:35 -0700 Received: from isl.cf.ac.uk (isl-gate.elsy.cf.ac.uk [131.251.22.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id DAA25000 ; Fri, 12 May 1995 03:47:29 -0700 Received: (from paul@localhost) by isl.cf.ac.uk (8.6.9/8.6.9) id LAA05062; Fri, 12 May 1995 11:45:03 +0100 From: Paul Richards Message-Id: <199505121045.LAA05062@isl.cf.ac.uk> Subject: Re: Changed information for PR gnu/397 To: rgrimes@gndrsh.aac.dev.com (Rodney W. Grimes) Date: Fri, 12 May 1995 11:45:03 +0100 (BST) Cc: rgrimes@freefall.cdrom.com, henrich@crh.cl.msu.edu, freebsd-bugs@freefall.cdrom.com In-Reply-To: <199505120458.VAA15555@gndrsh.aac.dev.com> from "Rodney W. Grimes" at May 11, 95 09:58:45 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 987 Sender: bugs-owner@FreeBSD.org Precedence: bulk In reply to Rodney W. Grimes who said > > > > > Synopsis: man spews worthless information > > > > State-Changed-From-To: open-closed > > State-Changed-By: rgrimes > > State-Changed-When: Thu May 11 21:56:42 PDT 1995 > > State-Changed-Why: > > /home/ncvs/src/gnu/usr.bin/man/man/man.c,v <-- man.c > > new revision: 1.12; previous revision: 1.11 > > > > What do you folks think about what I just used for the reason for > changing the status? Basically that is a cut and paste of the > output from the cvs commit. I think this is what we should be > doing instead of manually saying ``fixed in revision blah of blah''. Ideally we should automate the thing. Add a flag to cvs, something like cvs ci -pr 95 That closed the PR witht the commit message. Pretty easily done I reckon. Maybe Nate and I can discuss it. -- Paul Richards, FreeBSD core team member. Internet: paul@FreeBSD.org, http://www.isl.cf.ac.uk/ Phone: +44 1222 874000 x6646 (work), +44 1222 457651 (home) From owner-freebsd-bugs Fri May 12 04:10:17 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id EAA26551 for bugs-outgoing; Fri, 12 May 1995 04:10:17 -0700 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 EAA26537 ; Fri, 12 May 1995 04:09:49 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id VAA23467; Fri, 12 May 1995 21:07:45 +1000 Date: Fri, 12 May 1995 21:07:45 +1000 From: Bruce Evans Message-Id: <199505121107.VAA23467@godzilla.zeta.org.au> To: rgrimes@freefall.cdrom.com, rgrimes@gndrsh.aac.dev.com Subject: Re: Changed information for PR gnu/397 Cc: freebsd-bugs@freefall.cdrom.com, henrich@crh.cl.msu.edu Sender: bugs-owner@FreeBSD.org Precedence: bulk >> State-Changed-Why: >> /home/ncvs/src/gnu/usr.bin/man/man/man.c,v <-- man.c >> new revision: 1.12; previous revision: 1.11 >> >What do you folks think about what I just used for the reason for >changing the status? Basically that is a cut and paste of the >output from the cvs commit. I think this is what we should be >doing instead of manually saying ``fixed in revision blah of blah''. Doesn't revision 1.12 always follow 1.11? "Fixed in ..." is more readable. Most users will see at most the final source file and won't want to know where it was in ncvs. The won't be able to see the Id in too many cases. man.c doesn't have one, at least in revision 1.11 :-). Bruce From owner-freebsd-bugs Fri May 12 04:46:16 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id EAA27751 for bugs-outgoing; Fri, 12 May 1995 04:46:16 -0700 Received: from ki1.chemie.fu-berlin.de (ki1.Chemie.FU-Berlin.DE [160.45.24.21]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id EAA27745 for ; Fri, 12 May 1995 04:46:13 -0700 Received: by ki1.chemie.fu-berlin.de (Smail3.1.28.1) from sirius.physik.fu-berlin.de (130.133.3.140) with smtp id ; Fri, 12 May 95 13:45 MEST Received: by sirius.physik.fu-berlin.de; id AA25665; Fri, 12 May 1995 13:45:58 +0200 From: Thomas Graichen Message-Id: <9505121145.AA25665@sirius.physik.fu-berlin.de> Subject: cat /proc/0/regs crashes FreeBSD To: freebsd-bugs@FreeBSD.org Date: Fri, 12 May 1995 13:45:56 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 646 Sender: bugs-owner@FreeBSD.org Precedence: bulk hello you may definitely crash FreeBSD (2.0 and 950412-SNAP) using cat /proc/0/regs maybe in other ways too via the proc-fs t _______________________________________________________||_____________________ __|| Perfection is reached, not when there is no __|| thomas graichen longer anything to add, but when there __|| freie universitaet berlin is no longer anything to take away __|| fachbereich physik __|| - Antoine de Saint-Exupery - __|| ___________________________||____email: graichen@omega.physik.fu-berlin.de____ From owner-freebsd-bugs Fri May 12 08:00:25 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA06303 for bugs-outgoing; Fri, 12 May 1995 08:00:25 -0700 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 IAA06283 for ; Fri, 12 May 1995 08:00:18 -0700 Received: from shadows.cs.hut.fi by hutcs.cs.hut.fi with SMTP id AA22175 (5.65c8/HUTCS-S 1.4 for ); Fri, 12 May 1995 17:59:23 +0300 Received: (ylo@localhost) by shadows.cs.hut.fi (8.6.10/8.6.10) id RAA03674; Fri, 12 May 1995 17:59:24 +0300 Date: Fri, 12 May 1995 17:59:24 +0300 Message-Id: <199505121459.RAA03674@shadows.cs.hut.fi> From: Tatu Ylonen To: bde@zeta.org.au Cc: maddox@CS.Berkeley.EDU, freebsd-bugs@freefall.cdrom.com, maddox@redwood.CS.Berkeley.EDU, shadows-tech@cs.hut.fi In-Reply-To: <199505120932.TAA20816@godzilla.zeta.org.au> (bde@zeta.org.au) Subject: Re: i386/395: CRITICAL PROBLEM: spl functions implemented incorrectly Organization: Helsinki University of Technology, Finland Sender: bugs-owner@FreeBSD.org Precedence: bulk > No it can't. `static inline' functions have the same semantics as > ordinary static functions. They aren't equivalent to macros. Reordering > is severely limited by the C Standard. The ISO version section 5.1.2.3 > says: > > "Accessing a volatile object, modifying an object, modifying a file, or > calling a function that does any of these operations are all _side effects_. > At ... _sequence points_, all side effects of previous evaluations shall > be complete and no side effects of subsequent evaluations shall have > taken place". > > Note that static [inline] functions are not special. spl*() all modify > the (non-volatile) object `cpl', so the above applies to them. Making > `cpl' volatile wouldn't affect this and would be wrong (it isn't volatile > as far as C routines can tell since interrupt handlers preserve it). You don't say anything about what can be assumed about values of non-volatile expressions. I checked with gcc-2.6.3 (with patches for i386 bugs - I get same results with plain 2.6.3). The following code: extern int cpl; extern int value; static __inline int spl1() { int old = cpl; cpl |= 1; return old; } static __inline void splx(int x) { cpl = x; } void foo() { int x, y; value *= 2; x = spl1(); value *= 3; splx(x); } When compiled with "gcc -O -S koe.c" this gives: .file "koe.c" gcc2_compiled.: ___gnu_compiled_c: .text .align 2 .globl _foo .type _foo,@function _foo: pushl %ebp movl %esp,%ebp movl _value,%eax leal 0(,%eax,2),%edx movl %edx,_value movl _cpl,%ecx orb $1,_cpl leal (%edx,%eax,4),%eax <-- note: "value" kept in register across movl %eax,_value call to spl1. movl %ecx,_cpl leave ret Lfe1: .size _foo,Lfe1-_foo Thus, the spl code did not do what it was supposed to do: we cannot make assumptions about values computed before entering the critical section being still valid in the critical section. There definitely is a serious problem here. I cannot be absolutely sure whether it is in the compiler or in the kernel as I do not have the standard. In my opinion the compiler is doing only reasonable and expectable things here. It is keeping the non-volatile value "value" in a register across a call it knows will not modify "value". This sounds very reasonable. Tatu Ylonen From owner-freebsd-bugs Fri May 12 08:39:12 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA08848 for bugs-outgoing; Fri, 12 May 1995 08:39:12 -0700 Received: from silver.sdsmt.edu (root@silver.sdsmt.edu [151.159.1.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id IAA08842 for ; Fri, 12 May 1995 08:39:10 -0700 Received: from msmail.sdsmt.edu (msmail.sdsmt.edu [151.159.1.43]) by silver.sdsmt.edu (8.6.12/8.6.12) with SMTP id JAA13544 for ; Fri, 12 May 1995 09:39:07 -0600 Received: by msmail.sdsmt.edu with Microsoft Mail id <2FB3811C@msmail.sdsmt.edu>; Fri, 12 May 95 09:39:08 MDT From: "Unser, Danny" To: "'FreeBSD - Bugs'" Subject: adduser & 950412-SNAP Date: Fri, 12 May 95 09:37:00 MDT Message-ID: <2FB3811C@msmail.sdsmt.edu> Encoding: 6 TEXT X-Mailer: Microsoft Mail V3.0 Sender: bugs-owner@FreeBSD.org Precedence: bulk Why isn't I cannot add anymore users after the initial install? When I try to add a user, the program takes me all the way through the questions and asks for confirmation. After that it just hangs. Also, why can't I startup the /stand/scripts/setup.sh script? From owner-freebsd-bugs Fri May 12 08:40:00 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA08877 for bugs-outgoing; Fri, 12 May 1995 08:40:00 -0700 Received: from silver.sdsmt.edu (root@silver.sdsmt.edu [151.159.1.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id IAA08871 for ; Fri, 12 May 1995 08:39:59 -0700 Received: from msmail.sdsmt.edu (msmail.sdsmt.edu [151.159.1.43]) by silver.sdsmt.edu (8.6.12/8.6.12) with SMTP id JAA31772 for ; Fri, 12 May 1995 09:39:57 -0600 Received: by msmail.sdsmt.edu with Microsoft Mail id <2FB3814D@msmail.sdsmt.edu>; Fri, 12 May 95 09:39:57 MDT From: "Unser, Danny" To: "'FreeBSD - Bugs'" Subject: 2.0-950412-SNAP Date: Fri, 12 May 95 09:39:00 MDT Message-ID: <2FB3814D@msmail.sdsmt.edu> Encoding: 6 TEXT X-Mailer: Microsoft Mail V3.0 Sender: bugs-owner@FreeBSD.org Precedence: bulk Major problem after re-boot. All processes seem to startup fine and well until after starting local daemons. The date is displayed after this and then the system hangs. If I do a good hard reboot sometimes it'll come up. From owner-freebsd-bugs Fri May 12 09:20:41 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA10890 for bugs-outgoing; Fri, 12 May 1995 09:20:41 -0700 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 JAA10854 for ; Fri, 12 May 1995 09:19:57 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id CAA01072; Sat, 13 May 1995 02:19:01 +1000 Date: Sat, 13 May 1995 02:19:01 +1000 From: Bruce Evans Message-Id: <199505121619.CAA01072@godzilla.zeta.org.au> To: bde@zeta.org.au, ylo@cs.hut.fi Subject: Re: i386/395: CRITICAL PROBLEM: spl functions implemented incorrectly Cc: freebsd-bugs@freefall.cdrom.com, maddox@CS.Berkeley.EDU, maddox@redwood.CS.Berkeley.EDU, shadows-tech@cs.hut.fi Sender: bugs-owner@FreeBSD.org Precedence: bulk >> "Accessing a volatile object, modifying an object, modifying a file, or >> calling a function that does any of these operations are all _side effects_. >> At ... _sequence points_, all side effects of previous evaluations shall >> be complete and no side effects of subsequent evaluations shall have >> taken place". >You don't say anything about what can be assumed about values of non-volatile >expressions. They can be assumed to be non-volatile :-). >I checked with gcc-2.6.3 (with patches for i386 bugs - I get same >results with plain 2.6.3). The following code: >extern int cpl; >extern int value; >static __inline int spl1() >{ > int old = cpl; > cpl |= 1; > return old; >} >static __inline void splx(int x) >{ > cpl = x; >} >void foo() >{ > int x, y; > value *= 2; > x = spl1(); > value *= 3; > splx(x); >} >When compiled with "gcc -O -S koe.c" this gives: > .file "koe.c" >gcc2_compiled.: >___gnu_compiled_c: >.text > .align 2 >.globl _foo > .type _foo,@function >_foo: > pushl %ebp > movl %esp,%ebp > movl _value,%eax > leal 0(,%eax,2),%edx > movl %edx,_value > movl _cpl,%ecx > orb $1,_cpl > leal (%edx,%eax,4),%eax <-- note: "value" kept in register across > movl %eax,_value call to spl1. > movl %ecx,_cpl > leave > ret >Lfe1: > .size _foo,Lfe1-_foo Note that cpl is stored to in the desired order. >Thus, the spl code did not do what it was supposed to do: we cannot >make assumptions about values computed before entering the critical >section being still valid in the critical section. spl isn't supposed to turn non-volatile variables into volatile ones. It just happens to have that effect if you hide it sufficiently from the compiler. For gcc-2.3.3 on the i386, any non-static function is hidden sufficiently. >There definitely is a serious problem here. I cannot be absolutely >sure whether it is in the compiler or in the kernel as I do not have >the standard. In my opinion the compiler is doing only reasonable and The problem is actually that many variables are declared as /*nonvolatile*/ when they are actually volatile. Almost any device driver contains dozens of examples. Consider a buffer that is filled by interrupt handlers, e.g, the clists in struct tty. The pointers for the buffer and the buffer contents are all volatile but none are declared volatile. A sufficiently good optimizer might cache some of the values across function calls. Non-static spl()s just require a better optimizer for there to be a problem. Note that the locking feature of spl*() isn't important here. Any call to an external function together with a call to a static inline spl*() would work just as well. Any write through a pointer together with a static inline spl*() would work just as well... On second thoughts, the optimizer doesn't need to be much better for an external function to not help. Consider the case where the critical variables and all pointers to them are static. Then the external function can't legitimately modify the values. I don't know of a good way to avoid this problem. Declaring all critical variables as volatile would be slow. It would be nice if the variables were volatile inside the critical region and volatile outside it, but C doesn't provide this feature directly. You could probably get it by declaring the variables as volatile and accessing them as *(/* nonvolatile */ foo_t *)&foovar inside the critical region but I don't want that. I seem to remember some bug reports for gcc under Linux related to this problem. I think it was expected that __asm("" : : : "memory"); would flush all cached variables from registers. It should do this because "memory" in the clobber list says that arbitrary memory might be written to. I think it didn't work as expected. If/when it works, it may be the best way to handle the problem. Bruce From owner-freebsd-bugs Fri May 12 09:29:28 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA11296 for bugs-outgoing; Fri, 12 May 1995 09:29:28 -0700 Received: from silver.sdsmt.edu (root@silver.sdsmt.edu [151.159.1.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id JAA11288 for ; Fri, 12 May 1995 09:29:26 -0700 Received: from msmail.sdsmt.edu (msmail.sdsmt.edu [151.159.1.43]) by silver.sdsmt.edu (8.6.12/8.6.12) with SMTP id KAA14089 for ; Fri, 12 May 1995 10:29:24 -0600 Received: by msmail.sdsmt.edu with Microsoft Mail id <2FB38CE4@msmail.sdsmt.edu>; Fri, 12 May 95 10:29:24 MDT From: "Unser, Danny" To: "'FreeBSD - Bugs'" Subject: FW: 2.0-950412-SNAP Date: Fri, 12 May 95 10:26:00 MDT Message-ID: <2FB38CE4@msmail.sdsmt.edu> Encoding: 34 TEXT X-Mailer: Microsoft Mail V3.0 Sender: bugs-owner@FreeBSD.org Precedence: bulk Okay, this is what it says after I reboot: syncing disks... done Fatal trap 12: page fault while in kernel mode fault virtual address = 0xefdd1cd8 fault core = supervisor read, page not present instruction pointer = 0x8:0xf012328a code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 461 (reboot) interrupt mask = panic: page fault Automatic reboot in 15 seconds - press a key on the console to abort Any help would surely be appreciated. Would the tcpd program from tcp_wrappers have anything to do with this? ---------- From: Danny K. Unser Sent: Friday, May 12, 1995 9:39AM To: 'FreeBSD - Bugs' Subject: 2.0-950412-SNAP Major problem after re-boot. All processes seem to startup fine and well until after starting local daemons. The date is displayed after this and then the system hangs. If I do a good hard reboot sometimes it'll come up. From owner-freebsd-bugs Fri May 12 09:34:13 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA11551 for bugs-outgoing; Fri, 12 May 1995 09:34:13 -0700 Received: from hutcs.cs.hut.fi (root@hutcs.cs.hut.fi [130.233.192.2]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id JAA11543 for ; Fri, 12 May 1995 09:34:10 -0700 Received: from shadows.cs.hut.fi by hutcs.cs.hut.fi with SMTP id AA23364 (5.65c8/HUTCS-S 1.4 for ); Fri, 12 May 1995 19:21:12 +0300 From: Heikki Suonsivu Received: (hsu@localhost) by shadows.cs.hut.fi (8.6.10/8.6.10) id TAA03878; Fri, 12 May 1995 19:21:12 +0300 Date: Fri, 12 May 1995 19:21:12 +0300 Message-Id: <199505121621.TAA03878@shadows.cs.hut.fi> To: freebsd-bugs@freefall.cdrom.com In-Reply-To: Tatu Ylonen's message of 12 May 1995 02:52:01 +0300 Subject: i386/395: CRITICAL PROBLEM: spl functions implemented incorrectly Organization: Helsinki University of Technology, Otaniemi, Finland Sender: bugs-owner@FreeBSD.org Precedence: bulk >Description: Spl functions (splbio, splclock, splhigh, splimp, splnet, splsoftclock, splsofttty, splstatclock, spltty, spl0, splx) are defined in /usr/src/sys/i386/include/spl.h as inline functions that modify the ordinary variable cpl (extern unsigned cpl in the same header). ... >How-To-Repeat: The real effects of this problem are not predictable or deterministic. They may depend on compiler version or optimization levels. General unreliability, mysterious problems, and random panics are all likely. I started to At least two of bugs reported by me were just like this s = splsomething(); if (foo) { ... something, which does verifyably not modify foo ... if (foo->bar) /* foo is NULL or garbage here, generating kernel page fault. */ } splx(s); ie. variable getting modified while it is assumed to keep its value. I think one of these reports was the FreeBSD 1.1.5.1 "print nfs server foo is alive again through NULL pointer", other was something under 2.*-current, can't remember which one (there are probably several open ones for me in GNATS, with stack traces and later ones with some kgdb wanderarounds). -- 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 May 12 10:56:39 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA15946 for bugs-outgoing; Fri, 12 May 1995 10:56:39 -0700 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 KAA15939 ; Fri, 12 May 1995 10:56:35 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id KAA01181; Fri, 12 May 1995 10:52:31 -0700 From: "Rodney W. Grimes" Message-Id: <199505121752.KAA01181@gndrsh.aac.dev.com> Subject: Re: Changed information for PR gnu/397 To: bde@zeta.org.au (Bruce Evans) Date: Fri, 12 May 1995 10:52:31 -0700 (PDT) Cc: rgrimes@freefall.cdrom.com, freebsd-bugs@freefall.cdrom.com, henrich@crh.cl.msu.edu In-Reply-To: <199505121107.VAA23467@godzilla.zeta.org.au> from "Bruce Evans" at May 12, 95 09:07:45 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1733 Sender: bugs-owner@FreeBSD.org Precedence: bulk > > >> State-Changed-Why: > >> /home/ncvs/src/gnu/usr.bin/man/man/man.c,v <-- man.c > >> new revision: 1.12; previous revision: 1.11 > >> > > >What do you folks think about what I just used for the reason for > >changing the status? Basically that is a cut and paste of the > >output from the cvs commit. I think this is what we should be > >doing instead of manually saying ``fixed in revision blah of blah''. > > Doesn't revision 1.12 always follow 1.11? "Fixed in ..." is more > readable. No, revision 1.12 does not always follow 1.11, if I would have been working in a release branch this could have been version 1.11.3.1 (First patch of 3rd branch of this file). > Most users will see at most the final source file and > won't want to know where it was in ncvs. There is a direct 1:1 mapping from this message to source tree location. Simply drop /home/ncvs. I think this is a minor nit that we can live with. > The won't be able to see > the Id in too many cases. man.c doesn't have one, at least in > revision 1.11 :-). I am aware of that, I don't want to go $Id$ the whole tree right now or in the near future. I would like to see the $FreeBSD$ thing reinacted (possible as a standard rcs add on option for site specific keywords that can be configed via a file instead of source patches, as it seems XFree, NetBSD and a few other folks do this). It was sad that it was disabled, but I was not able to stop this when it happened as I was on the road. It was disabled because of one small place that cvs did not get patched to handle it (cvs diff). -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-bugs Fri May 12 10:57:45 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA16054 for bugs-outgoing; Fri, 12 May 1995 10:57:45 -0700 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 KAA16044 for ; Fri, 12 May 1995 10:57:42 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id KAA01208; Fri, 12 May 1995 10:55:13 -0700 From: "Rodney W. Grimes" Message-Id: <199505121755.KAA01208@gndrsh.aac.dev.com> Subject: Re: cat /proc/0/regs crashes FreeBSD To: graichen@sirius.physik.fu-berlin.de (Thomas Graichen) Date: Fri, 12 May 1995 10:55:13 -0700 (PDT) Cc: freebsd-bugs@FreeBSD.org In-Reply-To: <9505121145.AA25665@sirius.physik.fu-berlin.de> from "Thomas Graichen" at May 12, 95 01:45:56 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 572 Sender: bugs-owner@FreeBSD.org Precedence: bulk > > hello > > you may definitely crash FreeBSD (2.0 and 950412-SNAP) using > > cat /proc/0/regs > > maybe in other ways too via the proc-fs This has been fixed: hookturn# cat /proc/0/regs àT`ð ñXÒ,ð'hookturn# hookturn# hookturn# uname -a FreeBSD hookturn.aac.dev.com 2.0-BUILT-19950511 FreeBSD 2.0-BUILT-19950511 #0: Thu May 11 22:01:20 PDT 1995 root@gndrsh.aac.dev.com:/usr/src/sys/compile/GNDRSH i386 -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-bugs Fri May 12 12:25:57 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA19671 for bugs-outgoing; Fri, 12 May 1995 12:25:57 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id MAA19665 for ; Fri, 12 May 1995 12:25:55 -0700 Received: from corbin.Root.COM (corbin.Root.COM [198.145.90.18]) by Root.COM (8.6.8/8.6.5) with ESMTP id MAA09961; Fri, 12 May 1995 12:28:55 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.11/8.6.5) with SMTP id MAA00168; Fri, 12 May 1995 12:25:55 -0700 Message-Id: <199505121925.MAA00168@corbin.Root.COM> To: Thomas Graichen cc: freebsd-bugs@FreeBSD.org Subject: Re: cat /proc/0/regs crashes FreeBSD In-reply-to: Your message of "Fri, 12 May 95 13:45:56 +0200." <9505121145.AA25665@sirius.physik.fu-berlin.de> From: David Greenman Reply-To: davidg@Root.COM Date: Fri, 12 May 1995 12:25:49 -0700 Sender: bugs-owner@FreeBSD.org Precedence: bulk >you may definitely crash FreeBSD (2.0 and 950412-SNAP) using > > cat /proc/0/regs > >maybe in other ways too via the proc-fs RCS file: /home/ncvs/src/sys/kern/init_main.c,v ... revision 1.23 date: 1995/05/04 08:21:24; author: davidg; state: Exp; lines: +9 -1 Kludged around a problem with "cat /proc/0/regs" causing a panic by initializing proc0's frame base, too, using cpu_set_init_frame(). It's a kludge because that macro is intended to be used only for init, but does what we want nonetheless. -DG From owner-freebsd-bugs Fri May 12 12:34:42 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA19823 for bugs-outgoing; Fri, 12 May 1995 12:34:42 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id MAA19817 for ; Fri, 12 May 1995 12:34:37 -0700 Received: by sequent.kiae.su id AA08530 (5.65.kiae-2 ); Fri, 12 May 1995 23:30:55 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Fri, 12 May 95 23:30:53 +0400 Received: (from ache@localhost) by astral.msk.su (8.6.8/8.6.6) id XAA02154; Fri, 12 May 1995 23:05:36 +0400 To: freebsd-bugs@freefall.cdrom.com, widmer@cisco.com References: <199505112110.OAA13821@freefall.cdrom.com> In-Reply-To: <199505112110.OAA13821@freefall.cdrom.com>; from "widmer@cisco.com" at Thu, 11 May 1995 14:10:02 -0700 Message-Id: Organization: Olahm Ha-Yetzirah Date: Fri, 12 May 1995 23:05:35 +0400 X-Mailer: Mail/@ [v2.34 FreeBSD] From: "Andrey A. Chernov, Black Mage" X-Class: Fast Subject: Re: i386/394: ip multicast in ep driver Lines: 19 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 688 Sender: bugs-owner@FreeBSD.org Precedence: bulk In message <199505112110.OAA13821@freefall.cdrom.com> widmer@cisco.com writes: > + if (error == ENETRESET) { > + /* > + * Multicast list has changed; set the > + * hardware filter accordingly > + */ > + epreset(ifp->if_unit); ^^^^^^^^^^^^^^^^^^^^^^ Your patch wrong here. See if_ed.c ed_setrcr() routine as valid example. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-bugs Fri May 12 12:56:48 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA20044 for bugs-outgoing; Fri, 12 May 1995 12:56:48 -0700 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 MAA20035 for ; Fri, 12 May 1995 12:56:38 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id FAA02157; Sat, 13 May 1995 05:55:56 +1000 Date: Sat, 13 May 1995 05:55:56 +1000 From: Bruce Evans Message-Id: <199505121955.FAA02157@godzilla.zeta.org.au> To: freebsd-bugs@freefall.cdrom.com, hsu@cs.hut.fi Subject: Re: i386/395: CRITICAL PROBLEM: spl functions implemented incorrectly Sender: bugs-owner@FreeBSD.org Precedence: bulk >At least two of bugs reported by me were just like this >s = splsomething(); >if (foo) { > ... something, which does verifyably not modify foo ... > if (foo->bar) /* foo is NULL or garbage here, generating kernel > page fault. */ >} >splx(s); >ie. variable getting modified while it is assumed to keep its value. I >think one of these reports was the FreeBSD 1.1.5.1 "print nfs server foo is >alive again through NULL pointer", other was something under 2.*-current, >can't remember which one (there are probably several open ones for me in >GNATS, with stack traces and later ones with some kgdb wanderarounds). There seems to be only one relevant one: >>Number: 378 >>Category: kern >>Synopsis: (apparently) bounce buffer code gets used on 32bit bus >... >Fatal trap 12: page fault while in kernel mode >fault virtual address = 0xa0 >fault code = supervisor read, page not present >instruction pointer >... >panic: vm_bounce_page_free: invalid bounce buffer >... >#12 0xf01147c3 in panic (...) >#13 0xf01ba964 in vm_bounce_page_free (...) >#14 0xf01baf00 in vm_bounce_free (...) >#15 0xf0126ee3 in biodone (...) >#16 0xf0185184 in scsi_done (...) >#17 0xf01bdedb in bt_done (...) >... >Reading in symbols for ../../i386/i386/vm_machdep.c...done. >#13 0xf01ba964 in vm_bounce_page_free (pa=0x00fd8000, count=1) (../../i386/i386/vm_machdep.c line 169) >(kgdb) list >164 if( pa == bouncepa[index]) >165 break; >166 } >167 >168 if( index == bouncepages) >169 panic("vm_bounce_page_free: invalid bounce buffer"); >170 >171 allocindex = index / BITS_IN_UNSIGNED; >172 bit = index % BITS_IN_UNSIGNED; >173 >(kgdb) print index >$18 = 0 >(kgdb) print bouncepages >$19 = 128 Everything seems reasonable except this. gdb says that index is nowhere near bouncepages. >... >(kgdb) print mynouncepa >No symbol "mynouncepa" in current context. >(kgdb) print mybouncepa >$21 = 0x00fd8000 >(kgdb) print *mybouncepa >Cannot read memory: address 0xfd8000 out of bounds. >(kgdb) up Oops. It would help to know if the buffer was found at index 0. > bounce buffer code shouldn't be called in this machine, >doesn't it say "enabling bounce buffer code" in boot on those which >need it? The bt driver always sets SDEV_BOUNCE :-(. Bruce From owner-freebsd-bugs Fri May 12 17:30:02 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id RAA15130 for bugs-outgoing; Fri, 12 May 1995 17:30:02 -0700 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id RAA15123 ; Fri, 12 May 1995 17:30:02 -0700 Date: Fri, 12 May 1995 17:30:02 -0700 Message-Id: <199505130030.RAA15123@freefall.cdrom.com> From: henrich@crh.cl.msu.edu Reply-To: henrich@crh.cl.msu.edu To: freebsd-bugs Subject: bin/398: VI broken? In-Reply-To: Your message of Fri, 12 May 1995 20:24:08 -0400 <199505130024.UAA21393@bsdprd1.ais.msu.edu> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 398 >Category: bin >Synopsis: VI doesnt do the correct thing >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 May 12 17:30:01 1995 >Originator: Charles Henrich >Organization: Michigan State University >Release: FreeBSD 2.1.0-Development i386 >Environment: remote xterm (vt102 mode) rloging into a freebsd box, with the term type set to vt100-am or vt100 >Description: When editing the following text (from man.c) if you place your cursor on the blank line between the int status and status =, then use the VI (o)pen line command, the status = line correctly drops one line, but the users cursor is then placed on the same line as the status =. CTRL-L refreshes to the correct location. Possibly a termcap bug? char ** add_dir_to_mpath_list (mp, p) char **mp; char *p; { int status; status = is_directory (p); if (status < 0) { fprintf (stderr, "Warning: couldn't stat file %s!\n", p); } else if (status == 0) { fprintf (stderr, "Warning: %s isn't a directory!\n", p); } else if (status == 1) { if (debug) fprintf (stderr, "adding %s to manpathlist\n", p); *mp++ = strdup (p); } return mp; } >How-To-Repeat: >Fix: >Audit-Trail: >Unformatted: From owner-freebsd-bugs Fri May 12 18:31:55 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA16359 for bugs-outgoing; Fri, 12 May 1995 18:31:55 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id SAA16346 for ; Fri, 12 May 1995 18:31:53 -0700 Received: by sequent.kiae.su id AA00863 (5.65.kiae-2 ); Sat, 13 May 1995 05:30:33 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Sat, 13 May 95 05:30:32 +0400 Received: (from ache@localhost) by astral.msk.su (8.6.8/8.6.6) id FAA00143; Sat, 13 May 1995 05:28:06 +0400 To: freebsd-bugs@freefall.cdrom.com, henrich@crh.cl.msu.edu References: <199505130030.RAA15123@freefall.cdrom.com> In-Reply-To: <199505130030.RAA15123@freefall.cdrom.com>; from "henrich@crh.cl.msu.edu" at Fri, 12 May 1995 17:30:02 -0700 Message-Id: Organization: Olahm Ha-Yetzirah Date: Sat, 13 May 1995 05:28:05 +0400 (MSD) X-Mailer: Mail/@ [v2.35 FreeBSD] From: "Andrey A. Chernov, Black Mage" X-Class: Fast Subject: Re: bin/398: VI broken? Lines: 25 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1183 Sender: bugs-owner@FreeBSD.org Precedence: bulk In message <199505130030.RAA15123@freefall.cdrom.com> henrich@crh.cl.msu.edu writes: > remote xterm (vt102 mode) rloging into a freebsd box, with the term > type set to vt100-am or vt100 > When editing the following text (from man.c) if you place your cursor > on the blank line between the int status and status =, then use the VI > (o)pen line command, the status = line correctly drops one line, but > the users cursor is then placed on the same line as the status =. > CTRL-L refreshes to the correct location. Possibly a termcap bug? I just try it, not with xterm but with true VT100 and MSDOS VT100 emulator and not see this bug (vi just simple redraw lower half of screen after 'o' command). What system/termcap versions your have? If they are < -current, please, update to -current. If bug still present, send me output of script(1) command. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-bugs Fri May 12 19:46:46 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id TAA21526 for bugs-outgoing; Fri, 12 May 1995 19:46:46 -0700 Received: from mpp.com (dialup-4-55.gw.umn.edu [128.101.96.55]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id TAA21498 for ; Fri, 12 May 1995 19:46:34 -0700 Received: (from mpp@localhost) by mpp.com (8.6.11/8.6.9) id VAA00225 for bugs@freebsd.org; Fri, 12 May 1995 21:45:44 -0500 From: Mike Pritchard Message-Id: <199505130245.VAA00225@mpp.com> Subject: -current kernel panics in rtfree To: bugs@FreeBSD.org Date: Fri, 12 May 1995 21:45:44 -0500 (CDT) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2308 Sender: bugs-owner@FreeBSD.org Precedence: bulk I don't have time to examine the crash dump I've got now, but I've seen a couple of crashes with a -current kernel from about 2 hours ago. The chain of events seems to be: 1) I make a slip connection (delete some routes, start the connection, setup my routing for my dynamic IP number from my provider), 2) do some stuff over the slip link (get mail, etc) 3) terminate the slip link (delete some of the previous routes I just setup, and reset them to route the way they were originally) The default route is involved above, which makes me suspect some code that went in recently in this area. I've never seen a problem with a kernel from a couple of weeks ago. Shortly after terminating the slip link the machine panics with: panic: rtfree During one of the panics I also saw: May 12 21:23:22 mpp /kernel.mpp: rtfree: 0xf06b2d00 not freed (neg refs) shortly before the actual panic. The stack trace from both crashes shows that we are in the softclock() routine processing the callout table. Here is the stack from the dump I have right now: Reading symbol data from /usr/var/crash/kernel.0... (no debugging symbols found)...done. IdlePTD 202000 panic: rtfree current pcb at 1d63b0 (kgdb) bt #0 0xf0199394 in boot () #1 0xf0117dc5 in panic () #2 0xf010125d in db_panic () #3 0xf0101146 in db_command (-266589452, -266589868, -267382174) #4 0xf01012c5 in db_command_loop () #5 0xf0103c48 in db_trap () #6 0xf01965ea in kdb_trap (3, 0, -272630676) #7 0xf019d9e4 in trap () #8 0xf0196e91 in exception:calltrap () #9 0xf0117dbf in panic () #10 0xf013f39f in rtfree (-261400576) #11 0xf013f434 in rtfree (-261365248) #12 0xf01441f5 in in_pcbdetach () #13 0xf014e16e in tcp_close () #14 0xf014e49e in tcp_timers (-261365504, 3) #15 0xf014ea35 in tcp_usrreq (-261372416, 19, 0, 3, 0) #16 0xf014e3cd in tcp_slowtimo () #17 0xf011fb0f in pfslowtimo (0) #18 0xf010bbf0 in softclock () #19 0xf01981e7 in exception:doreti_swi () #20 0xf012d9e0 in chmod () #21 0xf019e3c5 in syscall () (kgdb) quit Another disturbing thing that happened during the above crash was that my clock was also reset to be exactly 4 months in the past from May 12 to Jan 12, the time was correct. -- Mike Pritchard pritc003@maroon.tc.umn.edu "Go that way. Really fast. If something gets in your way, turn" From owner-freebsd-bugs Fri May 12 23:33:16 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id XAA03552 for bugs-outgoing; Fri, 12 May 1995 23:33:16 -0700 Received: from ki1.chemie.fu-berlin.de (ki1.Chemie.FU-Berlin.DE [160.45.24.21]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id XAA03546 for ; Fri, 12 May 1995 23:33:14 -0700 Received: by ki1.chemie.fu-berlin.de (Smail3.1.28.1) from sirius.physik.fu-berlin.de (130.133.3.140) with smtp id ; Sat, 13 May 95 08:33 MEST Received: by sirius.physik.fu-berlin.de; id AA04822; Sat, 13 May 1995 08:33:11 +0200 From: Thomas Graichen Message-Id: <9505130633.AA04822@sirius.physik.fu-berlin.de> Subject: xdm crashes To: freebsd-bugs@FreeBSD.org Date: Sat, 13 May 1995 08:33:11 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3607 Sender: bugs-owner@FreeBSD.org Precedence: bulk hallo now that i've had so much luck with my last reported bug (cat /proc/0/regs -> which was fixed before i send it) another try - sometimes get get problems with xdm - here is what i've mailed to jordan some weeks ago: * the system sometime crashes when i login via xdm - this only happens via xdm not via console and not if i login as root and su - to me - then i login in via one of the last wo ways and logout - the following xdm login will definitely NOT crash (i think because my homedir is then mounted via amd) - it will also not crash if root log's in (homedir local) - and it crashes only sometimes - no special rule when - here's what messages says: Apr 24 19:43:36 julia /vmunix: Fatal trap 12: page fault while in kernel mode Apr 24 19:43:38 julia /vmunix: fault virtual address = 0x38 Apr 24 19:43:38 julia /vmunix: fault code = supervisor read, page not present Apr 24 19:43:38 julia /vmunix: instruction pointer = 0x8:0xf0127086 Apr 24 19:43:38 julia /vmunix: code segment = base 0x0, limit 0xffff f, type 0x1b Apr 24 19:43:38 julia /vmunix: = DPL 0, pres 1, def32 1, gran 1 Apr 24 19:43:38 julia /vmunix: processor eflags = interrupt enabled, resume, IOP L = 0 Apr 24 19:43:39 julia /vmunix: current process = 173 (xdm) Apr 24 19:43:39 julia /vmunix: interrupt mask = Apr 24 19:43:40 julia /vmunix: panic: page fault Apr 24 19:43:40 julia /vmunix: Apr 24 19:43:40 julia /vmunix: syncing disks... 9 9 8 3 done Apr 24 19:43:40 julia /vmunix: Apr 24 19:43:40 julia /vmunix: dumping to dev 1, offset 32768 Apr 24 19:43:40 julia /vmunix: dump 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 earlier it also said Feb 9 10:49:44 julia /vmunix: Error in getattr: 70 this happens since i try the new snaps (or FreeBSD in general at this machine) -> since the 950210 snap i tried to debug the kernel core - but a backtrace gives nothing (only one line with a ? inside) - here is what the nfs-server (where my homedir comes from- it's a dec alpha with osf/1 - pardon Digital UNIX 3.0) says at the same time pr 24 19:42:21 sirius vmunix: NFS server: stale file handle fs(8,2054) file 1169 20 gen 798744795 Apr 24 19:42:21 sirius vmunix: getattr, client address = 130.133.3.235, errno 22 if you need any further information about this - please mail me - and i'll try to provide it ... and now another problem - but i think it might also be related to xfree - here's my report from some weeks ago: * then i log in via xdm everything works fine - but after some time i can't open any new window and in xdm-errors i find something like AUDIT: Thu Feb 9 11:44:17 1995: 111 X: client 9 rejected from IP 130.133.3.235 port 2564 130.133.3.235 it's my machine - it will only start working again if i type xhost + - why it will stop working after some time - i've never seen this before on linux or DEC OSF/1 - what does it exactly mean - now i do a xhost + in the Xsetup but this can't be the right way - i asked in comp.windows.x.i386unix (or so) but nobody could give me na answer that's all - thanks in advance - t _______________________________________________________||_____________________ __|| Perfection is reached, not when there is no __|| thomas graichen longer anything to add, but when there __|| freie universitaet berlin is no longer anything to take away __|| fachbereich physik __|| - Antoine de Saint-Exupery - __|| ___________________________||____email: graichen@omega.physik.fu-berlin.de____ From owner-freebsd-bugs Sat May 13 01:17:21 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id BAA09033 for bugs-outgoing; Sat, 13 May 1995 01:17:21 -0700 Received: from pelican.com (pelican.com [134.24.4.62]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id BAA09017 for ; Sat, 13 May 1995 01:17:13 -0700 Received: by pelican.com (Smail3.1.28.1 #5) id m0sACNm-000K2iC; Sat, 13 May 95 01:17 WET DST Message-Id: Date: Sat, 13 May 95 01:17 WET DST From: pete@pelican.com (Pete Carah) To: bugs@FreeBSD.org Subject: Re: i386/395: CRITICAL PROBLEM: spl functions implemented incorrectly In-Reply-To: <199505120932.TAA20816@godzilla.zeta.org.au> Organization: Pelican Consulting Sender: bugs-owner@FreeBSD.org Precedence: bulk In article <199505120932.TAA20816@godzilla.zeta.org.au> bde writes: > .... >This makes optimizations harder but doesn't stop them. The linker is >allowed to do global optimizations. >The standard also allows entire expressions, function calls and even >accesses to volatile objects to be optimized away if it can be shown >that the side effects are not needed. This is the usual "as if" >rule explictly stated. I've seen *read()* reordered by one global optimizer... Talk about unsafe!! (a major workstation manufacturer under the -O3 option.) (this broke a video application because the serial I/O that moved a video disk pointer got moved around the code outputting the picture :-( I've given up -O3 entirely in that system. Apparently the compiler correctly noticed that the picture's memory and the command's memory didn't physically overlap, and presumed to optimize... (I haven't checked for a couple of years, now; the compiler is several major releases later and this *might* have been fixed. I don't count on it, though...) >The average device driver probably depends on non-reordering in many other >places, but probably has more bugs from not declaring enough variables as >volatile. The old V7 kernel (and later) had to be compiled without even -O... "volatile" was added to improve this. Note that volatile protects things from *any* other threads (e.g. co-routines in multiprocessors), not just interrupt handlers. To make global optimizers safe in the presence of *any* non-memory side effects (I/O) one needs function-attribute flags in the library that the linker and compiler can check. This is not generally possible by just examining memory references in machines with memory-mapped I/O (mips, 68k, even our 'ed0' card, etc). Such flags have to be manually set; this can be forgotten in the rush before code-freeze :-). Standards committees aren't perfect either: Remember that the ansi C committee, at one time, (in)conveniently forgot that floating point addition is _not_ associative when discussing allowable -Ox manipulations, and was going to explicitly allow reordering of such even in the presence of ()... (the actual standard's wording did say "commutative, associative operators"; the examples made it obvious that the committee people weren't used to numerical analysis...) -- Pete From owner-freebsd-bugs Sat May 13 01:59:53 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id BAA12334 for bugs-outgoing; Sat, 13 May 1995 01:59:53 -0700 Received: from netcom19.netcom.com (bakul@netcom19.netcom.com [192.100.81.132]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id BAA12324 for ; Sat, 13 May 1995 01:59:50 -0700 Received: from localhost by netcom19.netcom.com (8.6.12/Netcom) id BAA28730; Sat, 13 May 1995 01:59:31 -0700 Message-Id: <199505130859.BAA28730@netcom19.netcom.com> To: bugs@FreeBSD.org Subject: Re: i386/395: CRITICAL PROBLEM: spl functions implemented incorrectly In-reply-to: Your message of "Sat, 13 May 95 01:17:00 +0700." Date: Sat, 13 May 95 01:59:30 -0700 From: Bakul Shah Sender: bugs-owner@FreeBSD.org Precedence: bulk Bruce Evans wrote: >The standard also allows entire expressions, function calls and even >accesses to volatile objects to be optimized away if it can be shown >that the side effects are not needed. This is the usual "as if" >rule explictly stated. Except that w.r.t. volatile the compiler has *no* way of knowing the side effects of external entities. The original intent of volatilve was precisely for preventing such `optimizations'. A more reasonable notation would've been _shared_ instead of _volatile_. It is easy to see that a shared variable can change behind your back. Unfortunately, `shared' nowadays connotes something much more specific. I agree with the rest of what Bruce said. This is why in general hiding things away in a function is not safe enough (though, usually, in practise it is). Making driver globals etc. volatile is the way to go (this problem has already been encountered and solved in a similar way by a number of commercial systems, especially multi- processor ones). This seems to work because a compiler must not reorder volatile accesses w.r.t. *other* volatile accesses and it must not optimize away such references. Though, I don't know if gcc handles them right in all cases. If you want to temporarily lose volatility for performance (and where you know this is safe), you can manually copy such values to registers or perhaps, typecasting will work. Pete Carah wrote: > To make global optimizers safe in the presence of *any* non-memory > side effects (I/O) one needs function-attribute flags in the library I think GNU extension of volatile attribute for a function deals with this well, when used with an asm() `function'. --bakul From owner-freebsd-bugs Sat May 13 02:17:32 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id CAA14221 for bugs-outgoing; Sat, 13 May 1995 02:17:32 -0700 Received: from mail.cs.tu-berlin.de (root@mail.cs.tu-berlin.de [130.149.17.13]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id CAA14198 for ; Sat, 13 May 1995 02:17:19 -0700 Received: from caramba.cs.tu-berlin.de (wosch@caramba.cs.tu-berlin.de [130.149.18.7]) by mail.cs.tu-berlin.de (8.6.10/8.6.10) with ESMTP id LAA21139; Sat, 13 May 1995 11:17:13 +0200 From: Wolfram Schneider Received: (wosch@localhost) by caramba.cs.tu-berlin.de (8.6.10/8.6.9) id LAA01941; Sat, 13 May 1995 11:17:07 +0200 Date: Sat, 13 May 1995 11:17:07 +0200 Message-Id: <199505130917.LAA01941@caramba.cs.tu-berlin.de> To: "Unser, Danny" Cc: "'FreeBSD - Bugs'" Subject: adduser & 950412-SNAP In-Reply-To: <2FB3811C@msmail.sdsmt.edu> References: <2FB3811C@msmail.sdsmt.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: bugs-owner@FreeBSD.org Precedence: bulk Danny Unser writes: > >Why isn't I cannot add anymore users after the initial install? When I >try to add a user, the program takes me all the way through the questions >and asks for confirmation. After that it just hangs. Fixed in -current (I hope). FreeBSD/FreeBSD-current/src/usr.sbin/adduser/ Gruß Wolfram -- http://hyperg.cs.tu-berlin.de/C~wosch From owner-freebsd-bugs Sat May 13 03:13:15 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id DAA18651 for bugs-outgoing; Sat, 13 May 1995 03:13:15 -0700 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 DAA18625 for ; Sat, 13 May 1995 03:12:56 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id UAA23813; Sat, 13 May 1995 20:08:00 +1000 Date: Sat, 13 May 1995 20:08:00 +1000 From: Bruce Evans Message-Id: <199505131008.UAA23813@godzilla.zeta.org.au> To: bakul@netcom.com, bugs@FreeBSD.org Subject: Re: i386/395: CRITICAL PROBLEM: spl functions implemented incorrectly Sender: bugs-owner@FreeBSD.org Precedence: bulk >Making driver globals etc. volatile is the way to go (this >problem has already been encountered and solved in a similar >way by a number of commercial systems, especially multi- >processor ones). This seems to work because a compiler must >not reorder volatile accesses w.r.t. *other* volatile >accesses and it must not optimize away such references. >Though, I don't know if gcc handles them right in all cases. In the case of the current implementation of spl*(), it works because the compiler must not reorder volatile accesses w.r.t. the store to cpl. >If you want to temporarily lose volatility for performance >(and where you know this is safe), you can manually copy >such values to registers or perhaps, typecasting will work. It's probably almost always safe because the volatile variables are amost always accessed in spl'ed regions where they are nonvolatile. For volatile hardware registers it is often important to copy the value for further processing because multiple accesses might have side effects. >Pete Carah wrote: >> To make global optimizers safe in the presence of *any* non-memory >> side effects (I/O) one needs function-attribute flags in the library >I think GNU extension of volatile attribute for a function >deals with this well, when used with an asm() `function'. `volatile' functions are ones that don't return. This meaning of volatile is deprecated (use the noreturn attribute). `volatile' asms are ones that can't be moved or deleted. The following seems to work OK to flush cached values of variables that should be volatile: #define invalidate_previous_loads() __asm __volatile("" : : : "memory") It pretends to clobber random memory, so it flushes cached values of all variables. It does the null assembler operation "" so it doesn't necessarily waste any time. In practice it may save or waste a little time due changing the pattern and number of loads. I added it to spl*() and examined the 14 modules that changed (out of 26). I didn't find any bugs. Usually only the caching of local variables changed, as in the following: void foo(int x) { invalidate_previous_loads(); bar(x); } Gcc copies the value of the arg to a register variable _before_ the invalidate step and passes the copy to bar(). Without the invalidate step, it pushes the original arg without loading it. Pushing through a register happens to be faster on i486's and would be used in all cases if the -m486 flag was used. The same sort of thing happens if you attempt to cache a value in a local variable (preferably a register) before calling spl*(). With the invalidate step, the caching is honoured. Without it, the caching is sometimes ignored, e.g., when the cached value has to be spilled to memory, there is little point in caching it, and gcc sometimes notices this. It is always(?) wrong to cache volatile variables before calling spl*(), so I wasn't surprised that there seemed to be no important changes. Bruce From owner-freebsd-bugs Sat May 13 04:30:30 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id EAA23558 for bugs-outgoing; Sat, 13 May 1995 04:30:30 -0700 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id EAA23545 for freebsd-bugs; Sat, 13 May 1995 04:30:27 -0700 Date: Sat, 13 May 1995 04:30:27 -0700 From: GNU GNATS Message-Id: <199505131130.EAA23545@freefall.cdrom.com> To: freebsd-bugs Subject: List of open Problem Reports Sender: bugs-owner@FreeBSD.org Precedence: bulk This is the list of currently open problem reports [1994/09/14] kern/1 Toshiba MK156FB scsi drive does not work with 2.0 ke [1994/10/07] kern/6 System hangs while using slip or ppp connection [1994/11/13] i386/14 No MBR put on prestine IDE disk drive [1994/11/14] bin/17 "mount -t foo /dev/wd1h /mnt" gives incorrect error [1994/11/18] kern/21 kernel panic. [1994/11/18] conf/22 Cannot use links to share kernel objects [1994/11/23] kern/27 Loopback mounts confuse unmount-on-reboot code [1994/11/30] kern/34 nullfs and union mounts can result in wild pointer r [1994/12/03] kern/39 Recent config changes hosed ft config [1994/12/04] kern/40 Floppy tape probe hosed (FIX) [1994/12/06] kern/42 PC-NFS on -current can't access disks [1994/12/07] docs/43 manpage for keysu is missing. reference from keyinit [1994/12/07] kern/44 ep driver won't work with anything but bnc [1994/12/08] kern/46 ed driver don't know the link0 flag (IFF_LINK0) [1994/12/13] misc/48 /etc/rc does not recover recovery files [1994/12/14] kern/51 Panic accessing NFS mounted file system [1994/12/14] gnu/54 No manual entry for uucpd [1994/12/18] misc/67 It took 20 tries to get free-bsd installed [1994/12/18] misc/68 bininst leaves system kinda hung [1994/12/21] misc/75 Netboot ignores gateway [1994/12/20] conf/76 fdisk can't be trusted. [1994/12/21] i386/79 Reboots sometimes don't complete. [1994/12/23] misc/83 System crash after abrupt end of slip session [1995/01/03] kern/95 Configuring a SLIP device with source = destination [1995/01/09] kern/102 PANIC after running Merged Buffer Cache kernel for a [1995/01/10] bin/104 pax -rwl may corrupt filesystem [1995/01/11] i386/105 Distributed libm (msun) has non-standard error handl [1995/01/13] gnu/107 kernel build produces internal compiler error [1995/01/14] bin/109 at command doesn't parse dates time and doesn't prom [1995/01/14] misc/112 ^C cause panic during install [1995/01/14] bin/113 /bin/csh and /usr/local/bin/tcsh choke on my nasty c [1995/01/14] bin/115 systat iostat display doesn't scale high enough [1995/01/14] bin/116 disk transfer rates reported by systat :iostat are t [1995/01/14] misc/118 use of 386bsd partition tag makes multi-os boot hard [1995/01/14] misc/119 you cannot tune your newfs parameters at intall time [1995/01/14] misc/120 first Initial security report is bogus becuase of ls [1995/01/14] bin/124 traceroute doesn't support -g flag. [1995/01/14] docs/127 locate man page does not have any clues to how the d [1995/01/14] bin/129 fsck cannot take a mount point as an argument [1995/01/14] docs/131 there is no man page for uucpd [1995/01/14] docs/132 gettytab documentation is split between /etc/gettyta [1995/01/14] bin/133 mail program doesn't have editheaders option [1995/01/14] misc/134 ispell (in ports) thinks the dictionary is in /usr/d [1995/01/14] bin/135 not enough ptys; virtual console names conflict with [1995/01/14] docs/137 domainname man page references getdomainname(2) whic [1995/01/15] bin/146 version of compress is kinda old and slow [1995/01/19] bin/151 One of the pkg_add set /tmp mod to 755 [1995/01/19] kern/152 Kernel config doesn't handle "irq 2" as irq 9 [1995/01/20] bin/153 mount -u improvement for diskless systems [1995/01/21] kern/157 Quota system does not work [1995/01/21] docs/159 uucp manual files have wrong file locations. [1995/01/21] docs/161 Not MAKEDEV(8) manual page. [1995/01/21] bin/163 telneting sometimes doesn't yield a "login:" prompt [1995/01/21] docs/164 no ptrace(2) manual page. [1995/01/21] docs/165 No documentation on kernel boot flags. [1995/01/21] misc/166 /usr/include/machine/asmacros.h includes uninstalled [1995/01/21] bin/167 makewhatis ignores symbolic links. [1995/01/21] kern/169 Errors from mkdir & mv when directories paths end wi [1995/01/21] bin/170 ar does not print an error message with readonly lib [1995/01/21] docs/171 No documentation on .forward files. [1995/01/21] bin/172 cp -f does not work [1995/01/21] bin/173 rc trys to mount modload fs before ld is available. [1995/01/21] bin/174 Poor error message from stty [1995/01/22] kern/175 Syscons does not recover X graphics mode [1995/01/22] kern/176 EIDRM not defined in errno.h [1995/01/22] docs/177 man pages missing for SYSV IPC funtions [1995/01/23] kern/180 Fiddling with process stack and using scanf with inv [1995/01/24] gnu/183 can't resolve "operator <<" overload [1995/01/24] bin/184 send-pr says "Aborting ..." and happily removes the [1995/01/25] kern/185 kernel stability problems - can't sustain uptimes > [1995/01/25] conf/187 Files referenced in Makefiles do not exist [1995/01/25] bin/188 disklabel uses c partition by default, kernel says d [1995/01/30] gnu/196 size of bss in *.o's reported wrong by size [1995/01/30] bin/198 1.1.5.1 pine binary loops; top shows fancy values [1995/02/01] bin/199 quiz(6) reading database bug, pattern matching bug [1995/02/01] misc/202 System hang or reboot without clues, tcp ppp named r [1995/02/02] bin/204 Installing failes [1995/02/08] kern/211 mv returns "Invalid argument" unreasonably [1995/02/14] kern/214 Using wt driver crashes system [1995/02/14] kern/216 /kernel: panic: ffs_alloccg: map corrupted [1995/02/14] docs/218 dbm references from hash(3) [1995/02/16] kern/219 Performance on local net drops too much when SNDBUF [1995/02/16] misc/220 Cancel still doesn't work during install [1995/02/16] misc/221 lots of error messages during unpacking via ftp inst [1995/02/16] i386/222 boot prompt doesn't always work [1995/02/16] misc/223 default domain shouldn't be hostname [1995/02/18] kern/224 ppp net serial [1995/02/18] kern/225 Panic: invalid wire count when GDB kills stopped inf [1995/03/02] misc/229 acos() core dump [1995/03/03] bin/230 C++ contructors not being called [1995/03/05] gnu/231 send-pr initializes Organization with ~/.signature [1995/03/05] docs/232 The mandoc .St macro doesn't work or misses IEEE754 [1995/03/10] misc/236 2.0-950210-SNAP/src/extract.sh references "release" [1995/03/11] kern/238 failed assertion in ncr.c --> no more scsi disk acce [1995/03/13] bin/241 strange behavior of /bin/sh [1995/03/17] kern/247 Berkeley Packet Filter fix [1995/03/17] kern/248 scbus attach/probe information is inconsistent [1995/03/18] i386/251 disklabel(8) refuses to install new bootstrap [1995/03/18] kern/253 Tagged queuing with an Adaptec 2842 controller doesn [1995/03/19] gnu/256 nasty gdb bug back in 031595 system [1995/03/20] docs/263 There is absolutely no documentation for the dialog [1995/03/21] docs/265 mtrace command lacks man pages [1995/03/21] kern/266 ifconfig panics kernel built without option NFS [1995/03/27] bin/274 touch -t with century doesn't work [1995/03/28] kern/275 qic-02 streamer won't work [1995/03/28] kern/277 netstat -r reports entries with negative expire time [1995/03/28] kern/280 the new slice code is bitching about my old slices [1995/03/28] kern/281 Messages printed when checking CD ROM device too ver [1995/03/28] kern/282 buslogic adapter information WAY too verbose [1995/03/29] kern/284 Network gives permission denied [1995/03/30] conf/286 'make depend' on GENERIC kernel stops [1995/03/30] kern/287 Several header files are not consistent [1995/03/31] kern/288 panic: free: multiple frees [1995/04/01] gnu/289 info(1) cannot handle arrow keys on a VT100 [1995/04/01] kern/291 PCI devices still probe/attach after being disabled [1995/04/01] misc/292 rfc1323 and rfc1644 support can confuse terminal ser [1995/04/01] kern/293 wd0: interrupt timeout [1995/04/02] kern/294 Bootstrap has problems with -g compiled kernels [1995/04/04] i386/297 matcd does not play audio CDs from cdplay [1995/04/04] kern/299 SCSI probes stop at ID 7 even for WIDE busses [1995/04/05] bin/300 __fdnlist fails on kernels created by cc -g and stri [1995/04/06] conf/301 Log rotation wastes _much_ to much space [1995/04/06] kern/302 Changing st tapes after extract crashes system [1995/04/08] pending/307 request for a customer id [1995/04/08] bin/308 Do-it-yourself FTP needs to prompt for what to downl [1995/04/08] bin/309 Do-it-yourself FTP deletes /usr/tmp dir rather than [1995/04/08] bin/310 ^C or ^Z in do-it-yourself FTP installation crashes [1995/04/08] bin/311 Do-it-yourself FTP deletes /usr/tmp dir rather than [1995/04/09] bin/314 CTRL-Z during installation crashes install FDIV008 [1995/04/09] bin/315 Kernel and boot block don't agree on kernel name FD [1995/04/09] bin/316 SNAP950322 less stable on IDE than earlier releases [1995/04/09] docs/317 Install README doesn't list matcd as install choice [1995/04/09] bin/318 matcd driver not on boot or fixit floppy FDIV012 [1995/04/09] bin/319 Install doesn't strip sys name in prompt for domain [1995/04/09] bin/320 TCP/IP settings entered b4 install are not kept FDIV [1995/04/09] bin/321 TCP/IP settings given during install are not kept FD [1995/04/09] bin/322 No way to restart a failed FTP download FDIV016 [1995/04/09] bin/323 Creating lost+found causes fsck to stop fsck -y FDIV [1995/04/09] bin/324 /usr/include/sys -> /usr/sys/sys -> /usr/sys/sys FD [1995/04/09] bin/326 Weekly cron generates some usage and error messages [1995/04/09] bin/327 Clock management punishes you if CMOS != GMT FDIV020 [1995/04/09] bin/328 Checking for -c kernel changes randomly hangs FDIV02 [1995/04/09] bin/329 FTP transfers above 99K shown in scientific notation [1995/04/11] kern/332 Incorrect routes can cause system to reset [1995/04/11] kern/336 make world fails on NCR-SCSI machine [1995/04/11] i386/337 seagate controller code hangs on boot. [1995/04/14] docs/341 vnconfig(8) disagrees with its man page [1995/04/14] bin/342 lpd can allow users access to all of root's groups [1995/04/14] kern/343 tcpdump with filter fails on tun and lo devices [1995/04/14] misc/344 Signal 11 when running a user program [1995/04/15] kern/345 panic "biodone: page busy < 0" [1995/04/15] pending/346 request for a customer id [1995/04/17] kern/349 Panic with bad dir [1995/04/19] ports/352 many problems in tex package [1995/04/20] kern/353 xcdplayer crashes machine (with NCR810 SCSI) [1995/04/20] kern/354 Can't configure two IP aliases with the same network [1995/04/20] misc/355 policy on /usr/local permission in base release [1995/04/20] misc/356 package xanim2683.tgz is missing man page [1995/04/20] bin/357 pkg_delete aborts when subcommand fails [1995/04/24] bin/359 BS/DEL is still not quite right. [1995/04/25] conf/362 uname -r output hosed [1995/04/26] kern/365 if_fddisubr.c doesn't compile (it never has...?!?) [1995/04/26] kern/366 queue changes broke ISO tpip code [1995/04/26] kern/367 kernel hangs after ep0 attach message appears [1995/04/26] i386/369 AHA-154X-A problems [1995/04/29] kern/371 panic: msdosfs_unlock: denode not locked [1995/04/30] pending/372 request for a customer id [1995/05/01] gnu/373 In response to admittedly bogus code, gcc emits an o [1995/05/01] kern/374 panic: bad dir [1995/05/01] bin/375 NIS does not seem to work with Kerberos [1995/05/02] kern/376 tcpdump seems to cause spontaneous reboots [1995/05/02] kern/377 Can't config any but first bus of a host adapter [1995/05/03] kern/378 (apparently) bounce buffer code gets used on 32bit b [1995/05/05] kern/383 dd to from /dev/mem panics the machine. [1995/05/06] kern/384 ep0 conflicts with some other drivers [1995/05/06] kern/385 ep0 finds card on irq 10 when it's actually on 11 [1995/05/07] kern/387 scsistrategy doesn't use bounce buffers [1995/05/08] kern/388 Printing extremely slow when printing with a Deskjet [1995/05/08] bin/389 Simultaneous creation/deletion of dirs corrupts file [1995/05/09] i386/390 missing parameter in function "boot" [1995/05/09] bin/392 Simultaneous cp and ls of files on dos f/s hangs pro [1995/05/09] bin/393 Simultaneous cp and ls of files on dos f/s hangs pro [1995/05/11] i386/394 IP multicast not supported by ep driver [1995/05/11] i386/395 All spl functions implemented incorrectly in both Fr [1995/05/11] bin/396 telnetd problems. [1995/05/12] bin/398 VI doesnt do the correct thing /* EOF -- this list has not been truncated */ From owner-freebsd-bugs Sat May 13 06:20:02 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id GAA00850 for bugs-outgoing; Sat, 13 May 1995 06:20:02 -0700 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id GAA00843 ; Sat, 13 May 1995 06:20:01 -0700 Date: Sat, 13 May 1995 06:20:01 -0700 Message-Id: <199505131320.GAA00843@freefall.cdrom.com> From: John Capo Reply-To: John Capo To: freebsd-bugs Subject: bin/399: FtpPasv in libftp returns address of local variable In-Reply-To: Your message of Sat, 13 May 1995 08:42:09 -0400 <199505131242.IAA17555@irbs.irbs.com> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 399 >Category: bin >Synopsis: FtpPasv in libftp returns address of local variable >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat May 13 06:20:00 1995 >Originator: John Capo >Organization: IRBS Engineering >Release: FreeBSD 2.0.950418-SNAP i386 >Environment: >Description: Function FtpPasv() in libftp/FtpPasv.c returns address of local char array. >How-To-Repeat: >Fix: *** lib/libftp/FtpPasv.c.orig Tue Apr 25 16:31:06 1995 --- lib/libftp/FtpPasv.c Sat May 13 08:36:11 1995 *************** *** 19,25 **** char * FtpPasv (FTP *ftp) { char *msg; ! String PORT; char *p=PORT; if FtpError(FtpCommand(ftp,"PASV","",227,EOF)) --- 19,25 ---- char * FtpPasv (FTP *ftp) { char *msg; ! static String PORT; char *p=PORT; if FtpError(FtpCommand(ftp,"PASV","",227,EOF)) >Audit-Trail: >Unformatted: From owner-freebsd-bugs Sat May 13 11:00:02 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA07408 for bugs-outgoing; Sat, 13 May 1995 11:00:02 -0700 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA07401 ; Sat, 13 May 1995 11:00:01 -0700 Date: Sat, 13 May 1995 11:00:01 -0700 Message-Id: <199505131800.LAA07401@freefall.cdrom.com> From: wpaul@ctr.columbia.edu Reply-To: wpaul@ctr.columbia.edu To: freebsd-bugs Subject: kern/400: fade_saver loadable kernel module crashes system In-Reply-To: Your message of Sat, 13 May 1995 13:54:05 -0400 <199505131754.NAA02863@nakedgun.ctr.columbia.edu> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 400 >Category: kern >Synopsis: fade_saver loadable kernel module crashes system >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat May 13 11:00:01 1995 >Originator: Bill Paul >Organization: Center for Telecommunications Research, Columbia University >Release: FreeBSD 2.0.950418-SNAP i386 >Environment: The problem has been noted on two different systems, both running FreeBSD-current (as of today): Pentium 90Mhz CPU EISA system with 16 Mbytes RAM Adaptec 2740T EISA Twin Channel SCSI adapter Seagate ST31200N 1 Gbyte drive WD90C50 integrated SVGA hardware with 1 MB video RAM Inter EtherExpress Ethernet adapter SoundBlaster 16 sound card i386DX CPU (no FPU) ISA system with 8 Mbytes RAM IDE disk controller Quantum 50 Mbyte IDE disk 3Com 3c503 ethernet adapter Diamond Speedstar 3.01 (ET4000) SVGA adapter with 1Mbyte video RAM Kernel config file: Both systems have the syscons console driver compiled into their kernels. >Description: The fade_saver loadable screen saver module causes a fatal kernel trap when it activates. It can be modload'ed just fine, but as soon as syscons activates it, the system panics. The other modules seem to work fine. Here's a sample console log showing the panic. This is from a kernel built with sources supped just this morning: marple# modload -e saver_init fade_saver_mod.o fade screen saver installed Module loaded as ID 0 marple# modstat Type Id Off Loadaddr Size Info Rev Module Name MISC 0 0 f049f000 0008 f04a0000 1 fade_saver marple# vidcontrol -t 5 < /dev/ttyv0 marple# Fatal trap 12: page fault while in kernel mode fault virtual address = 0x3 fault code = supervisor read, page not present instruction pointer = 0x8:0xf049f080 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = Idle interrupt mask = panic: page fault syncing disks... 1 1 done Note that the instruction pointer points to a location inside the fade_saver's address space. Also note that 'make load' does not seem to work for for any of the syscons screen saver modules. It should. >How-To-Repeat: # cd /lkm # modload -e saver_init fade_saver_mod.o # vidcontrol -t 5 >Fix: No idea, though I suspect that the module may have fallen out of sync with the code in the syscons driver proper. I don't suppose it's occured to anyone what could happen if a clueless user tries to load a syscons saver module into a kernel that doesn't have the syscons driver in it? It might be a good idea to have the saver modules check to see if the syscons driver is actually present when they start, and if it isn't, unload themselves before they can do any damage, or at least scream loudly and not touch anything dangerous while they're there. >Audit-Trail: >Unformatted: From owner-freebsd-bugs Sat May 13 11:35:24 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA08382 for bugs-outgoing; Sat, 13 May 1995 11:35:24 -0700 Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id LAA08371 for ; Sat, 13 May 1995 11:35:22 -0700 Message-Id: <199505131835.LAA08371@freefall.cdrom.com> Received: by crh.cl.msu.edu (1.38.193.4/16.2) id AA12647; Sat, 13 May 1995 14:35:20 -0400 From: Charles Henrich Subject: login.c environ=envinit ? To: freebsd-bugs@FreeBSD.org Date: Sat, 13 May 1995 14:35:20 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 350 Sender: bugs-owner@FreeBSD.org Precedence: bulk Im looking at login.c ~line 400 where we reset the user environment if the p flag is passed, and we do this but just re-assigning the environment global. Shouldnt we free the environment memory before doing that? -Crh Charles Henrich Michigan State University henrich@crh.cl.msu.edu http://rs560.msu.edu/~henrich/ From owner-freebsd-bugs Sat May 13 14:20:02 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA12701 for bugs-outgoing; Sat, 13 May 1995 14:20:02 -0700 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA12694 ; Sat, 13 May 1995 14:20:01 -0700 Date: Sat, 13 May 1995 14:20:01 -0700 Message-Id: <199505132120.OAA12694@freefall.cdrom.com> From: henrich@crh.cl.msu.edu (Charles Henrich) Reply-To: henrich@crh.cl.msu.edu (Charles Henrich) To: freebsd-bugs Subject: bin/401: REMOTE_HOST REMOTE_PORT REMOTE_IP In-Reply-To: Your message of Sat, 13 May 1995 17:14:53 -0400 <199505132114.RAA26502@bsdprd1.ais.msu.edu> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 401 >Category: bin >Synopsis: Add REMOTE_* variables >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: change-request >Submitter-Id: current-users >Arrival-Date: Sat May 13 14:20:01 1995 >Originator: Charles Henrich & >Organization: Michigan State University >Release: FreeBSD 2.1.0-Development i386 >Environment: FreeBSD 950412-SNAP >Description: Modifications to inetd, telnetd, rlogind to make the following environment variables available to all processes. REMOTE_IP (Contains IP or -1.-1.-1.-1 (always a dotquad parseable) REMOTE_HOST (Contains hostname or ip if resolver fails) REMOTE_PORT (Contains the port of the remote host or -1 if failure) >How-To-Repeat: >Fix: As well as applying the following three patches, need to add -DDO_REMOTEVARS to telnetd and rlogind Makefile(s). The code in inetd wasnt #ifdef'd because working around the existing code would have been ugly/nasty. ------------------------------------------------------------------------------- *** usr.sbin/inetd/inetd.c Sat May 13 14:27:21 1995 --- usr.sbin/inetd/inetd.c.new Sat May 13 14:27:15 1995 *************** *** 252,257 **** --- 252,258 ---- pid_t pid; char buf[50]; struct sockaddr_in peer; + struct hostent *hs; int i; Argv = argv; *************** *** 354,372 **** sep->se_service); continue; } ! if(log) { ! i = sizeof peer; ! if(getpeername(ctrl, (struct sockaddr *) ! &peer, &i)) { syslog(LOG_WARNING, "getpeername(for %s): %m", sep->se_service); - continue; } ! syslog(LOG_INFO,"%s from %s", ! sep->se_service, ! inet_ntoa(peer.sin_addr)); } /* * Call tcpmux to find the real service to exec. */ --- 355,416 ---- sep->se_service); continue; } ! ! /***********************************************/ ! /* */ ! /* Originally getpeername was only called */ ! /* inside the if(log) block, and in that case */ ! /* if getpeername returned an error the code */ ! /* would continue back to the top of the loop. */ ! /* This doesnt make any sense, so in the new */ ! /* case (we always do a getpeername for the */ ! /* REMOTE_* vars) we just set the variables to */ ! /* UNKNOWN, -1.-1.-1.-1, -1 and drop through */ ! /* as it should. -Crh (henrich@msu.edu) */ ! /* */ ! /***********************************************/ ! ! i = sizeof peer; ! if(getpeername(ctrl, (struct sockaddr *) ! &peer, &i)) { ! ! if(log) { syslog(LOG_WARNING, "getpeername(for %s): %m", sep->se_service); } ! ! (void)setenv("REMOTE_HOST", "UNKNOWN", 1); ! (void)setenv("REMOTE_IP", "-1.-1.-1.-1", 1); ! (void)setenv("REMOTE_PORT", "-1", 1); ! ! } else { ! ! if(log) { ! syslog(LOG_INFO,"%s from %s", ! sep->se_service, ! inet_ntoa(peer.sin_addr)); ! } ! ! hs=gethostbyaddr((char *)&peer.sin_addr, ! sizeof(peer.sin_addr), ! AF_INET); ! ! if(hs != NULL) { ! (void)setenv("REMOTE_HOST", hs->h_name, ! 1); ! } else { ! (void)setenv("REMOTE_HOST", ! inet_ntoa(peer.sin_addr), 1); ! } ! ! (void)setenv("REMOTE_IP", ! inet_ntoa(peer.sin_addr), 1); ! ! sprintf(buf,"%hd", ntohs(peer.sin_port)); ! (void)setenv("REMOTE_PORT", buf, 1); } + /* * Call tcpmux to find the real service to exec. */ ------------------------------------------------------------------------------- *** libexec/telnetd/telnetd.c Fri Aug 12 19:00:02 1994 --- libexec/telnetd/telnetd.c.new Sat May 13 16:05:46 1995 *************** *** 758,763 **** --- 758,766 ---- int level; int ptynum; char user_name[256]; + #ifdef DO_REMOTEVARS + char remote_port[20]; + #endif /* DO_REMOTEVARS */ /* * Find an available pty to use. *************** *** 833,838 **** --- 836,848 ---- *user_name = 0; level = getterminaltype(user_name); setenv("TERM", terminaltype ? terminaltype : "network", 1); + + #ifdef DO_REMOTEVARS + setenv("REMOTE_HOST", remote_host_name, 1); + setenv("REMOTE_IP", inet_ntoa(who->sin_addr), 1); + sprintf(remote_port,"%hd", ntohs(who->sin_port)); + setenv("REMOTE_PORT", remote_port, 1); + #endif /* DO_REMOTEVARS */ /* * Start up the login process on the slave side of the terminal ------------------------------------------------------------------------------- *** libexec/rlogind/rlogind.c Sat May 13 16:07:38 1995 --- libexec/rlogind/rlogind.c.new Sat May 13 17:02:46 1995 *************** *** 200,205 **** --- 200,208 ---- register struct hostent *hp; char hostname[2 * MAXHOSTNAMELEN + 1]; char c; + #ifdef DO_REMOTEVARS + char remote_port[20]; + #endif /* DO_REMOTEVARS */ alarm(60); read(f, &c, 1); *************** *** 293,298 **** --- 296,315 ---- if (f > 2) /* f should always be 0, but... */ (void) close(f); setup_term(0); + + #ifdef DO_REMOTEVARS + setenv("REMOTE_HOST", hostname, 1); + setenv("REMOTE_IP", inet_ntoa(fromp->sin_addr), 1); + + /**********************************************************/ + /* fromp->sin_port is in host-byte-order for some strange */ + /* reason here, so we dont do a ntohs here. */ + /**********************************************************/ + + sprintf(remote_port,"%hd", fromp->sin_port); + setenv("REMOTE_PORT", remote_port, 1); + #endif /* DO_REMOTEVARS */ + if (strchr(lusername, '-')) { syslog(LOG_ERR, "tried to pass user \"%s\" to login", lusername); >Audit-Trail: >Unformatted: From owner-freebsd-bugs Sat May 13 15:11:37 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id PAA13694 for bugs-outgoing; Sat, 13 May 1995 15:11:37 -0700 Received: (from ache@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id PAA13680 ; Sat, 13 May 1995 15:11:37 -0700 Date: Sat, 13 May 1995 15:11:37 -0700 From: "Andrey A. Chernov" Message-Id: <199505132211.PAA13680@freefall.cdrom.com> To: jc@irbs.com, ache, freebsd-bugs Subject: Changed information for PR bin/399 Sender: bugs-owner@FreeBSD.org Precedence: bulk Synopsis: FtpPasv in libftp returns address of local variable State-Changed-From-To: open-closed State-Changed-By: ache State-Changed-When: Sat May 13 15:10:02 PDT 1995 State-Changed-Why: Fix applied in FtpPasv.c v1.2 From owner-freebsd-bugs Sat May 13 15:20:03 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id PAA13933 for bugs-outgoing; Sat, 13 May 1995 15:20:03 -0700 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id PAA13926 ; Sat, 13 May 1995 15:20:02 -0700 Date: Sat, 13 May 1995 15:20:02 -0700 Message-Id: <199505132220.PAA13926@freefall.cdrom.com> From: henrich@crh.cl.msu.edu (Charles Henrich) Reply-To: henrich@crh.cl.msu.edu (Charles Henrich) To: freebsd-bugs Subject: bin/402: w -n doesnt work as advertised. In-Reply-To: Your message of Sat, 13 May 1995 18:13:35 -0400 <199505132213.SAA27116@bsdprd1.ais.msu.edu> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 402 >Category: bin >Synopsis: w -n shows non-numeric addresses >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 May 13 15:20:01 1995 >Originator: Charles Henrich & >Organization: Michigan State University >Release: FreeBSD 2.1.0-Development i386 >Environment: FreeBSD 950412-SNAP >Description: The w manpage says w -n should: -n Show network addresses as numbers (normally w interprets address- es and attempts to display them symbolically). Unfortunatly it doesnt, it just takes the value in utmp and dumps it to the screen. Unless the value in ptmp is numeric, we dont get what we want. This especially sucks for any scripts that rely on w -n showing numeric's. >How-To-Repeat: >Fix: I modified w.c to attempt to figure out the ip address of the hosts that were non-IP. Because some folks might need an option to make w not do any resolver lookups, I also added -l which mirrors the the existing -n flag, and ensures no nameserver calls get executed. *** w.1 Fri Aug 5 10:13:34 1994 --- w.1.new Sat May 13 18:03:54 1995 *************** *** 39,45 **** .Nd "who present users are and what they are doing" .Sh SYNOPSIS .Nm w ! .Op Fl hin .Op Fl M Ar core .Op Fl N Ar system .Op Ar user --- 39,45 ---- .Nd "who present users are and what they are doing" .Sh SYNOPSIS .Nm w ! .Op Fl hiln .Op Fl M Ar core .Op Fl N Ar system .Op Ar user *************** *** 65,70 **** --- 65,72 ---- Suppress the heading. .It Fl i Output is sorted by idle time. + .It Fl l + Never do resolver/nameserver lookups .It Fl M Extract values associated with the name list from the specified core instead of the default *** w.c Sat Feb 18 11:29:39 1995 --- w.c.new Sat May 13 18:06:51 1995 *************** *** 88,94 **** int ttywidth; /* width of tty */ int argwidth; /* width of tty */ int header = 1; /* true if -h flag: don't print heading */ ! int nflag; /* true if -n flag: don't convert addrs */ int sortidle; /* sort bu idle time */ char *sel_user; /* login of particular user selected */ char domain[MAXHOSTNAMELEN]; --- 88,95 ---- int ttywidth; /* width of tty */ int argwidth; /* width of tty */ int header = 1; /* true if -h flag: don't print heading */ ! int nflag; /* true if -n flag: return numeric addrs */ ! int lflag; /* true if -l flag: no resolver lookups -Crh */ int sortidle; /* sort bu idle time */ char *sel_user; /* login of particular user selected */ char domain[MAXHOSTNAMELEN]; *************** *** 159,166 **** case 'n': nflag = 1; break; ! case 'f': case 'l': case 's': case 'u': case 'w': ! warnx("[-flsuw] no longer supported"); /* FALLTHROUGH */ case '?': default: --- 160,170 ---- case 'n': nflag = 1; break; ! case 'l': ! lflag = 1; ! break; ! case 'f': case 's': case 'u': case 'w': ! warnx("[-fsuw] no longer supported"); /* FALLTHROUGH */ case '?': default: *************** *** 294,300 **** p = *ep->utmp.ut_host ? ep->utmp.ut_host : "-"; if ((x = strchr(p, ':')) != NULL) *x++ = '\0'; ! if (!nflag && isdigit(*p) && (long)(l = inet_addr(p)) != -1 && (hp = gethostbyaddr((char *)&l, sizeof(l), AF_INET))) { if (domain[0] != '\0') { --- 298,304 ---- p = *ep->utmp.ut_host ? ep->utmp.ut_host : "-"; if ((x = strchr(p, ':')) != NULL) *x++ = '\0'; ! if (!lflag && !nflag && isdigit(*p) && (long)(l = inet_addr(p)) != -1 && (hp = gethostbyaddr((char *)&l, sizeof(l), AF_INET))) { if (domain[0] != '\0') { *************** *** 306,311 **** --- 310,326 ---- } p = hp->h_name; } + if(!lflag && nflag && !isdigit(*p) && *p != '-') + { + hp=gethostbyname(p); + if(hp != NULL) + { + struct in_addr in; + memmove(&in, hp->h_addr, sizeof(in)); + p = inet_ntoa(in); + } + } + if (x) { (void)snprintf(buf, sizeof(buf), "%s:%s", p, x); p = buf; >Audit-Trail: >Unformatted: From owner-freebsd-bugs Sat May 13 15:27:48 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id PAA14047 for bugs-outgoing; Sat, 13 May 1995 15:27:48 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id PAA14041 for ; Sat, 13 May 1995 15:27:45 -0700 Received: from corbin.Root.COM (corbin.Root.COM [198.145.90.18]) by Root.COM (8.6.8/8.6.5) with ESMTP id PAA00426; Sat, 13 May 1995 15:30:44 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.11/8.6.5) with SMTP id PAA01616; Sat, 13 May 1995 15:27:39 -0700 Message-Id: <199505132227.PAA01616@corbin.Root.COM> To: henrich@crh.cl.msu.edu (Charles Henrich) cc: freebsd-bugs@freefall.cdrom.com Subject: Re: bin/402: w -n doesnt work as advertised. In-reply-to: Your message of "Sat, 13 May 95 15:20:02 PDT." <199505132220.PAA13926@freefall.cdrom.com> From: David Greenman Reply-To: davidg@Root.COM Date: Sat, 13 May 1995 15:27:34 -0700 Sender: bugs-owner@FreeBSD.org Precedence: bulk > I modified w.c to attempt to figure out the ip address of the hosts > that were non-IP. Because some folks might need an option to make w > not do any resolver lookups, I also added -l which mirrors the > the existing -n flag, and ensures no nameserver calls get executed. Actually, I strongly dislike the 4.4 "w" doing nameserver lookups by default. On any reasonable system that has > 20 users on it, it can take anywhere from several seconds to several minutes for the w output to finish. In my opinion, the default for w should be reverted back to the old behavior of trusting what is in wtmp. -DG From owner-freebsd-bugs Sat May 13 15:28:04 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id PAA14057 for bugs-outgoing; Sat, 13 May 1995 15:28:04 -0700 Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id PAA14049 for ; Sat, 13 May 1995 15:28:02 -0700 Message-Id: <199505132228.PAA14049@freefall.cdrom.com> Received: by crh.cl.msu.edu (1.38.193.4/16.2) id AA23405; Sat, 13 May 1995 18:27:59 -0400 Date: Sat, 13 May 1995 18:27:59 -0400 From: Charles Henrich To: freebsd-bugs@FreeBSD.org Subject: bin/396: telnetd problems fix. X-Newsreader: NN version 6.5.0 #10 (NOV) Sender: bugs-owner@FreeBSD.org Precedence: bulk > > >Number: 396 > > >Category: bin > > >Synopsis: telnetd problems. > > >Confidential: no > > >Severity: serious > > >Priority: medium > > >Responsible: freebsd-bugs (FreeBSD bugs mailing list) > > >State: open > > >Class: sw-bug > > >Submitter-Id: current-users > > >Arrival-Date: Thu May 11 17:10:01 1995 > > >Originator: Charles Henrich > > >Organization: > > Michigan State University > > >Release: FreeBSD 2.1.0-Development i386 (950412-SNAP) > > >Environment: > > > > > > This bug is encountered on all FreeBSD systems running 950412-SNAP as > > well as 950210-SNAP, probably on all 2.x versions. > > Probably on all 4.4 based OS's. Did you also open a bug report with FTP > software?? They use to base there code on BSD 4.2 / Net/2 and it probably > still has the bugs from that generation of code. > > NCSA Telnet also seems to have this problem.... This is fixable by disabling -DLINEMODE for telnetd, this also seems to make things feel more responsive. While it was pointed out that this will make slower links (ppp) work slower, most folks using ppp are going to be doing so with software that could be breaking on this, making the system unusable. I would strongly suggest we disable -DLINEMODE as the default for the system. Working slow is better than not working fast. We should do this for 2.0.5. -- Charles Henrich Michigan State University henrich@crh.cl.msu.edu http://rs560.msu.edu/~henrich/ From owner-freebsd-bugs Sat May 13 15:30:43 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id PAA14111 for bugs-outgoing; Sat, 13 May 1995 15:30:43 -0700 Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id PAA14104 for ; Sat, 13 May 1995 15:30:41 -0700 Message-Id: <199505132230.PAA14104@freefall.cdrom.com> Received: by crh.cl.msu.edu (1.38.193.4/16.2) id AA23520; Sat, 13 May 1995 18:30:25 -0400 From: Charles Henrich Subject: Re: bin/402: w -n doesnt work as advertised. To: davidg@Root.COM Date: Sat, 13 May 1995 18:30:25 -0400 (EDT) Cc: henrich@crh.cl.msu.edu, freebsd-bugs@freefall.cdrom.com In-Reply-To: <199505132227.PAA01616@corbin.Root.COM> from "David Greenman" at May 13, 95 03:27:34 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1038 Sender: bugs-owner@FreeBSD.org Precedence: bulk > > I modified w.c to attempt to figure out the ip address of the hosts > > that were non-IP. Because some folks might need an option to make w > > not do any resolver lookups, I also added -l which mirrors the > > the existing -n flag, and ensures no nameserver calls get executed. > > Actually, I strongly dislike the 4.4 "w" doing nameserver lookups by > default. On any reasonable system that has > 20 users on it, it can take > anywhere from several seconds to several minutes for the w output to finish. > In my opinion, the default for w should be reverted back to the old behavior > of trusting what is in wtmp. Must be a slow nameserver? Most local nameervers will cache all retrieved data for an hour to a day, given that the responses should 80% of the time come from your local nameserver. I never have any problems with the lookups, w never takes even a second to run. -Crh Charles Henrich Michigan State University henrich@crh.cl.msu.edu http://rs560.msu.edu/~henrich/ From owner-freebsd-bugs Sat May 13 15:37:30 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id PAA14243 for bugs-outgoing; Sat, 13 May 1995 15:37:30 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id PAA14237 for ; Sat, 13 May 1995 15:37:28 -0700 Received: from corbin.Root.COM (corbin.Root.COM [198.145.90.18]) by Root.COM (8.6.8/8.6.5) with ESMTP id PAA00486; Sat, 13 May 1995 15:40:33 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.11/8.6.5) with SMTP id PAA00131; Sat, 13 May 1995 15:37:29 -0700 Message-Id: <199505132237.PAA00131@corbin.Root.COM> To: Charles Henrich cc: freebsd-bugs@freefall.cdrom.com Subject: Re: bin/402: w -n doesnt work as advertised. In-reply-to: Your message of "Sat, 13 May 95 18:30:25 EDT." <199505132233.PAA00451@Root.COM> From: David Greenman Reply-To: davidg@Root.COM Date: Sat, 13 May 1995 15:37:28 -0700 Sender: bugs-owner@FreeBSD.org Precedence: bulk >> > I modified w.c to attempt to figure out the ip address of the hosts >> > that were non-IP. Because some folks might need an option to make w >> > not do any resolver lookups, I also added -l which mirrors the >> > the existing -n flag, and ensures no nameserver calls get executed. >> >> Actually, I strongly dislike the 4.4 "w" doing nameserver lookups by >> default. On any reasonable system that has > 20 users on it, it can take >> anywhere from several seconds to several minutes for the w output to finish. >> In my opinion, the default for w should be reverted back to the old behavior >> of trusting what is in wtmp. > >Must be a slow nameserver? Most local nameervers will cache all retrieved data >for an hour to a day, given that the responses should 80% of the time come from >your local nameserver. I never have any problems with the lookups, w never >takes even a second to run. This works if the nameserver for all the domains is currently reachable. If it isn't, it can take a minute for the query to timeout. About half the time I do a 'w' on freefall, it takes > 1 minute to complete because of this. In other cases, it's often that nameservers are slow to respond - 2 seconds isn't unusual for non-cached entries. If this happens with just a few of the users, the delay can approach 5-10 seconds. The problem grows as the number of users increases. It's extremely annoying. -DG From owner-freebsd-bugs Sat May 13 15:39:04 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id PAA14261 for bugs-outgoing; Sat, 13 May 1995 15:39:04 -0700 Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id PAA14255 for ; Sat, 13 May 1995 15:39:02 -0700 Message-Id: <199505132239.PAA14255@freefall.cdrom.com> Received: by crh.cl.msu.edu (1.38.193.4/16.2) id AA23977; Sat, 13 May 1995 18:38:55 -0400 From: Charles Henrich Subject: Re: bin/402: w -n doesnt work as advertised. To: davidg@Root.COM Date: Sat, 13 May 1995 18:38:55 -0400 (EDT) Cc: henrich@crh.cl.msu.edu, freebsd-bugs@freefall.cdrom.com In-Reply-To: <199505132237.PAA00131@corbin.Root.COM> from "David Greenman" at May 13, 95 03:37:28 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 872 Sender: bugs-owner@FreeBSD.org Precedence: bulk > This works if the nameserver for all the domains is currently reachable. If >it isn't, it can take a minute for the query to timeout. About half the time I >do a 'w' on freefall, it takes > 1 minute to complete because of this. In >other cases, it's often that nameservers are slow to respond - 2 seconds isn't >unusual for non-cached entries. If this happens with just a few of the users, >the delay can approach 5-10 seconds. The problem grows as the number of users >increases. It's extremely annoying. Thats true, but if the user has logged in, they have caused their entry to be cached at the local nameserver, so you should very rarely be going offsite to get the data.. Unless something is broken in the local nameserver. -Crh Charles Henrich Michigan State University henrich@crh.cl.msu.edu http://rs560.msu.edu/~henrich/ From owner-freebsd-bugs Sat May 13 15:43:38 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id PAA14304 for bugs-outgoing; Sat, 13 May 1995 15:43:38 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id PAA14298 for ; Sat, 13 May 1995 15:43:35 -0700 Received: from corbin.Root.COM (corbin.Root.COM [198.145.90.18]) by Root.COM (8.6.8/8.6.5) with ESMTP id PAA00538; Sat, 13 May 1995 15:46:41 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.11/8.6.5) with SMTP id PAA00153; Sat, 13 May 1995 15:43:37 -0700 Message-Id: <199505132243.PAA00153@corbin.Root.COM> To: Charles Henrich cc: freebsd-bugs@freefall.cdrom.com Subject: Re: bin/402: w -n doesnt work as advertised. In-reply-to: Your message of "Sat, 13 May 95 18:38:55 EDT." <199505132239.PAA14255@freefall.cdrom.com> From: David Greenman Reply-To: davidg@Root.COM Date: Sat, 13 May 1995 15:43:36 -0700 Sender: bugs-owner@FreeBSD.org Precedence: bulk >> This works if the nameserver for all the domains is currently reachable. If >>it isn't, it can take a minute for the query to timeout. About half the time I >>do a 'w' on freefall, it takes > 1 minute to complete because of this. In >>other cases, it's often that nameservers are slow to respond - 2 seconds isn't >>unusual for non-cached entries. If this happens with just a few of the users, >>the delay can approach 5-10 seconds. The problem grows as the number of users >>increases. It's extremely annoying. > >Thats true, but if the user has logged in, they have caused their entry to be >cached at the local nameserver, so you should very rarely be going offsite to >get the data.. Unless something is broken in the local nameserver. Again, not if the nameserver for a given zone is down. If it was down when they logged in and down when somebody does a "w", then there won't be any cached entry. named doesn't cache "timed-out" queries. -DG From owner-freebsd-bugs Sat May 13 15:44:37 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id PAA14330 for bugs-outgoing; Sat, 13 May 1995 15:44:37 -0700 Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id PAA14324 for ; Sat, 13 May 1995 15:44:35 -0700 Message-Id: <199505132244.PAA14324@freefall.cdrom.com> Received: by crh.cl.msu.edu (1.38.193.4/16.2) id AA24288; Sat, 13 May 1995 18:44:27 -0400 From: Charles Henrich Subject: Re: bin/402: w -n doesnt work as advertised. To: davidg@Root.COM Date: Sat, 13 May 1995 18:44:27 -0400 (EDT) Cc: henrich@crh.cl.msu.edu, freebsd-bugs@freefall.cdrom.com In-Reply-To: <199505132243.PAA00153@corbin.Root.COM> from "David Greenman" at May 13, 95 03:43:36 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 435 Sender: bugs-owner@FreeBSD.org Precedence: bulk > Again, not if the nameserver for a given zone is down. If it was down when > they logged in and down when somebody does a "w", then there won't be any > cached entry. named doesn't cache "timed-out" queries. Okay good point, you win. w should default to w -n (in -current) or -l (my patch). -Crh Charles Henrich Michigan State University henrich@crh.cl.msu.edu http://rs560.msu.edu/~henrich/ From owner-freebsd-bugs Sat May 13 17:36:17 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id RAA16673 for bugs-outgoing; Sat, 13 May 1995 17:36:17 -0700 Received: from cardhu.cs.hut.fi (hsu@laphroaig.cs.hut.fi [130.233.192.94]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id RAA16666 for ; Sat, 13 May 1995 17:36:14 -0700 Received: by cardhu.cs.hut.fi id AA15782 (5.65c8/HUTCS-C 1.3 for freebsd-bugs@freefall.cdrom.com); Sun, 14 May 1995 03:33:14 +0300 Date: Sun, 14 May 1995 03:33:14 +0300 From: Heikki Suonsivu Message-Id: <199505140033.AA15782@cardhu.cs.hut.fi> To: Bruce Evans Cc: freebsd-bugs@freefall.cdrom.com, hsu@cs.hut.fi Subject: Re: i386/395: CRITICAL PROBLEM: spl functions implemented incorrectly In-Reply-To: <199505121955.FAA02157@godzilla.zeta.org.au> References: <199505121955.FAA02157@godzilla.zeta.org.au> Organization: Helsinki University of Technology, Otaniemi, Finland Sender: bugs-owner@FreeBSD.org Precedence: bulk Bruce Evans writes: > >s = splsomething(); > >if (foo) { > > ... something, which does verifyably not modify foo ... > > if (foo->bar) /* foo is NULL or garbage here, generating kernel > > page fault. */ > >} > >splx(s); > >can't remember which one (there are probably several open ones for me in > >GNATS, with stack traces and later ones with some kgdb wanderarounds). > There seems to be only one relevant one: > >>Synopsis: (apparently) bounce buffer code gets used on 32bit bus I thought there would be more, but maybe I just didn't send them or they got lost somewhere... The FreeBSD 1 "NFS server foo is alive again" problem wasn't reported as PR but by mail to freebsd-bugs, its old story (but still valid, almost every time one of the nfs servers panics, the FreeBSD 1 goes with it after the server comes up). > > bounce buffer code shouldn't be called in this machine, > >doesn't it say "enabling bounce buffer code" in boot on those which > >need it? > The bt driver always sets SDEV_BOUNCE :-(. I took the whole thing out to see if it affected the problem. It didn't, but exchanging the motherboard from P60 to P90 seems to reduce the frequency of problems. -- 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 Sat May 13 18:00:31 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA16914 for bugs-outgoing; Sat, 13 May 1995 18:00:31 -0700 Received: from jabba.fdn.org (jabba.fdn.org [193.55.4.70]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id SAA16908 for ; Sat, 13 May 1995 18:00:26 -0700 Received: (from uucp@localhost) by jabba.fdn.org (8.6.8/8.6.9) with UUCP id DAA29264; Sun, 14 May 1995 03:00:05 +0200 Received: (pb@localhost) by fasterix.frmug.fr.net (8.6.11/fasterix-941011) id CAA02666; Sun, 14 May 1995 02:58:58 +0200 From: Pierre Beyssac Message-Id: <199505140058.CAA02666@fasterix.frmug.fr.net> Subject: Re: -current kernel panics in rtfree To: pritc003@maroon.tc.umn.edu (Mike Pritchard) Date: Sun, 14 May 1995 02:58:56 +0200 (MET DST) Cc: bugs@FreeBSD.org In-Reply-To: <199505130245.VAA00225@mpp.com> from "Mike Pritchard" at May 12, 95 09:45:44 pm 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: 2295 Sender: bugs-owner@FreeBSD.org Precedence: bulk Mike Pritchard writes: [ panic in rtfree during a slip connection ] Same for me using PPP. Like Mike, I noticed this problem recently. I run a kernel compiled from friday night -current. I have a different kernel stack dump, though. My panics seem to occur during a UDP sendto. Note the recursive call to rtfree. It seems that the code causing the panic is : void rtfree(rt) register struct rtentry *rt; { register struct radix_node_head *rnh = rt_tables[rt_key(rt)->sa_family]; register struct ifaddr *ifa; if (rt == 0 || rnh == 0) panic("rtfree"); Which is recursively called by rtfree() itself at the end of the subroutine : if (rt->rt_parent) { RTFREE(rt->rt_parent); } I'll try to identify the problem, if I can. I'll keep the crash dump(s) :-) in case anybody wishes me to provide more info. panic: rtfree [...] #1 0xf01105a3 in panic () #2 0xf0135eef in rtfree () #3 0xf0135f84 in rtfree () #4 0xf013efaf in ip_output () #5 0xf0144d35 in udp_output () #6 0xf0144ff5 in udp_usrreq () #7 0xf011d4e2 in sosend () #8 0xf011fad3 in sendit () #9 0xf011fbb0 in sendto () #10 0xf01701fd in syscall () #11 0xf016894b in Xsyscall () Here are the results of a "netstat -r -n" done during a PPP connection, in case it might help. I've not been able to extract the same info from the crash dump with "netstat -r -n -M vmcore" ("kvm_open: cannot read IdlePTD"), so don't take the following as a strict image of the routes at the time of the panic. They're likely very close, however. Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 193.55.4.3 UGc 2 0 ppp0 127.0.0.1 127.0.0.1 UH 1 436 lo0 193.55.4.3 193.55.4.149 UH 3 5 ppp0 193.56.58 link#1 UC 0 0 193.56.58.138 0:40:5:12:bd:dd UHLW 1 40 lo0 I have a local ethernet (193.56.58.0) on a NE2000 clone, my local PPP address is 193.55.4.149 (fasterix.fdn.fr) and the PPP server is 193.55.4.3. -- Pierre Beyssac pb@fasterix.frmug.fr.net pb@fasterix.fdn.fr FreeBSD, NetBSD, Linux -- Il y a moins bien, mais c'est plus cher. You can also get less bang for more bucks. (translation F. Berjon) From owner-freebsd-bugs Sat May 13 18:48:02 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA17392 for bugs-outgoing; Sat, 13 May 1995 18:48:02 -0700 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 SAA17386 for ; Sat, 13 May 1995 18:47:58 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id SAA01094; Sat, 13 May 1995 18:47:09 -0700 From: "Rodney W. Grimes" Message-Id: <199505140147.SAA01094@gndrsh.aac.dev.com> Subject: Re: bin/396: telnetd problems fix. To: henrich@crh.cl.msu.edu (Charles Henrich) Date: Sat, 13 May 1995 18:47:09 -0700 (PDT) Cc: freebsd-bugs@FreeBSD.org In-Reply-To: <199505132228.PAA14049@freefall.cdrom.com> from "Charles Henrich" at May 13, 95 06:27:59 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2050 Sender: bugs-owner@FreeBSD.org Precedence: bulk > > > > >Number: 396 > > > >Category: bin > > > >Synopsis: telnetd problems. > > > >Confidential: no > > > >Severity: serious > > > >Priority: medium > > > >Responsible: freebsd-bugs (FreeBSD bugs mailing list) > > > >State: open > > > >Class: sw-bug > > > >Submitter-Id: current-users > > > >Arrival-Date: Thu May 11 17:10:01 1995 > > > >Originator: Charles Henrich > > > >Organization: > > > Michigan State University > > > >Release: FreeBSD 2.1.0-Development i386 (950412-SNAP) > > > >Environment: > > > > > > > > > This bug is encountered on all FreeBSD systems running 950412-SNAP as > > > well as 950210-SNAP, probably on all 2.x versions. > > > > Probably on all 4.4 based OS's. Did you also open a bug report with FTP > > software?? They use to base there code on BSD 4.2 / Net/2 and it probably > > still has the bugs from that generation of code. > > > > NCSA Telnet also seems to have this problem.... > > This is fixable by disabling -DLINEMODE for telnetd, this also seems to make > things feel more responsive. While it was pointed out that this will make > slower links (ppp) work slower, most folks using ppp are going to be doing so > with software that could be breaking on this, making the system unusable. I > would strongly suggest we disable -DLINEMODE as the default for the system. > Working slow is better than not working fast. We should do this for 2.0.5. I disagree, and we have been down this road at least 4 times in the last 2 years with FreeBSD. The bug is not in the FreeBSD code, it should not be bandaided to work with code that gets option negotiation wrong. I don't like to fix bugs in other software by making FreeBSD slower at *anything*. Go get NCSA and FTP software to fix there very ancient and broken code, they have had 2 years to do this, and still have not. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-bugs Sat May 13 18:49:44 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA17401 for bugs-outgoing; Sat, 13 May 1995 18:49:44 -0700 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 SAA17395 for ; Sat, 13 May 1995 18:49:41 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id SAA01103; Sat, 13 May 1995 18:48:47 -0700 From: "Rodney W. Grimes" Message-Id: <199505140148.SAA01103@gndrsh.aac.dev.com> Subject: Re: bin/402: w -n doesnt work as advertised. To: henrich@crh.cl.msu.edu (Charles Henrich) Date: Sat, 13 May 1995 18:48:47 -0700 (PDT) Cc: davidg@Root.COM, henrich@crh.cl.msu.edu, freebsd-bugs@freefall.cdrom.com In-Reply-To: <199505132230.PAA14104@freefall.cdrom.com> from "Charles Henrich" at May 13, 95 06:30:25 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1425 Sender: bugs-owner@FreeBSD.org Precedence: bulk > > > > I modified w.c to attempt to figure out the ip address of the hosts > > > that were non-IP. Because some folks might need an option to make w > > > not do any resolver lookups, I also added -l which mirrors the > > > the existing -n flag, and ensures no nameserver calls get executed. > > > > Actually, I strongly dislike the 4.4 "w" doing nameserver lookups by > > default. On any reasonable system that has > 20 users on it, it can take > > anywhere from several seconds to several minutes for the w output to finish. > > In my opinion, the default for w should be reverted back to the old behavior > > of trusting what is in wtmp. > > Must be a slow nameserver? Most local nameervers will cache all retrieved data > for an hour to a day, given that the responses should 80% of the time come from > your local nameserver. I never have any problems with the lookups, w never > takes even a second to run. Try it on a box that has people coming in from behind firewalls, on freefall we have several users whos DNS reverse lookup is hidden by one thing or another and doing a ``w'' on freefall while one of them is logged in is quite painful. For machines that don't have such wide access you won't ever see this problem, but it does exist. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-bugs Sat May 13 18:52:05 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA17420 for bugs-outgoing; Sat, 13 May 1995 18:52:05 -0700 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 SAA17414 for ; Sat, 13 May 1995 18:52:03 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id SAA01112; Sat, 13 May 1995 18:51:10 -0700 From: "Rodney W. Grimes" Message-Id: <199505140151.SAA01112@gndrsh.aac.dev.com> Subject: Re: bin/402: w -n doesnt work as advertised. To: henrich@crh.cl.msu.edu (Charles Henrich) Date: Sat, 13 May 1995 18:51:09 -0700 (PDT) Cc: davidg@Root.COM, henrich@crh.cl.msu.edu, freebsd-bugs@freefall.cdrom.com In-Reply-To: <199505132239.PAA14255@freefall.cdrom.com> from "Charles Henrich" at May 13, 95 06:38:55 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1358 Sender: bugs-owner@FreeBSD.org Precedence: bulk > > > This works if the nameserver for all the domains is currently reachable. If > >it isn't, it can take a minute for the query to timeout. About half the time I > >do a 'w' on freefall, it takes > 1 minute to complete because of this. In > >other cases, it's often that nameservers are slow to respond - 2 seconds isn't > >unusual for non-cached entries. If this happens with just a few of the users, > >the delay can approach 5-10 seconds. The problem grows as the number of users > >increases. It's extremely annoying. > > Thats true, but if the user has logged in, they have caused their entry to be > cached at the local nameserver, so you should very rarely be going offsite to > get the data.. Unless something is broken in the local nameserver. ^^^^^ More often than not, it is broken in the remote nameserver, so that even the login takes a long time as it too does the lookup. Also, again, folks who sit behind certain firewalls don't ever have a reverse lookup (something, IMHO that should be outlawed requireing at least some kind of outside DNS server exists to return fictitious names, ie 2 views of the world DNS firewalling). -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-bugs Sat May 13 19:00:03 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id TAA17548 for bugs-outgoing; Sat, 13 May 1995 19:00:03 -0700 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id TAA17538 ; Sat, 13 May 1995 19:00:03 -0700 Date: Sat, 13 May 1995 19:00:03 -0700 Message-Id: <199505140200.TAA17538@freefall.cdrom.com> From: Heikki Suonsivu Reply-To: Heikki Suonsivu To: freebsd-bugs Subject: misc/403: FreeBSD 1-compiled tcsh, bash and zsh binaries dump on vt102 In-Reply-To: Your message of Sun, 14 May 1995 04:59:13 +0300 <199505140159.EAA27295@katiska.clinet.fi> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 403 >Category: misc >Synopsis: FreeBSD 1-compiled tcsh, bash and zsh binaries dump on vt102 >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 May 13 19:00:02 1995 >Originator: Heikki Suonsivu >Organization: Helsinki University of Technology, Finland >Release: FreeBSD 2.0-BUILT-19950507 i386 >Environment: FreeBSD current (at most a week old), bash, zsh and tcsh binaries from older FreeBSD 1.1.5.1 system, but they may be from 1.1 ages. >Description: bash, zsh and tcsh print "Termcap entry too long" when setting terminal type to vt102 (or larger like vt220). I don't know when this changed and why, I recompiled the shells on FreeBSD 2 and they work now. >How-To-Repeat: I guess this happens if you take binary from FreeBSD 1 and try to run on it FreeBSD 2 with compatibility shlibs installed. >Fix: Recompile the stuff. I guess this isn't dangerous, just wondering what has changed and will it affect other programs too (none noticed yet)? >Audit-Trail: >Unformatted: From owner-freebsd-bugs Sat May 13 19:28:56 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id TAA18705 for bugs-outgoing; Sat, 13 May 1995 19:28:56 -0700 Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id TAA18662 for ; Sat, 13 May 1995 19:28:50 -0700 Message-Id: <199505140228.TAA18662@freefall.cdrom.com> Received: by crh.cl.msu.edu (1.38.193.4/16.2) id AA04814; Sat, 13 May 1995 22:28:32 -0400 From: Charles Henrich Subject: Re: bin/402: w -n doesnt work as advertised. To: rgrimes@gndrsh.aac.dev.com (Rodney W. Grimes) Date: Sat, 13 May 1995 22:28:32 -0400 (EDT) Cc: henrich@crh.cl.msu.edu, davidg@Root.COM, freebsd-bugs@freefall.cdrom.com In-Reply-To: <199505140151.SAA01112@gndrsh.aac.dev.com> from "Rodney W. Grimes" at May 13, 95 06:51:09 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 438 Sender: bugs-owner@FreeBSD.org Precedence: bulk Here is a semi-related question, if I peruse my login logs (last) on one of our servers (with lots of non-msu users) the vast majority of entries are listed as numeric IP's, however w will properly return a name on nearly all of them. Does the freebsd login have a very fast dns timeout or some such? -Crh Charles Henrich Michigan State University henrich@crh.cl.msu.edu http://rs560.msu.edu/~henrich/ From owner-freebsd-bugs Sat May 13 19:30:58 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id TAA19046 for bugs-outgoing; Sat, 13 May 1995 19:30:58 -0700 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 TAA19032 for ; Sat, 13 May 1995 19:30:49 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA04228; Sat, 13 May 95 20:23:52 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9505140223.AA04228@cs.weber.edu> Subject: Re: bin/396: telnetd problems fix. To: rgrimes@gndrsh.aac.dev.com (Rodney W. Grimes) Date: Sat, 13 May 95 20:23:51 MDT Cc: henrich@crh.cl.msu.edu, freebsd-bugs@FreeBSD.org In-Reply-To: <199505140147.SAA01094@gndrsh.aac.dev.com> from "Rodney W. Grimes" at May 13, 95 06:47:09 pm X-Mailer: ELM [version 2.4dev PL52] Sender: bugs-owner@FreeBSD.org Precedence: bulk > I disagree, and we have been down this road at least 4 times in the > last 2 years with FreeBSD. The bug is not in the FreeBSD code, it should > not be bandaided to work with code that gets option negotiation wrong. > > I don't like to fix bugs in other software by making FreeBSD slower at > *anything*. Go get NCSA and FTP software to fix there very ancient > and broken code, they have had 2 years to do this, and still have not. Change the offer/accept order in BSD so it does not appear to be a 4.2 system to this software (without impacting the actual algorithm for doing the negotiation) and the problem will disappear. The option ordering is commutative as far as BSD is concerned, but associative as far as the malfunctioning clients are concerned. It costs nothing and fixes many things to commute the BSD order to change the clients opinion of the association. Other than that, you're right: we've been down the road before and it doesn't need a big rehash. All the opinions "A is broken; fix A", "B is broken, fix B", and "A is broken, fix B" have been restated. 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 May 13 19:31:17 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id TAA19095 for bugs-outgoing; Sat, 13 May 1995 19:31:17 -0700 Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id TAA19077 for ; Sat, 13 May 1995 19:31:08 -0700 Message-Id: <199505140231.TAA19077@freefall.cdrom.com> Received: by crh.cl.msu.edu (1.38.193.4/16.2) id AA04939; Sat, 13 May 1995 22:31:00 -0400 From: Charles Henrich Subject: Re: bin/396: telnetd problems fix. To: rgrimes@gndrsh.aac.dev.com (Rodney W. Grimes) Date: Sat, 13 May 1995 22:31:00 -0400 (EDT) Cc: henrich@crh.cl.msu.edu, freebsd-bugs@FreeBSD.org In-Reply-To: <199505140147.SAA01094@gndrsh.aac.dev.com> from "Rodney W. Grimes" at May 13, 95 06:47:09 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1374 Sender: bugs-owner@FreeBSD.org Precedence: bulk > >This is fixable by disabling -DLINEMODE for telnetd, this also seems to make > >things feel more responsive. While it was pointed out that this will make > >slower links (ppp) work slower, most folks using ppp are going to be doing s > >with software that could be breaking on this, making the system unusable. I > >would strongly suggest we disable -DLINEMODE as the default for the system. > >Working slow is better than not working fast. We should do this for 2.0.5. > > I disagree, and we have been down this road at least 4 times in the > last 2 years with FreeBSD. The bug is not in the FreeBSD code, it should > not be bandaided to work with code that gets option negotiation wrong. > > I don't like to fix bugs in other software by making FreeBSD slower at > *anything*. Go get NCSA and FTP software to fix there very ancient > and broken code, they have had 2 years to do this, and still have not. The problem is when users have to interact with FreeBSD boxes they bitch that FreeBSD is broken, "afterall it works with Linnnuxxx". This is not good. Has anyone actually done any real tests to see if its lots faster? I work on ppp quite frequently and my system doesnt support LINEMODE and it doesnt feel bad at all. -Crh Charles Henrich Michigan State University henrich@crh.cl.msu.edu http://rs560.msu.edu/~henrich/ From owner-freebsd-bugs Sat May 13 19:35:44 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id TAA19853 for bugs-outgoing; Sat, 13 May 1995 19:35:44 -0700 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 TAA19830 for ; Sat, 13 May 1995 19:35:38 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id TAA01401; Sat, 13 May 1995 19:34:45 -0700 From: "Rodney W. Grimes" Message-Id: <199505140234.TAA01401@gndrsh.aac.dev.com> Subject: Re: bin/396: telnetd problems fix. To: henrich@crh.cl.msu.edu (Charles Henrich) Date: Sat, 13 May 1995 19:34:45 -0700 (PDT) Cc: henrich@crh.cl.msu.edu, freebsd-bugs@FreeBSD.org In-Reply-To: <199505140230.TAA01363@gndrsh.aac.dev.com> from "Charles Henrich" at May 13, 95 10:31:00 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1702 Sender: bugs-owner@FreeBSD.org Precedence: bulk > > > >This is fixable by disabling -DLINEMODE for telnetd, this also seems to make > > >things feel more responsive. While it was pointed out that this will make > > >slower links (ppp) work slower, most folks using ppp are going to be doing s > > >with software that could be breaking on this, making the system unusable. I > > >would strongly suggest we disable -DLINEMODE as the default for the system. > > >Working slow is better than not working fast. We should do this for 2.0.5. > > > > I disagree, and we have been down this road at least 4 times in the > > last 2 years with FreeBSD. The bug is not in the FreeBSD code, it should > > not be bandaided to work with code that gets option negotiation wrong. > > > > I don't like to fix bugs in other software by making FreeBSD slower at > > *anything*. Go get NCSA and FTP software to fix there very ancient > > and broken code, they have had 2 years to do this, and still have not. > > The problem is when users have to interact with FreeBSD boxes they bitch that > FreeBSD is broken, "afterall it works with Linnnuxxx". This is not good. Has > anyone actually done any real tests to see if its lots faster? I work on ppp > quite frequently and my system doesnt support LINEMODE and it doesnt feel bad > at all. Could you go do just the change that Terry Lambert suggested, test it out for me and tell me if it fixes the problem. If it does we can send it out for wide code review and commit it! No loss of LINEMODE, and no more problem from broken 4.2BSD detection clients. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-bugs Sat May 13 19:37:32 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id TAA19999 for bugs-outgoing; Sat, 13 May 1995 19:37:32 -0700 Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id TAA19981 for ; Sat, 13 May 1995 19:37:28 -0700 Message-Id: <199505140237.TAA19981@freefall.cdrom.com> Received: by crh.cl.msu.edu (1.38.193.4/16.2) id AA05236; Sat, 13 May 1995 22:37:19 -0400 From: Charles Henrich Subject: Re: bin/396: telnetd problems fix. To: rgrimes@gndrsh.aac.dev.com (Rodney W. Grimes) Date: Sat, 13 May 1995 22:37:19 -0400 (EDT) Cc: henrich@crh.cl.msu.edu, freebsd-bugs@FreeBSD.org In-Reply-To: <199505140234.TAA01401@gndrsh.aac.dev.com> from "Rodney W. Grimes" at May 13, 95 07:34:45 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 492 Sender: bugs-owner@FreeBSD.org Precedence: bulk > Could you go do just the change that Terry Lambert suggested, test it out > for me and tell me if it fixes the problem. If it does we can send it out > for wide code review and commit it! No loss of LINEMODE, and no more > problem from broken 4.2BSD detection clients. I'll do that tommorow, Im at home and dont have access to any broken software ;) -Crh Charles Henrich Michigan State University henrich@crh.cl.msu.edu http://rs560.msu.edu/~henrich/ From owner-freebsd-bugs Sat May 13 22:26:59 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA23852 for bugs-outgoing; Sat, 13 May 1995 22:26:59 -0700 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 WAA23846 for ; Sat, 13 May 1995 22:26:52 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id PAA15514; Sun, 14 May 1995 15:25:12 +1000 Date: Sun, 14 May 1995 15:25:12 +1000 From: Bruce Evans Message-Id: <199505140525.PAA15514@godzilla.zeta.org.au> To: freebsd-bugs@FreeBSD.org, henrich@crh.cl.msu.edu Subject: Re: login.c environ=envinit ? Sender: bugs-owner@FreeBSD.org Precedence: bulk >Im looking at login.c ~line 400 where we reset the user environment if the p >flag is passed, and we do this but just re-assigning the environment global. >Shouldnt we free the environment memory before doing that? Only if the environment memory was malloced. But there is no way for login to know. Only setenv() knows. Perhaps unsetenv((char *)0) should be a standard way of unsetting everything. unsetenv() currently doesn't even know if setenv() called malloc and doesn't free anything. Bruce