From owner-freebsd-bugs Sun Oct 22 13:06:49 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA04996 for bugs-outgoing; Sun, 22 Oct 1995 13:06:49 -0700 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA04991 for ; Sun, 22 Oct 1995 13:06:38 -0700 Received: from grumble.grondar.za (grumble.grondar.za [196.7.18.130]) by grunt.grondar.za (8.6.12/8.6.9) with ESMTP id WAA03260 for ; Sun, 22 Oct 1995 22:06:20 +0200 Received: from localhost (localhost [127.0.0.1]) by grumble.grondar.za (8.6.12/8.6.9) with SMTP id WAA02899 for ; Sun, 22 Oct 1995 22:06:20 +0200 Message-Id: <199510222006.WAA02899@grumble.grondar.za> X-Authentication-Warning: grumble.grondar.za: Host localhost didn't use HELO protocol To: bugs@freebsd.org Subject: swap-pager: out of space? Date: Sun, 22 Oct 1995 22:06:19 +0200 From: Mark Murray Sender: owner-bugs@freebsd.org Precedence: bulk Anyone else seing this? It happens when I load the system - eg a make world and a ghostscript print job... Oct 22 11:01:23 grumble /kernel: swap_pager: out of space Oct 22 11:01:29 grumble /kernel: swap_pager: out of space Oct 22 11:01:29 grumble /kernel: pid 4795: as: uid 0: exited on signal 6 Oct 22 11:01:30 grumble /kernel: pid 4797: hostname: uid 100: exited on signal 6 Oct 22 11:01:49 grumble /kernel: swap_pager: out of space Oct 22 11:01:50 grumble /kernel: pid 4809: cat: uid 100: exited on signal 6 Oct 22 11:01:53 grumble /kernel: pid 4811: hostname: uid 100: exited on signal 6 Oct 22 11:01:57 grumble /kernel: swap_pager: out of space Oct 22 11:01:59 grumble /kernel: pid 4820: ls: uid 100: exited on signal 6 Oct 22 11:01:59 grumble /kernel: pid 4822: hostname: uid 100: exited on signal 6 Oct 22 11:02:15 grumble /kernel: swap_pager: out of space Oct 22 11:02:23 grumble /kernel: swap_pager: out of space Oct 22 11:02:26 grumble /kernel: pid 4829: hostname: uid 100: exited on signal 6 Oct 22 11:02:39 grumble /kernel: swap_pager: out of space Oct 22 11:02:40 grumble /kernel: pid 4837: hostname: uid 100: exited on signal 6 Oct 22 11:02:41 grumble /kernel: pid 4834: sh: uid 1: exited on signal 6 M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grumble.grondar.za for PGP key From owner-freebsd-bugs Sun Oct 22 14:05:25 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA07310 for bugs-outgoing; Sun, 22 Oct 1995 14:05:25 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA07300 for ; Sun, 22 Oct 1995 14:05:18 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id WAA10320; Sun, 22 Oct 1995 22:05:11 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id WAA00211; Sun, 22 Oct 1995 22:05:11 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id WAA07894; Sun, 22 Oct 1995 22:03:27 +0100 From: J Wunsch Message-Id: <199510222103.WAA07894@uriah.heep.sax.de> Subject: Re: swap-pager: out of space? To: mark@grondar.za (Mark Murray) Date: Sun, 22 Oct 1995 22:03:26 +0100 (MET) Cc: bugs@freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199510222006.WAA02899@grumble.grondar.za> from "Mark Murray" at Oct 22, 95 10:06:19 pm 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: 470 Sender: owner-bugs@freebsd.org Precedence: bulk As Mark Murray wrote: > > Anyone else seing this? It happens when I load the system - eg > a make world and a ghostscript print job... > > Oct 22 11:01:23 grumble /kernel: swap_pager: out of space > Oct 22 11:01:29 grumble /kernel: swap_pager: out of space Looks like you've been swamping your swap area. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-bugs Sun Oct 22 14:20:38 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA07701 for bugs-outgoing; Sun, 22 Oct 1995 14:20:38 -0700 Received: from mail.cs.tu-berlin.de (root@mail.cs.tu-berlin.de [130.149.17.13]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA07689 for ; Sun, 22 Oct 1995 14:20:24 -0700 Received: from caramba.cs.tu-berlin.de (wosch@caramba.cs.tu-berlin.de [130.149.17.12]) by mail.cs.tu-berlin.de (8.6.12/8.6.12) with ESMTP id WAA13322 for ; Sun, 22 Oct 1995 22:06:23 +0100 From: Wolfram Schneider Received: (wosch@localhost) by caramba.cs.tu-berlin.de (8.6.12/8.6.9) id WAA21621; Sun, 22 Oct 1995 22:06:19 +0100 Date: Sun, 22 Oct 1995 22:06:19 +0100 Message-Id: <199510222106.WAA21621@caramba.cs.tu-berlin.de> To: bugs@freebsd.org Subject: Manpage Makefile patches MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-bugs@freebsd.org Precedence: bulk --- src/gnu/usr.bin/awk/Makefile Mon Jan 16 22:02:00 1995 +++ src/gnu/usr.bin/awk/Makefile.new Sun Oct 22 18:41:25 1995 @@ -10,5 +10,6 @@ DPADD+= ${LIBGNUREGEX} ${LIBM} LDADD+= -lgnuregex -lm +MLINKS+=awk gawk .include #.include "../../usr.bin/Makefile.inc" --- src/gnu/usr.bin/cc/cc/Makefile Tue Dec 27 02:02:00 1994 +++ src/gnu/usr.bin/cc/cc/Makefile.new Sun Oct 22 19:08:08 1995 @@ -8,6 +8,6 @@ .PATH: ${.CURDIR}/../cc_int SRCS+= obstack.c version.c LINKS= ${BINDIR}/cc ${BINDIR}/gcc -MLINKS= cc.1 gcc.1 +MLINKS= cc.1 gcc.1 cc.1 g++.1 .include --- src/usr.bin/lex/Makefile Sat Aug 27 02:00:00 1994 +++ src/usr.bin/lex/Makefile.new Sun Oct 22 19:07:11 1995 @@ -20,6 +20,7 @@ LFLAGS+= -is CFLAGS+= -I. -I${.CURDIR} MAN1= lex.1 lexdoc.1 +MLINKS= lex.1 flex.1 lexdoc.1 flexdoc.1 CLEANFILES+= parse.c parse.h scan.c y.tab.h y.tab.c --- src/usr.bin/vi/common/Makefile Sun Sep 11 02:00:00 1994 +++ src/usr.bin/vi/common/Makefile.new Sun Oct 22 19:11:52 1995 @@ -8,6 +8,7 @@ LINKS+= ${BINDIR}/${VI} ${BINDIR}/vi ${BINDIR}/${EX} ${BINDIR}/ex LINKS+= ${BINDIR}/${VI} ${BINDIR}/view MAN1= ${.CURDIR}/../USD.doc/vi.man/vi.1 +MLINKS+=vi.1 ex.1 vi.1 view.1 CFLAGS+=-I. -I${.CURDIR} DPADD+= ${LIBCURSES} ${LIBTERMCAP} ${LIBUTIL} --- src/usr.sbin/pcvt/userkeys/Makefile Sun Feb 5 14:49:00 1995 +++ src/usr.sbin/pcvt/userkeys/Makefile.new Sun Oct 22 19:17:46 1995 @@ -12,6 +12,7 @@ PROG= vt220keys CLEANFILES+= core.vt220keys vt220keys.core +MLINKS+=vt220keys.1 vt220.1 .include --- src/gnu/usr.bin/gzip/Makefile Tue Jul 25 05:08:00 1995 +++ src/gnu/usr.bin/gzip/Makefile.new Sun Oct 22 19:21:08 1995 @@ -9,7 +9,11 @@ LINKS+= ${BINDIR}/gzip ${BINDIR}/gunzip LINKS+= ${BINDIR}/gzip ${BINDIR}/gzcat LINKS+= ${BINDIR}/gzip ${BINDIR}/zcat + +LINKS+= ${BINDIR}/zgrep ${BINDIR}/zegrep +LINKS+= ${BINDIR}/zgrep ${BINDIR}/zfgrep NOSHARED=yes +MLINKS+=zdiff.1 zcmp.1 afterinstall: ${INSTALL} -c -o ${BINOWN} -g ${BINGRP} -m ${BINMODE} \ --- src/lib/libm/Makefile Fri Aug 5 02:00:00 1994 +++ src/lib/libm/Makefile.new Sun Oct 22 21:54:44 1995 @@ -138,13 +138,36 @@ common_source/rint.3 common_source/sin.3 common_source/sinh.3 \ common_source/sqrt.3 common_source/tan.3 common_source/tanh.3 -MLINKS+=erf.3 erfc.3 -MLINKS+=exp.3 expm1.3 exp.3 log.3 exp.3 log10.3 exp.3 log1p.3 exp.3 pow.3 -MLINKS+=hypot.3 cabs.3 +MLINKS+=ceil.3 ceilf.3 +MLINKS+=sqrt.3 sqrtf.3 sqrt.3 cbrt.3 sqrt.3 cbrt.3 +MLINKS+=erf.3 erfc.3 erf.3 erff.3 erf.3 erfcf.3 +MLINKS+=exp.3 expm1.3 exp.3 log.3 exp.3 log10.3 exp.3 log1p.3 exp.3 pow.3 \ + exp.3 expf.3 exp.3 exp2.3 exp.3 exp2f.3 exp.3 exp10.3 exp.3 exp10f.3 \ + exp.3 expm1f.3 exp.3 logf.3 exp.3 log2.3 exp.3 log2f.3 \ + exp.3 log10f.3 exp.3 log1pf.3 exp.3 powf.3 +MLINKS+=fabs.3 fabsf.3 +MLINKS+=floor.3 floorf.3 +MLINKS+=fmod.3 fmodf.3 +MLINKS+=hypot.3 cabs.3 hypot.3 hypotf.3 hypot.3 cabsf.3 MLINKS+=ieee.3 copysign.3 ieee.3 drem.3 ieee.3 finite.3 ieee.3 logb.3 \ - ieee.3 scalb.3 -MLINKS+=j0.3 j1.3 j0.3 jn.3 j0.3 y0.3 j0.3 y1.3 j0.3 yn.3 -MLINKS+=lgamma.3 gamma.3 + ieee.3 scalb.3 ieee.3 copysignf.3 ieee.3 finitef.3 \ + ieee.3 ilogbf.3 ieee.3 nextafterf.3 ieee.3 remainderf.3 \ + ieee.3 scalbnf.3 +MLINKS+=ieee_test.3 scalbf.3 ieee_test.e significandf.3 + +MLINKS+=j0.3 j1.3 j0.3 jn.3 j0.3 y0.3 j0.3 y1.3 j0.3 yn.3 \ + j0.3 j0f.3 j0.3 j1f.3 j0.3 jnf.3 j0.3 y0f.3 j0.3 y1f.3 j0.3 ynf.3 + +MLINKS+=lgamma.3 gamma.3 gamma.3 lgammaf.3 gamma.3 gammaf.3 +MLINKS+=acos.3 acosf.3 +MLINKS+=acosh.3 acoshf.3 +MLINKS+=asin.3 asinf.3 +MLINKS+=asinh.3 asinhf.3 +MLINKS+=atan.3 atanf.3 +MLINKS+=atan2.3 atan2f.3 +MLINKS+=atanh.3 atanhf.3 +MLINKS+=cos.3 cosf.3 + # can't use the standard mkdep, because there are some .s files that # are using '#' as a comment indicator and cpp thinks it's an undefined --- src/share/man/man3/Makefile Sun Oct 15 22:08:00 1995 +++ src/share/man/man3/Makefile.new Sun Oct 22 19:53:42 1995 @@ -16,6 +16,36 @@ MLINKS+=queue.3 circleq_insert_tail.3 queue.3 circleq_remove.3 MLINKS+=stdarg.3 varargs.3 stdarg.3 va_arg.3 stdarg.3 va_end.3 MLINKS+=stdarg.3 va_start.3 +MLINKS+=bitstring.3 bit_alloc.3 +MLINKS+=bitstring.3 bit_clear.3 +MLINKS+=bitstring.3 bit_decl.3 +MLINKS+=bitstring.3 bit_ffs.3 +MLINKS+=bitstring.3 bit_nclear.3 +MLINKS+=bitstring.3 bit_nset.3 +MLINKS+=bitstring.3 bit_set.3 +MLINKS+=bitstring.3 bitstr_size.3 +MLINKS+=bitstring.3 bit_test.3 +MLINKS+=queue.3 LIST_ENTRY.3 +MLINKS+=queue.3 LIST_HEAD.3 +MLINKS+=queue.3 LIST_INIT.3 +MLINKS+=queue.3 LIST_INSERT_AFTER.3 +MLINKS+=queue.3 LIST_INSERT_HEAD.3 +MLINKS+=queue.3 LIST_REMOVE.3 +MLINKS+=queue.3 TAILQ_ENTRY.3 +MLINKS+=queue.3 TAILQ_HEAD.3 +MLINKS+=queue.3 TAILQ_INIT.3 +MLINKS+=queue.3 TAILQ_INSERT_AFTER.3 +MLINKS+=queue.3 TAILQ_INSERT_HEAD.3 +MLINKS+=queue.3 TAILQ_INSERT_TAIL.3 +MLINKS+=queue.3 TAILQ_REMOVE.3 +MLINKS+=queue.3 CIRCLEQ_ENTRY.3 +MLINKS+=queue.3 CIRCLEQ_HEAD.3 +MLINKS+=queue.3 CIRCLEQ_INIT.3 +MLINKS+=queue.3 CIRCLEQ_INSERT_AFTER.3 +MLINKS+=queue.3 CIRCLEQ_INSERT_BEFORE.3 +MLINKS+=queue.3 CIRCLEQ_INSERT_HEAD.3 +MLINKS+=queue.3 CIRCLEQ_INSERT_TAIL.3 +MLINKS+=queue.3 CIRCLEQ_REMOVE.3 clean depend lint tags: --- src/lib/libc/gen/Makefile.inc Tue May 30 12:21:00 1995 +++ src/lib/libc/gen/Makefile.inc.new Sun Oct 22 21:36:14 1995 @@ -58,13 +58,15 @@ MLINKS+=config_open.3 config_next.3 config_open.3 config_close.3 \ config_open.3 config_skip.3 MLINKS+=crypt.3 encrypt.3 crypt.3 setkey.3 +MLINKS+=crypt.3 des_setkey.3 crypt.3 des_cipher.3 MLINKS+=directory.3 closedir.3 directory.3 dirfd.3 directory.3 opendir.3 \ directory.3 readdir.3 directory.3 rewinddir.3 directory.3 seekdir.3 \ directory.3 telldir.3 MLINKS+=exec.3 execl.3 exec.3 execle.3 exec.3 execlp.3 exec.3 execv.3 \ - exec.3 execvp.3 + exec.3 execvp.3 exec.3 exect.3 MLINKS+=err.3 verr.3 err.3 errx.3 err.3 verrx.3 err.3 warn.3 err.3 vwarn.3 \ - err.3 warnx.3 err.3 vwarnx.3 + err.3 warnx.3 err.3 vwarnx.3 err.3 err_set_file.3 \ + err.3 err_set_exit.3 MLINKS+=isinf.3 isnan.3 MLINKS+=getcap.3 cgetcap.3 getcap.3 cgetclose.3 getcap.3 cgetent.3 \ getcap.3 cgetfirst.3 getcap.3 cgetmatch.3 getcap.3 cgetnext.3 \ --- src/lib/libncurses/Makefile Sun Aug 6 17:02:00 1995 +++ src/lib/libncurses/Makefile.new Sun Oct 22 21:28:48 1995 @@ -80,5 +80,290 @@ ncurses.3 MAN5 = term.5 terminfo.5 +MLINKS+=curs_addch.3 addch.3 +MLINKS+=curs_addch.3 waddch.3 +MLINKS+=curs_addch.3 mvaddch.3 +MLINKS+=curs_addch.3 mvwaddch.3 +MLINKS+=curs_addch.3 echochar.3 +MLINKS+=curs_addch.3 wechochar.3 + +MLINKS+=curs_addchstr.3 addchstr.3 +MLINKS+=curs_addchstr.3 addchnstr.3 +MLINKS+=curs_addchstr.3 waddchstr.3 +MLINKS+=curs_addchstr.3 waddchnstr.3 +MLINKS+=curs_addchstr.3 mvaddchstr.3 +MLINKS+=curs_addchstr.3 mvaddchnstr.3 +MLINKS+=curs_addchstr.3 mvwaddchstr.3 +MLINKS+=curs_addchstr.3 mvwaddchnstr.3 + +MLINKS+=curs_addstr.3 addstr.3 +MLINKS+=curs_addstr.3 addnstr.3 +MLINKS+=curs_addstr.3 waddstr.3 +MLINKS+=curs_addstr.3 waddnstr.3 +MLINKS+=curs_addstr.3 mvaddstr.3 +MLINKS+=curs_addstr.3 mvaddnstr.3 +MLINKS+=curs_addstr.3 mvwaddstr.3 +MLINKS+=curs_addstr.3 mvwaddnstr.3 + +MLINKS+=curs_attr.3 attroff.3 +MLINKS+=curs_attr.3 wattroff.3 +MLINKS+=curs_attr.3 attron.3 +MLINKS+=curs_attr.3 wattron.3 +MLINKS+=curs_attr.3 attrset.3 +MLINKS+=curs_attr.3 wattrset.3 +MLINKS+=curs_attr.3 standend.3 +MLINKS+=curs_attr.3 wstandend.3 +MLINKS+=curs_attr.3 standout.3 +MLINKS+=curs_attr.3 wstandout.3 + +MLINKS+=curs_beep.3 beep.3 +MLINKS+=curs_beep.3 flash.3 + +MLINKS+=curs_bkgd.3 bkgdset.3 +MLINKS+=curs_bkgd.3 wbkgdset.3 +MLINKS+=curs_bkgd.3 bkgd.3 +MLINKS+=curs_bkgd.3 wbkgd.3 + +MLINKS+=curs_border.3 border.3 +MLINKS+=curs_border.3 wborder.3 +MLINKS+=curs_border.3 box.3 +MLINKS+=curs_border.3 hline.3 +MLINKS+=curs_border.3 whline.3 +MLINKS+=curs_border.3 vline.3 +MLINKS+=curs_border.3 wvline.3 + +MLINKS+=curs_clear.3 erase.3 +MLINKS+=curs_clear.3 werase.3 +MLINKS+=curs_clear.3 clear.3 +MLINKS+=curs_clear.3 wclear.3 +MLINKS+=curs_clear.3 clrtobot.3 +MLINKS+=curs_clear.3 wclrtobot.3 +MLINKS+=curs_clear.3 clrtoeol.3 +MLINKS+=curs_clear.3 wclrtoeol.3 + +MLINKS+=curs_color.3 start_color.3 +MLINKS+=curs_color.3 init_pair.3 +MLINKS+=curs_color.3 init_color.3 +MLINKS+=curs_color.3 has_colors.3 +MLINKS+=curs_color.3 can_change_color.3 +MLINKS+=curs_color.3 color_content.3 +MLINKS+=curs_color.3 pair_content.3 + +MLINKS+=curs_delch.3 delch.3 +MLINKS+=curs_delch.3 wdelch.3 +MLINKS+=curs_delch.3 mvdelch.3 +MLINKS+=curs_delch.3 mvwdelch.3 + +MLINKS+=curs_deleteln.3 deleteln.3 +MLINKS+=curs_deleteln.3 wdeleteln.3 +MLINKS+=curs_deleteln.3 insdelln.3 +MLINKS+=curs_deleteln.3 winsdelln.3 +MLINKS+=curs_deleteln.3 insertln.3 +MLINKS+=curs_deleteln.3 winsertln.3 + +MLINKS+=curs_getch.3 getch.3 +MLINKS+=curs_getch.3 wgetch.3 +MLINKS+=curs_getch.3 mvgetch.3 +MLINKS+=curs_getch.3 mvwgetch.3 +MLINKS+=curs_getch.3 ungetch.3 + +MLINKS+=curs_getstr.3 getstr.3 +MLINKS+=curs_getstr.3 wgetstr.3 +MLINKS+=curs_getstr.3 mvgetstr.3 +MLINKS+=curs_getstr.3 mvwgetstr.3 +MLINKS+=curs_getstr.3 wgetnstr.3 + +MLINKS+=curs_getyx.3 getyx.3 +MLINKS+=curs_getyx.3 getparyx.3 +MLINKS+=curs_getyx.3 getbegyx.3 +MLINKS+=curs_getyx.3 getmaxyx.3 + +MLINKS+=curs_inch.3 inch.3 +MLINKS+=curs_inch.3 winch.3 +MLINKS+=curs_inch.3 mvinch.3 +MLINKS+=curs_inch.3 mvwinch.3 + +MLINKS+=curs_inchstr.3 inchstr.3 +MLINKS+=curs_inchstr.3 inchnstr.3 +MLINKS+=curs_inchstr.3 winchstr.3 +MLINKS+=curs_inchstr.3 winchnstr.3 +MLINKS+=curs_inchstr.3 mvinchstr.3 +MLINKS+=curs_inchstr.3 mvinchnstr.3 +MLINKS+=curs_inchstr.3 mvwinchstr.3 +MLINKS+=curs_inchstr.3 mvwinchnstr.3 + +MLINKS+=curs_initscr.3 initscr.3 +MLINKS+=curs_initscr.3 newterm.3 +MLINKS+=curs_initscr.3 endwin.3 +MLINKS+=curs_initscr.3 isendwin.3 +MLINKS+=curs_initscr.3 set_term.3 +MLINKS+=curs_initscr.3 delscreen.3 + +MLINKS+=curs_inopts.3 cbreak.3 +MLINKS+=curs_inopts.3 nocbreak.3 +MLINKS+=curs_inopts.3 echo.3 +MLINKS+=curs_inopts.3 noecho.3 +MLINKS+=curs_inopts.3 halfdelay.3 +MLINKS+=curs_inopts.3 intrflush.3 +MLINKS+=curs_inopts.3 keypad.3 +MLINKS+=curs_inopts.3 meta.3 +MLINKS+=curs_inopts.3 nodelay.3 +MLINKS+=curs_inopts.3 notimeout.3 +MLINKS+=curs_inopts.3 raw.3 +MLINKS+=curs_inopts.3 noraw.3 +MLINKS+=curs_inopts.3 noqiflush.3 +MLINKS+=curs_inopts.3 qiflush.3 +MLINKS+=curs_inopts.3 timeout.3 +MLINKS+=curs_inopts.3 wtimeout.3 +MLINKS+=curs_inopts.3 typeahead.3 + +MLINKS+=curs_insch.3 insch.3 +MLINKS+=curs_insch.3 winsch.3 +MLINKS+=curs_insch.3 mvinsch.3 +MLINKS+=curs_insch.3 mvwinsch.3 + +MLINKS+=curs_instr.3 insstr.3 +MLINKS+=curs_instr.3 insnstr.3 +MLINKS+=curs_instr.3 winsstr.3 +MLINKS+=curs_instr.3 winsnstr.3 +MLINKS+=curs_instr.3 mvinsstr.3 +MLINKS+=curs_instr.3 mvinsnstr.3 +MLINKS+=curs_instr.3 mvwinsstr.3 +MLINKS+=curs_instr.3 mvwinsnstr.3 + +MLINKS+=curs_instr.3 instr.3 +MLINKS+=curs_instr.3 innstr.3 +MLINKS+=curs_instr.3 winstr.3 +MLINKS+=curs_instr.3 winnstr.3 +MLINKS+=curs_instr.3 mvinstr.3 +MLINKS+=curs_instr.3 mvinnstr.3 +MLINKS+=curs_instr.3 mvwinstr.3 +MLINKS+=curs_instr.3 mvwinnstr.3 + +MLINKS+=curs_kernel.3 def_prog_mode.3 +MLINKS+=curs_kernel.3 def_shell_mode.3 +MLINKS+=curs_kernel.3 reset_prog_mode.3 +MLINKS+=curs_kernel.3 reset_shell_mode.3 +MLINKS+=curs_kernel.3 resetty.3 savetty.3 +MLINKS+=curs_kernel.3 setsyx.3 +MLINKS+=curs_kernel.3 ripoffline.3 +MLINKS+=curs_kernel.3 curs_set.3 +MLINKS+=curs_kernel.3 napms.3 + +MLINKS+=curs_move.3 move.3 +MLINKS+=curs_move.3 wmove + +MLINKS+=curs_outopts.3 clearok.3 +MLINKS+=curs_outopts.3 idlok.3 +MLINKS+=curs_outopts.3 idcok.3 +MLINKS+=curs_outopts.3 immedok.3 +MLINKS+=curs_outopts.3 leaveok.3 +MLINKS+=curs_outopts.3 setscrreg.3 +MLINKS+=curs_outopts.3 wsetscrreg.3 +MLINKS+=curs_outopts.3 scrollok.3 +MLINKS+=curs_outopts.3 nl.3 +MLINKS+=curs_outopts.3 nonl.3 + +MLINKS+=curs_overlay.3 overlay.3 +MLINKS+=curs_overlay.3 overwrite.3 +MLINKS+=curs_overlay.3 copywin.3 + +MLINKS+=curs_pad.3 newpad.3 +MLINKS+=curs_pad.3 subpad.3 +MLINKS+=curs_pad.3 prefresh.3 +MLINKS+=curs_pad.3 pnoutrefresh.3 +MLINKS+=curs_pad.3 pechochar.3 + +MLINKS+=curs_printw.3 printw.3 +MLINKS+=curs_printw.3 wprintw.3 +MLINKS+=curs_printw.3 mvprintw.3 +MLINKS+=curs_printw.3 mvwprintw.3 +MLINKS+=curs_printw.3 vwprintw.3 + +MLINKS+=curs_refresh.3 refresh.3 +MLINKS+=curs_refresh.3 wrefresh.3 +MLINKS+=curs_refresh.3 wnoutrefresh.3 +MLINKS+=curs_refresh.3 doupdate.3 +MLINKS+=curs_refresh.3 redrawwin.3 +MLINKS+=curs_refresh.3 wredrawln.3 + +MLINKS+=curs_scanw.3 scanw.3 +MLINKS+=curs_scanw.3 wscanw.3 +MLINKS+=curs_scanw.3 mvscanw.3 +MLINKS+=curs_scanw.3 mvwscanw.3 +MLINKS+=curs_scanw.3 vwscanw.3 + +MLINKS+=curs_scr_dump.3 scr_dump.3 +MLINKS+=curs_scr_dump.3 scr_restore.3 +MLINKS+=curs_scr_dump.3 scr_init.3 +MLINKS+=curs_scr_dump.3 scr_set.3 + +MLINKS+=curs_scroll.3 scroll.3 +MLINKS+=curs_scroll.3 srcl.3 +MLINKS+=curs_scroll.3 wscrl.3 + +MLINKS+=curs_slk.3 slk_init.3 +MLINKS+=curs_slk.3 slk_set.3 +MLINKS+=curs_slk.3 slk_refresh.3 +MLINKS+=curs_slk.3 slk_noutrefresh.3 +MLINKS+=curs_slk.3 slk_label.3 +MLINKS+=curs_slk.3 slk_clear.3 +MLINKS+=curs_slk.3 slk_restore.3 +MLINKS+=curs_slk.3 slk_touch.3 +MLINKS+=curs_slk.3 slk_attron.3 +MLINKS+=curs_slk.3 slk_attrset.3 +MLINKS+=curs_slk.3 slk_attroff.3 + +MLINKS+=curs_termattrs.3 baudrate.3 +MLINKS+=curs_termattrs.3 erasechar.3 +MLINKS+=curs_termattrs.3 has_ic.3 +MLINKS+=curs_termattrs.3 has_il.3 +MLINKS+=curs_termattrs.3 killchar.3 +MLINKS+=curs_termattrs.3 longname.3 +MLINKS+=curs_termattrs.3 termattrs.3 +MLINKS+=curs_termattrs.3 termname.3 + +MLINKS+=curs_terminfo.3 setupterm.3 +MLINKS+=curs_terminfo.3 setterm.3 +MLINKS+=curs_terminfo.3 set_curterm.3 +MLINKS+=curs_terminfo.3 del_curterm.3 +MLINKS+=curs_terminfo.3 restartterm.3 +MLINKS+=curs_terminfo.3 tparm.3 +MLINKS+=curs_terminfo.3 tputs.3 +MLINKS+=curs_terminfo.3 putp.3 +MLINKS+=curs_terminfo.3 vidputs.3 +MLINKS+=curs_terminfo.3 vidattr.3 +MLINKS+=curs_terminfo.3 mvcur.3 +MLINKS+=curs_terminfo.3 tigetflag.3 +MLINKS+=curs_terminfo.3 tigetnum.3 +MLINKS+=curs_terminfo.3 tigetstr.3 + +MLINKS+=curs_touch.3 touchwin.3 +MLINKS+=curs_touch.3 touchline.3 +MLINKS+=curs_touch.3 untouchwin.3 +MLINKS+=curs_touch.3 wtouchln.3 +MLINKS+=curs_touch.3 is_linetouched.3 +MLINKS+=curs_touch.3 is_wintouched.3 + +MLINKS+=curs_util.3 unctrl.3 +MLINKS+=curs_util.3 keyname.3 +MLINKS+=curs_util.3 filter.3 +MLINKS+=curs_util.3 use_env.3 +MLINKS+=curs_util.3 putwin.3 +MLINKS+=curs_util.3 getwin.3 +MLINKS+=curs_util.3 delay_output.3 +MLINKS+=curs_util.3 flushinp.3 + +MLINKS+= curs_window.3 newwin.3 +MLINKS+= curs_window.3 delwin.3 +MLINKS+= curs_window.3 mvwin.3 +MLINKS+= curs_window.3 subwin.3 +MLINKS+= curs_window.3 derwin.3 +MLINKS+= curs_window.3 mvderwin.3 +MLINKS+= curs_window.3 dupwin.3 +MLINKS+= curs_window.3 wsyncup.3 +MLINKS+= curs_window.3 syncok.3 +MLINKS+= curs_window.3 wcursyncup.3 +MLINKS+= curs_window.3 wsyncdown.3 .include --- src/lib/libc/rpc/Makefile.inc Tue May 30 12:34:00 1995 +++ src/lib/libc/rpc/Makefile.inc.new Sun Oct 22 21:43:55 1995 @@ -20,4 +20,5 @@ MAN3+= rpc/bindresvport.3 rpc/getrpcent.3 rpc/getrpcport.3 rpc/rpc.3 MAN5+= rpc/rpc.5 MAN8+= rpc/rstat_svc.8 +MLINKS+=getrpcent.3 getrpcbyname.3 getrpcent.3 getrpcbynumber.3 --- src/usr.sbin/pcvt/keycap/Makefile Tue Jul 25 05:23:00 1995 +++ src/usr.sbin/pcvt/keycap/Makefile.new Sun Oct 22 21:50:03 1995 @@ -18,6 +18,9 @@ SRCS = keycap.c MAN3 = keycap.${MAN3EXT} MAN5 = man5/keycap.${MAN5EXT} +MLINKS+= keycap.3 kgetent.3 keycap.3 kgetnum.3 keycap.3 kgetflag.3 \ + keycap.3 kgetstr.3 + #CLEANFILES+= keycap.0 man5/keycap.0 beforeinstall: --- src/lib/libc/net/Makefile.inc Mon Aug 21 23:06:00 1995 +++ src/lib/libc/net/Makefile.inc.new Sun Oct 22 21:52:53 1995 @@ -35,7 +35,7 @@ MLINKS+=inet.3 addr.3 inet.3 inet_addr.3 inet.3 inet_lnaof.3 \ inet.3 inet_makeaddr.3 inet.3 inet_netof.3 inet.3 inet_network.3 \ inet.3 inet_ntoa.3 inet.3 network.3 inet.3 ntoa.3 inet.3 inet_aton.3 -MLINKS+=linkaddr.3 linkntoa.3 +MLINKS+=linkaddr.3 link_ntoa.3 linkaddr.3 link_addr.3 linkaddr.3 linkntoa.3 MLINKS+=ns.3 ns_addr.3 ns.3 ns_ntoa.3 MLINKS+=rcmd.3 rresvport.3 rcmd.3 iruserok.3 rcmd.3 ruserok.3 MLINKS+=resolver.3 dn_comp.3 resolver.3 dn_expand.3 resolver.3 res_init.3 \ From owner-freebsd-bugs Sun Oct 22 23:34:00 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA24006 for bugs-outgoing; Sun, 22 Oct 1995 23:34:00 -0700 Received: from toadflax.cs.ucdavis.edu (toadflax.cs.ucdavis.edu [128.120.56.188]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id XAA24001 for ; Sun, 22 Oct 1995 23:33:58 -0700 Received: by toadflax.cs.ucdavis.edu (4.1/UCD.CS.2.6) id AA12132; Sun, 22 Oct 95 23:33:55 PDT From: obrien@cs.ucdavis.edu (David E. O'Brien) Message-Id: <9510230633.AA12132@toadflax.cs.ucdavis.edu> Subject: minor bugs in 2.1 SNAP To: bugs@freeBsd.org Date: Sun, 22 Oct 1995 23:33:54 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 392 Sender: owner-bugs@freeBsd.org Precedence: bulk In FreeBSD 2.1 10/05 SNAP: * /usr/src/lib/libc/string/strspn.3 says "strcspn" in the description section. (strcspn.3 is a seperate man page) * /etc/printcap lists /var/spool/output/lpd as the sample spool directory. It does not exist. /var/spool/lpd does however. (Which is "better" according to the BSD 4.4 directory heirachy thinking?) -- David (obrien@cs.ucdavis.edu) From owner-freebsd-bugs Mon Oct 23 05:20:02 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA04883 for bugs-outgoing; Mon, 23 Oct 1995 05:20:02 -0700 Received: (from gnats@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA04877 ; Mon, 23 Oct 1995 05:20:01 -0700 Resent-Date: Mon, 23 Oct 1995 05:20:01 -0700 Resent-Message-Id: <199510231220.FAA04877@freefall.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@freefall.FreeBSD.org, nops@maths.tcd.ie Received: from salmon.maths.tcd.ie (mmdf@salmon.maths.tcd.ie [134.226.81.11]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id FAA04824 for ; Mon, 23 Oct 1995 05:16:31 -0700 Received: from synge.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id aa18309; 23 Oct 95 13:15 BST Received: (from ajudge@localhost) by synge.maths.tcd.ie (8.6.12/8.6.12) id MAA03126; Mon, 23 Oct 1995 12:15:26 GMT Message-Id: <199510231215.MAA03126@synge.maths.tcd.ie> Date: Mon, 23 Oct 1995 12:15:26 GMT From: Alan Judge Reply-To: nops@maths.tcd.ie To: FreeBSD-gnats-submit@freebsd.org Cc: nops@maths.tcd.ie X-Send-Pr-Version: 3.2 Subject: bin/789: pkg_add broken in 2.1.0-951020? Sender: owner-bugs@freebsd.org Precedence: bulk >Number: 789 >Category: bin >Synopsis: pkg_add doesn't work >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Oct 23 05:20:00 PDT 1995 >Last-Modified: >Originator: Alan Judge >Organization: Department of Maths, Trinity College, Dublin, Ireland >Release: FreeBSD 2.1-STABLE i386 >Environment: P120 with 2.1.0-951020-SNAP installed. Using some of the 2.1-packages. >Description: pkg_add doesn't seem to work properly. Two problems: - If the package is in the current directory, pkg_add can't seem to find it unless you give a full path. - Even given a full path, pkg_add just seems to go through the motions (run's mtree, updates /var/db/pkg) but doesn't actually install any of the package. Example output below. >How-To-Repeat: synge# cd /tmp synge# pkg_add tcpblast-1.0.tgz tar: can't open archive ./tcpblast-1.0.tgz : No such file or directory tar: child returned status 3 tar: +CONTENTS not found in archive Unable to open table of contents file `+CONTENTS' - not a package? synge# pkg_add /tmp/tcpblast-1.0.tgz synge# ls -ls /usr/local/bin synge# synge# pkg_info -Ia tcpblast-1.0 This is the TCPBLAST program. Segmentation fault (core dumped) synge# pkg_delete tcpblast-1.0 File `/usr/local/bin/tcpblast' doesn't really exist. >Fix: You can always install by hand.. A quick look at info would indicate that the core is due to leave_playpen being called even though info doesn't have a playpen. >Audit-Trail: >Unformatted: From owner-freebsd-bugs Mon Oct 23 08:36:16 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA10512 for bugs-outgoing; Mon, 23 Oct 1995 08:36:16 -0700 Received: (from bde@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA10491 ; Mon, 23 Oct 1995 08:36:12 -0700 Date: Mon, 23 Oct 1995 08:36:12 -0700 From: Bruce Evans Message-Id: <199510231536.IAA10491@freefall.freebsd.org> To: kargl@troutmask.apl.washington.edu, bde, freebsd-bugs Subject: Re: docs/776 Sender: owner-bugs@FreeBSD.org Precedence: bulk Synopsis: j0 man page has formatting problem and errors State-Changed-From-To: open-closed State-Changed-By: bde State-Changed-When: Mon Oct 23 08:33:51 PDT 1995 State-Changed-Why: Fixed in revision 1.3 (1995/10/22) of j0.3. From owner-freebsd-bugs Tue Oct 24 16:47:38 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA11975 for bugs-outgoing; Tue, 24 Oct 1995 16:47:38 -0700 Received: from tellab5.lisle.tellabs.com (tellab5.lisle.tellabs.com [138.111.243.28]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id QAA11950 ; Tue, 24 Oct 1995 16:47:30 -0700 From: mikebo@tellabs.com Received: from sunc210.tellabs.com by tellab5.lisle.tellabs.com with smtp (Smail3.1.29.1 #4) id m0t7t3W-000jCJC; Tue, 24 Oct 95 18:46 CDT Received: by sunc210.tellabs.com (SMI-8.6/1.9) id SAA13180; Tue, 24 Oct 1995 18:46:50 -0500 Message-Id: <199510242346.SAA13180@sunc210.tellabs.com> Subject: 2.1.0-951020-SNAP: Major bug in NFS again! To: hackers@freebsd.org Date: Tue, 24 Oct 1995 18:46:50 -0500 (CDT) Cc: bugs@freebsd.org, mikebo (Mike Borowiec) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-bugs@freebsd.org Precedence: bulk Greetings - There is a major bug somewhere in the bowels of RPC or NFS... When the hacks were backed out of /usr/src/lib/libc/rpc/clnt_udp.c a couple months ago, I expected NFS to multi-homed servers to work again - it doesn't! While the NFS mount works OK, subsequent accesses to the filesystem (a "df" for example) lock up the session... The following is Solaris snoop output which shows the problem. TOYBOX is running 2.1.0-951020-SNAP and TELLABK (aka SUNK) is a multi-homed server running SunOS 4.1.3 and "routed -q". First we do the mount: # mount tellabk:/export/home/tellabk-4 /usr/home toybox -> tellabk PORTMAP C GETPORT prog=100003 (NFS) vers=2 proto=UDP sunk -> toybox PORTMAP R GETPORT port=2049 toybox -> tellabk PORTMAP C GETPORT prog=100005 (MOUNT) vers=1 proto=UDP sunk -> toybox PORTMAP R GETPORT port=737 toybox -> tellabk MOUNT C Mount /export/home/tellabk-4 sunk -> toybox MOUNT R Mount OK F=075B Looks like the mount completed OK, even though the replies came from SUNK, TELLABK's alter-ego. So let's do a "df": # df toybox -> tellabk NFS C STATFS FH=075B sunk -> toybox NFS R STATFS OK toybox -> sunk ICMP Destination unreachable (Bad port) toybox -> tellabk NFS C STATFS FH=075B (retransmit) sunk -> toybox NFS R STATFS OK toybox -> sunk ICMP Destination unreachable (Bad port) ... ... ad infinitum ... As you can see, TOYBOX seems to be expecting the STATFS response from TELLABK, not its SUNK alter ego, and complains by sending ICMP Dest Unreachables. At this point, the session is locked up and "df" can never be killed - it is stuck in the kernel. Granted, most users won't be affected by this problem - but for me, this is a show stopper supreme - the single biggest problem I had with 2.0.5R. Because of it, I cannot use automounter at all and any NFS is crippled. I will gladly assist in any way I can to resolve this... work nights, weekends, whatever.... Please don't press this bug into the 2.1 CDs! - Mike -- -------------------------------------------------------------------------- Michael Borowiec - mikebo@tellabs.com - Tellabs Operations Inc. Senior Member of Technical Staff 4951 Indiana Avenue, MS 63 708-512-8211 FAX: 708-512-7099 Lisle, IL 60532 USA -------------------------------------------------------------------------- From owner-freebsd-bugs Tue Oct 24 18:21:49 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA15428 for bugs-outgoing; Tue, 24 Oct 1995 18:21:49 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA15403 ; Tue, 24 Oct 1995 18:21:35 -0700 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id SAA06946; Tue, 24 Oct 1995 18:21:27 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id SAA27638; Tue, 24 Oct 1995 18:17:03 -0700 Message-Id: <199510250117.SAA27638@corbin.Root.COM> To: mikebo@tellabs.com cc: hackers@freebsd.org, bugs@freebsd.org Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! In-reply-to: Your message of "Tue, 24 Oct 95 18:46:50 CDT." <199510242346.SAA13180@sunc210.tellabs.com> From: David Greenman Reply-To: davidg@Root.COM Date: Tue, 24 Oct 1995 18:17:02 -0700 Sender: owner-bugs@freebsd.org Precedence: bulk >The following is Solaris snoop output which shows the problem. TOYBOX >is running 2.1.0-951020-SNAP and TELLABK (aka SUNK) is a multi-homed >server running SunOS 4.1.3 and "routed -q". First we do the mount: > ># mount tellabk:/export/home/tellabk-4 /usr/home > > toybox -> tellabk PORTMAP C GETPORT prog=100003 (NFS) vers=2 proto=UDP > sunk -> toybox PORTMAP R GETPORT port=2049 > toybox -> tellabk PORTMAP C GETPORT prog=100005 (MOUNT) vers=1 proto=UDP > sunk -> toybox PORTMAP R GETPORT port=737 > toybox -> tellabk MOUNT C Mount /export/home/tellabk-4 > sunk -> toybox MOUNT R Mount OK F=075B > >Looks like the mount completed OK, even though the replies came from SUNK, >TELLABK's alter-ego. So let's do a "df": Yeah, that's the problem. This doesn't look like a FreeBSD problem to me - it looks like the Sun is replying out a different interface then it received the mount request from. FreeBSD rightfully thinks this is crap coming from some irrelevant machine. I think you should be able to work around it by using the name/address of "sunk" when doing the mount. -DG From owner-freebsd-bugs Tue Oct 24 18:44:46 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA16898 for bugs-outgoing; Tue, 24 Oct 1995 18:44:46 -0700 Received: from relay1.UU.NET (relay1.UU.NET [192.48.96.5]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA16879 for ; Tue, 24 Oct 1995 18:44:37 -0700 Received: from ast.com by relay1.UU.NET with SMTP id QQzmxi15168; Tue, 24 Oct 1995 21:44:18 -0400 (EDT) Received: from trsvax.fw.ast.com (fw.ast.com) by ast.com with SMTP id AA29294 (5.67b/IDA-1.5 for <@uunet:bugs@freebsd.org>); Tue, 24 Oct 1995 18:45:44 -0700 Received: from nemesis by trsvax.fw.ast.com with uucp (Smail3.1.29.1 #3) id m0t7urd-00007rC; Tue, 24 Oct 95 20:42 CDT Received: by nemesis.lonestar.org (Smail3.1.27.1 #19) id m0t7ul9-000ItkC; Tue, 24 Oct 95 20:36 WET DST Message-Id: Date: Tue, 24 Oct 95 20:36 WET DST To: bugs@freebsd.org From: uhclem%nemesis@fw.ast.com (Frank Durda IV) Sent: Tue Oct 24 1995, 20:36:02 CDT Subject: re: kern/770: Floppy kernel won't boot with T485 or IDT L2 cache FDIV032 Sender: owner-bugs@freebsd.org Precedence: bulk kern/770: Floppy kernel won't boot with T485 or IDT L2 cache FDIV032 If you recall, this was a problem where if you had a 486-based system with a Intel 485 Cache module or a IDT L2 cache module, the boot floppy would not boot unless you physically removed the cache module first. (This is a transparent cache system, and there are no BIOS controls needed to manipulate or disable it.) This problem first appeared in 2.0.5-ALPHA and has been present in all SNAPs and releases since. Until now. For some reason, the 1022-SNAP floppy boots (circa Monday 1400CDT) fine on these systems (I tested three different models today). I also re-verified that 1005 and 2.0.5-R fail on the exact same systems. The only reason I went back to looking at this at all, was that I was installing 2.0.5-R on a system and forgot about the cache module. But instead of hanging like all the other systems did, this system (supposedly the same as two of the machines I was using) got a kernel panic and dumped what might be useful information. So I wanted to run 1022 on it and get the panic info to hopefully narrow down where the problem is. But 1022-Monday-1400CDT (Geez, put a .1 on it or something) boots successfully. So something changed between 1005 and 1022 in the boot.flp department that makes things all better. I hope somebody knows what the change was! :-) I suspect that nobody knows since I haven't seen a notification on this bug indicating that this issue was 'closed' or even 'analyzed'. Oh, I didn't have a 1005 floppy handy, but if a panic display for the 1005 or 2.0.5-R kernel would be useful to somebody, let me know (private mail please). Frank Durda IV |"The Knights who say "LETNi" or uhclem%nemesis@fw.ast.com (Sick 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 Tue Oct 24 19:46:00 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA21997 for bugs-outgoing; Tue, 24 Oct 1995 19:46:00 -0700 Received: from tellab5.lisle.tellabs.com (tellab5.lisle.tellabs.com [138.111.243.28]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id TAA21974 ; Tue, 24 Oct 1995 19:45:51 -0700 From: mikebo@tellabs.com Received: from tellabk.tellabs.com by tellab5.lisle.tellabs.com with smtp (Smail3.1.29.1 #4) id m0t7vqB-000jCNC; Tue, 24 Oct 95 21:45 CDT Received: by tellabk.tellabs.com (4.1/1.9) id AA11614; Tue, 24 Oct 95 21:45:18 CDT Message-Id: <9510250245.AA11614@tellabk.tellabs.com> Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! To: davidg@Root.COM Date: Tue, 24 Oct 1995 21:45:17 -0500 (CDT) Cc: hackers@freebsd.org, bugs@freebsd.org In-Reply-To: <199510250117.SAA27638@corbin.Root.COM> from "David Greenman" at Oct 24, 95 06:17: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: 3577 Sender: owner-bugs@freebsd.org Precedence: bulk David G. wrote: > Mike Borowiec wrote: > >The following is Solaris snoop output which shows the problem. TOYBOX > >is running 2.1.0-951020-SNAP and TELLABK (aka SUNK) is a multi-homed > >server running SunOS 4.1.3 and "routed -q". First we do the mount: > > > ># mount tellabk:/export/home/tellabk-4 /usr/home > > > > toybox -> tellabk PORTMAP C GETPORT prog=100003 (NFS) vers=2 proto=UDP > > sunk -> toybox PORTMAP R GETPORT port=2049 > > toybox -> tellabk PORTMAP C GETPORT prog=100005 (MOUNT) vers=1 proto=UDP > > sunk -> toybox PORTMAP R GETPORT port=737 > > toybox -> tellabk MOUNT C Mount /export/home/tellabk-4 > > sunk -> toybox MOUNT R Mount OK F=075B > > > >Looks like the mount completed OK, even though the replies came from SUNK, > >TELLABK's alter-ego. So let's do a "df": > > Yeah, that's the problem. This doesn't look like a FreeBSD problem to me - > it looks like the Sun is replying out a different interface then it received > the mount request from. FreeBSD rightfully thinks this is crap coming from > some irrelevant machine. I think you should be able to work around it by using > the name/address of "sunk" when doing the mount. > Yes, the Sun is replying from a different interface than it received the mount request from. That's because the Sun is running "routed" and learns its route back to TOYBOX from a RIP announcement made by a router. Using the name/addr of SUNK may work today - what if tomorrow the router decides TELLABK is best, or SUNK2, or SUNK3, etc. "Correct" or not, Suns do not always reply back on the same interface from which they receive a request. It is basically a crap-shoot... Worse, if the router dynamically changes the route back to TOYBOX, for whatever reason (down interface, route optimization), the Sun will dutifully begin replying on a new interface as soon as the RIP announcement is received. This isn't something that can be changed on a Sun. Even configuring a Sun with static routes won't really solve the problem, as someone/sometime is bound to request a mount from an interface which is not the server's default route. In that case, the reply would come from the interface tagged with the default route. The onus is on the client to deal with it... This situation is correctly handled by every commercial UNIX OS I've worked with. I don't know what security implications that has, but I do know that FreeBSD's NFS (and so the whole OS) is useless to me (and others running in a similar environment) unless it works with Suns and plays by their rules. If I can't use the OS, the security doesn't do me a damn bit of good! I can document this behavior in SunOS, Solaris and HP/UX if it will help strengthen the argument. This is the real world behavior, and I'm inclined to believe that FreeBSD is not in a position to dictate what's "proper behaviour" to Sun (the progenitors of RPC and NFS) and the rest of the commerical UNIX market. Sorry for the rambling discourse, but I need this fixed or I can't use FreeBSD. At the least, can the "Sun behavior" I need be added as an option to the mount command? - Mike -- -------------------------------------------------------------------------- Michael Borowiec - mikebo@tellabs.com - Tellabs Operations Inc. Senior Member of Technical Staff 4951 Indiana Avenue, MS 63 708-512-8211 FAX: 708-512-7099 Lisle, IL 60532 USA -------------------------------------------------------------------------- From owner-freebsd-bugs Tue Oct 24 20:43:38 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA24516 for bugs-outgoing; Tue, 24 Oct 1995 20:43:38 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA24493 ; Tue, 24 Oct 1995 20:43:30 -0700 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id UAA07118; Tue, 24 Oct 1995 20:43:29 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id UAA27854; Tue, 24 Oct 1995 20:38:46 -0700 Message-Id: <199510250338.UAA27854@corbin.Root.COM> To: mikebo@tellabs.com cc: hackers@freebsd.org, bugs@freebsd.org Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! In-reply-to: Your message of "Tue, 24 Oct 95 21:45:17 CDT." <9510250245.AA11614@tellabk.tellabs.com> From: David Greenman Reply-To: davidg@Root.COM Date: Tue, 24 Oct 1995 20:38:46 -0700 Sender: owner-bugs@freebsd.org Precedence: bulk >This isn't something that can be changed on a Sun. Even configuring a >Sun with static routes won't really solve the problem, as someone/sometime >is bound to request a mount from an interface which is not the server's >default route. In that case, the reply would come from the interface >tagged with the default route. The onus is on the client to deal with it... The client should ignore NFS packets from hosts that it's not talking to or doesn't know about, and that's what all 4.4BSD derived OSs do. >This situation is correctly handled by every commercial UNIX OS I've >worked with. I don't know what security implications that has, but I >do know that FreeBSD's NFS (and so the whole OS) is useless to me >(and others running in a similar environment) unless it works with >Suns and plays by their rules. If I can't use the OS, the security >doesn't do me a damn bit of good! > >I can document this behavior in SunOS, Solaris and HP/UX if it will >help strengthen the argument. This is the real world behavior, and I'm >inclined to believe that FreeBSD is not in a position to dictate what's >"proper behaviour" to Sun (the progenitors of RPC and NFS) and the rest >of the commerical UNIX market. This is obviously flamebait and I'm not going to respond to it. >Sorry for the rambling discourse, but I need this fixed or I can't >use FreeBSD. At the least, can the "Sun behavior" I need be added >as an option to the mount command? If you choose not to use my suggested work-around, then I guess you can't use FreeBSD. For the NFS server, FreeBSD (and all other 4.4BSD derived systems) keep an authentication list in the kernel that is constructed from /etc/exports. For the NFS client, FreeBSD requires that replies to its RPC requests come from the same address that they were issued to. If it didn't work this way, then *anyone* could send bogus udp datagrams with hand-tailored RPC calls/replies to you and as long as that someone can come up with a file handle (which is relatively easy), he can do unchecked file operations and bypass the system security. Other commercial vendors are running old security- broken versions of NFS and this makes them wide open for security attacks. The best I could offer you would be a kernel option to disable this security, but I'll say right now that this *won't* be in the 2.1 release. -DG From owner-freebsd-bugs Tue Oct 24 20:50:04 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA24815 for bugs-outgoing; Tue, 24 Oct 1995 20:50:04 -0700 Received: (from gnats@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA24808 ; Tue, 24 Oct 1995 20:50:01 -0700 Resent-Date: Tue, 24 Oct 1995 20:50:01 -0700 Resent-Message-Id: <199510250350.UAA24808@freefall.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@freefall.FreeBSD.org, mike@marker.cs.utah.edu Received: from marker.cs.utah.edu (marker.cs.utah.edu [155.99.212.61]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA24542 for ; Tue, 24 Oct 1995 20:44:16 -0700 Received: (from mike@localhost) by marker.cs.utah.edu (8.6.11/8.6.9) id VAA10157; Tue, 24 Oct 1995 21:44:03 -0600 Message-Id: <199510250344.VAA10157@marker.cs.utah.edu> Date: Tue, 24 Oct 1995 21:44:03 -0600 From: Mike Hibler Reply-To: mike@marker.cs.utah.edu To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: kern/791: panic: bpf: ifpromisc failed Sender: owner-bugs@freebsd.org Precedence: bulk >Number: 791 >Category: kern >Synopsis: interrupt out of tcpdump at the wrong time, panic kernel >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Oct 24 20:50:00 PDT 1995 >Last-Modified: >Originator: Mike Hibler >Organization: Utah >Release: FreeBSD 2.1.0-950726-SNAP i386 >Environment: >Description: bpf.c isn't prepared to deal with detaching from an interface that is down >How-To-Repeat: ifconfig foo up tcpdump -i foo & ifconfig foo down >Fix: NetBSD fixed this by checking the return value from ifpromisc and not panicing on EINVAL. >Audit-Trail: >Unformatted: From owner-freebsd-bugs Tue Oct 24 21:21:30 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA26269 for bugs-outgoing; Tue, 24 Oct 1995 21:21:30 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA26264 ; Tue, 24 Oct 1995 21:21:24 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.12/8.6.12) id VAA16934; Tue, 24 Oct 1995 21:20:41 -0700 From: Julian Elischer Message-Id: <199510250420.VAA16934@ref.tfs.com> Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! To: davidg@Root.COM Date: Tue, 24 Oct 1995 21:20:41 -0700 (PDT) Cc: mikebo@tellabs.com, hackers@freebsd.org, bugs@freebsd.org In-Reply-To: <199510250338.UAA27854@corbin.Root.COM> from "David Greenman" at Oct 24, 95 08:38:46 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 2426 Sender: owner-bugs@freebsd.org Precedence: bulk > > The client should ignore NFS packets from hosts that it's not talking to or > doesn't know about, and that's what all 4.4BSD derived OSs do. unfortunatly it doesn't gain you anything in security to do so however > This is obviously flamebait and I'm not going to respond to it. I'm pretty sure FreeBSD can be made to do the same thing too, given the right icmp packets > > >Sorry for the rambling discourse, but I need this fixed or I can't > >use FreeBSD. At the least, can the "Sun behavior" I need be added > >as an option to the mount command? like most misguided security attempts it should be optional. > > If you choose not to use my suggested work-around, then I guess you can't > use FreeBSD. For the NFS server, FreeBSD (and all other 4.4BSD derived systems) well 4.4BSD derived OS's comprise OSF/1, NetBSD, FreeBSD and BSD/OS. Not exactly aearthshaking combination, and I wouldn't be surprised to see that OSF1 might act differently.. (they are actually net2.5 based) > keep an authentication list in the kernel that is constructed from > /etc/exports. For the NFS client, FreeBSD requires that replies to its RPC > requests come from the same address that they were issued to. If it didn't > work this way, then *anyone* could send bogus udp datagrams with hand-tailored > RPC calls/replies to you and as long as that someone can come up with a file > handle (which is relatively easy), he can do unchecked file operations and > bypass the system security. So? I can make my machine have any address you wish.. and probably still get a packet to your machine.. I mean the source address is not looked at for routing.. It's a security feature to keep out SIMPLE attacks but fails on any really dedicated attack. anyway we're talking being a CLIENT here.. you're talking about being a server, with the exports list.. I didn't notice the exports list being involved in the client side of things.. I think that if we get a patch to make this optional, then we should allow it to be included.. certainly there should be some way to tell NFS that two addresses are equivalent. A Mount option MIGHT work, but you'd have to feed it an alternate IP address.. (not a name) possibbly a routing table entry could be used to do it.. > The best I could offer you would be a kernel option to disable this > security, but I'll say right now that this *won't* be in the 2.1 release. > > -DG > From owner-freebsd-bugs Tue Oct 24 22:14:16 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA28028 for bugs-outgoing; Tue, 24 Oct 1995 22:14:16 -0700 Received: from tellab5.lisle.tellabs.com (tellab5.lisle.tellabs.com [138.111.243.28]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id WAA28006 ; Tue, 24 Oct 1995 22:14:09 -0700 From: mikebo@tellabs.com Received: from tellabk.tellabs.com by tellab5.lisle.tellabs.com with smtp (Smail3.1.29.1 #4) id m0t7y9X-000jC3C; Wed, 25 Oct 95 00:13 CDT Received: by tellabk.tellabs.com (4.1/1.9) id AA12294; Wed, 25 Oct 95 00:13:26 CDT Message-Id: <9510250513.AA12294@tellabk.tellabs.com> Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! To: davidg@Root.COM Date: Wed, 25 Oct 1995 00:13:25 -0500 (CDT) Cc: hackers@freebsd.org, bugs@freebsd.org In-Reply-To: <199510250338.UAA27854@corbin.Root.COM> from "David Greenman" at Oct 24, 95 08:38:46 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: 2852 Sender: owner-bugs@freebsd.org Precedence: bulk David G. wrote: > The client should ignore NFS packets from hosts that it's not talking to or > doesn't know about, and that's what all 4.4BSD derived OSs do. > OK... thanks for pointing this out. It's news to me. > >I can document this behavior in SunOS, Solaris and HP/UX if it will > >help strengthen the argument... > > This is obviously flamebait and I'm not going to respond to it. > I'm merely trying to make a case: that in order to use FreeBSD in a heterogenous (business) environment, it needs to work with NFS servers in the same way as commerical OSes. I didn't know this was a 4.4BSD-ism. > If you choose not to use my suggested work-around, then I guess you can't > use FreeBSD. OUCH! C'mon, is this how things are supposed to work around here? Your workaround will not work... the routes change on-the-fly! Just to find out _which_ server interface is currently responding requires the client admin to do a "netstat -r | grep destination-net" on the server, and then fix the client system. How do I create an automounter map or fstab that deals with this? Answer: Can't > ... For the NFS client, FreeBSD requires that replies to its RPC > requests come from the same address that they were issued to. ... I know that in some places such security is a necessity - but it's hard for me to picture one of my fellow engineers hand-tailoring RPC calls/replies to hack into a system they can walk up to and reboot with ... ;v) I can't dictate major changes in my corporate network to accomodate what is essentially a hobbyist system. If I can't make it work in that context, what is the likelyhood that this OS will be chosen for anything serious? I agree with the spirit in which the change was made, but let's be practical. If you can't make it work, what good is the security? > The best I could offer you would be a kernel option to disable this > security, but I'll say right now that this *won't* be in the 2.1 release. > I really appreciate that you would consider doing this! I know of at least one other site where this is a problem. I take it this could not simply be an option to mount? - Mike PS> I don't want to come off as being grumpy or confrontational. I like FreeBSD and appreciate all the hard work everyone here does for free. I've been an advocate of FreeBSD (been running it since 1.1), have a lot of time invested in it, and it steams me to think that I can't use it! Sorry for the length of the post. -- -------------------------------------------------------------------------- Michael Borowiec - mikebo@tellabs.com - Tellabs Operations Inc. Senior Member of Technical Staff 4951 Indiana Avenue, MS 63 708-512-8211 FAX: 708-512-7099 Lisle, IL 60532 USA -------------------------------------------------------------------------- From owner-freebsd-bugs Wed Oct 25 02:06:19 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA05307 for bugs-outgoing; Wed, 25 Oct 1995 02:06:19 -0700 Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id CAA05284 ; Wed, 25 Oct 1995 02:06:10 -0700 Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0t81mi-0003x4C; Wed, 25 Oct 95 02:06 PDT Received: from localhost (localhost [127.0.0.1]) by critter.tfs.com (8.6.11/8.6.9) with SMTP id KAA03187; Wed, 25 Oct 1995 10:06:06 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost didn't use HELO protocol To: mikebo@tellabs.com cc: davidg@Root.COM, hackers@freebsd.org, bugs@freebsd.org Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! In-reply-to: Your message of "Wed, 25 Oct 1995 00:13:25 EST." <9510250513.AA12294@tellabk.tellabs.com> Date: Wed, 25 Oct 1995 10:06:05 +0100 Message-ID: <3185.814611965@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-bugs@freebsd.org Precedence: bulk > David G. wrote: > > The client should ignore NFS packets from hosts that it's not talking to or > > doesn't know about, and that's what all 4.4BSD derived OSs do. > > > OK... thanks for pointing this out. It's news to me. I guess you could fix this if you have proper multihoming defined in the DNS/hosts, and let mountd handle it. The other way would be to connect(2) the udp socket or alternatively to use tcp (and nfsv3 ?)... -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-bugs Wed Oct 25 06:28:13 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA13776 for bugs-outgoing; Wed, 25 Oct 1995 06:28:13 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA13764 ; Wed, 25 Oct 1995 06:28:10 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id GAA27344; Wed, 25 Oct 1995 06:27:34 -0700 To: davidg@Root.COM cc: mikebo@tellabs.com, hackers@freebsd.org, bugs@freebsd.org Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! In-reply-to: Your message of "Tue, 24 Oct 1995 20:38:46 PDT." <199510250338.UAA27854@corbin.Root.COM> Date: Wed, 25 Oct 1995 06:27:33 -0700 Message-ID: <27341.814627653@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-bugs@freebsd.org Precedence: bulk > This is obviously flamebait and I'm not going to respond to it. I don't think he meant it as flamebait, I read it as him simply trying to state a position (which he did at least mark with a "soapbox on", thus indicating that he knew it to be a contraversal issue) that if FreeBSD can't interoperate with the big boys, then people aren't going to praise FreeBSD for taking the high road, they're going to say that FreeBSD is crap because it can't even talk to the most popular workstation platform on the planet. I can at least see where he's coming from! > bypass the system security. Other commercial vendors are running old security > broken versions of NFS and this makes them wide open for security attacks. And I can see your point as well. Clearly, it's Sun that needs to clean their house and not us.. They've screwed the pooch and I hope Mike can at least understand the natural horror reaction at proposing we lobotomize our security just to cope with someone else's total lack of it. Maybe we can reach a compromise.. > The best I could offer you would be a kernel option to disable this > security, but I'll say right now that this *won't* be in the 2.1 release. I agree - 2.1 is simply too close, though I see no reason why the power-users won't be able to retrofit your solution from 2.2. Still, this strikes me as a problem we're going to see reported often enough that maybe we should make it a MIB variable instead of a kernel compile option, ala the net.inet.tcp.rfc* knobs we already support. Jordan From owner-freebsd-bugs Wed Oct 25 07:23:53 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA15422 for bugs-outgoing; Wed, 25 Oct 1995 07:23:53 -0700 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id HAA15416 for ; Wed, 25 Oct 1995 07:23:49 -0700 Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA07418; Wed, 25 Oct 1995 10:23:33 -0400 Date: Wed, 25 Oct 1995 10:23:33 -0400 From: "Garrett A. Wollman" Message-Id: <9510251423.AA07418@halloran-eldar.lcs.mit.edu> To: Poul-Henning Kamp Cc: mikebo@tellabs.com, bugs@freebsd.org Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! In-Reply-To: <3185.814611965@critter.tfs.com> References: <9510250513.AA12294@tellabk.tellabs.com> <3185.814611965@critter.tfs.com> Sender: owner-bugs@freebsd.org Precedence: bulk [CC list trimmed] < said: > The other way would be to connect(2) the udp socket or alternatively > to use tcp (and nfsv3 ?)... Actually, connect(2) is what is presently being done and part of what causes the breakage. From mount_nfs(8): -c For UDP mount points, do not do a connect(2). This must be used for servers that do not reply to requests from the standard NFS port number 2049. Unfortunately, I don't believe that even this option will help, since the problem is that the server is replying from an address that the client has no way of knowing represents the same host. But it may be worth a try. (This option can also be accessed through the deprecated syntax `noconn'.) -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-bugs Wed Oct 25 07:30:04 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA15703 for bugs-outgoing; Wed, 25 Oct 1995 07:30:04 -0700 Received: (from gnats@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA15696 ; Wed, 25 Oct 1995 07:30:02 -0700 Date: Wed, 25 Oct 1995 07:30:02 -0700 Message-Id: <199510251430.HAA15696@freefall.freebsd.org> To: freebsd-bugs Cc: From: "Garrett A. Wollman" Subject: kern/791: panic: bpf: ifpromisc failed Reply-To: "Garrett A. Wollman" Sender: owner-bugs@FreeBSD.org Precedence: bulk The following reply was made to PR kern/791; it has been noted by GNATS. From: "Garrett A. Wollman" To: mike@marker.cs.utah.edu Cc: FreeBSD-gnats-submit@freebsd.org Subject: kern/791: panic: bpf: ifpromisc failed Date: Wed, 25 Oct 1995 10:24:14 -0400 < said: > ifconfig foo up > tcpdump -i foo & > > ifconfig foo down > Fixed In The Next Release. (And in -current.) -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-bugs Wed Oct 25 07:58:27 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA17791 for bugs-outgoing; Wed, 25 Oct 1995 07:58:27 -0700 Received: from plains.nodak.edu (89@plains.NoDak.edu [134.129.111.64]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA17750 ; Wed, 25 Oct 1995 07:58:14 -0700 Received: (from tinguely@localhost) by plains.nodak.edu (8.6.11/8.6.10) id JAA09084; Wed, 25 Oct 1995 09:58:04 -0500 Date: Wed, 25 Oct 1995 09:58:04 -0500 From: Mark Tinguely Message-Id: <199510251458.JAA09084@plains.nodak.edu> To: davidg@Root.COM, mikebo@tellabs.com Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! Cc: bugs@freebsd.org, hackers@freebsd.org Content-Length: 555 Sender: owner-bugs@freebsd.org Precedence: bulk what is the IP number of tellabk and sunk (or if this is private, what is the relationship between these two numbers is sunk IP < tellabk IP)? If I remember correctly when I was playing with IP aliases (ie "multi-homed"), on a new connection from a multi-homed FreeBSD machine, the multi-homed machine used lowest IP number whether the lowest IP was the real (ifconfig without an alias) interface address or not. I think this operation is incorrect. UDP and TCP should alway orginate the real address not the lowest (possibly and alias) address. --mark. From owner-freebsd-bugs Wed Oct 25 08:48:29 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA21111 for bugs-outgoing; Wed, 25 Oct 1995 08:48:29 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA21104 for ; Wed, 25 Oct 1995 08:48:24 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id BAA11466; Thu, 26 Oct 1995 01:46:14 +1000 Date: Thu, 26 Oct 1995 01:46:14 +1000 From: Bruce Evans Message-Id: <199510251546.BAA11466@godzilla.zeta.org.au> To: bugs@FreeBSD.org, uhclem%nemesis@fw.ast.com Subject: re: kern/770: Floppy kernel won't boot with T485 or IDT L2 cache FDIV032 Sender: owner-bugs@FreeBSD.org Precedence: bulk >So something changed between 1005 and 1022 in the boot.flp department that >makes things all better. I hope somebody knows what the change was! :-) kzip was changed to load the kernel lower at a more carefully chosen (lower, not fixed) address so that booting in 4MB works. kzipboot was changed so that decompressing the kernel doesn't overwrite the stub that calls the decompression code (and is returned too). Decompression now usually overwrites the start of the uncompressed kernel but doesn't get as far as the decompression code. Bruce From owner-freebsd-bugs Wed Oct 25 08:50:07 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA21277 for bugs-outgoing; Wed, 25 Oct 1995 08:50:07 -0700 Received: (from gnats@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA21265 ; Wed, 25 Oct 1995 08:50:04 -0700 Resent-Date: Wed, 25 Oct 1995 08:50:04 -0700 Resent-Message-Id: <199510251550.IAA21265@freefall.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@freefall.FreeBSD.org, "Received:from zed.ludd.luth.se (root@zed.ludd.luth.se [130.240.16.33]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA20790 for" ; Wed, 25.Oct.1995.08:41:35.-0700 Received: from hal.ludd.luth.se (hal.ludd.luth.se [130.240.16.4]) by zed.ludd.luth.se (8.6.12/8.6.11) with ESMTP id QAA12949 for ; Wed, 25 Oct 1995 16:41:30 +0100 Received: (murduth@localhost) by hal.ludd.luth.se (8.6.11/8.6.11) id QAA03319 for FreeBSD-gnats-submit@freebsd.org; Wed, 25 Oct 1995 16:39:52 +0100 Message-Id: <199510251539.QAA03319@hal.ludd.luth.se> Date: Wed, 25 Oct 1995 16:39:51 +0100 (MET) From: Joakim Henriksson To: FreeBSD-gnats-submit@freebsd.org Subject: kern/792: cd9660 very slow Sender: owner-bugs@freebsd.org Precedence: bulk >Number: 792 >Category: kern >Synopsis: cd9660 very slow. >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Oct 25 08:50:03 PDT 1995 >Last-Modified: >Originator: Joakim Henriksson >Organization: Ludd >Release: FreeBSD 2.0-BUILT-19950603 i386 >Environment: Toshiba XM-5301-B CDROM (4x spin on SCSI) >Description: I only get 200k/s transfer speed from the cdrom when mounted. But cat'ing from t he raw-device yeilds 600k/s what gives. Huge overhead on the cd9660 fs? >How-To-Repeat: mount any cdrom on my computer. >Fix: Workaround: "cat /dev/cd0 >cdrom ; mount_cd9660 cdrom /mnt" Very space taking though :) >Audit-Trail: >Unformatted: From owner-freebsd-bugs Wed Oct 25 09:11:54 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA23193 for bugs-outgoing; Wed, 25 Oct 1995 09:11:54 -0700 Received: (from wollman@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA23163 ; Wed, 25 Oct 1995 09:11:49 -0700 Date: Wed, 25 Oct 1995 09:11:49 -0700 From: "Garrett A. Wollman" Message-Id: <199510251611.JAA23163@freefall.freebsd.org> To: mike@marker.cs.utah.edu, wollman, freebsd-bugs Subject: Re: kern/791 Sender: owner-bugs@FreeBSD.org Precedence: bulk Synopsis: interrupt out of tcpdump at the wrong time, panic kernel State-Changed-From-To: open-closed State-Changed-By: wollman State-Changed-When: Wed Oct 25 09:11:20 PDT 1995 State-Changed-Why: Fixed in -current. From owner-freebsd-bugs Wed Oct 25 09:41:45 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA25296 for bugs-outgoing; Wed, 25 Oct 1995 09:41:45 -0700 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id JAA25268 ; Wed, 25 Oct 1995 09:41:41 -0700 Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA13947; Wed, 25 Oct 1995 12:41:30 -0400 Date: Wed, 25 Oct 1995 12:41:30 -0400 From: "Garrett A. Wollman" Message-Id: <9510251641.AA13947@halloran-eldar.lcs.mit.edu> To: "Jordan K. Hubbard" Cc: davidg@root.com, mikebo@tellabs.com, hackers@freebsd.org, bugs@freebsd.org Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! In-Reply-To: <27341.814627653@time.cdrom.com> References: <199510250338.UAA27854@corbin.Root.COM> <27341.814627653@time.cdrom.com> Sender: owner-bugs@freebsd.org Precedence: bulk < said: > I agree - 2.1 is simply too close, though I see no reason why the > power-users won't be able to retrofit your solution from 2.2. Still, > this strikes me as a problem we're going to see reported often enough > that maybe we should make it a MIB variable instead of a kernel > compile option, ala the net.inet.tcp.rfc* knobs we already support. Wrong part of the MIB. You can add support for practically any NFS parameter you want under fs.nfs. There should probably be a lot more; I only implemented the statistics because of the pressing need to get `nfsstat' working with LKMed NFS. Someone who knows a lot about NFS should be able to come up with all sorts of useful parameters to tune. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-bugs Wed Oct 25 09:57:57 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA26869 for bugs-outgoing; Wed, 25 Oct 1995 09:57:57 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA26864 ; Wed, 25 Oct 1995 09:57:54 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id JAA28528; Wed, 25 Oct 1995 09:56:45 -0700 To: "Garrett A. Wollman" cc: davidg@root.com, mikebo@tellabs.com, hackers@freebsd.org, bugs@freebsd.org Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! In-reply-to: Your message of "Wed, 25 Oct 1995 12:41:30 EDT." <9510251641.AA13947@halloran-eldar.lcs.mit.edu> Date: Wed, 25 Oct 1995 09:56:45 -0700 Message-ID: <28525.814640205@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-bugs@freebsd.org Precedence: bulk > > compile option, ala the net.inet.tcp.rfc* knobs we already support. > > Wrong part of the MIB. You can add support for practically any NFS > parameter you want under fs.nfs. There should probably be a lot more; Sorry, I by no means meant to imply that the NFS options should go under net.inet.tcp.*! I'm not quite *that* stupid.. :-) I merely cited these as examples of "work around" options that deal with broken external-world situations and are implemented as MIB variables. Jordan From owner-freebsd-bugs Wed Oct 25 10:02:49 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA27354 for bugs-outgoing; Wed, 25 Oct 1995 10:02:49 -0700 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id KAA27345 ; Wed, 25 Oct 1995 10:02:46 -0700 Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA15161; Wed, 25 Oct 1995 13:02:23 -0400 Date: Wed, 25 Oct 1995 13:02:23 -0400 From: "Garrett A. Wollman" Message-Id: <9510251702.AA15161@halloran-eldar.lcs.mit.edu> To: Mark Tinguely Cc: davidg@root.com, mikebo@tellabs.com, bugs@freebsd.org, hackers@freebsd.org Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! In-Reply-To: <199510251458.JAA09084@plains.nodak.edu> References: <199510251458.JAA09084@plains.nodak.edu> Sender: owner-bugs@freebsd.org Precedence: bulk < said: > used lowest IP number whether the lowest IP was the real (ifconfig without > an alias) interface address or not There is no such distinction. All the alias flag does is tell the `ifconfig' program not to delete the old interface address before adding the new one. As far as the kernel is concerned, all aliases are equal. This becomes more clear if you consider the case for which aliases were originally written (multiple logical IP subnets on one wire). In any case, FreeBSD does the right thing when serving NFS: it sends replies from the address to which the request was send; this is unlike Sun's behavior---they never bothered to think about multi-homing---which sends a reply back from any (effectively) randomly-chosen address on the host regardless of where the request was sent. (This fits in with Sun's demonstrated philosophy of no security and brokenness in the case of network failures.) -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-bugs Wed Oct 25 12:00:02 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA05661 for bugs-outgoing; Wed, 25 Oct 1995 12:00:02 -0700 Received: (from gnats@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA05655 ; Wed, 25 Oct 1995 12:00:01 -0700 Date: Wed, 25 Oct 1995 12:00:01 -0700 Message-Id: <199510251900.MAA05655@freefall.freebsd.org> To: freebsd-bugs Cc: From: Bruce Evans Subject: Re: kern/792: cd9660 very slow Reply-To: Bruce Evans Sender: owner-bugs@FreeBSD.org Precedence: bulk The following reply was made to PR kern/792; it has been noted by GNATS. From: Bruce Evans To: FreeBSD-gnats-submit@freebsd.org, murduth@ludd.luth.se Cc: Subject: Re: kern/792: cd9660 very slow Date: Thu, 26 Oct 1995 04:50:07 +1000 >I only get 200k/s transfer speed from the cdrom when mounted. But cat'ing from t >he raw-device yeilds 600k/s what gives. Huge overhead on the cd9660 fs? Slowness is normal for small files on most file systems :(. I get only 129K/sec for `tar cf /dev/null /usr/src/bin' on a SCSI disk that has a raw throughput of 2500K/sec and an iozone throughput of 1200K/sec. How big are the files that you only get 200K/sec on? cd9660 doesn't support clustering unless the block size is >= 4K (unlikely) so it is likely to be slow on large files too. Bruce From owner-freebsd-bugs Wed Oct 25 13:44:30 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA13192 for bugs-outgoing; Wed, 25 Oct 1995 13:44:30 -0700 Received: from tellab5.lisle.tellabs.com (tellab5.lisle.tellabs.com [138.111.243.28]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id NAA13187 ; Wed, 25 Oct 1995 13:44:25 -0700 From: mikebo@tellabs.com Received: from sunc210.tellabs.com by tellab5.lisle.tellabs.com with smtp (Smail3.1.29.1 #4) id m0t8CfU-000jBzC; Wed, 25 Oct 95 15:43 CDT Received: by sunc210.tellabs.com (SMI-8.6/1.9) id PAA00582; Wed, 25 Oct 1995 15:43:19 -0500 Message-Id: <199510252043.PAA00582@sunc210.tellabs.com> Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! To: wollman@lcs.mit.edu (Garrett A. Wollman) Date: Wed, 25 Oct 1995 15:43:18 -0500 (CDT) Cc: bugs@freebsd.org, hackers@freebsd.org, davew@sees.bangor.ac.uk In-Reply-To: <9510251423.AA07418@halloran-eldar.lcs.mit.edu> from "Garrett A. Wollman" at Oct 25, 95 10:23:33 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-bugs@freebsd.org Precedence: bulk Garrett wrote: > Actually, connect(2) is what is presently being done and part of what > causes the breakage. From mount_nfs(8): > > -c For UDP mount points, do not do a connect(2). This must be used > for servers that do not reply to requests from the standard NFS > port number 2049. > > Unfortunately, I don't believe that even this option will help, since > the problem is that the server is replying from an address that the > client has no way of knowing represents the same host. But it may be > worth a try. (This option can also be accessed through the deprecated > syntax `noconn'.) > Wahoo! This option did the trick, even though the ip_addrs didn't match. This option did _not_ work under 2.0.5R, due to bad hackage of the RPC code in libc. It does seem to work under 2.1.0-951020-SNAP! Come to think of it, the "bad hackage" was, in fact, a connect() being done in lib/libc/rpc/clnt_udp.c. Hopefully, now that we know this is a workaround for strict 4.4BSD net security, the "-o noconn" option will not be removed. I must admit I don't understand why a connect(2) is being done. Isn't UDP a connection- LESS protocol? Perhaps someone can explain... I am only an egg. ;v) Thanks everyone for your suggestions! - Mike -- -------------------------------------------------------------------------- Michael Borowiec - mikebo@tellabs.com - Tellabs Operations Inc. Senior Member of Technical Staff 4951 Indiana Avenue, MS 63 708-512-8211 FAX: 708-512-7099 Lisle, IL 60532 USA -------------------------------------------------------------------------- From owner-freebsd-bugs Wed Oct 25 14:35:53 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA18780 for bugs-outgoing; Wed, 25 Oct 1995 14:35:53 -0700 Received: from hemi.com (hemi.com [204.132.158.10]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA18739 ; Wed, 25 Oct 1995 14:35:44 -0700 Received: (from mbarkah@localhost) by hemi.com (8.6.11/8.6.9) id PAA05072; Wed, 25 Oct 1995 15:39:47 -0600 From: Ade Barkah Message-Id: <199510252139.PAA05072@hemi.com> Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! To: mikebo@tellabs.com Date: Wed, 25 Oct 1995 15:39:47 -0600 (MDT) Cc: wollman@lcs.mit.edu, bugs@freebsd.org, hackers@freebsd.org, davew@sees.bangor.ac.uk In-Reply-To: <199510252043.PAA00582@sunc210.tellabs.com> from "mikebo@tellabs.com" at Oct 25, 95 03:43:18 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 814 Sender: owner-bugs@freebsd.org Precedence: bulk [Michael Borowiec wrote] > Hopefully, now that we know this is a workaround for strict 4.4BSD net > security, the "-o noconn" option will not be removed. I must admit I > don't understand why a connect(2) is being done. Isn't UDP a connection- > LESS protocol? Perhaps someone can explain... I am only an egg. ;v) I'm not familiar with your specific problem (jumped in the middle of the thread) but although UDP is a connectionless proctocol, one can still use connect() on a udp socket to associate the udp destina- tion address. Alternatively such address can be specified on each send*(). -Ade Barkah -------------------------------------------------------------------- Inet: mbarkah@hemi.com - HEMISPHERE ONLINE - www: -------------------------------------------------------------------- From owner-freebsd-bugs Wed Oct 25 16:40:05 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA29874 for bugs-outgoing; Wed, 25 Oct 1995 16:40:05 -0700 Received: (from gnats@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA29863 ; Wed, 25 Oct 1995 16:40:02 -0700 Resent-Date: Wed, 25 Oct 1995 16:40:02 -0700 Resent-Message-Id: <199510252340.QAA29863@freefall.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@freefall.FreeBSD.org, jin@pesto.lbl.gov Received: from pesto.lbl.gov (pesto.lbl.gov [128.3.196.67]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA29299 for ; Wed, 25 Oct 1995 16:31:53 -0700 Received: (from jin@localhost) by pesto.lbl.gov (8.6.12/8.6.12) id QAA12232; Wed, 25 Oct 1995 16:31:47 -0700 Message-Id: <199510252331.QAA12232@pesto.lbl.gov> Date: Wed, 25 Oct 1995 16:31:47 -0700 From: "Jin Guojun[ITG]" Reply-To: jin@pesto.lbl.gov To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: kern/793: ep0 cannot be configured and more. Sender: owner-bugs@freebsd.org Precedence: bulk >Number: 793 >Category: kern >Synopsis: ep0 cannot be configured and more. >Confidential: yes >Severity: critical >Priority: high >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Oct 25 16:40:01 PDT 1995 >Last-Modified: >Originator: Jin Guojun[ITG] >Organization: /-------------- Jin Guojun ------------ v ---- Internet: g_jin@lbl.gov ----\ | Imaging & Distributed Computing | Usenet: ucbvax!g_jin@lbl.gov | | Lawrence Berkeley Laboratory | Bitnet: -- | | 50B-2239, Berkeley, CA 94720 - jin%george.lbl.gov@Csa3.LBL.Gov | \--Ph#:(510) 486-7531 + Fax: 486-6363 --^--http://www-itg.lbl.gov/ITG.html-/ >Release: FreeBSD 2.1-STABLE i386 >Environment: 3Com Elink-III 3c509 ethernet card tested with many motherboards The all files are dated OCT. 21, and floppy is dated OCT. 23. >Description: The 3c509 ethernet card has been found, but not configured to given host id: # ifconfig -a lp0: flags=8810 mtu 1500 ep0: flags=863 mtu 1500 ether 00:00:24:34:12:d7 lo0: flags=8009 mtu 16384 inet 127.0.0.1 netmask 0xff000000 sl0: flags=c010 mtu 552 tun0: flags=8010 mtu 1500 Also, after manually configuring ep0 correctly, it won't go further than one hop. i.e., if the machine is on 128.3.123 net, then, it won't see 128.3.124 net even though it can see the router and all other hosts on the 128.3.123 net. >How-To-Repeat: See Description >Fix: The installer works fine. I rebuild the kernel, the problem is still in. So, the bug is in some modified code for either the 3Com driver or in the network driver. >Audit-Trail: >Unformatted: From owner-freebsd-bugs Wed Oct 25 16:59:49 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA01382 for bugs-outgoing; Wed, 25 Oct 1995 16:59:49 -0700 Received: from hermes.sees.bangor.ac.uk (hermes.sees.bangor.ac.uk [147.143.102.8]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id QAA01346 ; Wed, 25 Oct 1995 16:59:35 -0700 From: Mr D Whitehead (Ext 2703) Message-Id: <17209.9510252357@hermes.sees.bangor.ac.uk> Received: from sol (sol.sees.bangor.ac.uk) by hermes.sees.bangor.ac.uk; Thu, 26 Oct 95 00:57:09 BST Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! To: mikebo@tellabs.com Date: Wed, 25 Oct 1995 23:57:09 +0000 (GMT) Cc: bugs@freebsd.org, hackers@freebsd.org In-Reply-To: <199510252043.PAA00582@sunc210.tellabs.com> from "mikebo@tellabs.com" at Oct 25, 95 03:43:18 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: 2010 Sender: owner-bugs@freebsd.org Precedence: bulk > > Garrett wrote: > > Actually, connect(2) is what is presently being done and part of what > > causes the breakage. From mount_nfs(8): > > > > -c For UDP mount points, do not do a connect(2). This must be used > > for servers that do not reply to requests from the standard NFS > > port number 2049. > > > > Unfortunately, I don't believe that even this option will help, since > > the problem is that the server is replying from an address that the > > client has no way of knowing represents the same host. But it may be > > worth a try. (This option can also be accessed through the deprecated > > syntax `noconn'.) > > > Wahoo! This option did the trick, even though the ip_addrs didn't match. > This option did _not_ work under 2.0.5R, due to bad hackage of the RPC ^^^^^ I beg to differ, we are using 2.0.5R (from the CD) and it _was_ the solution to our problem! > code in libc. It does seem to work under 2.1.0-951020-SNAP! Come to > think of it, the "bad hackage" was, in fact, a connect() being done in > lib/libc/rpc/clnt_udp.c. > > Hopefully, now that we know this is a workaround for strict 4.4BSD net > security, the "-o noconn" option will not be removed. I must admit I > don't understand why a connect(2) is being done. Isn't UDP a connection- > LESS protocol? Perhaps someone can explain... I am only an egg. ;v) > -- Dave Whitehead (Computer Support Staff) ------------------------------------------------------------------------------- EMAIL:- | TELEPHONE (work):- (work) davew@sees.bangor.ac.uk | +44 1248 382703 (Direct line) (home) 100023.1076@compuserve.com | +44 1248 351151 ext 2703 ------------------------------------------------------------------------------- SNAIL MAIL:- Dave Whitehead School of Electronic Engineering & Computer Systems, University College of North Wales, Dean Street, Bangor LL57 1UT ------------------------------------------------------------------------------ From owner-freebsd-bugs Thu Oct 26 03:12:34 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA29918 for bugs-outgoing; Thu, 26 Oct 1995 03:12:34 -0700 Received: from mail.cs.tu-berlin.de (root@mail.cs.tu-berlin.de [130.149.17.13]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id DAA29832 for ; Thu, 26 Oct 1995 03:09:22 -0700 Received: from caramba.cs.tu-berlin.de (wosch@caramba.cs.tu-berlin.de [130.149.17.12]) by mail.cs.tu-berlin.de (8.6.12/8.6.12) with ESMTP id KAA05285 for ; Thu, 26 Oct 1995 10:34:35 +0100 Received: (from wosch@localhost) by localhost (8.6.9/8.6.9) id QAA18606; Wed, 25 Oct 1995 16:58:28 +0100 Date: Wed, 25 Oct 1995 16:58:28 +0100 From: Wolfram Schneider Message-Id: <199510251558.QAA18606@localhost> To: bugs@freebsd.org Subject: Manpage Makefile patches II Reply-to: Wolfram Schneider MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-bugs@freebsd.org Precedence: bulk Last part. I am awfully sorry, the following files are also in previous patch. src/gnu/usr.bin/cc/cc/Makefile src/lib/libc/gen/Makefile.inc src/lib/libm/Makefile src/usr.bin/vi/common/Makefile Wolfram --- src/gnu/usr.bin/cc/cc/Makefile Tue Dec 27 02:02:00 1994 +++ src/gnu/usr.bin/cc/cc/Makefile.new Mon Oct 23 21:44:10 1995 @@ -8,6 +8,6 @@ .PATH: ${.CURDIR}/../cc_int SRCS+= obstack.c version.c LINKS= ${BINDIR}/cc ${BINDIR}/gcc -MLINKS= cc.1 gcc.1 +MLINKS= cc.1 gcc.1 cc.1 g++.1 cc.1 c++.1 .include --- src/usr.bin/vi/common/Makefile Sun Sep 11 02:00:00 1994 +++ src/usr.bin/vi/common/Makefile.new Mon Oct 23 21:46:13 1995 @@ -8,6 +8,8 @@ LINKS+= ${BINDIR}/${VI} ${BINDIR}/vi ${BINDIR}/${EX} ${BINDIR}/ex LINKS+= ${BINDIR}/${VI} ${BINDIR}/view MAN1= ${.CURDIR}/../USD.doc/vi.man/vi.1 +MLINKS+=vi.1 ex.1 vi.1 view.1 +MLINKS+=vi.1 nex.1 vi.1 nview.1 vi.1 nvi.1 CFLAGS+=-I. -I${.CURDIR} DPADD+= ${LIBCURSES} ${LIBTERMCAP} ${LIBUTIL} --- src/lib/libc/gen/Makefile.inc Tue May 30 12:21:00 1995 +++ src/lib/libc/gen/Makefile.inc.new Tue Oct 24 14:15:10 1995 @@ -58,13 +58,15 @@ MLINKS+=config_open.3 config_next.3 config_open.3 config_close.3 \ config_open.3 config_skip.3 MLINKS+=crypt.3 encrypt.3 crypt.3 setkey.3 +MLINKS+=crypt.3 des_setkey.3 crypt.3 des_cipher.3 MLINKS+=directory.3 closedir.3 directory.3 dirfd.3 directory.3 opendir.3 \ directory.3 readdir.3 directory.3 rewinddir.3 directory.3 seekdir.3 \ directory.3 telldir.3 MLINKS+=exec.3 execl.3 exec.3 execle.3 exec.3 execlp.3 exec.3 execv.3 \ - exec.3 execvp.3 + exec.3 execvp.3 exec.3 exect.3 MLINKS+=err.3 verr.3 err.3 errx.3 err.3 verrx.3 err.3 warn.3 err.3 vwarn.3 \ - err.3 warnx.3 err.3 vwarnx.3 + err.3 warnx.3 err.3 vwarnx.3 err.3 err_set_file.3 \ + err.3 err_set_exit.3 MLINKS+=isinf.3 isnan.3 MLINKS+=getcap.3 cgetcap.3 getcap.3 cgetclose.3 getcap.3 cgetent.3 \ getcap.3 cgetfirst.3 getcap.3 cgetmatch.3 getcap.3 cgetnext.3 \ @@ -88,7 +90,7 @@ MLINKS+=getusershell.3 endusershell.3 getusershell.3 setusershell.3 MLINKS+=glob.3 globfree.3 MLINKS+=popen.3 pclose.3 -MLINKS+=psignal.3 sys_siglist.3 +MLINKS+=psignal.3 sys_siglist.3 psignal.3 sys_signame.3 MLINKS+=pwcache.3 user_from_uid.3 pwcache.3 group_from_gid.3 MLINKS+=rand48.3 _rand48.3 rand48.3 drand48.3 rand48.3 erand48.3 \ rand48.3 jrand48.3 rand48.3 lcong48.3 rand48.3 lrand48.3 \ @@ -112,3 +114,4 @@ MLINKS+=ttyname.3 isatty.3 ttyname.3 ttyslot.3 MLINKS+=tzset.3 tzsetwall.3 MLINKS+=vis.3 strvis.3 vis.3 strvisx.3 +MLINKS+=unvis.3 strunvis.3 --- src/lib/libm/Makefile Fri Aug 5 02:00:00 1994 +++ src/lib/libm/Makefile.new Tue Oct 24 14:09:27 1995 @@ -138,13 +138,41 @@ common_source/rint.3 common_source/sin.3 common_source/sinh.3 \ common_source/sqrt.3 common_source/tan.3 common_source/tanh.3 -MLINKS+=erf.3 erfc.3 -MLINKS+=exp.3 expm1.3 exp.3 log.3 exp.3 log10.3 exp.3 log1p.3 exp.3 pow.3 -MLINKS+=hypot.3 cabs.3 +MLINKS+=rint.3 rintf.3 +MLINKS+=ceil.3 ceilf.3 +MLINKS+=sqrt.3 sqrtf.3 sqrt.3 cbrt.3 sqrt.3 cbrt.3 +MLINKS+=erf.3 erfc.3 erf.3 erff.3 erf.3 erfcf.3 +MLINKS+=exp.3 expm1.3 exp.3 log.3 exp.3 log10.3 exp.3 log1p.3 exp.3 pow.3 \ + exp.3 expf.3 exp.3 exp2.3 exp.3 exp2f.3 exp.3 exp10.3 exp.3 exp10f.3 \ + exp.3 expm1f.3 exp.3 logf.3 exp.3 log2.3 exp.3 log2f.3 \ + exp.3 log10f.3 exp.3 log1pf.3 exp.3 powf.3 +MLINKS+=fabs.3 fabsf.3 +MLINKS+=floor.3 floorf.3 +MLINKS+=fmod.3 fmodf.3 +MLINKS+=hypot.3 cabs.3 hypot.3 hypotf.3 hypot.3 cabsf.3 MLINKS+=ieee.3 copysign.3 ieee.3 drem.3 ieee.3 finite.3 ieee.3 logb.3 \ - ieee.3 scalb.3 -MLINKS+=j0.3 j1.3 j0.3 jn.3 j0.3 y0.3 j0.3 y1.3 j0.3 yn.3 -MLINKS+=lgamma.3 gamma.3 + ieee.3 scalb.3 ieee.3 copysignf.3 ieee.3 finitef.3 \ + ieee.3 ilogbf.3 ieee.3 nextafterf.3 ieee.3 remainderf.3 \ + ieee.3 scalbnf.3 +MLINKS+=ieee_test.3 scalbf.3 ieee_test.e significandf.3 + +MLINKS+=j0.3 j1.3 j0.3 jn.3 j0.3 y0.3 j0.3 y1.3 j0.3 yn.3 \ + j0.3 j0f.3 j0.3 j1f.3 j0.3 jnf.3 j0.3 y0f.3 j0.3 y1f.3 j0.3 ynf.3 + +MLINKS+=lgamma.3 gamma.3 gamma.3 lgammaf.3 gamma.3 gammaf.3 +MLINKS+=acos.3 acosf.3 +MLINKS+=acosh.3 acoshf.3 +MLINKS+=asin.3 asinf.3 +MLINKS+=asinh.3 asinhf.3 +MLINKS+=atan.3 atanf.3 +MLINKS+=atan2.3 atan2f.3 +MLINKS+=atanh.3 atanhf.3 +MLINKS+=cos.3 cosf.3 +MLINKS+=sin.3 sinf.3 +MLINKS+=sinh.3 sinhf.3 +MLINKS+=tan.3 tanf.3 +MLINKS+=tanh.3 tanhf.3 + # can't use the standard mkdep, because there are some .s files that # are using '#' as a comment indicator and cpp thinks it's an undefined --- src/lib/libcompat/Makefile Mon May 1 16:53:00 1995 +++ src/lib/libcompat/Makefile.new Mon Oct 23 21:57:21 1995 @@ -25,6 +25,8 @@ MLINKS+=stty.3 gtty.3 MLINKS+=cftime.3 ascftime.3 +MLINKS+=lsearch.3 lfind.3 + # compat 4.3 sources # XXX MISSING: ecvt.c gcvt.c sibuf.c sobuf.c strout.c SRCS+= cfree.c lsearch.c regex.c rexec.c --- src/lib/libc/locale/Makefile.inc Thu Feb 16 10:13:00 1995 +++ src/lib/libc/locale/Makefile.inc.new Tue Oct 24 23:19:37 1995 @@ -15,3 +15,10 @@ locale/rune.3 locale/setlocale.3 locale/toascii.3 locale/tolower.3 \ locale/toupper.3 MAN4+= locale/euc.4 locale/utf2.4 +MLINKS+=multibyte.3 mblen.3 multibyte.3 mbstowcs.3 multibyte.3 mbtowc.3 \ + multibyte.3 wcstombs.3 multibyte.3 wctomb.3 +MLINKS+=rune.3 setrunelocale.3 rune.3 setinvalidrune.3 \ + rune.3 sgetrune.3 rune.3 sputrune.3 +MLINKS+=setlocale.3 localeconv.3 +MLINKS+=euc.4 EUC.4 +MLINKS+=utf2.4 UTF2.4 --- src/lib/libc/string/Makefile.inc Tue Mar 7 10:12:00 1995 +++ src/lib/libc/string/Makefile.inc.new Mon Oct 23 22:05:26 1995 @@ -94,4 +94,5 @@ MLINKS+=strcat.3 strncat.3 MLINKS+=strcmp.3 strncmp.3 MLINKS+=strcpy.3 strncpy.3 -MLINKS+=strerror.3 perror.3 +MLINKS+=strerror.3 perror.3 strerror.3 sys_errlist \ + strerror.3 sys_nerr --- src/lib/libscsi/Makefile Tue Oct 24 13:57:05 1995 +++ src/lib/libscsi/Makefile.new Sun Aug 6 17:02:00 1995 @@ -9,11 +9,6 @@ #MLINKS+=kvm_getprocs.3 kvm_getargv.3 kvm_getprocs.3 kvm_getenvv.3 #MLINKS+=kvm_open.3 kvm_openfiles.3 kvm_open.3 kvm_close.3 #MLINKS+=kvm_read.3 kvm_write.3 -MLINKS+=scsi.3 scsireq_buff_decode.3 scsi.3 scsireq_build.3 \ - scsi.3 scsireq_decode.3 scsi.3 scsireq_encode.3 \ - scsi.3 scsireq_enter.3 scsi.3 scsireq_new.3 \ - scsi.3 scsireq_reset.3 scsi.3 SCSIREQ_ERROR.3 scsi.3 scsi_open.3 \ - scsi.3 scsi_debug.3 scsi.3 scsi_debug_output.3 beforeinstall: -cd ${.CURDIR}; cmp -s scsi.h ${DESTDIR}/usr/include/scsi.h || \ --- src/lib/libtermcap/Makefile Sun Aug 6 17:02:00 1995 +++ src/lib/libtermcap/Makefile.new Tue Oct 24 14:11:41 1995 @@ -9,7 +9,7 @@ MAN3= termcap.3 MLINKS= termcap.3 tgetent.3 termcap.3 tgetflag.3 termcap.3 tgetnum.3 \ termcap.3 tgetstr.3 termcap.3 tgoto.3 termcap.3 tputs.3 \ - termcap.3 tparm.3 + termcap.3 tparm.3 termcap.3 _set_ospeed.3 LINKS= ${LIBDIR}/libtermcap.a ${LIBDIR}/libtermlib.a .if !defined(NOPIC) LINKS+= ${SHLIBDIR}/libtermcap.so.${SHLIB_MAJOR}.${SHLIB_MINOR} \ --- src/lib/libc/stdtime/Makefile.inc Tue Sep 13 02:00:00 1994 +++ src/lib/libc/stdtime/Makefile.inc.new Tue Oct 24 14:12:57 1995 @@ -8,3 +8,4 @@ MLINKS+=ctime.3 asctime.3 ctime.3 difftime.3 ctime.3 gmtime.3 \ ctime.3 localtime.3 ctime.3 mktime.3 +MLINKS+=time2posix.3 posix2time.3 --- src/share/man/man4/man4.i386/Makefile Tue Oct 10 11:04:00 1995 +++ src/share/man/man4/man4.i386/Makefile.new Tue Oct 24 14:18:31 1995 @@ -10,7 +10,7 @@ MLINKS+= apm.4 ../apm.4 MLINKS+= asc.4 ../asc.4 MLINKS+= bt.4 ../bt.4 -MLINKS+= cx.4 ../cx.4 +MLINKS+= cx.4 ../cx.4 cx.4 if_cx.4 if_cx.4 ../if_cx.4 MLINKS+= cy.4 ../cy.4 MLINKS+= ed.4 ../ed.4 MLINKS+= fdc.4 ../fdc.4 --- src/share/man/man4/Makefile Tue Mar 14 22:15:00 1995 +++ src/share/man/man4/Makefile.new Tue Oct 24 14:22:45 1995 @@ -8,6 +8,10 @@ MLINKS+=netintro.4 networking.4 MLINKS+=ipfirewall.4 ipacct.4 ipfirewall.4 ipfw.4 ipfirewall.4 ipaccounting.4 MLINKS+=fpa.4 fea.4 +MLINKS+=esis.4 es-is.4 +MLINKS+=lkm.4 LKM.4 +MLINKS+=tp.4 TP.4 + # XXX NOT IMPORTED: man4.hp300 man4.sparc man4.tahoe man4.vax SUBDIR= man4.i386 --- src/share/man/man5/Makefile Thu Apr 13 04:57:00 1995 +++ src/share/man/man5/Makefile.new Tue Oct 24 14:25:27 1995 @@ -5,7 +5,7 @@ group.5 hosts.5 link.5 networks.5 passwd.5 phones.5 printcap.5 \ procfs.5 protocols.5 remote.5 resolver.5 services.5 shells.5 \ stab.5 types.5 utmp.5 -MLINKS= fs.5 inode.5 utmp.5 wtmp.5 utmp.5 lastlog.5 +MLINKS= fs.5 inode.5 utmp.5 wtmp.5 utmp.5 lastlog.5 dir.5 dirent.5 clean depend lint tags: --- src/games/canfield/canfield/Makefile Sun Sep 11 02:00:00 1994 +++ src/games/canfield/canfield/Makefile.new Tue Oct 24 22:36:11 1995 @@ -5,6 +5,7 @@ DPADD= ${LIBCURSES} ${LIBTERMCAP} ${LIBCOMPAT} LDADD= -lcurses -ltermcap -lcompat HIDEGAME=hidegame +MLINKS+=canfield.6 cfscores.6 .include "../../Makefile.inc" --- src/gnu/games/chess/Makefile Tue Jul 25 05:06:00 1995 +++ src/gnu/games/chess/Makefile.new Tue Oct 24 22:38:13 1995 @@ -7,6 +7,7 @@ DPADD= ${LIBCURSES} ${LIBTERMCAP} LDADD= -lcurses -ltermcap HIDEGAME=hidegame +MLINKS+=chess.6 Chess.6 beforeinstall: ${INSTALL} -c -o ${BINOWN} -g ${BINGRP} -m 444 \ --- src/games/snake/snake/Makefile Sun Sep 11 02:00:00 1994 +++ src/games/snake/snake/Makefile.new Tue Oct 24 22:40:57 1995 @@ -3,6 +3,7 @@ PROG= snake SRCS= snake.c move.c MAN6= snake.6 +MLINKS+=snake.6 snscore.6 DPADD= ${LIBM} ${LIBTERMCAP} ${LIBCOMPAT} LDADD= -lm -ltermcap -lcompat HIDEGAME=hidegame --- src/libexec/bootpd/Makefile Wed Jul 26 05:08:00 1995 +++ src/libexec/bootpd/Makefile.new Tue Oct 24 22:51:20 1995 @@ -12,5 +12,6 @@ MAN5= bootptab.5 MAN8= bootpd.8 +MLINKS+=bootpd.8 bootpgw.8 .include -- Wolfram Schneider http://hyperg.cs.tu-berlin.de/C~wosch From owner-freebsd-bugs Thu Oct 26 07:17:53 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA07480 for bugs-outgoing; Thu, 26 Oct 1995 07:17:53 -0700 Received: from tellab5.lisle.tellabs.com (tellab5.lisle.tellabs.com [138.111.243.28]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id HAA07463 ; Thu, 26 Oct 1995 07:17:44 -0700 From: mikebo@tellabs.com Received: from sunc210.tellabs.com by tellab5.lisle.tellabs.com with smtp (Smail3.1.29.1 #4) id m0t8T7E-000jBzC; Thu, 26 Oct 95 09:17 CDT Received: by sunc210.tellabs.com (SMI-8.6/1.9) id JAA01701; Thu, 26 Oct 1995 09:17:03 -0500 Message-Id: <199510261417.JAA01701@sunc210.tellabs.com> Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! To: davew@sees.bangor.ac.uk (Mr D Whitehead) Date: Thu, 26 Oct 1995 09:17:03 -0500 (CDT) Cc: bugs@freebsd.org, hackers@freebsd.org In-Reply-To: <17209.9510252357@hermes.sees.bangor.ac.uk> from "Mr D Whitehead" at Oct 25, 95 11:57:09 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-bugs@freebsd.org Precedence: bulk Dave wrote: > > Garrett wrote: > > > Actually, connect(2) is what is presently being done and part of what > > > causes the breakage. From mount_nfs(8): > > > > > > -c For UDP mount points, do not do a connect(2). This must be used > > > for servers that do not reply to requests from the standard NFS > > > port number 2049. > > > > > Wahoo! This option did the trick, even though the ip_addrs didn't match. > > This option did _not_ work under 2.0.5R, due to bad hackage of the RPC > ^^^^^ > I beg to differ, we are using 2.0.5R (from the CD) and > it _was_ the solution to our problem! > > > code in libc. It does seem to work under 2.1.0-951020-SNAP! Come to > > think of it, the "bad hackage" was, in fact, a connect() being done in > > lib/libc/rpc/clnt_udp.c. > I did try "noconn" while monitoring with snoop and a Sniffer, and under 2.0.5R (from the CD also), it did not solve the problem of differing ip_addrs. My traces showed ICMP Destination unreachable (Bad port) with or without noconn. But, there's no arguing with results. I couldn't get it to work, and documented it months ago. No sense going back now... - Mike -- -------------------------------------------------------------------------- Michael Borowiec - mikebo@tellabs.com - Tellabs Operations Inc. Senior Member of Technical Staff 4951 Indiana Avenue, MS 63 708-512-8211 FAX: 708-512-7099 Lisle, IL 60532 USA -------------------------------------------------------------------------- From owner-freebsd-bugs Thu Oct 26 11:12:26 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA16682 for bugs-outgoing; Thu, 26 Oct 1995 11:12:26 -0700 Received: from devnull (devnull.mpd.tandem.com [131.124.4.29]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA16663 ; Thu, 26 Oct 1995 11:12:20 -0700 Received: from olympus by devnull (8.6.8/8.6.6) id NAA24979; Thu, 26 Oct 1995 13:11:37 -0500 Received: by olympus (4.1/TSS2.1) id AA28231; Thu, 26 Oct 95 13:11:44 CDT From: faulkner@mpd.tandem.com (Boyd Faulkner) Message-Id: <9510261811.AA28231@olympus> Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! To: mikebo@tellabs.com Date: Thu, 26 Oct 1995 13:11:43 -0500 (CDT) Cc: davidg@Root.COM, hackers@freebsd.org, bugs@freebsd.org In-Reply-To: <9510250245.AA11614@tellabk.tellabs.com> from "mikebo@tellabs.com" at Oct 24, 95 09:45:17 pm X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 4392 Sender: owner-bugs@freebsd.org Precedence: bulk Mike, Is this your rpc problem again, or are you past that now? Last time you had problems of this sort, I recommended using the noconn option for NFS. It was not the solution for you last time but the symptoms I see here seem more in line with this fix. You mount and then all packets start coming from another interface. Using noconn, keeps you from connecting until you know about the new interface. I hope this works for you this time. Boyd > > David G. wrote: > > Mike Borowiec wrote: > > >The following is Solaris snoop output which shows the problem. TOYBOX > > >is running 2.1.0-951020-SNAP and TELLABK (aka SUNK) is a multi-homed > > >server running SunOS 4.1.3 and "routed -q". First we do the mount: > > > > > ># mount tellabk:/export/home/tellabk-4 /usr/home > > > > > > toybox -> tellabk PORTMAP C GETPORT prog=100003 (NFS) vers=2 proto=UDP > > > sunk -> toybox PORTMAP R GETPORT port=2049 > > > toybox -> tellabk PORTMAP C GETPORT prog=100005 (MOUNT) vers=1 proto=UDP > > > sunk -> toybox PORTMAP R GETPORT port=737 > > > toybox -> tellabk MOUNT C Mount /export/home/tellabk-4 > > > sunk -> toybox MOUNT R Mount OK F=075B > > > > > >Looks like the mount completed OK, even though the replies came from SUNK, > > >TELLABK's alter-ego. So let's do a "df": > > > > Yeah, that's the problem. This doesn't look like a FreeBSD problem to me - > > it looks like the Sun is replying out a different interface then it received > > the mount request from. FreeBSD rightfully thinks this is crap coming from > > some irrelevant machine. I think you should be able to work around it by using > > the name/address of "sunk" when doing the mount. > > > Yes, the Sun is replying from a different interface than it received > the mount request from. That's because the Sun is running "routed" and > learns its route back to TOYBOX from a RIP announcement made by a router. > Using the name/addr of SUNK may work today - what if tomorrow the router > decides TELLABK is best, or SUNK2, or SUNK3, etc. > > > "Correct" or not, Suns do not always reply back on the same interface > from which they receive a request. It is basically a crap-shoot... Worse, > if the router dynamically changes the route back to TOYBOX, for whatever > reason (down interface, route optimization), the Sun will dutifully begin > replying on a new interface as soon as the RIP announcement is received. > > This isn't something that can be changed on a Sun. Even configuring a > Sun with static routes won't really solve the problem, as someone/sometime > is bound to request a mount from an interface which is not the server's > default route. In that case, the reply would come from the interface > tagged with the default route. The onus is on the client to deal with it... > > This situation is correctly handled by every commercial UNIX OS I've > worked with. I don't know what security implications that has, but I > do know that FreeBSD's NFS (and so the whole OS) is useless to me > (and others running in a similar environment) unless it works with > Suns and plays by their rules. If I can't use the OS, the security > doesn't do me a damn bit of good! > > I can document this behavior in SunOS, Solaris and HP/UX if it will > help strengthen the argument. This is the real world behavior, and I'm > inclined to believe that FreeBSD is not in a position to dictate what's > "proper behaviour" to Sun (the progenitors of RPC and NFS) and the rest > of the commerical UNIX market. > > > Sorry for the rambling discourse, but I need this fixed or I can't > use FreeBSD. At the least, can the "Sun behavior" I need be added > as an option to the mount command? > - Mike > -- > -------------------------------------------------------------------------- > Michael Borowiec - mikebo@tellabs.com - Tellabs Operations Inc. > Senior Member of Technical Staff 4951 Indiana Avenue, MS 63 > 708-512-8211 FAX: 708-512-7099 Lisle, IL 60532 USA > -------------------------------------------------------------------------- > -- _______________________________________________________________________ Boyd Faulkner - faulkner@isd.tandem.com - http://cactus.org/~faulkner _______________________________________________________________________ From owner-freebsd-bugs Thu Oct 26 11:50:04 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA18300 for bugs-outgoing; Thu, 26 Oct 1995 11:50:04 -0700 Received: (from gnats@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA18294 ; Thu, 26 Oct 1995 11:50:02 -0700 Resent-Date: Thu, 26 Oct 1995 11:50:02 -0700 Resent-Message-Id: <199510261850.LAA18294@freefall.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@freefall.FreeBSD.org, joerg_wunsch@interface-business.de Received: from mail.Germany.EU.net (mail.Germany.EU.net [192.76.144.65]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA17972 for ; Thu, 26 Oct 1995 11:40:10 -0700 Received: by mail.Germany.EU.net with UUCP (5.59:10/EUnetD-2.5.2.e) via EUnet id TAA27505; Thu, 26 Oct 1995 19:38:42 +0100 Received: from ida.interface-business.de (ida.interface-business.de [193.101.57.203]) by innocence.interface-business.de (8.6.11/8.6.9) with ESMTP id TAA00202 for ; Thu, 26 Oct 1995 19:14:33 +0100 Received: (from j@localhost) by ida.interface-business.de (8.6.11/8.6.9) id TAA09770; Thu, 26 Oct 1995 19:12:42 +0100 Message-Id: <199510261812.TAA09770@ida.interface-business.de> Date: Thu, 26 Oct 1995 19:12:42 +0100 From: "J. Wunsch" Reply-To: joerg_wunsch@interface-business.de To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: kern/794: swap partition at offset 0 still broken Sender: owner-bugs@freebsd.org Precedence: bulk >Number: 794 >Category: kern >Synopsis: swap partition at offset 0 still broken >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Oct 26 11:50:01 PDT 1995 >Last-Modified: >Originator: J Wunsch >Organization: >Release: FreeBSD 2.0-BUILT-19950603 i386 >Environment: FreeBSD 2.0.5 >Description: Configuring a swap partition of offset 0 (relative to start of slice) is still broken. Swapping works now, but a kernel core dump has finally been clobbering the disklabel. >How-To-Repeat: Configure a swap partition at offset 0, enable kernel dumps, and cause a panic condition. >Fix: not yet known. >Audit-Trail: >Unformatted: From owner-freebsd-bugs Thu Oct 26 12:23:59 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA19296 for bugs-outgoing; Thu, 26 Oct 1995 12:23:59 -0700 Received: from devnull (devnull.mpd.tandem.com [131.124.4.29]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA19291 ; Thu, 26 Oct 1995 12:23:57 -0700 Received: from olympus by devnull (8.6.8/8.6.6) id OAA00203; Thu, 26 Oct 1995 14:23:14 -0500 Received: by olympus (4.1/TSS2.1) id AA28585; Thu, 26 Oct 95 14:23:11 CDT From: faulkner@mpd.tandem.com (Boyd Faulkner) Message-Id: <9510261923.AA28585@olympus> Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! To: mikebo@tellabs.com Date: Thu, 26 Oct 1995 14:23:10 -0500 (CDT) Cc: davew@sees.bangor.ac.uk, bugs@freebsd.org, hackers@freebsd.org In-Reply-To: <199510261417.JAA01701@sunc210.tellabs.com> from "mikebo@tellabs.com" at Oct 26, 95 09:17:03 am X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 1696 Sender: owner-bugs@freebsd.org Precedence: bulk > > Dave wrote: > > > Garrett wrote: > > > > Actually, connect(2) is what is presently being done and part of what > > > > causes the breakage. From mount_nfs(8): > > > > > > > > -c For UDP mount points, do not do a connect(2). This must be used > > > > for servers that do not reply to requests from the standard NFS > > > > port number 2049. > > > > > > > Wahoo! This option did the trick, even though the ip_addrs didn't match. > > > This option did _not_ work under 2.0.5R, due to bad hackage of the RPC > > ^^^^^ > > I beg to differ, we are using 2.0.5R (from the CD) and > > it _was_ the solution to our problem! > > > > > code in libc. It does seem to work under 2.1.0-951020-SNAP! Come to > > > think of it, the "bad hackage" was, in fact, a connect() being done in > > > lib/libc/rpc/clnt_udp.c. > > > I did try "noconn" while monitoring with snoop and a Sniffer, and under > 2.0.5R (from the CD also), it did not solve the problem of differing > ip_addrs. My traces showed ICMP Destination unreachable (Bad port) with > or without noconn. But, there's no arguing with results. I couldn't get > it to work, and documented it months ago. No sense going back now... > - Mike > -- I remember seeing it, too. Oddly enough, the rpc problem did not affect amd which was handling my mounts. (I was already running with noconn.) But, if I tried to connect with mount, it would fail. Boyd -- _______________________________________________________________________ Boyd Faulkner - faulkner@isd.tandem.com - http://cactus.org/~faulkner _______________________________________________________________________ From owner-freebsd-bugs Thu Oct 26 15:08:39 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA29815 for bugs-outgoing; Thu, 26 Oct 1995 15:08:39 -0700 Received: from tellab5.lisle.tellabs.com (tellab5.lisle.tellabs.com [138.111.243.28]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id PAA29801 ; Thu, 26 Oct 1995 15:08:29 -0700 From: mikebo@tellabs.com Received: from sunc210.tellabs.com by tellab5.lisle.tellabs.com with smtp (Smail3.1.29.1 #4) id m0t8aSZ-000jCvC; Thu, 26 Oct 95 17:07 CDT Received: by sunc210.tellabs.com (SMI-8.6/1.9) id RAA00763; Thu, 26 Oct 1995 17:07:34 -0500 Message-Id: <199510262207.RAA00763@sunc210.tellabs.com> Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! To: faulkner@mpd.tandem.com (Boyd Faulkner) Date: Thu, 26 Oct 1995 17:07:33 -0500 (CDT) Cc: mikebo (Mike Borowiec), davidg@Root.COM, hackers@freebsd.org, bugs@freebsd.org In-Reply-To: <9510261811.AA28231@olympus> from "Boyd Faulkner" at Oct 26, 95 01:11:43 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-bugs@freebsd.org Precedence: bulk Boyd wrote: > Is this your rpc problem again, or are you past that now? Last time you > had problems of this sort, I recommended using the noconn option for NFS. > It was not the solution for you last time but the symptoms I see here seem > more in line with this fix. You mount and then all packets start coming > from another interface. Using noconn, keeps you from connecting until you > know about the new interface. I hope this works for you this time. > -------------------------------------------------------------------------- PROBLEM DEFINITION: Server: Multi-homed Sun server running routed (receiving routes via RIP) Client: distant FreeBSD 2.x client (not on any of the servers ethernets) The Server's IP route to Client's network is unknown, and may change whenever the Server receives a RIP update from router. The following scenarios assume that: 1) The client is not on any network to which the server has a direct ethernet connection. 2) Packets arrive from the client on server's ethernet interface 'A'. 3) The server's route table contains a route to the client's network. 4) The route in 3) causes packets sent to the client to leave server's ethernet interface 'B'. Result: reply source address is different than request destination address. Under 2.0.5R (with or without noconn option): MOUNT command hangs unkillable on Client. Client reaction: ICMP message "Destination unreachable (Bad port)" sent to responding IP address. Under 2.1.0-951020-SNAP (without noconn option): MOUNT command completes OK. Provided no other access to the file- system are attempted first, UMOUNT also completes OK. However, any commands which access the now mounted filesystem (such as df or ls) hang unkillable and file system can not be UMOUNTED. Client reaction: ICMP message "Destination unreachable (Bad port)" sent to responding IP address. Under 2.1.0-951020-SNAP (with noconn option): MOUNT and UMOUNT command completes OK. All accesses to mounted filesystem complete OK. Everything appears OK. This is the normal behaviour of most major commercial UNIX and UNIX-like OSes. -------------------------------------------------------------------------- Hopefully, this is the last time I need to document this. ;v) I do have a question: Would a FreeBSD server always respond to a client from the same interface on which it received a request - even though its route table has a different route to the clients network? - Mike -- -------------------------------------------------------------------------- Michael Borowiec - mikebo@tellabs.com - Tellabs Operations Inc. Senior Member of Technical Staff 4951 Indiana Avenue, MS 63 708-512-8211 FAX: 708-512-7099 Lisle, IL 60532 USA -------------------------------------------------------------------------- From owner-freebsd-bugs Fri Oct 27 03:09:20 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA10804 for bugs-outgoing; Fri, 27 Oct 1995 03:09:20 -0700 Received: from gateway.sequent.com (gateway.sequent.com [138.95.18.1]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id DAA10799 for ; Fri, 27 Oct 1995 03:09:15 -0700 Received: from crg8.sequent.com (crg8.sequent.com [138.95.19.9]) by gateway.sequent.com (8.6.12/8.6.9) with ESMTP id DAA02704 for ; Fri, 27 Oct 1995 03:06:04 -0700 Received: from localhost (bjj@localhost) by crg8.sequent.com (8.6.12/8.6.9) with SMTP id DAA29250 for ; Fri, 27 Oct 1995 03:06:57 -0700 Message-Id: <199510271006.DAA29250@crg8.sequent.com> X-Authentication-Warning: crg8.sequent.com: Host localhost didn't use HELO protocol To: bugs@freebsd.org Subject: bug in /bin/sh for loops Date: Fri, 27 Oct 95 03:06:55 PDT From: Ben Jackson Sender: owner-bugs@freebsd.org Precedence: bulk [FreeBSD 2.1.0 951005-SNAP] The appended shell script doesn't have the expected output. The first half executes a loop which prints 0, 1, 2. The second half introduces a simple background job during each loop iteration. It seems that at the point where you run a background job in a { } list, the shell forks and the rest of the {} list runs in the new shell. This results in the value of VAR being lost (hence output 0,0,0) and having the main shell exit before the loop finishes running. All of the other shell-local information is also lost (jobs list, etc). Every other shell that claimed Bourne shell compatibility (zsh, ksh, AT&T sh) that I tried it on did what you'd expect. --Ben VAR=0 for X in 1 2 3 do echo $VAR VAR=$X done VAR=0 for X in 1 2 3 do echo $VAR VAR=$X /bin/ls > /dev/null & done From owner-freebsd-bugs Fri Oct 27 07:11:03 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA20467 for bugs-outgoing; Fri, 27 Oct 1995 07:11:03 -0700 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id HAA20462 for ; Fri, 27 Oct 1995 07:10:59 -0700 Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA22857; Fri, 27 Oct 1995 10:10:51 -0400 Date: Fri, 27 Oct 1995 10:10:51 -0400 From: "Garrett A. Wollman" Message-Id: <9510271410.AA22857@halloran-eldar.lcs.mit.edu> To: mikebo@tellabs.com Cc: bugs@freebsd.org Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! In-Reply-To: <199510262207.RAA00763@sunc210.tellabs.com> References: <9510261811.AA28231@olympus> <199510262207.RAA00763@sunc210.tellabs.com> Sender: owner-bugs@freebsd.org Precedence: bulk < I do have a question: > Would a FreeBSD server always respond to a client from the same interface > on which it received a request - even though its route table has a > different route to the clients network? No. Source address != interface. If the source address is already set in the outgoing IP packet, ip_output() will not change it even if the packet goes out an interface which does not have that address on it. (Otherwise forwarding would not work!) From ip_output: /* * If source address not specified yet, use address * of outgoing interface. */ if (ip->ip_src.s_addr == INADDR_ANY) ip->ip_src = IA_SIN(ia)->sin_addr; You can force UDP to fill in a specific source address by calling bind(). A correct implementation of ANY UDP-based protocol will get a list of interfaces and create a single, bound socket per interface address. (Half the glue to obviate this problem is present in the kernel.) -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-bugs Fri Oct 27 08:07:04 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA22959 for bugs-outgoing; Fri, 27 Oct 1995 08:07:04 -0700 Received: from tellab5.lisle.tellabs.com (tellab5.lisle.tellabs.com [138.111.243.28]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id IAA22936 ; Fri, 27 Oct 1995 08:06:56 -0700 From: mikebo@tellabs.com Received: from sunc210.tellabs.com by tellab5.lisle.tellabs.com with smtp (Smail3.1.29.1 #4) id m0t8qMP-000jBiC; Fri, 27 Oct 95 10:06 CDT Received: by sunc210.tellabs.com (SMI-8.6/1.9) id KAA00739; Fri, 27 Oct 1995 10:06:14 -0500 Message-Id: <199510271506.KAA00739@sunc210.tellabs.com> Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! To: wollman@lcs.mit.edu (Garrett A. Wollman) Date: Fri, 27 Oct 1995 10:06:13 -0500 (CDT) Cc: mikebo (Mike Borowiec), bugs@freebsd.org, hackers@freebsd.org In-Reply-To: <9510271410.AA22857@halloran-eldar.lcs.mit.edu> from "Garrett A. Wollman" at Oct 27, 95 10:10:51 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-bugs@freebsd.org Precedence: bulk Garret wrote: > < > I do have a question: > > Would a FreeBSD server always respond to a client from the same interface > > on which it received a request - even though its route table has a > > different route to the clients network? > > No. Source address != interface. If the source address is already > set in the outgoing IP packet, ip_output() will not change it even if > the packet goes out an interface which does not have that address on > it. (Otherwise forwarding would not work!) > So, a multi-homed FreeBSD NFS server would behave the same as a multi- homed Sun NFS server and adhere to the route table. That's what I thought, but is contrary to some grumblings I've heard about the way Sun serves NFS. Some people have sworn that the "proper" thing for the server to do is send replies out the same interface that received the request - evidently not caring whether it adhered to the route table or not. The bottom line is that people mounting filesystems from a multi-homed FreeBSD server could potentially run into the same problem I experienced (NFS replies with a different source addr than the request's destination addr), and be forced to use the "noconn" option. So much for my feeling bad about using those damn rogue Suns. ;v) Since, in this situation, the FreeBSD NFS client doesn't behave according to the "Industry standard" (requires a special option to mount), perhaps this issue should be included in the FAQ. Even though it is not an issue that pops up _frequently_, it is a real hair-puller. Since posting my problem, I've had several people write saying they had the same experience, and it took several days until some kind soul pointed out the deprecated noconn option, which is buried in the mount_nfs man page. Hopefully, deprecated doesn't mean it will be removed anytime soon. ;v) Regards, - Mike -- -------------------------------------------------------------------------- Michael Borowiec - mikebo@tellabs.com - Tellabs Operations Inc. Senior Member of Technical Staff 4951 Indiana Avenue, MS 63 708-512-8211 FAX: 708-512-7099 Lisle, IL 60532 USA -------------------------------------------------------------------------- From owner-freebsd-bugs Fri Oct 27 08:32:59 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA25161 for bugs-outgoing; Fri, 27 Oct 1995 08:32:59 -0700 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id IAA25149 for ; Fri, 27 Oct 1995 08:32:55 -0700 Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA22796; Fri, 27 Oct 1995 11:32:53 -0400 Date: Fri, 27 Oct 1995 11:32:53 -0400 From: "Garrett A. Wollman" Message-Id: <9510271532.AA22796@halloran-eldar.lcs.mit.edu> To: mikebo@tellabs.com Cc: bugs@freebsd.org Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! In-Reply-To: <199510271506.KAA00739@sunc210.tellabs.com> References: <9510271410.AA22857@halloran-eldar.lcs.mit.edu> <199510271506.KAA00739@sunc210.tellabs.com> Sender: owner-bugs@freebsd.org Precedence: bulk [CCs trimmed AGAIN] <> No. Source address != interface. If the source address is already >> set in the outgoing IP packet, ip_output() will not change it even if >> the packet goes out an interface which does not have that address on >> it. (Otherwise forwarding would not work!) >> > So, a multi-homed FreeBSD NFS server would behave the same as a multi- > homed Sun NFS server and adhere to the route table. No, that's not what I said. A multi-homed FreeBSD NFS server would always send replies with a source address precisely the same as the destination address from the request, regardless of the interface the request arrived on or the reply will be sent on. > serves NFS. Some people have sworn that the "proper" thing for the server > to do is send replies out the same interface that received the > request - The interface is irrelevant. What matters is the addresses involved. > evidently not caring whether it adhered to the route table or not. ``adhered to the route table'' is not meaningful. > Since posting my problem, I've had several people write saying they had > the same experience, and it took several days until some kind soul pointed > out the deprecated noconn option, which is buried in the mount_nfs man page. The `-c' option is not deprecated (and probably won't be in light of the tremendous population of broken servers out there). It's the `noconn' syntax for it that is deprecated. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-bugs Fri Oct 27 10:08:08 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA04406 for bugs-outgoing; Fri, 27 Oct 1995 10:08:08 -0700 Received: from tribe.com (tribe.com [199.35.172.35]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA04397 for ; Fri, 27 Oct 1995 10:08:06 -0700 Received: from [205.184.207.4] ([205.184.207.4]) by tribe.com (8.6.11/8.6.9) with SMTP id KAA08844 for ; Fri, 27 Oct 1995 10:07:51 -0700 Date: Fri, 27 Oct 1995 10:07:51 -0700 Message-Id: <199510271707.KAA08844@tribe.com> X-Sender: kedron@tribe.tribe.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: bugs@freebsd.org From: kedron@tribe.com (Kedron Wolcott) Subject: 2.0.5 mktemp bug. Sender: owner-bugs@freebsd.org Precedence: bulk Hello! Sorry about not filing this report with the send-pr command, but I'm just learning Unix now and I don't have the mail program up. However, I do think this is a bug. The program --------- #include void main ( void ) { mktemp( "/tmp/tmp.XXXX" ); } --------- gives me a bus-error core dump. I'm running FreeBSD release 2.0.5 #0, and I compiled the program with GCC-2.6.3. Thanks. Kedron Wolcott From owner-freebsd-bugs Fri Oct 27 10:16:51 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA05699 for bugs-outgoing; Fri, 27 Oct 1995 10:16:51 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA05675 for ; Fri, 27 Oct 1995 10:16:45 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id LAA04338; Fri, 27 Oct 1995 11:18:55 -0600 Date: Fri, 27 Oct 1995 11:18:55 -0600 From: Nate Williams Message-Id: <199510271718.LAA04338@rocky.sri.MT.net> To: kedron@tribe.com (Kedron Wolcott) Cc: bugs@freebsd.org Subject: Re: 2.0.5 mktemp bug. In-Reply-To: <199510271707.KAA08844@tribe.com> References: <199510271707.KAA08844@tribe.com> Sender: owner-bugs@freebsd.org Precedence: bulk > Sorry about not filing this report with the send-pr command, but I'm just > learning Unix now and I don't have the mail program up. > > However, I do think this is a bug. The program > > --------- > #include > > void > main ( void ) > { > mktemp( "/tmp/tmp.XXXX" ); > } > --------- > > gives me a bus-error core dump. As well it should. This is the exepected behavior. From the manpage. The mktemp() function takes the given file name template and overwrites a portion of it to create a file name. The routine is attempting to write to a constant string, which it can't so it cores. You need to give a writeable memory location to mktemp(). Nate From owner-freebsd-bugs Fri Oct 27 10:17:04 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA05734 for bugs-outgoing; Fri, 27 Oct 1995 10:17:04 -0700 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id KAA05728 for ; Fri, 27 Oct 1995 10:17:02 -0700 Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA23164; Fri, 27 Oct 1995 13:16:48 -0400 Date: Fri, 27 Oct 1995 13:16:48 -0400 From: "Garrett A. Wollman" Message-Id: <9510271716.AA23164@halloran-eldar.lcs.mit.edu> To: kedron@tribe.com (Kedron Wolcott) Cc: bugs@freebsd.org Subject: 2.0.5 mktemp bug. In-Reply-To: <199510271707.KAA08844@tribe.com> References: <199510271707.KAA08844@tribe.com> Sender: owner-bugs@freebsd.org Precedence: bulk < However, I do think this is a bug. The program > --------- > #include > void > main ( void ) > { > mktemp( "/tmp/tmp.XXXX" ); > } > --------- Your program is wrong. String literals are not modifiable. The correct code is as follows: int /* NB: not void */ main(void) { char name[] = "/tmp/tmp.XXXX"; mktemp(name); /* NB: using modifiable array, not a literal */ return 0; } -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-bugs Fri Oct 27 10:36:45 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA07150 for bugs-outgoing; Fri, 27 Oct 1995 10:36:45 -0700 Received: from tellab5.lisle.tellabs.com (tellab5.lisle.tellabs.com [138.111.243.28]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id KAA07141 ; Fri, 27 Oct 1995 10:36:40 -0700 From: mikebo@tellabs.com Received: from sunc210.tellabs.com by tellab5.lisle.tellabs.com with smtp (Smail3.1.29.1 #4) id m0t8shM-000jC3C; Fri, 27 Oct 95 12:36 CDT Received: by sunc210.tellabs.com (SMI-8.6/1.9) id MAA00863; Fri, 27 Oct 1995 12:36:01 -0500 Message-Id: <199510271736.MAA00863@sunc210.tellabs.com> Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! To: davidg@Root.COM Date: Fri, 27 Oct 1995 12:36:00 -0500 (CDT) Cc: mikebo (Mike Borowiec), wollman@lcs.mit.edu, hackers@freebsd.org, bugs@freebsd.org In-Reply-To: <199510271645.JAA00169@corbin.Root.COM> from "David Greenman" at Oct 27, 95 09:45:52 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-bugs@freebsd.org Precedence: bulk David wrote: > >Garret wrote: > ... > >> No. Source address != interface. > ... > I think you might be confusing this a bit. As was said above, just because > the packet goes out an interface because of a prefered route doesn't mean that > it will have that interface's address. ... chop ... Dohhhhh! I see the light... been working with Suns too long. ;v) Can anyone point me at a document that describes the proper, 4.4BSD operation vs. the old, insecure method? I'm assuming this is an RFC or architectural paper? Thanks everyone for your patience. - Mike -- -------------------------------------------------------------------------- Michael Borowiec - mikebo@tellabs.com - Tellabs Operations Inc. Senior Member of Technical Staff 4951 Indiana Avenue, MS 63 708-512-8211 FAX: 708-512-7099 Lisle, IL 60532 USA -------------------------------------------------------------------------- From owner-freebsd-bugs Fri Oct 27 12:13:36 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA13613 for bugs-outgoing; Fri, 27 Oct 1995 12:13:36 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA13604 for ; Fri, 27 Oct 1995 12:13:32 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id FAA24825; Sat, 28 Oct 1995 05:12:01 +1000 Date: Sat, 28 Oct 1995 05:12:01 +1000 From: Bruce Evans Message-Id: <199510271912.FAA24825@godzilla.zeta.org.au> To: bugs@freebsd.org, kedron@tribe.com Subject: Re: 2.0.5 mktemp bug. Sender: owner-bugs@freebsd.org Precedence: bulk >However, I do think this is a bug. The program >--------- >#include >void >main ( void ) >{ > mktemp( "/tmp/tmp.XXXX" ); >} >--------- >gives me a bus-error core dump. I'm running FreeBSD release 2.0.5 #0, and >I compiled the program with GCC-2.6.3. mktemp() modifies the string passed to it, so the string must be in writable storage. String constants are read only in FreeBSD+gcc. You should copy the string constant to a suitable large non-const array, e.g., `char foo[32]'. Bruce From owner-freebsd-bugs Fri Oct 27 18:50:03 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA04109 for bugs-outgoing; Fri, 27 Oct 1995 18:50:03 -0700 Received: (from gnats@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA04103 ; Fri, 27 Oct 1995 18:50:01 -0700 Resent-Date: Fri, 27 Oct 1995 18:50:01 -0700 Resent-Message-Id: <199510280150.SAA04103@freefall.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@freefall.FreeBSD.org, gordon@sneaky.lerctr.org Received: from lerami.lerctr.org (lerami.lerctr.org [206.85.10.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id SAA03951 for ; Fri, 27 Oct 1995 18:45:23 -0700 Received: from rwsys by lerami.lerctr.org with uucp (Smail3.1.29.1 #4 /\oo/\) id ; Fri, 27 Oct 95 20:45 Received: by rwsys.lonestar.org (Smail3.1.27.1 #1) id m0t8rCb-00002uC; Fri, 27 Oct 95 11:00 CDT Received: by hammy.lerctr.org (Smail3.1.29.1 #1) id m0t8ktz-0000FzC; Fri, 27 Oct 95 04:16 CDT Message-Id: Date: Fri, 27 Oct 95 04:16 CDT From: gordon@sneaky.lerctr.org Reply-To: gordon@sneaky.lerctr.org To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: kern/795: sysctl lets ordinary users lock up system Sender: owner-bugs@freebsd.org Precedence: bulk >Number: 795 >Category: kern >Synopsis: sysctl lets ordinary users lock up system >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Oct 27 18:50:00 PDT 1995 >Last-Modified: >Originator: Gordon Burditt >Organization: >Release: FreeBSD 2.0-BUILT-19950603 i386 >Environment: FreeBSD 2.0.5R syscons console driver 486DX/33 CPU >Description: Attempting to retrieve the sysctl() information from kern.vnode locks up the system some of the time. The lock is probably on the vnode table (ps won't run), and you cannot log in on another terminal/virtual console, execute ps on any terminal/virtual console already logged in, ^C or ^Z out of the program, or much of anything else. Some UUCP conversations continue, but they may not last past the point of needing to switch files. >How-To-Repeat: Run the following program several times as an unprivileged user. I always had it lock up the system within 3 tries, usually 1 or 2. If it makes a difference, I always ran it from a syscons virtual console. When it's locked up, you cannot interrupt the program with ^C or ^Z, you cannot log in on another virtual terminal or serial port (You never get the password: prompt), ps never finishes, and to get anything useful done, you have to reboot. Don't run this program unless you are prepared to reboot. /* sysctlcrash.c */ # include # include # include # include int main(int argc, char **argv) { int ret; int mib[6]; int len; char buffer[8192]; mib[0] = CTL_KERN; mib[1] = KERN_VNODE; len = 8192; ret = sysctl(mib, 2, buffer, &len, NULL, 0); exit(0); } >Fix: This code section was derived from a piece of code intended to treewalk the MIB, uh, "filesystem", and find all the stuff sysctl -A misses, so I set it up to avoid this particular combination, but I don't have a fix. I also find it interesting that both EISDIR and ENOTDIR indicate that the name I have chosen is not terminal and I should lengthen it. Gordon L. Burditt sneaky.lerctr.org!gordon >Audit-Trail: >Unformatted: From owner-freebsd-bugs Fri Oct 27 22:10:03 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA13399 for bugs-outgoing; Fri, 27 Oct 1995 22:10:03 -0700 Received: (from gnats@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA13379 ; Fri, 27 Oct 1995 22:10:01 -0700 Resent-Date: Fri, 27 Oct 1995 22:10:01 -0700 Resent-Message-Id: <199510280510.WAA13379@freefall.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@freefall.FreeBSD.org, uhclem@fw.ast.com Received: from ast.com (irvine.ast.com [165.164.128.2]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id WAA13248 for ; Fri, 27 Oct 1995 22:07:39 -0700 Received: from fw.ast.com by ast.com with SMTP id AA03095 (5.67b/IDA-1.5 for ); Fri, 27 Oct 1995 22:08:48 -0700 Received: from nemesis by fw.ast.com with uucp (Smail3.1.29.1 #4) id m0t93PX-000086C; Sat, 28 Oct 95 00:02 CDT Received: by nemesis.lonestar.org (Smail3.1.27.1 #19) id m0t93D5-000IvJC; Fri, 27 Oct 95 23:49 WET DST Message-Id: Date: Fri, 27 Oct 95 23:49 WET DST From: uhclem%nemesis@fw.ast.com Reply-To: uhclem@fw.ast.com To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: misc/796: Network install incomplete in 1026-SNAP FDIV036 Sender: owner-bugs@freebsd.org Precedence: bulk >Number: 796 >Category: misc >Synopsis: Network install doesn't update /etc/hosts FDIV036 >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Oct 27 22:10:00 PDT 1995 >Last-Modified: >Originator: Frank Durda IV >Organization: none >Release: FreeBSD 2.1.0-951026-SNAP >Environment: Fresh install of 2.1.0-951026-SNAP on local ethernet network. Install was via FTP. >Description: After performing a successfull installation of a 1026 SNAP system using FTP from "another site", (which means I had to describe the network interface, IP number and other IP-ish details), all appears OK. In my case, the IP was 165.164.6.19 and the download was from 165.164.6.15. The mask was 255.255.0.0, the 1026 system was named skaro.lonestar.org. The remote system was nemesis.lonestar.org (165.164.6.15). However, on the first reboot, several error messages are displayed during the start-up process: ... skaro.lonestar.org: bad value [1] skaro.lonestar.org: bad value ... standard daemons: cron printer sendmailMy host name (skaro.lonestar.org) does not seem to exist! Connection refused [2] . <--- [3] Period on its own line. Oct 27 23:24:52 skaro sendmail[90]: NOQUEUE: SYSERR(root): My host name (skaro.lonestar.org) does not seem to exist!: (Connection refused) [2] . <--- [3] Period on its own line. On logging-in, none of the networking services work correctly. The problem appears to be that the installation process enabled networking, but did not use the information gathered during the installation to create an entry for /etc/hosts. By adding: 165.164.6.19 skaro.lonestar.org skaro to /etc/hosts, and rebooting, all errors went away. These are the same parameters entered during the installation process. Note that I only had a single network interface, and I did not run "Network Configuration" after the install was complete because it implies that you only needed to do this if you had multiple interfaces or were going to change things previously set, or turn on something like NFS. (I don't know if running Network Configuration a second time would have made any difference.) >How-To-Repeat: You can repeat it by doing a network installation. You probably can recreate similar errors by deleting the contents of /etc/hosts and rebooting. >Fix: Have the installation program stick an entry for the machine being installed in /etc/hosts. If a FTP installation was done, the installation system has all the information needed to make the entry. It also appears sendmail needs its error message fixed so that the trailing "." doesn't end up on its own line. The extra "." does not appear in /var/log/messages, but the rest of the error message does. The source of the "bad value" error also needs to be investigated. This message is displayed but does not appear in /var/log/messages. >Audit-Trail: >Unformatted: From owner-freebsd-bugs Fri Oct 27 22:10:04 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA13404 for bugs-outgoing; Fri, 27 Oct 1995 22:10:04 -0700 Received: (from gnats@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA13391 ; Fri, 27 Oct 1995 22:10:02 -0700 Resent-Date: Fri, 27 Oct 1995 22:10:02 -0700 Resent-Message-Id: <199510280510.WAA13391@freefall.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@freefall.FreeBSD.org, uhclem@fw.ast.com Received: from ast.com (irvine.ast.com [165.164.128.2]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id WAA13252 for ; Fri, 27 Oct 1995 22:07:41 -0700 Received: from fw.ast.com by ast.com with SMTP id AA03099 (5.67b/IDA-1.5 for ); Fri, 27 Oct 1995 22:08:50 -0700 Received: from nemesis by fw.ast.com with uucp (Smail3.1.29.1 #4) id m0t93PY-000083C; Sat, 28 Oct 95 00:02 CDT Received: by nemesis.lonestar.org (Smail3.1.27.1 #19) id m0t93Kr-000IvJC; Fri, 27 Oct 95 23:57 WET DST Message-Id: Date: Fri, 27 Oct 95 23:57 WET DST From: uhclem%nemesis@fw.ast.com Reply-To: uhclem@fw.ast.com To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: bin/797: X probeonly during install gets Not Found error FDIV037 Sender: owner-bugs@freebsd.org Precedence: bulk >Number: 797 >Category: bin >Synopsis: X probeonly during install gets Not Found error FDIV037 >Confidential: no >Severity: non-critical >Priority: high >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Oct 27 22:10:01 PDT 1995 >Last-Modified: >Originator: Frank Durda IV >Organization: >Release: FreeBSD 2.1.0-951026-SNAP >Environment: 1026 system freshly installed and still running from boot floppy (not yet rebooted.) >Description: After a successful installation, if you have installed X and elect to configure X, at one point it asks if you would like to set up a Symlink X to start X. I answered "yes". A few dozen questions later when configuring my video board, I was offered the chance to test the clock settings by doing a probeonly. When this was attempted, I get a "X: Command not found.", so the probeonly is not performed. It appears the symlink is not yet in place or is not in the right place for where the X configuration is looking. >How-To-Repeat: See above. >Fix: >Audit-Trail: >Unformatted: From owner-freebsd-bugs Sat Oct 28 01:05:23 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA21953 for bugs-outgoing; Sat, 28 Oct 1995 01:05:23 -0700 Received: (from pst@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA21930 ; Sat, 28 Oct 1995 01:05:16 -0700 Date: Sat, 28 Oct 1995 01:05:16 -0700 From: Paul Traina Message-Id: <199510280805.BAA21930@freefall.freebsd.org> To: fortin@acm.org, pst, freebsd-bugs Subject: Re: bin/163 Sender: owner-bugs@FreeBSD.org Precedence: bulk Synopsis: telneting sometimes doesn't yield a "login:" prompt until is hit State-Changed-From-To: open-closed State-Changed-By: pst State-Changed-When: Sat Oct 28 01:02:02 PDT 1995 State-Changed-Why: Bug was fixed on 9/5/95. From owner-freebsd-bugs Sat Oct 28 01:12:03 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA22553 for bugs-outgoing; Sat, 28 Oct 1995 01:12:03 -0700 Received: (from pst@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA22520 ; Sat, 28 Oct 1995 01:11:58 -0700 Date: Sat, 28 Oct 1995 01:11:58 -0700 From: Paul Traina Message-Id: <199510280811.BAA22520@freefall.freebsd.org> To: pst@Shockwave.COM, pst, freebsd-bugs Subject: Re: kern/280 Sender: owner-bugs@FreeBSD.org Precedence: bulk Synopsis: the new slice code is bitching about my old slices State-Changed-From-To: open-closed State-Changed-By: pst State-Changed-When: Sat Oct 28 01:10:55 PDT 1995 State-Changed-Why: No longer relevant. From owner-freebsd-bugs Sat Oct 28 01:53:51 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA26192 for bugs-outgoing; Sat, 28 Oct 1995 01:53:51 -0700 Received: (from bde@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA26156 ; Sat, 28 Oct 1995 01:53:48 -0700 Date: Sat, 28 Oct 1995 01:53:48 -0700 From: Bruce Evans Message-Id: <199510280853.BAA26156@freefall.freebsd.org> To: gordon@sneaky.lerctr.org, bde, freebsd-bugs Subject: Re: kern/795 Sender: owner-bugs@FreeBSD.org Precedence: bulk Synopsis: sysctl lets ordinary users lock up system State-Changed-From-To: open-closed State-Changed-By: bde State-Changed-When: Sat Oct 28 01:50:25 PDT 1995 State-Changed-Why: Fixed in revision 1.36 of vfs_subr.c by cleaning up properly before the error returns. From owner-freebsd-bugs Sat Oct 28 04:30:17 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id EAA05120 for bugs-outgoing; Sat, 28 Oct 1995 04:30:17 -0700 Received: (from gnats@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id EAA05103 for freebsd-bugs; Sat, 28 Oct 1995 04:30:14 -0700 Date: Sat, 28 Oct 1995 04:30:14 -0700 From: GNU GNATS Message-Id: <199510281130.EAA05103@freefall.freebsd.org> To: freebsd-bugs Subject: Summary of Problem Reports Sender: owner-bugs@FreeBSD.org Precedence: bulk Number of currently open reports: 305 Number of curently analyzed reports: 13 From owner-freebsd-bugs Sat Oct 28 07:14:12 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA14184 for bugs-outgoing; Sat, 28 Oct 1995 07:14:12 -0700 Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA14179 for ; Sat, 28 Oct 1995 07:14:08 -0700 Received: from uucp6.UU.NET by relay5.UU.NET with SMTP id QQznki17826; Sat, 28 Oct 1995 10:14:04 -0400 (EDT) Received: from uanet.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Sat, 28 Oct 1995 10:14:04 -0400 Received: by crocodil.monolit.kiev.ua; Sat, 28 Oct 95 16:11:48 +0200 Received: from dog.farm.org (farm-cs.farm.org [193.124.48.230]) by clipper.cs.kiev.ua (8.6.4) with ESMTP id QAA20030 for ; Sat, 28 Oct 1995 16:05:50 +0200 Received: (from dk@localhost) by dog.farm.org (MK54/dk1) id QAA06981 for freebsd-bugs@freebsd.org; Sat, 28 Oct 1995 16:08:17 +0200 From: Dmitry Kohmanyuk Message-Id: <199510281408.QAA06981@dog.farm.org> Subject: 2.0.5-RELEASE: NFS cannot export 2 dirs on 1 partition? To: freebsd-bugs@freebsd.org Date: Sat, 28 Oct 1995 14:08:15 +0000 () Reply-To: dk+@ua.net X-Class: Fast X-OS-Of-Choice: FreeBSD 2.0.5-RELEASE X-NIC-Handle: DK379 X-Mailer: ELM [version 2.4 PL22 dk9] Content-Type: text Sender: owner-bugs@freebsd.org Precedence: bulk hi fellow FBSD'ers, I got the following problem with 2.0.5-RELEASE NFS server: I have 3 disk partitions on my HD, /, /usr, and /xvar. I want to have 4 exported dirs, /usr/src, /usr/ports, /xvar/ftp and /xvar/pubhome. first, I have set up /etc/exports so only /usr/src and /xvar/ftp were exported. That was all fine. then, I have added two more dirs, namely, /usr/ports and /xvar/pubhome. when I do kill -1 mountd_pid (or just reboot the system), it says: (not screenshot, but should be close) can't change attributes for /usr/ports bad exports list line /usr/ports [machines where dir in exported to] and same for /xvar/pubhome. Am I missing something? (maybe 2.1-STABLE? ;-)) other glitch: really, I have somewhat nicer names for them, like /r/ftp, /r/src.fbsd, etc, and local symlinks on NFS server, but it seems that FreeBSD cannot export path with symlinks (remote mounts of these names work ok - server translates them to real names correctly). So now I have to list real paths in /etc/exports and can use symlinks on clients. Is this corrected in newer versions? AFAIK, Solaris can export (`share') symlinks just fine (they appear resolved in `showmount' output, well). please Cc: replies to me (I'm not receiving -bugs just now). From owner-freebsd-bugs Sat Oct 28 07:55:51 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA16909 for bugs-outgoing; Sat, 28 Oct 1995 07:55:51 -0700 Received: from sunny.bog.msu.su (dima@sunny.bog.msu.su [158.250.20.1]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA16880 for ; Sat, 28 Oct 1995 07:55:40 -0700 Received: (from dima@localhost) by sunny.bog.msu.su (8.6.12/8.6.12) id RAA27191; Sat, 28 Oct 1995 17:51:45 +0300 Date: Sat, 28 Oct 1995 17:51:41 +0300 (????) From: Dmitry Khrustalev To: dk+@ua.net cc: freebsd-bugs@freebsd.org Subject: Re: 2.0.5-RELEASE: NFS cannot export 2 dirs on 1 partition? In-Reply-To: <199510281408.QAA06981@dog.farm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-bugs@freebsd.org Precedence: bulk On Sat, 28 Oct 1995, Dmitry Kohmanyuk wrote: > hi fellow FBSD'ers, > > I got the following problem with 2.0.5-RELEASE NFS server: > > I have 3 disk partitions on my HD, /, /usr, and /xvar. > I want to have 4 exported dirs, /usr/src, /usr/ports, > /xvar/ftp and /xvar/pubhome. > > first, I have set up /etc/exports so only /usr/src and /xvar/ftp > were exported. That was all fine. > > then, I have added two more dirs, namely, /usr/ports and /xvar/pubhome. > when I do kill -1 mountd_pid (or just reboot the system), it says: > (not screenshot, but should be close) > > can't change attributes for /usr/ports > bad exports list line /usr/ports [machines where dir in exported to] > > and same for /xvar/pubhome. > This is intended behavior. You can have only one export per filesystem. Check -alldirs export option, maybe it will help you. -Dima. From owner-freebsd-bugs Sat Oct 28 09:53:15 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA28610 for bugs-outgoing; Sat, 28 Oct 1995 09:53:15 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA28588 for ; Sat, 28 Oct 1995 09:53:08 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id RAA23928; Sat, 28 Oct 1995 17:50:47 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id RAA06251; Sat, 28 Oct 1995 17:50:46 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id QAA06414; Sat, 28 Oct 1995 16:33:15 +0100 From: J Wunsch Message-Id: <199510281533.QAA06414@uriah.heep.sax.de> Subject: Re: 2.0.5 mktemp bug. To: kedron@tribe.com Date: Sat, 28 Oct 1995 16:33:15 +0100 (MET) Cc: bugs@freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199510271912.FAA24825@godzilla.zeta.org.au> from "Bruce Evans" at Oct 28, 95 05:12:01 am 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: 793 Sender: owner-bugs@freebsd.org Precedence: bulk As Bruce Evans wrote: > > You should copy the string constant to a suitable large non-const ^^^^ > array, e.g., `char foo[32]'. ...or initialize a variable with it: static char template[] = "/tmp/fooXXXXX"; ... mktemp(template); It depends on the application which variant is more appropriate. Btw., this has *not* been the expected behaviour in the pre-ANSI era, so if you're porting a very old program, you could sometimes stumple across this problem. That's why "gcc -traditional" doesn't make constant strings read/only, but you're strongly encouraged to do the right thing instead of relying on this hack. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-bugs Sat Oct 28 11:03:11 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA02704 for bugs-outgoing; Sat, 28 Oct 1995 11:03:11 -0700 Received: from meter.eng.uci.edu (root@meter.eng.uci.edu [128.200.85.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA02685 ; Sat, 28 Oct 1995 11:03:06 -0700 Received: from newport.ece.uci.edu by meter.eng.uci.edu (8.7) id LAA07003; Sat, 28 Oct 1995 11:03:03 -0700 (PDT) Received: from localhost by newport.ece.uci.edu (8.7) id LAA12313; Sat, 28 Oct 1995 11:03:02 -0700 (PDT) Message-Id: <199510281803.LAA12313@newport.ece.uci.edu> To: stable@freebsd.org cc: bugs@freebsd.org Subject: probs with latest stable snap Date: Sat, 28 Oct 1995 11:03:01 -0700 From: Steven Wallace Sender: owner-bugs@freebsd.org Precedence: bulk I installed the latest snapshot and have some probs: First, when installing, I tried to create two freebsd partitions on the same drive. When it tried to format the partitions, I got "/dev/rsd0s1a: 'a' partition is unavailable" I deleted one partition and was able to continue installing on the other. Another problem I have is running 'xclock'. I get this message: "Warning: Select failed; error code 22", which repeats indefinitely. This is from the xclock distributed on the 2.0.5 cdrom. Also, this morning I woke up to found my computer had rebooted itself and it was in a continuous reboot loop with this panic: (no problems like this in -current) fatal trap 18: integer divide fault while in kernel mode ip = 0x8:0xf019b10b, "pentium_microtime" code segment base 0x0, limit 0xfff type 0x1b, DPL0, press 1, defs 1, gran 1 proc eflags = resume, IOPL = 0 cp = 0 (swapper) i mask = net tty bio Ahh! I have traced it to line 180 of microtime.s: divl %ecx # get value in usec Hmmm, it appears the code checks for pentium_mhz != 0, so it could not be div by 0. However, I looked up div, and it says, "If the dividend is 0 or if the quotient is too large to fit in the result accumulator, a divide error fault (interrupt 0) occurs. So, if the pentium cycle count is > 2^59, then on my 90 MHz pentium (correctly reported), the fault will occur. I do not know what originally caused the first panic, but it appears it put the pentium clock count to a large number. Then it rebooted and gets into a panic div 0 loop. I noticed that after I hit reset, then it booted up just fine (resetting the counter?). I noticed in -current code it has a i586_ctr_bias long long which gets initialized and subtracts the cycle count before the division in microtime.s. I think something like this should be put into -stable to prevent this panic. Steven From owner-freebsd-bugs Sat Oct 28 11:41:45 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA07530 for bugs-outgoing; Sat, 28 Oct 1995 11:41:45 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA07488 ; Sat, 28 Oct 1995 11:41:35 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id FAA05152; Sun, 29 Oct 1995 05:39:01 +1100 Date: Sun, 29 Oct 1995 05:39:01 +1100 From: Bruce Evans Message-Id: <199510281839.FAA05152@godzilla.zeta.org.au> To: stable@freebsd.org, swallace@ece.uci.edu Subject: Re: probs with latest stable snap Cc: bugs@freebsd.org Sender: owner-bugs@freebsd.org Precedence: bulk >Ahh! I have traced it to line 180 of microtime.s: > divl %ecx # get value in usec >Hmmm, it appears the code checks for pentium_mhz != 0, so it could not >be div by 0. However, I looked up div, and it says, "If the >dividend is 0 or if the quotient is too large to fit in the result accumulator, a divide error fault (interrupt 0) occurs. >So, if the pentium cycle count is > 2^59, then on my 90 MHz pentium >(correctly reported), the fault will occur. I do not know what originally >caused the first panic, but it appears it put the pentium clock count >to a large number. Then it rebooted and gets into a panic div 0 loop. >I noticed that after I hit reset, then it booted up just fine (resetting >the counter?). >I noticed in -current code it has a i586_ctr_bias long long which >gets initialized and subtracts the cycle count before the division >in microtime.s. I think something like this should be put into -stable >to prevent this panic. Normally the counter gets set every clock tick. This reduces the dividend in much the same way as subtracting i586_ctr_bias, so there should be no problem dividing. However, microtime() is apparently sometimes called before the counter has been reset after booting. -current initializes i586_ctr_bias early so there should be no problem. The equivalent in -stable would be resetting the counter early. Bruce From owner-freebsd-bugs Sat Oct 28 12:44:07 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA14353 for bugs-outgoing; Sat, 28 Oct 1995 12:44:07 -0700 Received: (from pst@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA14331 ; Sat, 28 Oct 1995 12:44:05 -0700 Date: Sat, 28 Oct 1995 12:44:05 -0700 From: Paul Traina Message-Id: <199510281944.MAA14331@freefall.freebsd.org> To: matte@sdf.luth.se, pst, freebsd-bugs Subject: Re: kern/224 Sender: owner-bugs@FreeBSD.org Precedence: bulk Synopsis: ppp net serial State-Changed-From-To: open-closed State-Changed-By: pst State-Changed-When: Sat Oct 28 12:43:20 PDT 1995 State-Changed-Why: We believe this to be fixed in current releases. From owner-freebsd-bugs Sat Oct 28 12:45:24 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA14630 for bugs-outgoing; Sat, 28 Oct 1995 12:45:24 -0700 Received: (from peter@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA14607 ; Sat, 28 Oct 1995 12:45:22 -0700 Date: Sat, 28 Oct 1995 12:45:22 -0700 From: Peter Wemm Message-Id: <199510281945.MAA14607@freefall.freebsd.org> To: peter@jhome.DIALix.COM, peter, freebsd-bugs Subject: Re: ports/773 Sender: owner-bugs@FreeBSD.org Precedence: bulk Synopsis: screen-3.6.2 from -current wont work... State-Changed-From-To: open-closed State-Changed-By: peter State-Changed-When: Sat Oct 28 12:44:25 PDT 1995 State-Changed-Why: Fixed in rev 1.2 of ports/utils/screen/patches/patch-ac From owner-freebsd-bugs Sat Oct 28 12:51:32 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA15375 for bugs-outgoing; Sat, 28 Oct 1995 12:51:32 -0700 Received: from fledge.watson.org (FLEDGE.RES.CMU.EDU [128.2.95.74]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA15343 ; Sat, 28 Oct 1995 12:51:23 -0700 Received: (from robert@localhost) by fledge.watson.org (8.6.11/8.6.10) id PAA19630; Sat, 28 Oct 1995 15:51:16 -0400 Date: Sat, 28 Oct 1995 15:51:15 -0400 (EDT) From: Robert Watson To: bugs@freebsd.org cc: questions@freebsd.org Subject: netstat question.. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-bugs@freebsd.org Precedence: bulk I got the following this morning when randomly typing netstat: fledge>netstat Active Internet connections Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp 0 0 FLEDGE.RES.CMU.E.2573 gateway.us.sidwe.imap2 TIME_WAIT netstat: kvm_read: kvm_read: Bad address tcp 0 0 FLEDGE.RES.CMU.E.pop3 PC22013.RES.CMU..1097 TIME_WAIT netstat: kvm_read: kvm_read: Bad address netstat: kvm_read: kvm_read: Bad address ^C fledge>netstat Active Internet connections Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp 0 0 localhost.res.cm.2574 localhost.res.cm.domai TIME_WAIT tcp 0 0 FLEDGE.RES.CMU.E.2573 gateway.us.sidwe.imap2 TIME_WAIT tcp 0 0 FLEDGE.RES.CMU.E.6000 UNIX17.ANDREW.CM.1344 ESTABLISHED tcp 0 0 FLEDGE.RES.CMU.E.2425 UNIX17.ANDREW.CM.telne ESTABLISHED tcp 0 0 FLEDGE.RES.CMU.E.2422 gateway.us.sidwe.telne ESTABLISHED udp 0 0 localhost.res.cm.domai *.* udp 0 0 FLEDGE.RES.CMU.E.domai *.* This time it completed successfully. Any ideas as to what caused that the first time through? I haven't recompiled a kernel or touched the kernel in over a month.. Nothing appeared in dmesg or /var/log/messages From owner-freebsd-bugs Sat Oct 28 12:56:09 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA16064 for bugs-outgoing; Sat, 28 Oct 1995 12:56:09 -0700 Received: (from pst@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA16039 ; Sat, 28 Oct 1995 12:56:07 -0700 Date: Sat, 28 Oct 1995 12:56:07 -0700 From: Paul Traina Message-Id: <199510281956.MAA16039@freefall.freebsd.org> To: uhclem%nemesis@fw.ast.com, pst, freebsd-bugs Subject: Re: bin/316 Sender: owner-bugs@FreeBSD.org Precedence: bulk Synopsis: SNAP950322 less stable on IDE than earlier releases FDIV009 State-Changed-From-To: open-feedback State-Changed-By: pst State-Changed-When: Sat Oct 28 12:55:33 PDT 1995 State-Changed-Why: How is the system behaving these days? Can we close this out? From owner-freebsd-bugs Sat Oct 28 12:59:35 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA16235 for bugs-outgoing; Sat, 28 Oct 1995 12:59:35 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA16230 ; Sat, 28 Oct 1995 12:59:32 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id MAA04838; Sat, 28 Oct 1995 12:59:08 -0700 To: Steven Wallace cc: stable@freebsd.org, bugs@freebsd.org Subject: Re: probs with latest stable snap In-reply-to: Your message of "Sat, 28 Oct 1995 11:03:01 PDT." <199510281803.LAA12313@newport.ece.uci.edu> Date: Sat, 28 Oct 1995 12:59:08 -0700 Message-ID: <4836.814910348@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-bugs@freebsd.org Precedence: bulk > First, when installing, I tried to create two freebsd partitions on the > same drive. When it tried to format the partitions, I got > "/dev/rsd0s1a: 'a' partition is unavailable" DO NOT DO THAT. I guess I'll have to make it an error to do so since there are a lot of ways you can hose yourself if you do this (for one thing, it will only boot from the first partition it finds). Jordan From owner-freebsd-bugs Sat Oct 28 13:26:14 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA19529 for bugs-outgoing; Sat, 28 Oct 1995 13:26:14 -0700 Received: (from pst@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA19501 ; Sat, 28 Oct 1995 13:26:10 -0700 Date: Sat, 28 Oct 1995 13:26:10 -0700 From: Paul Traina Message-Id: <199510282026.NAA19501@freefall.freebsd.org> To: jj@ldjpc.apana.org.au, pst, freebsd-bugs Subject: Re: bin/454 Sender: owner-bugs@FreeBSD.org Precedence: bulk Synopsis: compile ports/x11/iv and ld got sig11 State-Changed-From-To: open-closed State-Changed-By: pst State-Changed-When: Sat Oct 28 13:24:58 PDT 1995 State-Changed-Why: Unreproducable. From owner-freebsd-bugs Sat Oct 28 13:28:15 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA20068 for bugs-outgoing; Sat, 28 Oct 1995 13:28:15 -0700 Received: (from pst@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA20036 ; Sat, 28 Oct 1995 13:28:08 -0700 Date: Sat, 28 Oct 1995 13:28:08 -0700 From: Paul Traina Message-Id: <199510282028.NAA20036@freefall.freebsd.org> To: jj@ldjpc.apana.org.au, pst, freebsd-bugs Subject: Re: misc/455 Sender: owner-bugs@FreeBSD.org Precedence: bulk Old Synopsis: library wont compile New Synopsis: interviews library wont compile State-Changed-From-To: open-closed State-Changed-By: pst State-Changed-When: Sat Oct 28 13:27:25 PDT 1995 State-Changed-Why: Unreproducable on a recent FreeBSD system. From owner-freebsd-bugs Sat Oct 28 15:11:11 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA02850 for bugs-outgoing; Sat, 28 Oct 1995 15:11:11 -0700 Received: from ast.com (irvine.ast.com [165.164.128.2]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id PAA02832 ; Sat, 28 Oct 1995 15:11:05 -0700 Received: from fw.ast.com by ast.com with SMTP id AA05949 (5.67b/IDA-1.5); Sat, 28 Oct 1995 15:12:14 -0700 Received: from nemesis by fw.ast.com with uucp (Smail3.1.29.1 #4) id m0t9JOP-000087C; Sat, 28 Oct 95 17:06 CDT Received: by nemesis.lonestar.org (Smail3.1.27.1 #19) id m0t9JDP-000IyNC; Sat, 28 Oct 95 16:54 WET DST Message-Id: Date: Sat, 28 Oct 95 16:54 WET DST To: pst@freefall.freebsd.org, freebsd-bugs@freefall.freebsd.org From: uhclem%nemesis@fw.ast.com (Frank Durda IV) Sent: Sat Oct 28 1995, 16:54:58 CDT Subject: Re: bin/316 Sender: owner-bugs@FreeBSD.org Precedence: bulk [0]Synopsis: SNAP950322 less stable on IDE than earlier releases FDIV009 [0] [0]State-Changed-From-To: open-feedback [0]State-Changed-By: pst [0]State-Changed-When: Sat Oct 28 12:55:33 PDT 1995 [0]State-Changed-Why: [0]How is the system behaving these days? Can we close this out? Wow, I thought this one had been closed long ago. Looking back through my notes, it cleared up at 2.0.5-ALPHA, so this issue is very closed, IMHO. Close that baby. 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 Sat Oct 28 15:15:04 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA03239 for bugs-outgoing; Sat, 28 Oct 1995 15:15:04 -0700 Received: (from pst@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA03204 ; Sat, 28 Oct 1995 15:15:00 -0700 Date: Sat, 28 Oct 1995 15:15:00 -0700 From: Paul Traina Message-Id: <199510282215.PAA03204@freefall.freebsd.org> To: henrich@crh.cl.msu.edu, pst, freebsd-bugs Subject: Re: kern/430 Sender: owner-bugs@FreeBSD.org Precedence: bulk Synopsis: SCSI Tape dont work State-Changed-From-To: open-closed State-Changed-By: pst State-Changed-When: Sat Oct 28 15:14:31 PDT 1995 State-Changed-Why: Ever since 07xx-SNAP the tape seems to behaving correctly. You can nix the problem. Thanks for inquiring! -Crh From owner-freebsd-bugs Sat Oct 28 15:16:30 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA03518 for bugs-outgoing; Sat, 28 Oct 1995 15:16:30 -0700 Received: (from pst@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA03486 ; Sat, 28 Oct 1995 15:16:25 -0700 Date: Sat, 28 Oct 1995 15:16:25 -0700 From: Paul Traina Message-Id: <199510282216.PAA03486@freefall.freebsd.org> To: uhclem%nemesis@fw.ast.com, pst, freebsd-bugs Subject: Re: bin/316 Sender: owner-bugs@FreeBSD.org Precedence: bulk Synopsis: SNAP950322 less stable on IDE than earlier releases FDIV009 State-Changed-From-To: feedback-closed State-Changed-By: pst State-Changed-When: Sat Oct 28 15:15:46 PDT 1995 State-Changed-Why: Wow, I thought this one had been closed long ago. Looking back through my notes, it cleared up at 2.0.5-ALPHA, so this issue is very closed, IMHO. Close that baby. Frank Durda IV |"The Knights who say "LETNi" From owner-freebsd-bugs Sat Oct 28 15:22:39 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA04199 for bugs-outgoing; Sat, 28 Oct 1995 15:22:39 -0700 Received: (from pst@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA04175 ; Sat, 28 Oct 1995 15:22:33 -0700 Date: Sat, 28 Oct 1995 15:22:33 -0700 From: Paul Traina Message-Id: <199510282222.PAA04175@freefall.freebsd.org> To: shipley@whimpy.dis.org, pst, freebsd-bugs Subject: Re: kern/293 Sender: owner-bugs@FreeBSD.org Precedence: bulk Synopsis: wd0: interrupt timeout State-Changed-From-To: open-closed State-Changed-By: pst State-Changed-When: Sat Oct 28 15:22:01 PDT 1995 State-Changed-Why: This got fixed a long time ago. From owner-freebsd-bugs Sat Oct 28 15:24:54 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA04404 for bugs-outgoing; Sat, 28 Oct 1995 15:24:54 -0700 Received: (from pst@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA04375 ; Sat, 28 Oct 1995 15:24:48 -0700 Date: Sat, 28 Oct 1995 15:24:48 -0700 From: Paul Traina Message-Id: <199510282224.PAA04375@freefall.freebsd.org> To: markd@grizzly.com, pst, freebsd-bugs Subject: Re: i386/105 Sender: owner-bugs@FreeBSD.org Precedence: bulk Synopsis: Distributed libm (msun) has non-standard error handling. State-Changed-From-To: open-analyzed State-Changed-By: pst State-Changed-When: Sat Oct 28 15:24:01 PDT 1995 State-Changed-Why: Got input back from JTC. From owner-freebsd-bugs Sat Oct 28 15:52:23 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA07536 for bugs-outgoing; Sat, 28 Oct 1995 15:52:23 -0700 Received: (from pst@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA07513 ; Sat, 28 Oct 1995 15:52:16 -0700 Date: Sat, 28 Oct 1995 15:52:16 -0700 From: Paul Traina Message-Id: <199510282252.PAA07513@freefall.freebsd.org> To: curnutt@Stoner.COM, pst, freebsd-bugs Subject: Re: gnu/107 Sender: owner-bugs@FreeBSD.org Precedence: bulk Synopsis: kernel build produces internal compiler error State-Changed-From-To: open-closed State-Changed-By: pst State-Changed-When: Sat Oct 28 15:51:29 PDT 1995 State-Changed-Why: Unreproducable, either a gcc 2.6.2 error (unlikely) or something that got cleaned up along the way, -or- bad hardware. From owner-freebsd-bugs Sat Oct 28 15:59:27 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA08090 for bugs-outgoing; Sat, 28 Oct 1995 15:59:27 -0700 Received: (from pst@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA08072 ; Sat, 28 Oct 1995 15:59:25 -0700 Date: Sat, 28 Oct 1995 15:59:25 -0700 From: Paul Traina Message-Id: <199510282259.PAA08072@freefall.freebsd.org> To: muir@idiom.com, pst, freebsd-bugs Subject: Re: bin/135 Sender: owner-bugs@FreeBSD.org Precedence: bulk Synopsis: not enough ptys; virtual console names conflict with ptys. State-Changed-From-To: open-closed State-Changed-By: pst State-Changed-When: Sat Oct 28 15:58:17 PDT 1995 State-Changed-Why: This was fixed, we now use ptys in the range [pqrsPQRS] and there is a total of 256 pty/ttyp pairs available. From owner-freebsd-bugs Sat Oct 28 16:18:11 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA09653 for bugs-outgoing; Sat, 28 Oct 1995 16:18:11 -0700 Received: (from pst@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA09631 ; Sat, 28 Oct 1995 16:18:08 -0700 Date: Sat, 28 Oct 1995 16:18:08 -0700 From: Paul Traina Message-Id: <199510282318.QAA09631@freefall.freebsd.org> To: taob@gate.sinica.edu.tw, pst, freebsd-bugs Subject: Re: docs/546 Sender: owner-bugs@FreeBSD.org Precedence: bulk Synopsis: Shared memory manual pages State-Changed-From-To: open-closed State-Changed-By: pst State-Changed-When: Sat Oct 28 16:17:21 PDT 1995 State-Changed-Why: date: 1995/10/03 19:17:21; author: joerg; state: Exp; Add man pages for the SYSV shm* and sem* functions. From owner-freebsd-bugs Sat Oct 28 16:21:56 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA09912 for bugs-outgoing; Sat, 28 Oct 1995 16:21:56 -0700 Received: from gate.ti.com (news.ti.com [192.94.94.33]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA09905 for ; Sat, 28 Oct 1995 16:21:53 -0700 Received: from tilde.csc.ti.com ([128.247.160.56]) by gate.ti.com (8.6.12/) with ESMTP id SAA00416 for ; Sat, 28 Oct 1995 18:21:22 -0500 Received: from Islington-Terrace (islington-terrace.hc.ti.com [192.94.82.15]) by tilde.csc.ti.com (8.6.12/8.6.12) with SMTP id SAA26536 for ; Sat, 28 Oct 1995 18:20:51 -0500 Message-Id: <3023911257-5359885@Islington-Terrace> Date: Sat, 28 Oct 95 18:20:57 CDT Moon: Waxing Crescent (26% of full) From: Paul Fuqua To: bugs@freebsd.org Subject: Can't Install 2.1.0-951020-SNAP on T4600 Sender: owner-bugs@freebsd.org Precedence: bulk I've failed to install the 2.1 release candidate on my Toshiba T4600 laptop (486DX, 8 MB, 200 MB IDE disk). I was previously running the 950210 snapshot of what became 2.0.5, and I've also run 1.1.5.1 and 1.0.2 on this machine in the past. I'm using the quick-installation menu, choosing X-user, custom, or minimal in different attempts, and I want to use NFS over PPP. I'm not trying the upgrade route, because I'm far enough behind 2.0.5 that I figure it wouldn't work. Problems: 1. I want to cut my disk into two partitions, 175 MB filesystem and 25 MB swap, like I already had, but the installation won't proceed without a separate /usr partition. After the warning about not having a separate /usr (to which I answer, yes, I'm sure), the first error is Couldn't make filesystems properly. Aborting. followed by Unable to create a new /etc/fstab file! Manual intervention will be required. and Unable to open /etc/sysconfig file! Things may work rather strangely as a result of this. and I'm returned to the main install menu. 2. If I give it separate / and /usr partitions, it gets farther, but after creating root and swap, I see Error mounting /mnt/dev/wd0s1e on /mnt/usr : Invalid argument. The alt-f2 screen shows a bunch of cpio: /mnt/dev/rwd0s1a not created: newer or same age version exists for all of a, b, and e, with and without the initial r (ie, six messages) followed by newfs: /mnt/dev/rwd0s1e: `e' partition is unavailable. If I continue, it copies the boot floppy to /stand, then says "Creating an emergency holographic shell on VTY4," then starts the PPP dialog sequence. I can't seem to find any commands in the emergency shell, so I can't do anything there. 3. If I accept the defaults and create /, /usr, and /var partitions, I avoid almost all the errors above, except for the holographic shell notice and the newer-or-same-age warnings, but what am I going to do with a 30-MB /var partition on a laptop? 4. The PPP sequence sets up its VTY3 window, but hangs no matter what I type, and isn't interruptible. I'm not using a modem, but a direct connection to my Sun's serial port, and without some kind of "help" command, I'm stuck. I'll try again if someone can help me get past all these, but for now I'm reinstalling 950210. Paul Fuqua Texas Instruments, Dallas, Texas pf@hc.ti.com From owner-freebsd-bugs Sat Oct 28 16:33:52 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA10597 for bugs-outgoing; Sat, 28 Oct 1995 16:33:52 -0700 Received: (from pst@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA10574 ; Sat, 28 Oct 1995 16:33:42 -0700 Date: Sat, 28 Oct 1995 16:33:42 -0700 From: Paul Traina Message-Id: <199510282333.QAA10574@freefall.freebsd.org> To: paul@lambda.demon.co.uk, pst, freebsd-bugs Subject: Re: misc/556 Sender: owner-bugs@FreeBSD.org Precedence: bulk Synopsis: Bug in /etc/rc State-Changed-From-To: open-closed State-Changed-By: pst State-Changed-When: Sat Oct 28 16:32:33 PDT 1995 State-Changed-Why: Fixed. From owner-freebsd-bugs Sat Oct 28 22:45:30 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA00209 for bugs-outgoing; Sat, 28 Oct 1995 22:45:30 -0700 Received: (from bde@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA00196 ; Sat, 28 Oct 1995 22:45:27 -0700 Date: Sat, 28 Oct 1995 22:45:27 -0700 From: Bruce Evans Message-Id: <199510290545.WAA00196@freefall.freebsd.org> To: mark@grondar.za, bde, freebsd-bugs Subject: Re: kern/175 Sender: owner-bugs@FreeBSD.org Precedence: bulk Synopsis: Syscons does not recover X graphics mode State-Changed-From-To: open-closed State-Changed-By: bde State-Changed-When: Sat Oct 28 22:34:52 PDT 1995 State-Changed-Why: The bug (as noticed by me) is actually in the XFree3.1.1 W32 server. The bug isn't reproducible in the XFree3.1.2 W32 server because a more serious bug in related initialization code always crashes the server.