From owner-freebsd-bugs Sun May 28 01:20:05 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id BAA07288 for bugs-outgoing; Sun, 28 May 1995 01:20:05 -0700 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id BAA07281 ; Sun, 28 May 1995 01:20:03 -0700 Date: Sun, 28 May 1995 01:20:03 -0700 Message-Id: <199505280820.BAA07281@freefall.cdrom.com> From: Philippe CHARNIER Reply-To: Philippe CHARNIER To: freebsd-bugs Subject: gnu/451: cvsinit/cvs doesn't work as expected with perl In-Reply-To: Your message of Sun, 28 May 1995 10:11:04 +0200 <199505280811.KAA11574@pcdif01.lirmm.fr> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 451 >Category: gnu >Synopsis: cvsinit/cvs doesn't work as expected with perl >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun May 28 01:20:01 1995 >Originator: Philippe CHARNIER >Organization: >Release: FreeBSD 2.0.950412-SNAP i386 >Environment: Also in current, (need perl to be installed) >Description: cvsinit is buggy, then cvs doesn't work as expected when perl is found and used. for example, the DEFAULT entry of loginfo is not compatible with log.pl which dies in: ($donefiles) && die "Too many arguments!\n"; cvsinit is also looking for files in the source tree, that is not correct, for those who don't have it... >How-To-Repeat: create a cvs root using cvsinit, if perl is on the system, cvs will use it. create some files, add them and commit them. >Fix: 1) add a Makefile for installing log.pl in /usr/share/.. because cvsinit need it. 2) add contrib as a subdir, it contains log.pl. 3) make cvsinit look into /usr/share/... (was the source tree). 4) make loginfo compatible with log.pl. =================================================================== New file /usr/src/gnu/usr.bin/cvs/contrib/Makefile *** /dev/null Sun May 28 00:21:33 1995 --- contrib/Makefile Sun May 28 00:18:13 1995 *************** *** 0 **** --- 1,17 ---- + # $Id$ + + CVSFILES= log.pl + + EXAMPDIR = /usr/share/examples/cvs + + NOMAN = noman + + all clean: + @echo -n + + install: + cd ${.CURDIR}; \ + install -c -o ${BINOWN} -g ${BINGRP} -m 444 ${CVSFILES} \ + ${DESTDIR}${EXAMPDIR} + + .include =================================================================== RCS file: /home2h/FreeBSD.cvsroot/src/gnu/usr.bin/cvs/Makefile,v retrieving revision 1.6 diff -u -r1.6 Makefile --- 1.6 1995/04/14 15:15:27 +++ Makefile 1995/05/27 22:15:11 @@ -1,5 +1,5 @@ # $Id: Makefile,v 1.6 1995/04/14 15:15:27 nate Exp $ -SUBDIR = lib cvs mkmodules cvsinit doc examples +SUBDIR = lib cvs mkmodules cvsinit doc examples contrib .include =================================================================== RCS file: /home2h/FreeBSD.cvsroot/src/gnu/usr.bin/cvs/cvsinit/cvsinit.sh,v retrieving revision 1.2 diff -u -r1.2 cvsinit.sh --- 1.2 1995/03/31 07:55:23 +++ cvsinit.sh 1995/05/27 22:11:45 @@ -10,8 +10,8 @@ # # This script should be run once to help you setup your site for CVS. -# this line is edited by Makefile when creating cvsinit.inst -CVSLIB="/usr/src/gnu/usr.bin/cvs" + +CVSLIB="/usr/share/examples/cvs" # Make sure that the CVSROOT variable is set if [ "x$CVSROOT" = x ]; then @@ -157,15 +157,15 @@ echo "Making a simple one for you..." # try to find perl; use fancy log script if we can for perlpath in `echo $PATH | sed -e 's/:/ /g'` x; do - if [ -f $perlpath/perl -a -r $CVSLIB/contrib/log.pl ]; then + if [ -f $perlpath/perl -a -r $CVSLIB/log.pl ]; then echo "#!$perlpath/perl" > $CVSROOT/CVSROOT/log.pl - cat $CVSLIB/contrib/log.pl >> $CVSROOT/CVSROOT/log.pl + cat $CVSLIB/log.pl >> $CVSROOT/CVSROOT/log.pl chmod 755 $CVSROOT/CVSROOT/log.pl - cp $CVSLIB/examples/loginfo $CVSROOT/CVSROOT/loginfo + cp $CVSLIB/loginfo $CVSROOT/CVSROOT/loginfo break fi done - if [ $perlpath = x -o ! -r $CVSLIB/contrib/log.pl ]; then + if [ $perlpath = x -o ! -r $CVSLIB/log.pl ]; then # we did not find perl anywhere, so make a simple loginfo file cat > $CVSROOT/CVSROOT/loginfo <<"HERE" # @@ -211,9 +211,9 @@ (cd $CVSROOT/CVSROOT; ci -q -u -t/dev/null -m"initial checkin of $info" $info) else echo "The $CVSROOT/CVSROOT/$info file does not exist." - if [ -r $CVSLIB/examples/$info ]; then + if [ -r $CVSLIB/$info ]; then echo "Making a simple one for you..." - sed -e 's/^\([^#]\)/#\1/' $CVSLIB/examples/$info > $CVSROOT/CVSROOT/$info + sed -e 's/^\([^#]\)/#\1/' $CVSLIB/$info > $CVSROOT/CVSROOT/$info fi fi echo "" =================================================================== RCS file: /home2h/FreeBSD.cvsroot/src/gnu/usr.bin/cvs/examples/loginfo,v retrieving revision 1.1.1.2 diff -u -r1.1.1.2 loginfo --- 1.1.1.2 1995/03/31 07:44:33 +++ loginfo 1995/05/27 22:16:58 @@ -17,4 +17,4 @@ # If the name ALL appears as a regular expression it is always used # in addition to the first matching regex or DEFAULT. # -DEFAULT $CVSROOT/CVSROOT/log.pl %s $CVSROOT/CVSROOT/commitlog +DEFAULT $CVSROOT/CVSROOT/log.pl -f $CVSROOT/CVSROOT/commitlog %s >Audit-Trail: >Unformatted: From owner-freebsd-bugs Sun May 28 06:10:02 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id GAA09205 for bugs-outgoing; Sun, 28 May 1995 06:10:02 -0700 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id GAA09196 ; Sun, 28 May 1995 06:10:01 -0700 Date: Sun, 28 May 1995 06:10:01 -0700 Message-Id: <199505281310.GAA09196@freefall.cdrom.com> From: Pierre Beyssac Reply-To: Pierre Beyssac To: freebsd-bugs Subject: kern/452: page fault in pagedaemon on vnode swapping In-Reply-To: Your message of Sun, 28 May 1995 14:56:52 +0200 <199505281256.OAA17468@fasterix.frmug.fr.net> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 452 >Category: kern >Synopsis: vnode swapping panics >Confidential: no >Severity: critical >Priority: high >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun May 28 06:10:01 1995 >Originator: Pierre Beyssac >Organization: Pierre Beyssac >Release: FreeBSD 2.0-BUILT-19950528 i386 >Environment: Diskless 486 PC. RAM : 4Mb Swap : 8Mb vnconfig'd in /swp >Description: Swapping works for awhile (swapinfo indicates 10-15% used). After some short time (apparently when a big amount of pages is swapped out at the same time to make room, e.g. to start "vi") the same panic occurs. Hand-copied from DDB : trap 12 page fault while in kernel mode supervisor read, page not present process 2 (pagedaemon) Stack trace: bcopy (apparently in macro nfsm_fhtom() in nfs_vnops.c:912) nfs_writerpc nfs_doio nfs_strategy vnstrategy spec_strategy swstrategy spec_strategy swap_pager_output swap_pager_putmulti vm_pager_put_pages vm_pageout_clean vm_pageout_scan vm_pageout getpbuf >How-To-Repeat: Make /swp a 8Mb file. Boot the diskless (4Mb) PC. # vnconfig -e /dev/vn0c /swp swap # swapinfo # vi something >Fix: None known. Direct NFS-swap doesn't help : many processes get a SIGSEGV and the kernel quickly panics too. Probably local swap works, I'll try that next. >Audit-Trail: >Unformatted: From owner-freebsd-bugs Sun May 28 07:40:03 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id HAA15526 for bugs-outgoing; Sun, 28 May 1995 07:40:03 -0700 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id HAA15519 ; Sun, 28 May 1995 07:40:02 -0700 Date: Sun, 28 May 1995 07:40:02 -0700 Message-Id: <199505281440.HAA15519@freefall.cdrom.com> From: Mark Murray Reply-To: Mark Murray To: freebsd-bugs Subject: misc/453: The release/Makefile does not make all des/eBones tarballs In-Reply-To: Your message of Sun, 28 May 1995 16:38:22 +0200 <199505281438.QAA19475@grumble.grondar.za> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 453 >Category: misc >Synopsis: The release/Makefile does not make all des/eBones tarballs >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun May 28 07:40:01 1995 >Originator: Mark Murray >Organization: GTA >Release: FreeBSD 2.0.5-TEST i386 >Environment: FreeBSD-current with the South African des/eBones source available. >Description: When I change to /usr/src/release, and type "make" (on a slightly hacked makefile to avoid "cvs co"'s), the only two tarballs made in R/ftp/des and R/cdrom/dists/des are total 386 drwxr-xr-x 2 root wheel 512 May 28 13:46 ./ drwxr-xr-x 11 root wheel 512 May 28 13:46 ../ -rw-r--r-- 3 root wheel 144754 May 28 13:02 des.aa -rw-r--r-- 3 root wheel 227877 May 28 13:11 sebones.aa des.aa only contains the crypt/des stuff, and sebones.aa only contains eBones source. >How-To-Repeat: cd src/release cp Makefile makefile vi makefile make release CHROOTDIR=/bfd cd /bfd/R/ftp/des >Fix: Not yet known. >Audit-Trail: >Unformatted: From owner-freebsd-bugs Sun May 28 12:22:46 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA01877 for bugs-outgoing; Sun, 28 May 1995 12:22:46 -0700 Received: (from ache@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA01863 ; Sun, 28 May 1995 12:22:45 -0700 Date: Sun, 28 May 1995 12:22:45 -0700 From: "Andrey A. Chernov" Message-Id: <199505281922.MAA01863@freefall.cdrom.com> To: fenner@parc.xerox.com, ache, freebsd-bugs Subject: Changed information for PR gnu/449 Sender: bugs-owner@FreeBSD.org Precedence: bulk Synopsis: perl's $] variable is broken State-Changed-From-To: open-closed State-Changed-By: ache State-Changed-When: Sun May 28 12:22:07 PDT 1995 State-Changed-Why: Applied in perl.c v1.3 From owner-freebsd-bugs Sun May 28 17:39:35 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id RAA08494 for bugs-outgoing; Sun, 28 May 1995 17:39:35 -0700 Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id RAA08488 for ; Sun, 28 May 1995 17:39:33 -0700 Message-Id: <199505290039.RAA08488@freefall.cdrom.com> Received: by crh.cl.msu.edu (1.38.193.4/16.2) id AA15862; Sun, 28 May 1995 20:39:31 -0400 From: Charles Henrich Subject: PCI Probe on Compaq's fail To: freebsd-bugs@FreeBSD.org Date: Sun, 28 May 1995 20:39:31 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 425 Sender: bugs-owner@FreeBSD.org Precedence: bulk I have a Compaq Prolinea, and probing the PCI bus appears to fail (i.e. no devices found). Has anyone else run into this, and found a solution? Is there more than one way to probe a PCI bus? (No bridge controller is found, nothing is found, all we get is a Mode 2 supports 16 devices) -Crh Charles Henrich Michigan State University henrich@crh.cl.msu.edu http://rs560.msu.edu/~henrich/ From owner-freebsd-bugs Sun May 28 18:30:03 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA09369 for bugs-outgoing; Sun, 28 May 1995 18:30:03 -0700 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA09362 ; Sun, 28 May 1995 18:30:02 -0700 Date: Sun, 28 May 1995 18:30:02 -0700 Message-Id: <199505290130.SAA09362@freefall.cdrom.com> From: Lucas James Reply-To: Lucas James To: freebsd-bugs Subject: misc/455: ports/x11/iv wont compile In-Reply-To: Your message of Mon, 29 May 1995 09:43:06 +0930 <199505290013.JAA09956@ldjpc.apana.org.au> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 455 >Category: misc >Synopsis: library wont compile >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun May 28 18:30:02 1995 >Originator: Lucas James >Organization: LDJpc Home un*x >Release: FreeBSD 2.0-RELEASE i386 >Environment: FreeBSD-2.0R + -current kernel, ld, gcc, ar, ranlib, tsort >Description: It just wont compile. >How-To-Repeat: # cd /usr/ports/x11/iv # make all and watch all the errors. >Fix: this will allow it to compile. whether it is correct or not....... There is still a problem in src/bin/ibuild with ld getting a sig11 (see separate pr) also in src/bin/idraw getting alot of undefined symbols, I haven't figured it out yet.... diff -rc work-orig/iv/src/include/IV-X11/xwindow.h work/iv/src/include/IV-X11/xwindow.h *** work-orig/iv/src/include/IV-X11/xwindow.h Fri Sep 25 07:46:22 1992 --- work/iv/src/include/IV-X11/xwindow.h Sun May 28 12:49:16 1995 *************** *** 46,53 **** class Style; class WindowCursorStack; class WindowTable; class XDisplay; ! struct WindowOverlayInfo { VisualID id_; long type_; --- 46,58 ---- class Style; class WindowCursorStack; class WindowTable; + /* + * modified by jj@ldjpc.apana.org.au + * + * this seems to break the compile... class XDisplay; ! * ! */ struct WindowOverlayInfo { VisualID id_; long type_; diff -rc work-orig/iv/src/lib/TIFF/prototypes.h work/iv/src/lib/TIFF/prototypes.h *** work-orig/iv/src/lib/TIFF/prototypes.h Sun May 28 12:39:56 1995 --- work/iv/src/lib/TIFF/prototypes.h Sun May 28 14:21:04 1995 *************** *** 25,31 **** */ #if USE_PROTOTYPES - va_dcl #define DECLARE1(f,t1,a1) f(t1 a1) #define DECLARE2(f,t1,a1,t2,a2) f(t1 a1, t2 a2) #define DECLARE3(f,t1,a1,t2,a2,t3,a3) f(t1 a1, t2 a2, t3 a3) --- 25,30 ---- diff -rc work-orig/iv/src/lib/TIFF/tif_aux.c work/iv/src/lib/TIFF/tif_aux.c *** work-orig/iv/src/lib/TIFF/tif_aux.c Sat Mar 28 08:23:06 1992 --- work/iv/src/lib/TIFF/tif_aux.c Sun May 28 14:15:50 1995 *************** *** 42,47 **** --- 42,49 ---- * explcit values so that defaults exist only one * place in the library -- in TIFFDefaultDirectory. */ + ; + /* for some reason it needs a ; before this line */ TIFFVGetFieldDefaulted(tif, tag, ap) TIFF *tif; int tag; diff -rc work-orig/iv/src/lib/TIFF/tif_dir.c work/iv/src/lib/TIFF/tif_dir.c *** work-orig/iv/src/lib/TIFF/tif_dir.c Sat Mar 7 06:29:51 1992 --- work/iv/src/lib/TIFF/tif_dir.c Sun May 28 13:00:03 1995 *************** *** 950,956 **** } if (tif->tif_flags & TIFF_SWAB) TIFFSwabShort(&dircount); ! lseek(tif->tif_fd, dircount*sizeof (TIFFDirEntry), L_INCR); if (!ReadOK(tif->tif_fd, &nextdir, sizeof (nextdir))) { TIFFError(module, "%s: Error fetching directory link", tif->tif_name); --- 950,957 ---- } if (tif->tif_flags & TIFF_SWAB) TIFFSwabShort(&dircount); ! /*added (off_t) .. jj@ldjpc.apana.org.au*/ ! lseek(tif->tif_fd, (off_t)(dircount*sizeof (TIFFDirEntry)), L_INCR); if (!ReadOK(tif->tif_fd, &nextdir, sizeof (nextdir))) { TIFFError(module, "%s: Error fetching directory link", tif->tif_name); diff -rc work-orig/iv/src/lib/TIFF/tif_dirwrite.c work/iv/src/lib/TIFF/tif_dirwrite.c *** work-orig/iv/src/lib/TIFF/tif_dirwrite.c Wed Mar 18 05:39:29 1992 --- work/iv/src/lib/TIFF/tif_dirwrite.c Sun May 28 12:57:11 1995 *************** *** 177,183 **** dataoff = tif->tif_diroff + sizeof (short) + dirsize + sizeof (long); if (dataoff & 1) dataoff++; ! (void) lseek(tif->tif_fd, dataoff, L_SET); tif->tif_curdir++; dir = (TIFFDirEntry *)data; /* --- 177,184 ---- dataoff = tif->tif_diroff + sizeof (short) + dirsize + sizeof (long); if (dataoff & 1) dataoff++; ! /* added (off_t) below.....jj@ldjpc.apana.org.au*/ ! (void) lseek(tif->tif_fd, (off_t)(dataoff), L_SET); tif->tif_curdir++; dir = (TIFFDirEntry *)data; /* *************** *** 314,320 **** /* * Write directory. */ ! (void) lseek(tif->tif_fd, tif->tif_diroff, L_SET); dircount = nfields; if (!WriteOK(tif->tif_fd, &dircount, sizeof (short))) { TIFFError(tif->tif_name, "Error writing directory count"); --- 315,322 ---- /* * Write directory. */ ! /*added (off_t) below.....jj@ldjpc.apana.org.au*/ ! (void) lseek(tif->tif_fd, (off_t)(tif->tif_diroff), L_SET); dircount = nfields; if (!WriteOK(tif->tif_fd, &dircount, sizeof (short))) { TIFFError(tif->tif_name, "Error writing directory count"); *************** *** 762,774 **** u_short dircount; long nextdir; ! tif->tif_diroff = (lseek(tif->tif_fd, 0L, L_XTND)+1) &~ 1L; if (tif->tif_header.tiff_diroff == 0) { /* * First directory, overwrite header. */ tif->tif_header.tiff_diroff = tif->tif_diroff; ! (void) lseek(tif->tif_fd, 0L, L_SET); if (!WriteOK(tif->tif_fd, &tif->tif_header, sizeof (tif->tif_header))) { TIFFError(tif->tif_name, "Error writing TIFF header"); --- 764,778 ---- u_short dircount; long nextdir; ! /* changed 0L to (off_t)0 below...jj@ldjpc.apana.org.au*/ ! tif->tif_diroff = (lseek(tif->tif_fd, (off_t)0, L_XTND)+1) &~ 1L; if (tif->tif_header.tiff_diroff == 0) { /* * First directory, overwrite header. */ tif->tif_header.tiff_diroff = tif->tif_diroff; ! /* changed 0L to (off_t)0 .. jj@ldjpc.apana.org.au*/ ! (void) lseek(tif->tif_fd, (off_t)0, L_SET); if (!WriteOK(tif->tif_fd, &tif->tif_header, sizeof (tif->tif_header))) { TIFFError(tif->tif_name, "Error writing TIFF header"); *************** *** 788,794 **** } if (tif->tif_flags & TIFF_SWAB) TIFFSwabShort(&dircount); ! lseek(tif->tif_fd, dircount * sizeof (TIFFDirEntry), L_INCR); if (!ReadOK(tif->tif_fd, &nextdir, sizeof (nextdir))) { TIFFError(module, "Error fetching directory link"); return (0); --- 792,799 ---- } if (tif->tif_flags & TIFF_SWAB) TIFFSwabShort(&dircount); ! /*added (off_t) below....jj@ldjpc.apana.org.au*/ ! lseek(tif->tif_fd, (off_t)(dircount * sizeof (TIFFDirEntry)), L_INCR); if (!ReadOK(tif->tif_fd, &nextdir, sizeof (nextdir))) { TIFFError(module, "Error fetching directory link"); return (0); *************** *** 796,802 **** if (tif->tif_flags & TIFF_SWAB) TIFFSwabLong((u_long *)&nextdir); } while (nextdir != 0); ! (void) lseek(tif->tif_fd, -sizeof (nextdir), L_INCR); if (!WriteOK(tif->tif_fd, &tif->tif_diroff, sizeof (tif->tif_diroff))) { TIFFError(module, "Error writing directory link"); return (0); --- 801,808 ---- if (tif->tif_flags & TIFF_SWAB) TIFFSwabLong((u_long *)&nextdir); } while (nextdir != 0); ! /*added (off_t) below ... jj@ldjpc.apana.org.au*/ ! (void) lseek(tif->tif_fd, (off_t)(-sizeof (nextdir)), L_INCR); if (!WriteOK(tif->tif_fd, &tif->tif_diroff, sizeof (tif->tif_diroff))) { TIFFError(module, "Error writing directory link"); return (0); diff -rc work-orig/iv/src/lib/TIFF/tif_write.c work/iv/src/lib/TIFF/tif_write.c *** work-orig/iv/src/lib/TIFF/tif_write.c Tue Feb 11 13:36:47 1992 --- work/iv/src/lib/TIFF/tif_write.c Sun May 28 12:57:57 1995 *************** *** 550,556 **** } } else td->td_stripoffset[strip] = ! lseek(tif->tif_fd, 0L, L_XTND); tif->tif_curoff = td->td_stripoffset[strip]; } if (!WriteOK(tif->tif_fd, data, cc)) { --- 550,557 ---- } } else td->td_stripoffset[strip] = ! /*changed 0L to (off_t)0 .. jj@ldjpc.apana.org.au*/ ! lseek(tif->tif_fd, (off_t)0, L_XTND); tif->tif_curoff = td->td_stripoffset[strip]; } if (!WriteOK(tif->tif_fd, data, cc)) { diff -rc work-orig/iv/src/lib/TIFF/tiffcompat.h work/iv/src/lib/TIFF/tiffcompat.h *** work-orig/iv/src/lib/TIFF/tiffcompat.h Tue Mar 31 12:01:04 1992 --- work/iv/src/lib/TIFF/tiffcompat.h Sun May 28 14:13:59 1995 *************** *** 154,160 **** #define lseek mpw_lseek extern long mpw_lseek(int, long, int); #else ! extern long lseek(); #endif /* --- 154,161 ---- #define lseek mpw_lseek extern long mpw_lseek(int, long, int); #else ! /*changed to the correct one...jj@ldjpc.apana.org.au*/ ! extern off_t lseek(); #endif /* *************** *** 163,170 **** #ifndef ReadOK #define ReadOK(fd, buf, size) (read(fd, (char *)buf, size) == size) #endif #ifndef SeekOK ! #define SeekOK(fd, off) (lseek(fd, (long)off, L_SET) == (long)off) #endif #ifndef WriteOK #define WriteOK(fd, buf, size) (write(fd, (char *)buf, size) == size) --- 164,172 ---- #ifndef ReadOK #define ReadOK(fd, buf, size) (read(fd, (char *)buf, size) == size) #endif + /*changed (long) to (off_t) to compile....jj@ldjpc.apana.org.au*/ #ifndef SeekOK ! #define SeekOK(fd, off) (lseek(fd, (off_t)off, L_SET) == (off_t)off) #endif #ifndef WriteOK #define WriteOK(fd, buf, size) (write(fd, (char *)buf, size) == size) *************** *** 202,211 **** */ #if defined(__STDC__) && !defined(USE_VARARGS) #define USE_VARARGS 0 #endif #if defined(USE_VARARGS) ! #if USE_VARARGS #include #define VA_START(ap, parmN) va_start(ap) #else --- 204,218 ---- */ #if defined(__STDC__) && !defined(USE_VARARGS) #define USE_VARARGS 0 + #else + #if defined(__FreeBSD__) + #undef USE_VARARGS + #define USE_VARARGS 0 + #endif #endif #if defined(USE_VARARGS) ! #if USE_VARARGS && !defined(__FreeBSD__) #include #define VA_START(ap, parmN) va_start(ap) #else >Audit-Trail: >Unformatted: From owner-freebsd-bugs Sun May 28 18:30:02 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA09356 for bugs-outgoing; Sun, 28 May 1995 18:30:02 -0700 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA09348 ; Sun, 28 May 1995 18:30:01 -0700 Date: Sun, 28 May 1995 18:30:01 -0700 Message-Id: <199505290130.SAA09348@freefall.cdrom.com> From: JJ and the masked Mail Man Reply-To: JJ and the masked Mail Man To: freebsd-bugs Subject: bin/454: ld got sig11 In-Reply-To: Your message of Mon, 29 May 1995 09:27:45 +0930 <199505282357.JAA09800@ldjpc.apana.org.au> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 454 >Category: bin >Synopsis: compile ports/x11/iv and ld got sig11 >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun May 28 18:30:01 1995 >Originator: Lucas James >Organization: -- >Release: FreeBSD 2.0-RELEASE i386 >Environment: Mostly 2.0R, with -current kernel, ld, gcc, ar, ranlib, tsort >Description: >> No MD5 checksum file. ===> Building for iv-3.1 making all for FREEBSD in ./src [...] making all for FREEBSD in ./src/bin/ibuild making all for FREEBSD in ./src/bin/ibuild/FREEBSD c++ -o a.out *.o -L../../../.././src/lib/Unidraw/FREEBSD -lUnidraw -L../../../.././src/lib/IV/FREEBSD -lIV -L/usr/X11R6/lib -lXext -lX11 -lm -lg++ cc: Internal compiler error: program ld got fatal signal 11 *** Error code 1 Stop. *** Error code 1 (ignored) >How-To-Repeat: # cd /usr/ports/x11/iv # make all >Fix: ????? >Audit-Trail: >Unformatted: From owner-freebsd-bugs Sun May 28 20:13:32 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id UAA13010 for bugs-outgoing; Sun, 28 May 1995 20:13:32 -0700 Received: from psi.wsl.sinica.edu.tw (psi.wsl.sinica.edu.tw [140.109.7.34]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id UAA13004 for ; Sun, 28 May 1995 20:13:26 -0700 Received: (from ywliu@localhost) by psi.wsl.sinica.edu.tw (8.6.9/8.6.9) id LAA19915 for freebsd-bugs@freebsd.org; Mon, 29 May 1995 11:22:33 GMT From: Yen-Wei Liu Message-Id: <199505291122.LAA19915@psi.wsl.sinica.edu.tw> Subject: uname() problem. Bug or not ? To: freebsd-bugs@FreeBSD.org Date: Mon, 29 May 1995 11:22:32 +0000 () X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 0 Sender: bugs-owner@FreeBSD.org Precedence: bulk From owner-freebsd-bugs Mon May 29 06:04:12 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id GAA27350 for bugs-outgoing; Mon, 29 May 1995 06:04:12 -0700 Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id GAA27344 for ; Mon, 29 May 1995 06:04:09 -0700 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.11/8.6.9) id GAA08152; Mon, 29 May 1995 06:01:34 -0700 Date: Mon, 29 May 1995 06:01:34 -0700 Message-Id: <199505291301.GAA08152@silvia.HIP.Berkeley.EDU> To: Lucas.James@ldjpc.apana.org.au CC: freebsd-bugs@freefall.cdrom.com In-reply-to: <199505290130.SAA09362@freefall.cdrom.com> (message from Lucas James on Sun, 28 May 1995 18:30:02 -0700) Subject: Re: misc/455: ports/x11/iv wont compile From: asami@CS.Berkeley.EDU (Satoshi Asami | =?ISO-2022-JP?B?GyRCQHUbKEI=?= =?ISO-2022-JP?B?GyRCOCsbKEIgGyRCOC0bKEI=?=) Sender: bugs-owner@FreeBSD.org Precedence: bulk * this will allow it to compile. whether it is correct or not....... Thanks, I tested it, it works exactly like you claim (well our ld doesn't get a signal :), so I committed it, because it seems to reduce the brokenness of the port by a significant margin. * There is still a problem in src/bin/ibuild with ld getting a sig11 * (see separate pr) also in src/bin/idraw getting alot of undefined * symbols, I haven't figured it out yet.... I spent the better part of the night trying to figure out the undefined symbol problem. It is because the library (libIV.a in src/lib/IV/FREEBSD) is defining a symbol (for instance) as _RasterRect__9ivPainterP8ivCanvasiiP8ivRaster while the source for idraw is referring to it as _ivRasterRect__9ivPainterP8ivCanvasiiP8ivRaster Note the missing "iv". There is a definition #define _lib_iv(name) iv##name in src/include/InterViews/iv.h, which is used as #define RasterRect _lib_iv(RasterRect) in Unidraw/_defines.h, and this file is included as #include in Unidraw/enter-scope.h. My head is spinning fast enough. Someone please unentangle this. Satoshi From owner-freebsd-bugs Mon May 29 12:00:03 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA04894 for bugs-outgoing; Mon, 29 May 1995 12:00:03 -0700 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA04885 ; Mon, 29 May 1995 12:00:02 -0700 Date: Mon, 29 May 1995 12:00:02 -0700 Message-Id: <199505291900.MAA04885@freefall.cdrom.com> From: paepcke@arcway.snafu.de Reply-To: paepcke@arcway.snafu.de To: freebsd-bugs Subject: ports/456: (new) x11/fvwm make do not look for xpm built In-Reply-To: Your message of Mon, 29 May 1995 21:32:56 GMT <199505292132.VAA02192@arcway.snafu.de> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 456 >Category: ports >Synopsis: (new) x11/fvwm make do not look for xpm built >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon May 29 12:00:01 1995 >Originator: Michael Paepcke >Organization: >Release: FreeBSD 2.0-BUILT-19950523 i386 >Environment: current >Description: the (new) fvwm-1.24r port do not try to build the graphics/xpm port >How-To-Repeat: [pkg_delete xpm-3.4e (xpm-xxx)] :-) cd /usr/ports/x11/fvwm make all >Fix: LIB_DEPENDS= ... >Audit-Trail: >Unformatted: From owner-freebsd-bugs Mon May 29 18:57:16 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA01261 for bugs-outgoing; Mon, 29 May 1995 18:57:16 -0700 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA08521 ; Mon, 29 May 1995 14:50:00 -0700 Date: Mon, 29 May 1995 14:50:00 -0700 Message-Id: <199505292150.OAA08521@freefall.cdrom.com> From: phk@FreeBSD.org Reply-To: phk@FreeBSD.org To: freebsd-bugs Subject: bin/457: possible csh bug In-Reply-To: Your message of Mon, 29 May 1995 14:41:41 -0700 <199505292141.OAA03621@critter.tfs.com> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 457 >Category: bin >Synopsis: We may have an obscure csh bug >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon May 29 14:50:00 1995 >Originator: Poul-Henning Kamp >Organization: >Release: FreeBSD BUILT-19950423 i386 >Environment: unknown >Description: /usr/bin/csh sometimes corrupts its own address space [[ malloc()ed memory ]] when the argument to the built-in cd command ends in a slash. Such corruption happens to the first slash in malloc()ed memory that follows the NULL-terminating byte of the directory-name if-and-only-if there is no NULL-byte between the directory-name NULL-terminator and the slash. This bug becomes evident to the users when the value of an environment variable which contains the slash character becomes truncated at the slash. This very old bug was inherited from BSD-csh and it exist in all BSD-based versions of the csh. >How-To-Repeat: Unknown >Fix: Unknown >Audit-Trail: >Unformatted: From owner-freebsd-bugs Tue May 30 02:08:25 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id CAA12451 for bugs-outgoing; Tue, 30 May 1995 02:08:25 -0700 Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id CAA12441 for ; Tue, 30 May 1995 02:08:22 -0700 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.11/8.6.9) id CAA10288; Tue, 30 May 1995 02:05:30 -0700 Date: Tue, 30 May 1995 02:05:30 -0700 Message-Id: <199505300905.CAA10288@silvia.HIP.Berkeley.EDU> To: Lucas.James@ldjpc.apana.org.au CC: chuckr@Glue.umd.edu, krebs@faps.uni-erlangen.de, freebsd-bugs@FreeBSD.org In-reply-to: (message from Lucas James on Tue, 30 May 1995 10:05:44 +0930 (CST)) Subject: Re: GCC 2.6.2 / InterViews won't compile From: asami@CS.Berkeley.EDU (Satoshi Asami | =?ISO-2022-JP?B?GyRCQHUbKEI=?= =?ISO-2022-JP?B?GyRCOCsbKEIgGyRCOC0bKEI=?=) Sender: bugs-owner@FreeBSD.org Precedence: bulk Hi guys. * Yahoo! It works (with a lot of tinkering.) I've attached a diff * from the original tar file. I don't see that attachment in this mail, do you know where it went? Anyway, I got a long patch from Thomas Krebs which seems to build iv-3.1 with shared libraries pretty well. Unfortunately, it's pretty long (only 536 KB ;), I don't want to put it in the cvs tree, so it's on ftp://freebsd.org/pub/FreeBSD/LOCAL_PORTS/iv-3.1-FreeBSD.patch.gz If I don't receive the patch to make one in ports work in the next couple of days, I will rewrite it to use Thomas' version so that we can have it on the CDROM. (I will make it ftp this patch.) FYI, the build process is: extract iv source, apply his patch, then export CPU=FreeBSD (or "setenv CPU FreeBSD" for *csh) make World XCONFIGDIR=/usr/X11R6/lib/X11/config Satoshi From owner-freebsd-bugs Tue May 30 02:54:53 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id CAA18735 for bugs-outgoing; Tue, 30 May 1995 02:54:53 -0700 Received: (from asami@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id CAA18718 ; Tue, 30 May 1995 02:54:51 -0700 Date: Tue, 30 May 1995 02:54:51 -0700 From: Satoshi Asami Message-Id: <199505300954.CAA18718@freefall.cdrom.com> To: paepcke@arcway.snafu.de, asami, freebsd-bugs Subject: Changed information for PR ports/456 Sender: bugs-owner@FreeBSD.org Precedence: bulk Synopsis: (new) x11/fvwm make do not look for xpm built State-Changed-From-To: open-closed State-Changed-By: asami State-Changed-When: Tue May 30 02:53:30 PDT 1995 State-Changed-Why: Proposed fix applied to revision 1.18 of ports/x11/fvwm/Makefile. From owner-freebsd-bugs Tue May 30 06:30:09 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id GAA24090 for bugs-outgoing; Tue, 30 May 1995 06:30:09 -0700 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id GAA24071 ; Tue, 30 May 1995 06:30:05 -0700 Date: Tue, 30 May 1995 06:30:05 -0700 Message-Id: <199505301330.GAA24071@freefall.cdrom.com> From: peterb@muc.de Reply-To: peterb@muc.de To: freebsd-bugs Subject: kern/459: AHA2842 (VL) Problems In-Reply-To: Your message of Tue, 30 May 1995 15:10:18 +0200 <199505301310.PAA00374@fns.muc.de> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 459 >Category: kern >Synopsis: Systems freezes w/ 2842 >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue May 30 06:30:02 1995 >Originator: Peter Bechtold >Organization: # Peter Bechtold # peterb@muc.de # Tel./Fax (+49 / 0) 89 / 542 0774 # >Release: FreeBSD 2.0-RELEASE i386 >Environment: AMD486DX4/100, VL, 20 MB Ram AHA1542B w/ Maxtor 7345S and Tandberg 3820, AHA2842 w/ Fujitsu M2684SA and 2 Maxtor 7345S, Spea Mercury Trio64 VL (no other VL cards) >Description: About two minutes after booting, the systems freezes. When pressing ALT-F?, an endless beep is heard. It happens with both the 1542 installed and not installed, any SCSI cable, with or without terminator power on a device installed. >How-To-Repeat: Just boot ... I tried -current once, same thing. >Fix: ?? >Audit-Trail: >Unformatted: From owner-freebsd-bugs Tue May 30 08:00:07 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA15001 for bugs-outgoing; Tue, 30 May 1995 08:00:07 -0700 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA14988 ; Tue, 30 May 1995 08:00:04 -0700 Date: Tue, 30 May 1995 08:00:04 -0700 Message-Id: <199505301500.IAA14988@freefall.cdrom.com> From: mark tinguely Reply-To: mark tinguely To: freebsd-bugs Subject: bin/461: Bogus lseek warning when dump large filesystems In-Reply-To: Your message of Tue, 30 May 1995 09:53:06 -0500 <199505301453.JAA00642@opus.cs.ndsu.NoDak.edu> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 461 >Category: bin >Synopsis: Bogus lseek warning when dump large filesystems >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue May 30 08:00:02 1995 >Originator: Mark Tinguely >Organization: North Dakota State University >Release: FreeBSD 2.1.0-Development i386 >Environment: >Description: When using dump/rdump on large filesytems (my case 3 GB), the lseek claims multiple times to have failed. The problem is a off_t is converted into a int and checked for a negative. A true lseek check should be checking if the off_t is equal to -1 for failure. >How-To-Repeat: run dump on a large (> 2GB) filesystem >Fix: since the lseek is set from the beginning of the filesystem, I simple check if the lseek returned the offset that was requested. maybe a more efficent test would be a test for -1. I never got the "lseek2" error message, but I changed that as well just in case. *** traverse.c.orig Thu May 26 01:34:03 1994 --- traverse.c Tue May 30 09:36:15 1995 *************** *** 558,564 **** extern int errno; loop: ! if ((int)lseek(diskfd, ((off_t)blkno << dev_bshift), 0) < 0) msg("bread: lseek fails\n"); if ((cnt = read(diskfd, buf, size)) == size) return; --- 558,565 ---- extern int errno; loop: ! if (lseek(diskfd, ((off_t)blkno << dev_bshift), 0) != ! ((off_t)blkno << dev_bshift)) msg("bread: lseek fails\n"); if ((cnt = read(diskfd, buf, size)) == size) return; *************** *** 598,604 **** */ bzero(buf, size); for (i = 0; i < size; i += dev_bsize, buf += dev_bsize, blkno++) { ! if ((int)lseek(diskfd, ((off_t)blkno << dev_bshift), 0) < 0) msg("bread: lseek2 fails!\n"); if ((cnt = read(diskfd, buf, (int)dev_bsize)) == dev_bsize) continue; --- 599,606 ---- */ bzero(buf, size); for (i = 0; i < size; i += dev_bsize, buf += dev_bsize, blkno++) { ! if (lseek(diskfd, ((off_t)blkno << dev_bshift), 0) != ! ((off_t)blkno << dev_bshift)) msg("bread: lseek2 fails!\n"); if ((cnt = read(diskfd, buf, (int)dev_bsize)) == dev_bsize) continue; >Audit-Trail: >Unformatted: From owner-freebsd-bugs Tue May 30 18:49:30 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA13885 for bugs-outgoing; Tue, 30 May 1995 18:49:30 -0700 Received: from seldon.apanix.apana.org.au (root@seldon.apanix.apana.org.au [192.203.213.8]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id SAA13256 for ; Tue, 30 May 1995 18:46:17 -0700 Received: from ldjpc.apana.org.au (ldjpc.apana.org.au [192.203.213.254]) by seldon.apanix.apana.org.au (8.6.10/8.6.9) with ESMTP id KAA02269; Wed, 31 May 1995 10:04:52 +0930 Received: (from jj@localhost) by ldjpc.apana.org.au (8.6.11/8.6.9) id JAA09592; Wed, 31 May 1995 09:02:58 +0930 From: Lucas James Date: Wed, 31 May 1995 09:02:56 +0930 (CST) To: Satoshi Asami | =?ISO-2022-JP?B?GyRCQHUbKEI=?= =?ISO-2022-JP?B?GyRCOCsbKEIgGyRCOC0bKEI=?= cc: Lucas.James@ldjpc.apana.org.au, chuckr@Glue.umd.edu, krebs@faps.uni-erlangen.de, freebsd-bugs@FreeBSD.org Subject: Re: GCC 2.6.2 / InterViews won't compile In-Reply-To: <199505300905.CAA10288@silvia.HIP.Berkeley.EDU> Message-ID: X-Warning: I speak only for myself MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1509080783-801876776=:9480" Sender: bugs-owner@FreeBSD.org Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-1509080783-801876776=:9480 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 30 May 1995, Satoshi Asami | =?ISO-2022-JP?B?GyRCQHUbKEI=?= =?ISO-2022-JP?B?GyRCOCsbKEIgGyRCOC0bKEI=?= wrote: > Hi guys. G'day > * Yahoo! It works (with a lot of tinkering.) I've attached a diff > * from the original tar file. > I don't see that attachment in this mail, do you know where it went? Yeah, It was owned by root, mod 600, so the mailer couldn't read it :( It should be mime-attached to this message tho. (fingers crossed) It is a patch that takes the tree that was extracted and patched (ie the one in port/x11/iv/work) and brings it to a state where it can compile and run. > Anyway, I got a long patch from > Thomas Krebs > which seems to build iv-3.1 with shared libraries pretty well. > Unfortunately, it's pretty long (only 536 KB ;), I don't want to put > it in the cvs tree, so it's on this one is about 41k Unless someone mails me Thomas' patch, I can't test it (on the end of a very slow link. :( -- Lucas James Lucas.James@ldjpc.apana.org.au Munno Para Scout Group - Assistant Scout Leader - "Kodak" Para Rover Crew - Rover Secretary --0-1509080783-801876776=:9480 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="iv.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: diff from 'make patch' in ports/x11/iv to a working version. ZGlmZiAtcmMgLS1leGNsdWRlPU1ha2VmaWxlIC0tZXhjbHVkZT1GUkVFQlNE IHdvcmstb3JpZy9pdi9tYWtlZmlsZSB3b3JrL2l2L21ha2VmaWxlDQoqKiog d29yay1vcmlnL2l2L21ha2VmaWxlCVdlZCBNYXkgMzEgMDg6NTI6MTMgMTk5 NQ0KLS0tIHdvcmsvaXYvbWFrZWZpbGUJU3VuIE1heSAyOCAxMjo0NToxOCAx OTk1DQoqKioqKioqKioqKioqKioNCioqKiAxNSwyMSAqKioqDQogIA0KICBN YWtlZmlsZToNCiAgCWltYWtlIC1UICJJbnRlclZpZXdzL3RlbXBsYXRlIiAt SS4vc3JjL2NvbmZpZyBcDQohIAkJLUkvdXNyL1gzODYvbGliL1gxMS9jb25m aWcgLURUT1BESVI9LiAtRENVUkRJUj0uDQogIA0KICAuREVGQVVMVDogc3Jj L01ha2VmaWxlDQogIAlAJChNQUtFKSAkKC5NQUtFRkxBR1MpIC1mIE1ha2Vm aWxlICdDUFU9JChDUFUpJyAkQA0KLS0tIDE1LDIxIC0tLS0NCiAgDQogIE1h a2VmaWxlOg0KICAJaW1ha2UgLVQgIkludGVyVmlld3MvdGVtcGxhdGUiIC1J Li9zcmMvY29uZmlnIFwNCiEgCQktSS91c3IvWDExUjYvbGliL1gxMS9jb25m aWcgLURUT1BESVI9LiAtRENVUkRJUj0uDQogIA0KICAuREVGQVVMVDogc3Jj L01ha2VmaWxlDQogIAlAJChNQUtFKSAkKC5NQUtFRkxBR1MpIC1mIE1ha2Vm aWxlICdDUFU9JChDUFUpJyAkQA0KZGlmZiAtcmMgLS1leGNsdWRlPU1ha2Vm aWxlIC0tZXhjbHVkZT1GUkVFQlNEIHdvcmstb3JpZy9pdi9zcmMvYmluL2lk cmF3L2lkY21kcy5jIHdvcmsvaXYvc3JjL2Jpbi9pZHJhdy9pZGNtZHMuYw0K KioqIHdvcmstb3JpZy9pdi9zcmMvYmluL2lkcmF3L2lkY21kcy5jCVNhdCBN YXkgMjMgMDM6Mzc6MzIgMTk5Mg0KLS0tIHdvcmsvaXYvc3JjL2Jpbi9pZHJh dy9pZGNtZHMuYwlNb24gTWF5IDI5IDIwOjE4OjQzIDE5OTUNCioqKioqKioq KioqKioqKg0KKioqIDI2LDMyICoqKioNCiAgDQogICNpbmNsdWRlICJpZGVk LmgiDQogICNpbmNsdWRlICJpZGNsYXNzZXMuaCINCi0gI2luY2x1ZGUgImlk Y21kcy5oIg0KICAjaW5jbHVkZSAiaWRjb21wLmgiDQogICNpbmNsdWRlICJp ZGRpYWxvZ3MuaCINCiAgI2luY2x1ZGUgImlkdmFycy5oIg0KLS0tIDI2LDMx IC0tLS0NCioqKioqKioqKioqKioqKg0KKioqIDQ2LDU2ICoqKioNCiAgI2lu Y2x1ZGUgPFVuaWRyYXcvQ29tbWFuZHMvZWRpdC5oPg0KICAjaW5jbHVkZSA8 VW5pZHJhdy9Db21tYW5kcy90cmFuc2Zvcm1zLmg+DQogIA0KLSAjdW5kZWYg RmlsZUNob29zZXINCi0gI2RlZmluZSBGaWxlQ2hvb3NlciBfbGliX2l2KEZp bGVDaG9vc2VyKQ0KLSANCiAgI2luY2x1ZGUgPHN0cmVhbS5oPg0KICANCiAg LyoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqLw0KICANCiAgQ2xh c3NJZCBPcGVuQ21kOjpHZXRDbGFzc0lkICgpIHsgcmV0dXJuIE9QRU5fQ01E OyB9DQotLS0gNDUsNTMgLS0tLQ0KICAjaW5jbHVkZSA8VW5pZHJhdy9Db21t YW5kcy9lZGl0Lmg+DQogICNpbmNsdWRlIDxVbmlkcmF3L0NvbW1hbmRzL3Ry YW5zZm9ybXMuaD4NCiAgDQogICNpbmNsdWRlIDxzdHJlYW0uaD4NCiAgDQor ICNpbmNsdWRlICJpZGNtZHMuaCINCiAgLyoqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqLw0KICANCiAgQ2xhc3NJZCBPcGVuQ21kOjpHZXRDbGFz c0lkICgpIHsgcmV0dXJuIE9QRU5fQ01EOyB9DQoqKioqKioqKioqKioqKioN CioqKiA1OSw2NiAqKioqDQogICAgICByZXR1cm4gT1BFTl9DTUQgPT0gaWQg fHwgVmlld0NvbXBDbWQ6OklzQShpZCk7DQogIH0NCiAgDQohIE9wZW5DbWQ6 Ok9wZW5DbWQgKENvbnRyb2xJbmZvKiBjLCBGaWxlQ2hvb3NlciogZmMpIDog Vmlld0NvbXBDbWQoYywgZmMpIHsgfQ0KISBPcGVuQ21kOjpPcGVuQ21kIChF ZGl0b3IqIGVkLCBGaWxlQ2hvb3NlciogZmMpIDogVmlld0NvbXBDbWQoZWQs IGZjKSB7IH0NCiAgDQogIENvbW1hbmQqIE9wZW5DbWQ6OkNvcHkgKCkgew0K ICAgICAgQ29tbWFuZCogY29weSA9IG5ldyBPcGVuQ21kKENvcHlDb250cm9s SW5mbygpKTsNCi0tLSA1Niw2MyAtLS0tDQogICAgICByZXR1cm4gT1BFTl9D TUQgPT0gaWQgfHwgVmlld0NvbXBDbWQ6OklzQShpZCk7DQogIH0NCiAgDQoh IE9wZW5DbWQ6Ok9wZW5DbWQgKENvbnRyb2xJbmZvKiBjLCBGaWxlQ2hvb3Nl ciogZmMpIDogVmlld0NvbXBDbWQoYywgZmMpIHsgfTsNCiEgT3BlbkNtZDo6 T3BlbkNtZCAoRWRpdG9yKiBlZCwgRmlsZUNob29zZXIqIGZjKSA6IFZpZXdD b21wQ21kKGVkLCBmYykgeyB9Ow0KICANCiAgQ29tbWFuZCogT3BlbkNtZDo6 Q29weSAoKSB7DQogICAgICBDb21tYW5kKiBjb3B5ID0gbmV3IE9wZW5DbWQo Q29weUNvbnRyb2xJbmZvKCkpOw0KZGlmZiAtcmMgLS1leGNsdWRlPU1ha2Vm aWxlIC0tZXhjbHVkZT1GUkVFQlNEIHdvcmstb3JpZy9pdi9zcmMvY29uZmln L0ludGVyVmlld3MvaXYtZnJlZWJzZC5jZiB3b3JrL2l2L3NyYy9jb25maWcv SW50ZXJWaWV3cy9pdi1mcmVlYnNkLmNmDQoqKiogd29yay1vcmlnL2l2L3Ny Yy9jb25maWcvSW50ZXJWaWV3cy9pdi1mcmVlYnNkLmNmCVdlZCBNYXkgMzEg MDg6NTI6MTMgMTk5NQ0KLS0tIHdvcmsvaXYvc3JjL2NvbmZpZy9JbnRlclZp ZXdzL2l2LWZyZWVic2QuY2YJTW9uIE1heSAyOSAyMTo1NTowMCAxOTk1DQoq KioqKioqKioqKioqKioNCioqKiAyLDggKioqKg0KICAjdW5kZWYgQ3BwQ21k DQogICNkZWZpbmUgQ3BwQ21kIGNwcA0KICAjdW5kZWYgQ0NEcml2ZXINCiEg I2RlZmluZSBDQ0RyaXZlciBjKysNCiAgI3VuZGVmIERlcGVuZENDRmxhZ3MN CiAgI2RlZmluZSBEZXBlbmRDQ0ZsYWdzICQoQ0NERUZJTkVTKSAkKENDSU5D TFVERVMpIC1JL3Vzci9pbmNsdWRlL2crKw0KICAjdW5kZWYgRXh0cmFDQ0xk TGlicw0KLS0tIDIsOCAtLS0tDQogICN1bmRlZiBDcHBDbWQNCiAgI2RlZmlu ZSBDcHBDbWQgY3BwDQogICN1bmRlZiBDQ0RyaXZlcg0KISAjZGVmaW5lIEND RHJpdmVyIC91c3IvYmluL2MrKw0KICAjdW5kZWYgRGVwZW5kQ0NGbGFncw0K ICAjZGVmaW5lIERlcGVuZENDRmxhZ3MgJChDQ0RFRklORVMpICQoQ0NJTkNM VURFUykgLUkvdXNyL2luY2x1ZGUvZysrDQogICN1bmRlZiBFeHRyYUNDTGRM aWJzDQpkaWZmIC1yYyAtLWV4Y2x1ZGU9TWFrZWZpbGUgLS1leGNsdWRlPUZS RUVCU0Qgd29yay1vcmlnL2l2L3NyYy9jb25maWcvSW50ZXJWaWV3cy9sb2Nh bC5kZWYgd29yay9pdi9zcmMvY29uZmlnL0ludGVyVmlld3MvbG9jYWwuZGVm DQoqKiogd29yay1vcmlnL2l2L3NyYy9jb25maWcvSW50ZXJWaWV3cy9sb2Nh bC5kZWYJV2VkIE1heSAzMSAwODo1MjoxMCAxOTk1DQotLS0gd29yay9pdi9z cmMvY29uZmlnL0ludGVyVmlld3MvbG9jYWwuZGVmCU1vbiBNYXkgMjkgMjM6 NTY6MzEgMTk5NQ0KKioqKioqKioqKioqKioqDQoqKiogMTAsMTggKioqKg0K ICAgKi8NCiAgI2luY2x1ZGUgPEludGVyVmlld3MvZ2NjLmRlZj4NCiAgDQoh ICNpZiBkZWZpbmVkKEZyZWVCU0RBcmNoaXRlY3R1cmUpDQogICN1bmRlZiBI YXNTdW5PU1NoYXJlZExpYnMNCiAgI2RlZmluZSBIYXNTdW5PU1NoYXJlZExp YnMgWUVTDQogICNlbmRpZg0KICANCiAgLyoNCi0tLSAxMCwyMCAtLS0tDQog ICAqLw0KICAjaW5jbHVkZSA8SW50ZXJWaWV3cy9nY2MuZGVmPg0KICANCiEg I2lmIGRlZmluZWQgKEZyZWVCU0RBcmNoaXRlY3R1cmUpDQogICN1bmRlZiBI YXNTdW5PU1NoYXJlZExpYnMNCiAgI2RlZmluZSBIYXNTdW5PU1NoYXJlZExp YnMgWUVTDQorICN1bmRlZiBIYXNTdW5PU1NoYXJlZExpYnJhcmllcw0KKyAj ZGVmaW5lIEhhc1N1bk9TU2hhcmVkTGlicmFyaWVzIFlFUw0KICAjZW5kaWYN CiAgDQogIC8qDQoqKioqKioqKioqKioqKioNCioqKiA0Nyw1MyAqKioqDQog ICAqIERlbGV0ZSB0aGlzIGRlZmluaXRpb24gaWYgeW91ciAvdG1wIHNwYWNl IGlzIGxlc3MgdGhhbiBmaXZlIG1lZ2FieXRlcy4NCiAgICovDQogICN1bmRl ZiBIYXNMYXJnZVRtcA0KLSAjZGVmaW5lIEhhc0xhcmdlVG1wIFlFUw0KICAN CiAgLyoNCiAgICogSWYgeW91IGRvIG5vdCB3YW50IHRvIGNyZWF0ZSBhIHN5 bWJvbGljIGxpbmsgY2FsbGVkICIvaW50ZXJ2aWV3cyINCi0tLSA0OSw1NCAt LS0tDQoqKioqKioqKioqKioqKioNCioqKiA3Nyw4MCAqKioqDQotLS0gNzgs ODQgLS0tLQ0KICAjZGVmaW5lIFhJbmNEaXIgL3Vzci9YMTFSNi9pbmNsdWRl DQogICN1bmRlZiBYTGliRGlyDQogICNkZWZpbmUgWExpYkRpciAvdXNyL1gx MVI2L2xpYg0KKyANCisgI3VuZGVmIFNoYXJlZENDRmxhZ3MNCisgI2RlZmlu ZSBTaGFyZWRDQ0ZsYWdzIC1mcGljDQogIA0KZGlmZiAtcmMgLS1leGNsdWRl PU1ha2VmaWxlIC0tZXhjbHVkZT1GUkVFQlNEIHdvcmstb3JpZy9pdi9zcmMv aW5jbHVkZS9JVi1YMTEveHdpbmRvdy5oIHdvcmsvaXYvc3JjL2luY2x1ZGUv SVYtWDExL3h3aW5kb3cuaA0KKioqIHdvcmstb3JpZy9pdi9zcmMvaW5jbHVk ZS9JVi1YMTEveHdpbmRvdy5oCUZyaSBTZXAgMjUgMDc6NDY6MjIgMTk5Mg0K LS0tIHdvcmsvaXYvc3JjL2luY2x1ZGUvSVYtWDExL3h3aW5kb3cuaAlTdW4g TWF5IDI4IDEyOjQ5OjE2IDE5OTUNCioqKioqKioqKioqKioqKg0KKioqIDQ2 LDUzICoqKioNCiAgY2xhc3MgU3R5bGU7DQogIGNsYXNzIFdpbmRvd0N1cnNv clN0YWNrOw0KICBjbGFzcyBXaW5kb3dUYWJsZTsNCiAgY2xhc3MgWERpc3Bs YXk7DQohIA0KICBzdHJ1Y3QgV2luZG93T3ZlcmxheUluZm8gew0KICAgICAg VmlzdWFsSUQgaWRfOw0KICAgICAgbG9uZyB0eXBlXzsNCi0tLSA0Niw1OCAt LS0tDQogIGNsYXNzIFN0eWxlOw0KICBjbGFzcyBXaW5kb3dDdXJzb3JTdGFj azsNCiAgY2xhc3MgV2luZG93VGFibGU7DQorIC8qDQorICAqIG1vZGlmaWVk IGJ5IGpqQGxkanBjLmFwYW5hLm9yZy5hdQ0KKyAgKg0KKyAgKiB0aGlzIHNl ZW1zIHRvIGJyZWFrIHRoZSBjb21waWxlLi4uDQogIGNsYXNzIFhEaXNwbGF5 Ow0KISAgKg0KISAgKi8NCiAgc3RydWN0IFdpbmRvd092ZXJsYXlJbmZvIHsN CiAgICAgIFZpc3VhbElEIGlkXzsNCiAgICAgIGxvbmcgdHlwZV87DQpkaWZm IC1yYyAtLWV4Y2x1ZGU9TWFrZWZpbGUgLS1leGNsdWRlPUZSRUVCU0Qgd29y ay1vcmlnL2l2L3NyYy9pbmNsdWRlL0ludGVyVmlld3MvX2RlZmluZXMuaCB3 b3JrL2l2L3NyYy9pbmNsdWRlL0ludGVyVmlld3MvX2RlZmluZXMuaA0KKioq IHdvcmstb3JpZy9pdi9zcmMvaW5jbHVkZS9JbnRlclZpZXdzL19kZWZpbmVz LmgJV2VkIE1heSAxMyAwNjoyOTowOSAxOTkyDQotLS0gd29yay9pdi9zcmMv aW5jbHVkZS9JbnRlclZpZXdzL19kZWZpbmVzLmgJTW9uIE1heSAyOSAxODoy NDoyNyAxOTk1DQoqKioqKioqKioqKioqKioNCioqKiAxLDE0ICoqKioNCiEg I2RlZmluZSBBbGlnbm1lbnQgX2xpYl9pdihBbGlnbm1lbnQpDQohICNkZWZp bmUgQ29sb3JJbnRlbnNpdHkgX2xpYl9pdihDb2xvckludGVuc2l0eSkNCiEg I2RlZmluZSBDb2xvck9wIF9saWJfaXYoQ29sb3JPcCkNCiEgI2RlZmluZSBD b29yZCBfbGliX2l2KENvb3JkKQ0KISAjZGVmaW5lIEV2ZW50VHlwZSBfbGli X2l2KEV2ZW50VHlwZSkNCiEgI2RlZmluZSBFdmVudEJ1dHRvbiBfbGliX2l2 KEV2ZW50QnV0dG9uKQ0KISAjZGVmaW5lIEdseXBoQnJlYWtUeXBlIF9saWJf aXYoR2x5cGhCcmVha1R5cGUpDQohICNkZWZpbmUgR2x5cGhJbmRleCBfbGli X2l2KEdseXBoSW5kZXgpDQohICNkZWZpbmUgSW50Q29vcmQgX2xpYl9pdihJ bnRDb29yZCkNCiEgI2RlZmluZSBQaXhlbENvb3JkIF9saWJfaXYoUGl4ZWxD b29yZCkNCiEgI2RlZmluZSBTZWxlY3Rpb24gX2xpYl9pdihTZWxlY3Rpb24p DQogICNkZWZpbmUgQWN0aW9uIF9saWJfaXYoQWN0aW9uKQ0KICAjZGVmaW5l IEFjdGl2ZUhhbmRsZXIgX2xpYl9pdihBY3RpdmVIYW5kbGVyKQ0KICAjZGVm aW5lIEFkanVzdGFibGUgX2xpYl9pdihBZGp1c3RhYmxlKQ0KLS0tIDEsNCAt LS0tDQohICNkZWZpbmUgQWNrbm93bGVkZ2VEaWFsb2cgX2xpYl9pdihBY2tu b3dsZWRnZURpYWxvZykNCiAgI2RlZmluZSBBY3Rpb24gX2xpYl9pdihBY3Rp b24pDQogICNkZWZpbmUgQWN0aXZlSGFuZGxlciBfbGliX2l2KEFjdGl2ZUhh bmRsZXIpDQogICNkZWZpbmUgQWRqdXN0YWJsZSBfbGliX2l2KEFkanVzdGFi bGUpDQoqKioqKioqKioqKioqKioNCioqKiAxNiwyMSAqKioqDQotLS0gNiwx NCAtLS0tDQogICNkZWZpbmUgQWdncmVnYXRlIF9saWJfaXYoQWdncmVnYXRl KQ0KICAjZGVmaW5lIEFnZ3JlZ2F0ZUluZm9fTGlzdCBfbGliX2l2KEFnZ3Jl Z2F0ZUluZm9fTGlzdCkNCiAgI2RlZmluZSBBbGlnbiBfbGliX2l2KEFsaWdu KQ0KKyAjZGVmaW5lIEFsaWduQ21kIF9saWJfaXYoQWxpZ25DbWQpDQorICNk ZWZpbmUgQWxpZ25Ub0dyaWRDbWQgX2xpYl9pdihBbGlnblRvR3JpZENtZCkN CisgI2RlZmluZSBBbGlnbm1lbnQgX2xpYl9pdihBbGlnbm1lbnQpDQogICNk ZWZpbmUgQWxsb2NhdGlvbiBfbGliX2l2KEFsbG9jYXRpb24pDQogICNkZWZp bmUgQWxsb2NhdGlvbkluZm8gX2xpYl9pdihBbGxvY2F0aW9uSW5mbykNCiAg I2RlZmluZSBBbGxvY2F0aW9uVGFibGUgX2xpYl9pdihBbGxvY2F0aW9uVGFi bGUpDQoqKioqKioqKioqKioqKioNCioqKiAyNCwzMSAqKioqDQotLS0gMTcs MjYgLS0tLQ0KICAjZGVmaW5lIEFwcGxpY2F0aW9uV2luZG93IF9saWJfaXYo QXBwbGljYXRpb25XaW5kb3cpDQogICNkZWZpbmUgQXJyYXlDb21wb3NpdG9y IF9saWJfaXYoQXJyYXlDb21wb3NpdG9yKQ0KICAjZGVmaW5lIEFycm93U3Vi Y2xhc3NOYW1lIF9saWJfaXYoQXJyb3dTdWJjbGFzc05hbWUpDQorICNkZWZp bmUgQmFja0NtZCBfbGliX2l2KEJhY2tDbWQpDQogICNkZWZpbmUgQmFja2dy b3VuZCBfbGliX2l2KEJhY2tncm91bmQpDQogICNkZWZpbmUgQmFubmVyIF9s aWJfaXYoQmFubmVyKQ0KKyAjZGVmaW5lIEJhc2ljRGlhbG9nIF9saWJfaXYo QmFzaWNEaWFsb2cpDQogICNkZWZpbmUgQmV2ZWwgX2xpYl9pdihCZXZlbCkN CiAgI2RlZmluZSBCZXZlbEZyYW1lIF9saWJfaXYoQmV2ZWxGcmFtZSkNCiAg I2RlZmluZSBCaXRtYXAgX2xpYl9pdihCaXRtYXApDQoqKioqKioqKioqKioq KioNCioqKiAzNiw4OSAqKioqDQotLS0gMzEsMTU4IC0tLS0NCiAgI2RlZmlu ZSBCb3hDYW5vbmljYWwgX2xpYl9pdihCb3hDYW5vbmljYWwpDQogICNkZWZp bmUgQm94RWxlbWVudCBfbGliX2l2KEJveEVsZW1lbnQpDQogICNkZWZpbmUg Qm94SW1wbCBfbGliX2l2KEJveEltcGwpDQorICNkZWZpbmUgQm94T2JqIF9s aWJfaXYoQm94T2JqKQ0KICAjZGVmaW5lIEJyZWFrIF9saWJfaXYoQnJlYWsp DQogICNkZWZpbmUgQnJlYWtfTGlzdCBfbGliX2l2KEJyZWFrX0xpc3QpDQog ICNkZWZpbmUgQnJvd3NlciBfbGliX2l2KEJyb3dzZXIpDQogICNkZWZpbmUg QnJvd3Nlckxpc3QgX2xpYl9pdihCcm93c2VyTGlzdCkNCiAgI2RlZmluZSBC cnVzaCBfbGliX2l2KEJydXNoKQ0KKyAjZGVmaW5lIEJydXNoQ21kIF9saWJf aXYoQnJ1c2hDbWQpDQogICNkZWZpbmUgQnJ1c2hJbXBsIF9saWJfaXYoQnJ1 c2hJbXBsKQ0KICAjZGVmaW5lIEJydXNoUmVwIF9saWJfaXYoQnJ1c2hSZXAp DQorICNkZWZpbmUgQnJ1c2hWYXIgX2xpYl9pdihCcnVzaFZhcikNCisgI2Rl ZmluZSBCcnVzaFZhclZpZXcgX2xpYl9pdihCcnVzaFZhclZpZXcpDQogICNk ZWZpbmUgQnV0dG9uIF9saWJfaXYoQnV0dG9uKQ0KICAjZGVmaW5lIEJ1dHRv bkxpc3QgX2xpYl9pdihCdXR0b25MaXN0KQ0KICAjZGVmaW5lIEJ1dHRvblN0 YXRlIF9saWJfaXYoQnV0dG9uU3RhdGUpDQorICNkZWZpbmUgQ0NueG4gX2xp Yl9pdihDQ254bikNCisgI2RlZmluZSBDQ254bl9IYXNoVGFibGUgX2xpYl9p dihDQ254bl9IYXNoVGFibGUpDQorICNkZWZpbmUgQ0dsdWUgX2xpYl9pdihD R2x1ZSkNCisgI2RlZmluZSBDTmV0IF9saWJfaXYoQ05ldCkNCisgI2RlZmlu ZSBDU29sdmVyIF9saWJfaXYoQ1NvbHZlcikNCisgI2RlZmluZSBDU29sdmVy SW5mbyBfbGliX2l2KENTb2x2ZXJJbmZvKQ0KKyAjZGVmaW5lIENTb2x2ZXJT dGF0ZSBfbGliX2l2KENTb2x2ZXJTdGF0ZSkNCiAgI2RlZmluZSBDYW52YXMg X2xpYl9pdihDYW52YXMpDQogICNkZWZpbmUgQ2FudmFzRGFtYWdlIF9saWJf aXYoQ2FudmFzRGFtYWdlKQ0KICAjZGVmaW5lIENhbnZhc1JlcCBfbGliX2l2 KENhbnZhc1JlcCkNCiAgI2RlZmluZSBDYXJkIF9saWJfaXYoQ2FyZCkNCisg I2RlZmluZSBDYXRhbG9nIF9saWJfaXYoQ2F0YWxvZykNCisgI2RlZmluZSBD YXRhbG9nQ2hvb3NlciBfbGliX2l2KENhdGFsb2dDaG9vc2VyKQ0KKyAjZGVm aW5lIENlbnRlckNtZCBfbGliX2l2KENlbnRlckNtZCkNCiAgI2RlZmluZSBD ZW50ZXJMYXlvdXQgX2xpYl9pdihDZW50ZXJMYXlvdXQpDQogICNkZWZpbmUg Q2hhcmFjdGVyIF9saWJfaXYoQ2hhcmFjdGVyKQ0KICAjZGVmaW5lIENoZWNr Qm94IF9saWJfaXYoQ2hlY2tCb3gpDQogICNkZWZpbmUgQ2hvaWNlSXRlbSBf bGliX2l2KENob2ljZUl0ZW0pDQorICNkZWZpbmUgQ2xhc3NJZCBfbGliX2l2 KENsYXNzSWQpDQorICNkZWZpbmUgQ2xpcGJvYXJkIF9saWJfaXYoQ2xpcGJv YXJkKQ0KICAjZGVmaW5lIENsaXBwaW5nU3RhY2sgX2xpYl9pdihDbGlwcGlu Z1N0YWNrKQ0KKyAjZGVmaW5lIENsb3NlRWRpdG9yQ21kIF9saWJfaXYoQ2xv c2VFZGl0b3JDbWQpDQorICNkZWZpbmUgQ2xvc2VkQlNwbGluZSBfbGliX2l2 KENsb3NlZEJTcGxpbmUpDQorICNkZWZpbmUgQ2xvc2VkU3BsaW5lQ29tcCBf bGliX2l2KENsb3NlZFNwbGluZUNvbXApDQorICNkZWZpbmUgQ2xvc2VkU3Bs aW5lVmlldyBfbGliX2l2KENsb3NlZFNwbGluZVZpZXcpDQogICNkZWZpbmUg Q29sb3IgX2xpYl9pdihDb2xvcikNCisgI2RlZmluZSBDb2xvckNtZCBfbGli X2l2KENvbG9yQ21kKQ0KKyAjZGVmaW5lIENvbG9yRGF0YSBfbGliX2l2KENv bG9yRGF0YSkNCiAgI2RlZmluZSBDb2xvckltcGwgX2xpYl9pdihDb2xvcklt cGwpDQorICNkZWZpbmUgQ29sb3JJbnRlbnNpdHkgX2xpYl9pdihDb2xvcklu dGVuc2l0eSkNCisgI2RlZmluZSBDb2xvck9wIF9saWJfaXYoQ29sb3JPcCkN CiAgI2RlZmluZSBDb2xvclJlcCBfbGliX2l2KENvbG9yUmVwKQ0KICAjZGVm aW5lIENvbG9yVGFibGUgX2xpYl9pdihDb2xvclRhYmxlKQ0KKyAjZGVmaW5l IENvbG9yVmFyIF9saWJfaXYoQ29sb3JWYXIpDQorICNkZWZpbmUgQ29tbWFu ZCBfbGliX2l2KENvbW1hbmQpDQorICNkZWZpbmUgQ29tbWFuZENvbnRyb2wg X2xpYl9pdihDb21tYW5kQ29udHJvbCkNCisgI2RlZmluZSBDb21tYW5kSW50 ZXJhY3RvciBfbGliX2l2KENvbW1hbmRJbnRlcmFjdG9yKQ0KKyAjZGVmaW5l IENvbXBOYW1lVmFyIF9saWJfaXYoQ29tcE5hbWVWYXIpDQorICNkZWZpbmUg Q29tcE5hbWVWYXJWaWV3IF9saWJfaXYoQ29tcE5hbWVWYXJWaWV3KQ0KICAj ZGVmaW5lIENvbXBsZXRpb25FZGl0b3IgX2xpYl9pdihDb21wbGV0aW9uRWRp dG9yKQ0KKyAjZGVmaW5lIENvbXBvbmVudCBfbGliX2l2KENvbXBvbmVudCkN CisgI2RlZmluZSBDb21wb25lbnRWaWV3IF9saWJfaXYoQ29tcG9uZW50Vmll dykNCiAgI2RlZmluZSBDb21wb3NpdGlvbiBfbGliX2l2KENvbXBvc2l0aW9u KQ0KICAjZGVmaW5lIENvbXBvc2l0aW9uQ29tcG9uZW50X0xpc3QgX2xpYl9p dihDb21wb3NpdGlvbkNvbXBvbmVudF9MaXN0KQ0KICAjZGVmaW5lIENvbXBv c2l0b3IgX2xpYl9pdihDb21wb3NpdG9yKQ0KKyAjZGVmaW5lIENvbmZpcm1E aWFsb2cgX2xpYl9pdihDb25maXJtRGlhbG9nKQ0KKyAjZGVmaW5lIENvbm5J bmZvIF9saWJfaXYoQ29ubkluZm8pDQorICNkZWZpbmUgQ29ubmVjdENtZCBf bGliX2l2KENvbm5lY3RDbWQpDQorICNkZWZpbmUgQ29ubmVjdE1hbmlwIF9s aWJfaXYoQ29ubmVjdE1hbmlwKQ0KKyAjZGVmaW5lIENvbm5lY3RUb29sIF9s aWJfaXYoQ29ubmVjdFRvb2wpDQorICNkZWZpbmUgQ29ubmVjdG9yIF9saWJf aXYoQ29ubmVjdG9yKQ0KKyAjZGVmaW5lIENvbm5lY3RvclZpZXcgX2xpYl9p dihDb25uZWN0b3JWaWV3KQ0KICAjZGVmaW5lIENvbnRyb2wgX2xpYl9pdihD b250cm9sKQ0KKyAjZGVmaW5lIENvbnRyb2xJbmZvIF9saWJfaXYoQ29udHJv bEluZm8pDQogICNkZWZpbmUgQ29udHJvbFN0YXRlIF9saWJfaXYoQ29udHJv bFN0YXRlKQ0KKyAjZGVmaW5lIENvb3JkIF9saWJfaXYoQ29vcmQpDQorICNk ZWZpbmUgQ29vcmRpbmF0ZVNwYWNlIF9saWJfaXYoQ29vcmRpbmF0ZVNwYWNl KQ0KKyAjZGVmaW5lIENvcHlDbWQgX2xpYl9pdihDb3B5Q21kKQ0KKyAjZGVm aW5lIENyZWF0b3IgX2xpYl9pdihDcmVhdG9yKQ0KICAjZGVmaW5lIEN1cnNv ciBfbGliX2l2KEN1cnNvcikNCiAgI2RlZmluZSBDdXJzb3JSZXAgX2xpYl9p dihDdXJzb3JSZXApDQogICNkZWZpbmUgQ3Vyc29yUmVwQml0bWFwIF9saWJf aXYoQ3Vyc29yUmVwQml0bWFwKQ0KICAjZGVmaW5lIEN1cnNvclJlcERhdGEg X2xpYl9pdihDdXJzb3JSZXBEYXRhKQ0KICAjZGVmaW5lIEN1cnNvclJlcEZv bnQgX2xpYl9pdihDdXJzb3JSZXBGb250KQ0KICAjZGVmaW5lIEN1cnNvclJl cFhGb250IF9saWJfaXYoQ3Vyc29yUmVwWEZvbnQpDQorICNkZWZpbmUgQ3V0 Q21kIF9saWJfaXYoQ3V0Q21kKQ0KKyAjZGVmaW5lIERhbWFnZSBfbGliX2l2 KERhbWFnZSkNCiAgI2RlZmluZSBEYW1hZ2VMaXN0IF9saWJfaXYoRGFtYWdl TGlzdCkNCisgI2RlZmluZSBEYXRhIF9saWJfaXYoRGF0YSkNCisgI2RlZmlu ZSBEYXRhQ2FjaGUgX2xpYl9pdihEYXRhQ2FjaGUpDQogICNkZWZpbmUgRGVi dWdHbHlwaCBfbGliX2l2KERlYnVnR2x5cGgpDQogICNkZWZpbmUgRGVjayBf bGliX2l2KERlY2spDQorICNkZWZpbmUgRGVsZXRlQ21kIF9saWJfaXYoRGVs ZXRlQ21kKQ0KICAjZGVmaW5lIERpYWxvZyBfbGliX2l2KERpYWxvZykNCiAg I2RlZmluZSBEaWFsb2dLaXQgX2xpYl9pdihEaWFsb2dLaXQpDQorICNkZWZp bmUgRGlhbG9nS2l0SW1wbCBfbGliX2l2KERpYWxvZ0tpdEltcGwpDQogICNk ZWZpbmUgRGlzcGxheSBfbGliX2l2KERpc3BsYXkpDQogICNkZWZpbmUgRGlz cGxheVJlcCBfbGliX2l2KERpc3BsYXlSZXApDQogICNkZWZpbmUgRG93bk1v dmVyIF9saWJfaXYoRG93bk1vdmVyKQ0KKyAjZGVmaW5lIERyYWcgX2xpYl9p dihEcmFnKQ0KKyAjZGVmaW5lIERyYWdNYW5pcCBfbGliX2l2KERyYWdNYW5p cCkNCisgI2RlZmluZSBEcmFnUmVwIF9saWJfaXYoRHJhZ1JlcCkNCisgI2Rl ZmluZSBEcmFnWm9uZSBfbGliX2l2KERyYWdab25lKQ0KKyAjZGVmaW5lIERy YWdab25lUmVwIF9saWJfaXYoRHJhZ1pvbmVSZXApDQorICNkZWZpbmUgRHJh Z1pvbmVTaW5rIF9saWJfaXYoRHJhZ1pvbmVTaW5rKQ0KKyAjZGVmaW5lIERy YWdab25lU2lua0hhbmRsZXIgX2xpYl9pdihEcmFnWm9uZVNpbmtIYW5kbGVy KQ0KKyAjZGVmaW5lIER1cENtZCBfbGliX2l2KER1cENtZCkNCisgI2RlZmlu ZSBFZGl0b3IgX2xpYl9pdihFZGl0b3IpDQorICNkZWZpbmUgRWRpdG9ySW1w bCBfbGliX2l2KEVkaXRvckltcGwpDQorICNkZWZpbmUgRWRpdG9ySW5mbyBf bGliX2l2KEVkaXRvckluZm8pDQorICNkZWZpbmUgRWxsaXBzZSBfbGliX2l2 KEVsbGlwc2UpDQorICNkZWZpbmUgRWxsaXBzZUNvbXAgX2xpYl9pdihFbGxp cHNlQ29tcCkNCisgI2RlZmluZSBFbGxpcHNlVmlldyBfbGliX2l2KEVsbGlw c2VWaWV3KQ0KICAjZGVmaW5lIEVubGFyZ2VyIF9saWJfaXYoRW5sYXJnZXIp DQogICNkZWZpbmUgRXZlbnQgX2xpYl9pdihFdmVudCkNCisgI2RlZmluZSBF dmVudEJ1dHRvbiBfbGliX2l2KEV2ZW50QnV0dG9uKQ0KICAjZGVmaW5lIEV2 ZW50UmVwIF9saWJfaXYoRXZlbnRSZXApDQorICNkZWZpbmUgRXZlbnRUeXBl IF9saWJfaXYoRXZlbnRUeXBlKQ0KICAjZGVmaW5lIEV4dGVuc2lvbiBfbGli X2l2KEV4dGVuc2lvbikNCisgI2RlZmluZSBFeHRlbnQgX2xpYl9pdihFeHRl bnQpDQorICNkZWZpbmUgRXh0ZXJuVmlldyBfbGliX2l2KEV4dGVyblZpZXcp DQogICNkZWZpbmUgRkJEaXJlY3RvcnkgX2xpYl9pdihGQkRpcmVjdG9yeSkN CisgI2RlZmluZSBGX0NpcmNsZSBfbGliX2l2KEZfQ2lyY2xlKQ0KKyAjZGVm aW5lIEZfQ2xvc2VkQlNwbGluZSBfbGliX2l2KEZfQ2xvc2VkQlNwbGluZSkN CisgI2RlZmluZSBGX0VsbGlwc2UgX2xpYl9pdihGX0VsbGlwc2UpDQorICNk ZWZpbmUgRl9PcGVuQlNwbGluZSBfbGliX2l2KEZfT3BlbkJTcGxpbmUpDQor ICNkZWZpbmUgRl9Qb2x5Z29uIF9saWJfaXYoRl9Qb2x5Z29uKQ0KKyAjZGVm aW5lIEZfUmVjdCBfbGliX2l2KEZfUmVjdCkNCiAgI2RlZmluZSBGaWVsZEVk aXRvciBfbGliX2l2KEZpZWxkRWRpdG9yKQ0KICAjZGVmaW5lIEZpZWxkRWRp dG9yQWN0aW9uIF9saWJfaXYoRmllbGRFZGl0b3JBY3Rpb24pDQogICNkZWZp bmUgRmllbGRFZGl0b3JJbXBsIF9saWJfaXYoRmllbGRFZGl0b3JJbXBsKQ0K KioqKioqKioqKioqKioqDQoqKiogOTIsMTEzICoqKioNCi0tLSAxNjEsMjEw IC0tLS0NCiAgI2RlZmluZSBGaWxlQ2hvb3NlciBfbGliX2l2KEZpbGVDaG9v c2VyKQ0KICAjZGVmaW5lIEZpbGVDaG9vc2VyQWN0aW9uIF9saWJfaXYoRmls ZUNob29zZXJBY3Rpb24pDQogICNkZWZpbmUgRmlsZUNob29zZXJJbXBsIF9s aWJfaXYoRmlsZUNob29zZXJJbXBsKQ0KKyAjZGVmaW5lIEZpbGVOYW1lVmFy VmlldyBfbGliX2l2KEZpbGVOYW1lVmFyVmlldykNCisgI2RlZmluZSBGaWxs UG9seWdvbk9iaiBfbGliX2l2KEZpbGxQb2x5Z29uT2JqKQ0KICAjZGVmaW5l IEZpeGVkTGF5b3V0IF9saWJfaXYoRml4ZWRMYXlvdXQpDQorICNkZWZpbmUg Rml4ZWRQaW4gX2xpYl9pdihGaXhlZFBpbikNCiAgI2RlZmluZSBGb250IF9s aWJfaXYoRm9udCkNCiAgI2RlZmluZSBGb250Qm91bmRpbmdCb3ggX2xpYl9p dihGb250Qm91bmRpbmdCb3gpDQorICNkZWZpbmUgRm9udENtZCBfbGliX2l2 KEZvbnRDbWQpDQogICNkZWZpbmUgRm9udEZhbWlseSBfbGliX2l2KEZvbnRG YW1pbHkpDQogICNkZWZpbmUgRm9udEZhbWlseUltcGwgX2xpYl9pdihGb250 RmFtaWx5SW1wbCkNCiAgI2RlZmluZSBGb250RmFtaWx5UmVwIF9saWJfaXYo Rm9udEZhbWlseVJlcCkNCiAgI2RlZmluZSBGb250SW1wbCBfbGliX2l2KEZv bnRJbXBsKQ0KICAjZGVmaW5lIEZvbnRSZXAgX2xpYl9pdihGb250UmVwKQ0K KyAjZGVmaW5lIEZvbnRWYXIgX2xpYl9pdihGb250VmFyKQ0KKyAjZGVmaW5l IEZvbnRWYXJWaWV3IF9saWJfaXYoRm9udFZhclZpZXcpDQogICNkZWZpbmUg RnJhbWUgX2xpYl9pdihGcmFtZSkNCisgI2RlZmluZSBGcm9udENtZCBfbGli X2l2KEZyb250Q21kKQ0KKyAjZGVmaW5lIEZ1bGxHcmFwaGljIF9saWJfaXYo RnVsbEdyYXBoaWMpDQogICNkZWZpbmUgR0xDb250ZXh0IF9saWJfaXYoR0xD b250ZXh0KQ0KICAjZGVmaW5lIEdMQ29udGV4dEltcGwgX2xpYl9pdihHTENv bnRleHRJbXBsKQ0KICAjZGVmaW5lIEdMV2luZG93IF9saWJfaXYoR0xXaW5k b3cpDQorICNkZWZpbmUgR1NEYXRhIF9saWJfaXYoR1NEYXRhKQ0KKyAjZGVm aW5lIEdWVV9IYXNoVGFibGUgX2xpYl9pdihHVlVfSGFzaFRhYmxlKQ0KKyAj ZGVmaW5lIEdWVXBkYXRlciBfbGliX2l2KEdWVXBkYXRlcikNCiAgI2RlZmlu ZSBHbHVlIF9saWJfaXYoR2x1ZSkNCiAgI2RlZmluZSBHbHlwaCBfbGliX2l2 KEdseXBoKQ0KKyAjZGVmaW5lIEdseXBoQnJlYWtUeXBlIF9saWJfaXYoR2x5 cGhCcmVha1R5cGUpDQorICNkZWZpbmUgR2x5cGhJbmRleCBfbGliX2l2KEds eXBoSW5kZXgpDQogICNkZWZpbmUgR3JhYkxpc3QgX2xpYl9pdihHcmFiTGlz dCkNCisgI2RlZmluZSBHcmFwaGljIF9saWJfaXYoR3JhcGhpYykNCisgI2Rl ZmluZSBHcmFwaGljQmxvY2sgX2xpYl9pdihHcmFwaGljQmxvY2spDQorICNk ZWZpbmUgR3JhcGhpY0NvbXAgX2xpYl9pdihHcmFwaGljQ29tcCkNCisgI2Rl ZmluZSBHcmFwaGljQ29tcFRvb2wgX2xpYl9pdihHcmFwaGljQ29tcFRvb2wp DQorICNkZWZpbmUgR3JhcGhpY0NvbXBzIF9saWJfaXYoR3JhcGhpY0NvbXBz KQ0KKyAjZGVmaW5lIEdyYXBoaWNWaWV3IF9saWJfaXYoR3JhcGhpY1ZpZXcp DQorICNkZWZpbmUgR3JhcGhpY1ZpZXdzIF9saWJfaXYoR3JhcGhpY1ZpZXdz KQ0KKyAjZGVmaW5lIEdyYXZpdHlDbWQgX2xpYl9pdihHcmF2aXR5Q21kKQ0K KyAjZGVmaW5lIEdyYXZpdHlWYXIgX2xpYl9pdihHcmF2aXR5VmFyKQ0KKyAj ZGVmaW5lIEdyYXZpdHlWYXJWaWV3IF9saWJfaXYoR3Jhdml0eVZhclZpZXcp DQorICNkZWZpbmUgR3JpZCBfbGliX2l2KEdyaWQpDQorICNkZWZpbmUgR3Jp ZENtZCBfbGliX2l2KEdyaWRDbWQpDQorICNkZWZpbmUgR3JpZERpYWxvZyBf bGliX2l2KEdyaWREaWFsb2cpDQorICNkZWZpbmUgR3JpZFNwYWNpbmdDbWQg X2xpYl9pdihHcmlkU3BhY2luZ0NtZCkNCiAgI2RlZmluZSBHcm91cCBfbGli X2l2KEdyb3VwKQ0KKyAjZGVmaW5lIEdyb3VwQ21kIF9saWJfaXYoR3JvdXBD bWQpDQogICNkZWZpbmUgR3Jvd2luZ0JTcGxpbmUgX2xpYl9pdihHcm93aW5n QlNwbGluZSkNCiAgI2RlZmluZSBHcm93aW5nQ2xvc2VkQlNwbGluZSBfbGli X2l2KEdyb3dpbmdDbG9zZWRCU3BsaW5lKQ0KICAjZGVmaW5lIEdyb3dpbmdN dWx0aUxpbmUgX2xpYl9pdihHcm93aW5nTXVsdGlMaW5lKQ0KKioqKioqKioq KioqKioqDQoqKiogMTE2LDEzNCAqKioqDQotLS0gMjEzLDI0MCAtLS0tDQog ICNkZWZpbmUgSEJvcmRlciBfbGliX2l2KEhCb3JkZXIpDQogICNkZWZpbmUg SEJveCBfbGliX2l2KEhCb3gpDQogICNkZWZpbmUgSEdsdWUgX2xpYl9pdihI R2x1ZSkNCisgI2RlZmluZSBIUGFuZWxDb250cm9sIF9saWJfaXYoSFBhbmVs Q29udHJvbCkNCiAgI2RlZmluZSBIUnVsZSBfbGliX2l2KEhSdWxlKQ0KICAj ZGVmaW5lIEhTY3JvbGxCYXIgX2xpYl9pdihIU2Nyb2xsQmFyKQ0KICAjZGVm aW5lIEhTY3JvbGxlciBfbGliX2l2KEhTY3JvbGxlcikNCisgI2RlZmluZSBI U2xvdENvbXAgX2xpYl9pdihIU2xvdENvbXApDQorICNkZWZpbmUgSFNsb3RW aWV3IF9saWJfaXYoSFNsb3RWaWV3KQ0KICAjZGVmaW5lIEhhbmRsZXIgX2xp Yl9pdihIYW5kbGVyKQ0KKyAjZGVmaW5lIEhpc3RvcnlNYXAgX2xpYl9pdihI aXN0b3J5TWFwKQ0KICAjZGVmaW5lIEhpdCBfbGliX2l2KEhpdCkNCiAgI2Rl ZmluZSBIaXRJbXBsIF9saWJfaXYoSGl0SW1wbCkNCiAgI2RlZmluZSBJY29u V2luZG93IF9saWJfaXYoSWNvbldpbmRvdykNCiAgI2RlZmluZSBJbWFnZSBf bGliX2l2KEltYWdlKQ0KKyAjZGVmaW5lIEltcG9ydENtZCBfbGliX2l2KElt cG9ydENtZCkNCisgI2RlZmluZSBJbm9yZGVyVmlldyBfbGliX2l2KElub3Jk ZXJWaWV3KQ0KICAjZGVmaW5lIElucHV0SGFuZGxlciBfbGliX2l2KElucHV0 SGFuZGxlcikNCiAgI2RlZmluZSBJbnB1dEhhbmRsZXJJbXBsIF9saWJfaXYo SW5wdXRIYW5kbGVySW1wbCkNCisgI2RlZmluZSBJbnRDb29yZCBfbGliX2l2 KEludENvb3JkKQ0KICAjZGVmaW5lIEludGVyYWN0b3IgX2xpYl9pdihJbnRl cmFjdG9yKQ0KICAjZGVmaW5lIEludGVyYWN0b3JIYW5kbGVyIF9saWJfaXYo SW50ZXJhY3RvckhhbmRsZXIpDQogICNkZWZpbmUgSW50ZXJhY3RvcldpbmRv dyBfbGliX2l2KEludGVyYWN0b3JXaW5kb3cpDQorICNkZWZpbmUgSXRlcmF0 b3IgX2xpYl9pdihJdGVyYXRvcikNCisgI2RlZmluZSBLZXlNYXAgX2xpYl9p dihLZXlNYXApDQogICNkZWZpbmUgS25vd25Gb250cyBfbGliX2l2KEtub3du Rm9udHMpDQogICNkZWZpbmUgTFJDb21wb3NpdGlvbiBfbGliX2l2KExSQ29t cG9zaXRpb24pDQogICNkZWZpbmUgTFJNYXJrZXIgX2xpYl9pdihMUk1hcmtl cikNCioqKioqKioqKioqKioqKg0KKioqIDEzNiwxOTggKioqKg0KLS0tIDI0 Miw0MDQgLS0tLQ0KICAjZGVmaW5lIExheW91dCBfbGliX2l2KExheW91dCkN CiAgI2RlZmluZSBMYXlvdXRLaXQgX2xpYl9pdihMYXlvdXRLaXQpDQogICNk ZWZpbmUgTGVmdE1vdmVyIF9saWJfaXYoTGVmdE1vdmVyKQ0KKyAjZGVmaW5l IExpbmUgX2xpYl9pdihMaW5lKQ0KKyAjZGVmaW5lIExpbmVDb21wIF9saWJf aXYoTGluZUNvbXApDQorICNkZWZpbmUgTGluZU9iaiBfbGliX2l2KExpbmVP YmopDQorICNkZWZpbmUgTGluZVZpZXcgX2xpYl9pdihMaW5lVmlldykNCisg I2RlZmluZSBMaW5rQ29tcCBfbGliX2l2KExpbmtDb21wKQ0KKyAjZGVmaW5l IExpbmtWaWV3IF9saWJfaXYoTGlua1ZpZXcpDQogICNkZWZpbmUgTUZEaWFs b2dLaXQgX2xpYl9pdihNRkRpYWxvZ0tpdCkNCiAgI2RlZmluZSBNRktpdCBf bGliX2l2KE1GS2l0KQ0KICAjZGVmaW5lIE1GS2l0SW1wbCBfbGliX2l2KE1G S2l0SW1wbCkNCiAgI2RlZmluZSBNYWNybyBfbGliX2l2KE1hY3JvKQ0KKyAj ZGVmaW5lIE1hY3JvQWN0aW9uTGlzdCBfbGliX2l2KE1hY3JvQWN0aW9uTGlz dCkNCisgI2RlZmluZSBNYWNyb0NtZCBfbGliX2l2KE1hY3JvQ21kKQ0KKyAj ZGVmaW5lIE1hZ25pZlZhciBfbGliX2l2KE1hZ25pZlZhcikNCisgI2RlZmlu ZSBNYWduaWZWYXJWaWV3IF9saWJfaXYoTWFnbmlmVmFyVmlldykNCisgI2Rl ZmluZSBNYWduaWZ5VG9vbCBfbGliX2l2KE1hZ25pZnlUb29sKQ0KKyAjZGVm aW5lIE1hbmFnZWRXaW5kb3cgX2xpYl9pdihNYW5hZ2VkV2luZG93KQ0KICAj ZGVmaW5lIE1hbmFnZWRXaW5kb3cgX2xpYl9pdihNYW5hZ2VkV2luZG93KQ0K ICAjZGVmaW5lIE1hbmFnZWRXaW5kb3dIaW50SW5mbyBfbGliX2l2KE1hbmFn ZWRXaW5kb3dIaW50SW5mbykNCiAgI2RlZmluZSBNYW5hZ2VkV2luZG93UmVw IF9saWJfaXYoTWFuYWdlZFdpbmRvd1JlcCkNCisgI2RlZmluZSBNYW5pcEdy b3VwIF9saWJfaXYoTWFuaXBHcm91cCkNCisgI2RlZmluZSBNYW5pcHVsYXRv ciBfbGliX2l2KE1hbmlwdWxhdG9yKQ0KICAjZGVmaW5lIE1hcmdpbkZyYW1l IF9saWJfaXYoTWFyZ2luRnJhbWUpDQogICNkZWZpbmUgTWFyZ2luTGF5b3V0 IF9saWJfaXYoTWFyZ2luTGF5b3V0KQ0KICAjZGVmaW5lIE1hdGNoRWRpdG9y IF9saWJfaXYoTWF0Y2hFZGl0b3IpDQorICNkZWZpbmUgTWF0Y2hFZGl0b3Ig X2xpYl9pdihNYXRjaEVkaXRvcikNCiAgI2RlZmluZSBNZW51IF9saWJfaXYo TWVudSkNCiAgI2RlZmluZSBNZW51QmFyIF9saWJfaXYoTWVudUJhcikNCiAg I2RlZmluZSBNZW51SW1wbCBfbGliX2l2KE1lbnVJbXBsKQ0KICAjZGVmaW5l IE1lbnVJdGVtIF9saWJfaXYoTWVudUl0ZW0pDQogICNkZWZpbmUgTWVzc2Fn ZSBfbGliX2l2KE1lc3NhZ2UpDQorICNkZWZpbmUgTW9iaWxpdHlDbWQgX2xp Yl9pdihNb2JpbGl0eUNtZCkNCisgI2RlZmluZSBNb2JpbGl0eURhdGEgX2xp Yl9pdihNb2JpbGl0eURhdGEpDQorICNkZWZpbmUgTW9kaWZTdGF0dXNWYXIg X2xpYl9pdihNb2RpZlN0YXR1c1ZhcikNCisgI2RlZmluZSBNb2RpZlN0YXR1 c1ZhclZpZXcgX2xpYl9pdihNb2RpZlN0YXR1c1ZhclZpZXcpDQogICNkZWZp bmUgTW9ub0dseXBoIF9saWJfaXYoTW9ub0dseXBoKQ0KKyAjZGVmaW5lIE1v bm9LaXQgX2xpYl9pdihNb25vS2l0KQ0KKyAjZGVmaW5lIE1vbm9LaXRJbXBs IF9saWJfaXYoTW9ub0tpdEltcGwpDQogICNkZWZpbmUgTW9ub1NjZW5lIF9s aWJfaXYoTW9ub1NjZW5lKQ0KKyAjZGVmaW5lIE1vdmVDbWQgX2xpYl9pdihN b3ZlQ21kKQ0KKyAjZGVmaW5lIE1vdmVEYXRhIF9saWJfaXYoTW92ZURhdGEp DQorICNkZWZpbmUgTW92ZVRvb2wgX2xpYl9pdihNb3ZlVG9vbCkNCiAgI2Rl ZmluZSBNb3ZlciBfbGliX2l2KE1vdmVyKQ0KKyAjZGVmaW5lIE11bHRpTGlu ZSBfbGliX2l2KE11bHRpTGluZSkNCisgI2RlZmluZSBNdWx0aUxpbmVDb21w IF9saWJfaXYoTXVsdGlMaW5lQ29tcCkNCisgI2RlZmluZSBNdWx0aUxpbmVP YmogX2xpYl9pdihNdWx0aUxpbmVPYmopDQorICNkZWZpbmUgTXVsdGlMaW5l VmlldyBfbGliX2l2KE11bHRpTGluZVZpZXcpDQorICNkZWZpbmUgTk9QQ21k IF9saWJfaXYoTk9QQ21kKQ0KKyAjZGVmaW5lIE5hbWVNYXAgX2xpYl9pdihO YW1lTWFwKQ0KKyAjZGVmaW5lIE5hbWVWYXIgX2xpYl9pdihOYW1lVmFyKQ0K KyAjZGVmaW5lIE5hbWVWYXJWaWV3IF9saWJfaXYoTmFtZVZhclZpZXcpDQog ICNkZWZpbmUgTmF0dXJhbExheW91dCBfbGliX2l2KE5hdHVyYWxMYXlvdXQp DQorICNkZWZpbmUgTmV3Q29tcENtZCBfbGliX2l2KE5ld0NvbXBDbWQpDQor ICNkZWZpbmUgTm9ybVNpemVDbWQgX2xpYl9pdihOb3JtU2l6ZUNtZCkNCisg I2RlZmluZSBPTERpYWxvZ0tpdCBfbGliX2l2KE9MRGlhbG9nS2l0KQ0KKyAj ZGVmaW5lIE9MS2l0IF9saWJfaXYoT0xLaXQpDQorICNkZWZpbmUgT0xLaXRJ bXBsIF9saWJfaXYoT0xLaXRJbXBsKQ0KKyAjZGVmaW5lIE9iamVjdE1hcCBf bGliX2l2KE9iamVjdE1hcCkNCisgI2RlZmluZSBPYmplY3RNYXBFbGVtIF9s aWJfaXYoT2JqZWN0TWFwRWxlbSkNCiAgI2RlZmluZSBPYnNlcnZhYmxlIF9s aWJfaXYoT2JzZXJ2YWJsZSkNCiAgI2RlZmluZSBPYnNlcnZlciBfbGliX2l2 KE9ic2VydmVyKQ0KICAjZGVmaW5lIE9ic2VydmVyTGlzdCBfbGliX2l2KE9i c2VydmVyTGlzdCkNCisgI2RlZmluZSBPcGVuQlNwbGluZSBfbGliX2l2KE9w ZW5CU3BsaW5lKQ0KICAjZGVmaW5lIE9wdGlvbkRlc2MgX2xpYl9pdihPcHRp b25EZXNjKQ0KKyAjZGVmaW5lIE9yaWVudGF0aW9uIF9saWJfaXYoT3JpZW50 YXRpb24pDQorICNkZWZpbmUgT3JpZW50YXRpb25DbWQgX2xpYl9pdihPcmll bnRhdGlvbkNtZCkNCisgI2RlZmluZSBQU0JydXNoIF9saWJfaXYoUFNCcnVz aCkNCisgI2RlZmluZSBQU0Nsb3NlZFNwbGluZSBfbGliX2l2KFBTQ2xvc2Vk U3BsaW5lKQ0KKyAjZGVmaW5lIFBTQ29sb3IgX2xpYl9pdihQU0NvbG9yKQ0K KyAjZGVmaW5lIFBTRWxsaXBzZSBfbGliX2l2KFBTRWxsaXBzZSkNCiAgI2Rl ZmluZSBQU0ZvbnQgX2xpYl9pdihQU0ZvbnQpDQogICNkZWZpbmUgUFNGb250 SW1wbCBfbGliX2l2KFBTRm9udEltcGwpDQorICNkZWZpbmUgUFNMaW5lIF9s aWJfaXYoUFNMaW5lKQ0KKyAjZGVmaW5lIFBTTGluayBfbGliX2l2KFBTTGlu aykNCisgI2RlZmluZSBQU011bHRpTGluZSBfbGliX2l2KFBTTXVsdGlMaW5l KQ0KKyAjZGVmaW5lIFBTUGFkIF9saWJfaXYoUFNQYWQpDQorICNkZWZpbmUg UFNQYXR0ZXJuIF9saWJfaXYoUFNQYXR0ZXJuKQ0KKyAjZGVmaW5lIFBTUGlu IF9saWJfaXYoUFNQaW4pDQorICNkZWZpbmUgUFNQb2x5Z29uIF9saWJfaXYo UFNQb2x5Z29uKQ0KKyAjZGVmaW5lIFBTUmFzdGVyIF9saWJfaXYoUFNSYXN0 ZXIpDQorICNkZWZpbmUgUFNSZWN0IF9saWJfaXYoUFNSZWN0KQ0KKyAjZGVm aW5lIFBTU2xvdCBfbGliX2l2KFBTU2xvdCkNCisgI2RlZmluZSBQU1NwbGlu ZSBfbGliX2l2KFBTU3BsaW5lKQ0KKyAjZGVmaW5lIFBTU3RlbmNpbCBfbGli X2l2KFBTU3RlbmNpbCkNCisgI2RlZmluZSBQU1RleHQgX2xpYl9pdihQU1Rl eHQpDQorICNkZWZpbmUgUFNWZXJ0aWNlcyBfbGliX2l2KFBTVmVydGljZXMp DQorICNkZWZpbmUgUGFkQ29tcCBfbGliX2l2KFBhZENvbXApDQorICNkZWZp bmUgUGFkR3JhcGhpYyBfbGliX2l2KFBhZEdyYXBoaWMpDQorICNkZWZpbmUg UGFkVmlldyBfbGliX2l2KFBhZFZpZXcpDQogICNkZWZpbmUgUGFnZSBfbGli X2l2KFBhZ2UpDQogICNkZWZpbmUgUGFnZUluZm9fTGlzdCBfbGliX2l2KFBh Z2VJbmZvX0xpc3QpDQogICNkZWZpbmUgUGFpbnRlciBfbGliX2l2KFBhaW50 ZXIpDQogICNkZWZpbmUgUGFpbnRlclJlcCBfbGliX2l2KFBhaW50ZXJSZXAp DQorICNkZWZpbmUgUGFuZWxDb250cm9sIF9saWJfaXYoUGFuZWxDb250cm9s KQ0KKyAjZGVmaW5lIFBhbmVsSW50ZXJhY3RvciBfbGliX2l2KFBhbmVsSW50 ZXJhY3RvcikNCiAgI2RlZmluZSBQYW5uZXIgX2xpYl9pdihQYW5uZXIpDQor ICNkZWZpbmUgUGFzdGVDbWQgX2xpYl9pdihQYXN0ZUNtZCkNCiAgI2RlZmlu ZSBQYXRjaCBfbGliX2l2KFBhdGNoKQ0KKyAjZGVmaW5lIFBhdGggX2xpYl9p dihQYXRoKQ0KICAjZGVmaW5lIFBhdGhSZW5kZXJJbmZvIF9saWJfaXYoUGF0 aFJlbmRlckluZm8pDQogICNkZWZpbmUgUGF0dGVybiBfbGliX2l2KFBhdHRl cm4pDQorICNkZWZpbmUgUGF0dGVybkNtZCBfbGliX2l2KFBhdHRlcm5DbWQp DQogICNkZWZpbmUgUGF0dGVyblJlcCBfbGliX2l2KFBhdHRlcm5SZXApDQor ICNkZWZpbmUgUGF0dGVyblZhciBfbGliX2l2KFBhdHRlcm5WYXIpDQorICNk ZWZpbmUgUGF0dGVyblZhclZpZXcgX2xpYl9pdihQYXR0ZXJuVmFyVmlldykN CiAgI2RlZmluZSBQZXJzcGVjdGl2ZSBfbGliX2l2KFBlcnNwZWN0aXZlKQ0K KyAjZGVmaW5lIFBpY3R1cmUgX2xpYl9pdihQaWN0dXJlKQ0KKyAjZGVmaW5l IFBpbkNvbXAgX2xpYl9pdihQaW5Db21wKQ0KKyAjZGVmaW5lIFBpbkdyYXBo aWMgX2xpYl9pdihQaW5HcmFwaGljKQ0KKyAjZGVmaW5lIFBpblZpZXcgX2xp Yl9pdihQaW5WaWV3KQ0KKyAjZGVmaW5lIFBpeGVsQ29vcmQgX2xpYl9pdihQ aXhlbENvb3JkKQ0KICAjZGVmaW5lIFBsYWNlbWVudCBfbGliX2l2KFBsYWNl bWVudCkNCisgI2RlZmluZSBQb2ludCBfbGliX2l2KFBvaW50KQ0KKyAjZGVm aW5lIFBvaW50T2JqIF9saWJfaXYoUG9pbnRPYmopDQogICNkZWZpbmUgUG9s eUdseXBoIF9saWJfaXYoUG9seUdseXBoKQ0KICAjZGVmaW5lIFBvbHlHbHlw aEltcGwgX2xpYl9pdihQb2x5R2x5cGhJbXBsKQ0KKyAjZGVmaW5lIFBvbHln b24gX2xpYl9pdihQb2x5Z29uKQ0KKyAjZGVmaW5lIFBvbHlnb25Db21wIF9s aWJfaXYoUG9seWdvbkNvbXApDQorICNkZWZpbmUgUG9seWdvblZpZXcgX2xp Yl9pdihQb2x5Z29uVmlldykNCiAgI2RlZmluZSBQb3B1cE1lbnUgX2xpYl9p dihQb3B1cE1lbnUpDQogICNkZWZpbmUgUG9wdXBXaW5kb3cgX2xpYl9pdihQ b3B1cFdpbmRvdykNCisgI2RlZmluZSBQb3N0U2NyaXB0VmlldyBfbGliX2l2 KFBvc3RTY3JpcHRWaWV3KQ0KKyAjZGVmaW5lIFBvc3RTY3JpcHRWaWV3cyBf bGliX2l2KFBvc3RTY3JpcHRWaWV3cykNCisgI2RlZmluZSBQb3N0b3JkZXJW aWV3IF9saWJfaXYoUG9zdG9yZGVyVmlldykNCisgI2RlZmluZSBQcmVvcmRl clZpZXcgX2xpYl9pdihQcmVvcmRlclZpZXcpDQorICNkZWZpbmUgUHJpbnRC UyBfbGliX2l2KFByaW50QlMpDQorICNkZWZpbmUgUHJpbnRDbWQgX2xpYl9p dihQcmludENtZCkNCisgI2RlZmluZSBQcmludERpYWxvZyBfbGliX2l2KFBy aW50RGlhbG9nKQ0KICAjZGVmaW5lIFByaW50ZXIgX2xpYl9pdihQcmludGVy KQ0KICAjZGVmaW5lIFByaW50ZXJSZXAgX2xpYl9pdihQcmludGVyUmVwKQ0K ICAjZGVmaW5lIFByb3BlcnR5RGF0YSBfbGliX2l2KFByb3BlcnR5RGF0YSkN CiAgI2RlZmluZSBQdWxsZG93bk1lbnUgX2xpYl9pdihQdWxsZG93bk1lbnUp DQogICNkZWZpbmUgUHVsbHJpZ2h0TWVudSBfbGliX2l2KFB1bGxyaWdodE1l bnUpDQogICNkZWZpbmUgUHVzaEJ1dHRvbiBfbGliX2l2KFB1c2hCdXR0b24p DQorICNkZWZpbmUgUXVpdENtZCBfbGliX2l2KFF1aXRDbWQpDQogICNkZWZp bmUgUkdCVGFibGUgX2xpYl9pdihSR0JUYWJsZSkNCiAgI2RlZmluZSBSYWRp b0J1dHRvbiBfbGliX2l2KFJhZGlvQnV0dG9uKQ0KICAjZGVmaW5lIFJhc3Rl ciBfbGliX2l2KFJhc3RlcikNCisgI2RlZmluZSBSYXN0ZXJDb21wIF9saWJf aXYoUmFzdGVyQ29tcCkNCisgI2RlZmluZSBSYXN0ZXJSZWN0IF9saWJfaXYo UmFzdGVyUmVjdCkNCiAgI2RlZmluZSBSYXN0ZXJSZXAgX2xpYl9pdihSYXN0 ZXJSZXApDQorICNkZWZpbmUgUmFzdGVyVmlldyBfbGliX2l2KFJhc3RlclZp ZXcpDQorICNkZWZpbmUgUmVjdENvbXAgX2xpYl9pdihSZWN0Q29tcCkNCisg I2RlZmluZSBSZWN0VmlldyBfbGliX2l2KFJlY3RWaWV3KQ0KKyAjZGVmaW5l IFJlZFRvRml0Q21kIF9saWJfaXYoUmVkVG9GaXRDbWQpDQorICNkZWZpbmUg UmVkb0NtZCBfbGliX2l2KFJlZG9DbWQpDQogICNkZWZpbmUgUmVkdWNlciBf bGliX2l2KFJlZHVjZXIpDQogICNkZWZpbmUgUmVnZXhwIF9saWJfaXYoUmVn ZXhwKQ0KKyAjZGVmaW5lIFJlcGxhY2VDbWQgX2xpYl9pdihSZXBsYWNlQ21k KQ0KICAjZGVmaW5lIFJlcUVyciBfbGliX2l2KFJlcUVycikNCiAgI2RlZmlu ZSBSZXF1aXJlbWVudCBfbGliX2l2KFJlcXVpcmVtZW50KQ0KICAjZGVmaW5l IFJlcXVpc2l0aW9uIF9saWJfaXYoUmVxdWlzaXRpb24pDQorICNkZWZpbmUg UmVzaGFwZVRvb2wgX2xpYl9pdihSZXNoYXBlVG9vbCkNCiAgI2RlZmluZSBS ZXNvdXJjZSBfbGliX2l2KFJlc291cmNlKQ0KKyAjZGVmaW5lIFJldmVydENt ZCBfbGliX2l2KFJldmVydENtZCkNCiAgI2RlZmluZSBSaWdodE1vdmVyIF9s aWJfaXYoUmlnaHRNb3ZlcikNCisgI2RlZmluZSBSb3RhdGVDbWQgX2xpYl9p dihSb3RhdGVDbWQpDQorICNkZWZpbmUgUm90YXRlVG9vbCBfbGliX2l2KFJv dGF0ZVRvb2wpDQogICNkZWZpbmUgUm90YXRpbmdMaW5lIF9saWJfaXYoUm90 YXRpbmdMaW5lKQ0KICAjZGVmaW5lIFJvdGF0aW5nTGluZUxpc3QgX2xpYl9p dihSb3RhdGluZ0xpbmVMaXN0KQ0KICAjZGVmaW5lIFJvdGF0aW5nUmVjdCBf bGliX2l2KFJvdGF0aW5nUmVjdCkNCioqKioqKioqKioqKioqKg0KKioqIDIx MSwyMTggKioqKg0KLS0tIDQxNyw0NDQgLS0tLQ0KICAjZGVmaW5lIFJ1YmJl clZlcnRleCBfbGliX2l2KFJ1YmJlclZlcnRleCkNCiAgI2RlZmluZSBSdWJi ZXJiYW5kIF9saWJfaXYoUnViYmVyYmFuZCkNCiAgI2RlZmluZSBSdWxlIF9s aWJfaXYoUnVsZSkNCisgI2RlZmluZSBTRkhfQ2xvc2VkQlNwbGluZSBfbGli X2l2KFNGSF9DbG9zZWRCU3BsaW5lKQ0KKyAjZGVmaW5lIFNGSF9PcGVuQlNw bGluZSBfbGliX2l2KFNGSF9PcGVuQlNwbGluZSkNCisgI2RlZmluZSBTRl9D aXJjbGUgX2xpYl9pdihTRl9DaXJjbGUpDQorICNkZWZpbmUgU0ZfQ2xvc2Vk QlNwbGluZSBfbGliX2l2KFNGX0Nsb3NlZEJTcGxpbmUpDQorICNkZWZpbmUg U0ZfRWxsaXBzZSBfbGliX2l2KFNGX0VsbGlwc2UpDQorICNkZWZpbmUgU0Zf TXVsdGlMaW5lIF9saWJfaXYoU0ZfTXVsdGlMaW5lKQ0KKyAjZGVmaW5lIFNG X09wZW5CU3BsaW5lIF9saWJfaXYoU0ZfT3BlbkJTcGxpbmUpDQorICNkZWZp bmUgU0ZfUG9seWdvbiBfbGliX2l2KFNGX1BvbHlnb24pDQorICNkZWZpbmUg U0ZfUmVjdCBfbGliX2l2KFNGX1JlY3QpDQogICNkZWZpbmUgU01GS2l0IF9s aWJfaXYoU01GS2l0KQ0KICAjZGVmaW5lIFNNRktpdEltcGwgX2xpYl9pdihT TUZLaXRJbXBsKQ0KKyAjZGVmaW5lIFNfQ2lyY2xlIF9saWJfaXYoU19DaXJj bGUpDQorICNkZWZpbmUgU19DbG9zZWRCU3BsaW5lIF9saWJfaXYoU19DbG9z ZWRCU3BsaW5lKQ0KKyAjZGVmaW5lIFNfRWxsaXBzZSBfbGliX2l2KFNfRWxs aXBzZSkNCisgI2RlZmluZSBTX011bHRpTGluZSBfbGliX2l2KFNfTXVsdGlM aW5lKQ0KKyAjZGVmaW5lIFNfT3BlbkJTcGxpbmUgX2xpYl9pdihTX09wZW5C U3BsaW5lKQ0KKyAjZGVmaW5lIFNfUG9seWdvbiBfbGliX2l2KFNfUG9seWdv bikNCisgI2RlZmluZSBTX1JlY3QgX2xpYl9pdihTX1JlY3QpDQorICNkZWZp bmUgU2F2ZUNvbXBBc0NtZCBfbGliX2l2KFNhdmVDb21wQXNDbWQpDQorICNk ZWZpbmUgU2F2ZUNvbXBDbWQgX2xpYl9pdihTYXZlQ29tcENtZCkNCisgI2Rl ZmluZSBTY2FsZUNtZCBfbGliX2l2KFNjYWxlQ21kKQ0KKyAjZGVmaW5lIFNj YWxlVG9vbCBfbGliX2l2KFNjYWxlVG9vbCkNCiAgI2RlZmluZSBTY2FsaW5n TGluZSBfbGliX2l2KFNjYWxpbmdMaW5lKQ0KICAjZGVmaW5lIFNjYWxpbmdM aW5lTGlzdCBfbGliX2l2KFNjYWxpbmdMaW5lTGlzdCkNCiAgI2RlZmluZSBT Y2FsaW5nUmVjdCBfbGliX2l2KFNjYWxpbmdSZWN0KQ0KKioqKioqKioqKioq KioqDQoqKiogMjIwLDIyNSAqKioqDQotLS0gNDQ2LDQ1MyAtLS0tDQogICNk ZWZpbmUgU2Nyb2xsQmFyIF9saWJfaXYoU2Nyb2xsQmFyKQ0KICAjZGVmaW5l IFNjcm9sbEJveCBfbGliX2l2KFNjcm9sbEJveCkNCiAgI2RlZmluZSBTY3Jv bGxlciBfbGliX2l2KFNjcm9sbGVyKQ0KKyAjZGVmaW5lIFNlbGVjdFRvb2wg X2xpYl9pdihTZWxlY3RUb29sKQ0KKyAjZGVmaW5lIFNlbGVjdGlvbiBfbGli X2l2KFNlbGVjdGlvbikNCiAgI2RlZmluZSBTZWxlY3Rpb25IYW5kbGVyIF9s aWJfaXYoU2VsZWN0aW9uSGFuZGxlcikNCiAgI2RlZmluZSBTZWxlY3Rpb25M aXN0IF9saWJfaXYoU2VsZWN0aW9uTGlzdCkNCiAgI2RlZmluZSBTZWxlY3Rp b25NYW5hZ2VyIF9saWJfaXYoU2VsZWN0aW9uTWFuYWdlcikNCioqKioqKioq KioqKioqKg0KKioqIDIzMiwyNDcgKioqKg0KLS0tIDQ2MCw0ODggLS0tLQ0K ICAjZGVmaW5lIFNoYXBlIF9saWJfaXYoU2hhcGUpDQogICNkZWZpbmUgU2hv d0ZyYW1lIF9saWJfaXYoU2hvd0ZyYW1lKQ0KICAjZGVmaW5lIFNpbXBsZUNv bXBvc2l0b3IgX2xpYl9pdihTaW1wbGVDb21wb3NpdG9yKQ0KKyAjZGVmaW5l IFNsY3RBbGxDbWQgX2xpYl9pdihTbGN0QWxsQ21kKQ0KICAjZGVmaW5lIFNs aWRlciBfbGliX2l2KFNsaWRlcikNCiAgI2RlZmluZSBTbGlkZXJJbXBsIF9s aWJfaXYoU2xpZGVySW1wbCkNCiAgI2RlZmluZSBTbGlkaW5nRWxsaXBzZSBf bGliX2l2KFNsaWRpbmdFbGxpcHNlKQ0KICAjZGVmaW5lIFNsaWRpbmdMaW5l IF9saWJfaXYoU2xpZGluZ0xpbmUpDQogICNkZWZpbmUgU2xpZGluZ0xpbmVM aXN0IF9saWJfaXYoU2xpZGluZ0xpbmVMaXN0KQ0KKyAjZGVmaW5lIFNsaWRp bmdQaW4gX2xpYl9pdihTbGlkaW5nUGluKQ0KICAjZGVmaW5lIFNsaWRpbmdQ b2ludExpc3QgX2xpYl9pdihTbGlkaW5nUG9pbnRMaXN0KQ0KICAjZGVmaW5l IFNsaWRpbmdSZWN0IF9saWJfaXYoU2xpZGluZ1JlY3QpDQorICNkZWZpbmUg U2xvdENvbXAgX2xpYl9pdihTbG90Q29tcCkNCisgI2RlZmluZSBTbG90R3Jh cGhpYyBfbGliX2l2KFNsb3RHcmFwaGljKQ0KKyAjZGVmaW5lIFNsb3RWaWV3 IF9saWJfaXYoU2xvdFZpZXcpDQorICNkZWZpbmUgU3BsaW5lQ29tcCBfbGli X2l2KFNwbGluZUNvbXApDQorICNkZWZpbmUgU3BsaW5lVmlldyBfbGliX2l2 KFNwbGluZVZpZXcpDQorICNkZWZpbmUgU3RhdGUgX2xpYl9pdihTdGF0ZSkN CisgI2RlZmluZSBTdGF0ZVZhciBfbGliX2l2KFN0YXRlVmFyKQ0KKyAjZGVm aW5lIFN0YXRlVmFyVmlldyBfbGliX2l2KFN0YXRlVmFyVmlldykNCiAgI2Rl ZmluZSBTdGVuY2lsIF9saWJfaXYoU3RlbmNpbCkNCisgI2RlZmluZSBTdGVu Y2lsQ29tcCBfbGliX2l2KFN0ZW5jaWxDb21wKQ0KKyAjZGVmaW5lIFN0ZW5j aWxWaWV3IF9saWJfaXYoU3RlbmNpbFZpZXcpDQogICNkZWZpbmUgU3RlcHBl ciBfbGliX2l2KFN0ZXBwZXIpDQogICNkZWZpbmUgU3RlcHBlclN1YmNsYXNz TmFtZSBfbGliX2l2KFN0ZXBwZXJTdWJjbGFzc05hbWUpDQorICNkZWZpbmUg U3RyZXRjaFRvb2wgX2xpYl9pdihTdHJldGNoVG9vbCkNCiAgI2RlZmluZSBT dHJldGNoaW5nUmVjdCBfbGliX2l2KFN0cmV0Y2hpbmdSZWN0KQ0KICAjZGVm aW5lIFN0cmluZ0Jyb3dzZXIgX2xpYl9pdihTdHJpbmdCcm93c2VyKQ0KICAj ZGVmaW5lIFN0cmluZ0Nob29zZXIgX2xpYl9pdihTdHJpbmdDaG9vc2VyKQ0K KioqKioqKioqKioqKioqDQoqKiogMjU0LDI1OSAqKioqDQotLS0gNDk1LDUw MiAtLS0tDQogICNkZWZpbmUgVEJDb21wb3NpdGlvbiBfbGliX2l2KFRCQ29t cG9zaXRpb24pDQogICNkZWZpbmUgVEJTY3JvbGxCb3ggX2xpYl9pdihUQlNj cm9sbEJveCkNCiAgI2RlZmluZSBUQlNjcm9sbEJveEltcGwgX2xpYl9pdihU QlNjcm9sbEJveEltcGwpDQorICNkZWZpbmUgVEZfMlBvcnQgX2xpYl9pdihU Rl8yUG9ydCkNCisgI2RlZmluZSBURl9EaXJlY3QgX2xpYl9pdihURl9EaXJl Y3QpDQogICNkZWZpbmUgVEdsdWUgX2xpYl9pdihUR2x1ZSkNCiAgI2RlZmlu ZSBUSUZGUmFzdGVyIF9saWJfaXYoVElGRlJhc3RlcikNCiAgI2RlZmluZSBU U29sdmVyIF9saWJfaXYoVFNvbHZlcikNCioqKioqKioqKioqKioqKg0KKioq IDI2MywyNzggKioqKg0KLS0tIDUwNiw1MjkgLS0tLQ0KICAjZGVmaW5lIFRl bGx0YWxlR3JvdXAgX2xpYl9pdihUZWxsdGFsZUdyb3VwKQ0KICAjZGVmaW5l IFRlbGx0YWxlU3RhdGUgX2xpYl9pdihUZWxsdGFsZVN0YXRlKQ0KICAjZGVm aW5lIFRleHRCdWZmZXIgX2xpYl9pdihUZXh0QnVmZmVyKQ0KKyAjZGVmaW5l IFRleHRCdWZmZXIgX2xpYl9pdihUZXh0QnVmZmVyKQ0KICAjZGVmaW5lIFRl eHRCdXR0b24gX2xpYl9pdihUZXh0QnV0dG9uKQ0KKyAjZGVmaW5lIFRleHRD b21wIF9saWJfaXYoVGV4dENvbXApDQogICNkZWZpbmUgVGV4dERpc3BsYXkg X2xpYl9pdihUZXh0RGlzcGxheSkNCiAgI2RlZmluZSBUZXh0RWRpdG9yIF9s aWJfaXYoVGV4dEVkaXRvcikNCisgI2RlZmluZSBUZXh0R3JhcGhpYyBfbGli X2l2KFRleHRHcmFwaGljKQ0KKyAjZGVmaW5lIFRleHRJbnRlcmFjdG9yIF9s aWJfaXYoVGV4dEludGVyYWN0b3IpDQorICNkZWZpbmUgVGV4dE1hbmlwIF9s aWJfaXYoVGV4dE1hbmlwKQ0KICAjZGVmaW5lIFRleHRSZW5kZXJJbmZvIF9s aWJfaXYoVGV4dFJlbmRlckluZm8pDQorICNkZWZpbmUgVGV4dFZpZXcgX2xp Yl9pdihUZXh0VmlldykNCiAgI2RlZmluZSBUaWxlIF9saWJfaXYoVGlsZSkN CiAgI2RlZmluZSBUaWxlRmlyc3RBbGlnbmVkIF9saWJfaXYoVGlsZUZpcnN0 QWxpZ25lZCkNCiAgI2RlZmluZSBUaWxlUmV2ZXJzZWQgX2xpYl9pdihUaWxl UmV2ZXJzZWQpDQogICNkZWZpbmUgVGlsZVJldmVyc2VkRmlyc3RBbGlnbmVk IF9saWJfaXYoVGlsZVJldmVyc2VkRmlyc3RBbGlnbmVkKQ0KICAjZGVmaW5l IFRpdGxlRnJhbWUgX2xpYl9pdihUaXRsZUZyYW1lKQ0KKyAjZGVmaW5lIFRv b2wgX2xpYl9pdihUb29sKQ0KICAjZGVmaW5lIFRvcExldmVsV2luZG93IF9s aWJfaXYoVG9wTGV2ZWxXaW5kb3cpDQorICNkZWZpbmUgVHJhbnNmZXJGdW5j dCBfbGliX2l2KFRyYW5zZmVyRnVuY3QpDQogICNkZWZpbmUgVHJhbnNmb3Jt Rml0dGVyIF9saWJfaXYoVHJhbnNmb3JtRml0dGVyKQ0KICAjZGVmaW5lIFRy YW5zZm9ybVNldHRlciBfbGliX2l2KFRyYW5zZm9ybVNldHRlcikNCiAgI2Rl ZmluZSBUcmFuc2Zvcm1lciBfbGliX2l2KFRyYW5zZm9ybWVyKQ0KKioqKioq KioqKioqKioqDQoqKiogMjgwLDMwNCAqKioqDQotLS0gNTMxLDU4NSAtLS0t DQogICNkZWZpbmUgVHJhbnNpZW50V2luZG93IF9saWJfaXYoVHJhbnNpZW50 V2luZG93KQ0KICAjZGVmaW5lIFRyYXkgX2xpYl9pdihUcmF5KQ0KICAjZGVm aW5lIFRyYXlFbGVtZW50IF9saWJfaXYoVHJheUVsZW1lbnQpDQorICNkZWZp bmUgVUFycmF5IF9saWJfaXYoVUFycmF5KQ0KKyAjZGVmaW5lIFVDaG9vc2Vy IF9saWJfaXYoVUNob29zZXIpDQorICNkZWZpbmUgVUNvbnRyb2wgX2xpYl9p dihVQ29udHJvbCkNCisgI2RlZmluZSBVQ29udHJvbEludGVyYWN0b3IgX2xp Yl9pdihVQ29udHJvbEludGVyYWN0b3IpDQorICNkZWZpbmUgVUhhc2hFbGVt IF9saWJfaXYoVUhhc2hFbGVtKQ0KKyAjZGVmaW5lIFVIYXNoVGFibGUgX2xp Yl9pdihVSGFzaFRhYmxlKQ0KKyAjZGVmaW5lIFVMYWJlbCBfbGliX2l2KFVM YWJlbCkNCisgI2RlZmluZSBVTGlzdCBfbGliX2l2KFVMaXN0KQ0KKyAjZGVm aW5lIFVNYXAgX2xpYl9pdihVTWFwKQ0KKyAjZGVmaW5lIFVNYXBFbGVtIF9s aWJfaXYoVU1hcEVsZW0pDQorICNkZWZpbmUgVVBhZ2UgX2xpYl9pdihVUGFn ZSkNCisgI2RlZmluZSBVU3RlbmNpbCBfbGliX2l2KFVTdGVuY2lsKQ0KKyAj ZGVmaW5lIFVuZG9DbWQgX2xpYl9pdihVbmRvQ21kKQ0KKyAjZGVmaW5lIFVu Z3JvdXBDbWQgX2xpYl9pdihVbmdyb3VwQ21kKQ0KKyAjZGVmaW5lIFVuaWRy YXcgX2xpYl9pdihVbmlkcmF3KQ0KICAjZGVmaW5lIFVwTW92ZXIgX2xpYl9p dihVcE1vdmVyKQ0KICAjZGVmaW5lIFZCb3JkZXIgX2xpYl9pdihWQm9yZGVy KQ0KICAjZGVmaW5lIFZCb3ggX2xpYl9pdihWQm94KQ0KICAjZGVmaW5lIFZH bHVlIF9saWJfaXYoVkdsdWUpDQorICNkZWZpbmUgVlBhbmVsQ29udHJvbCBf bGliX2l2KFZQYW5lbENvbnRyb2wpDQogICNkZWZpbmUgVlJ1bGUgX2xpYl9p dihWUnVsZSkNCiAgI2RlZmluZSBWU2Nyb2xsQmFyIF9saWJfaXYoVlNjcm9s bEJhcikNCiAgI2RlZmluZSBWU2Nyb2xsZXIgX2xpYl9pdihWU2Nyb2xsZXIp DQorICNkZWZpbmUgVlNsb3RDb21wIF9saWJfaXYoVlNsb3RDb21wKQ0KKyAj ZGVmaW5lIFZTbG90VmlldyBfbGliX2l2KFZTbG90VmlldykNCiAgI2RlZmlu ZSBWYXJpYWJsZUxheW91dCBfbGliX2l2KFZhcmlhYmxlTGF5b3V0KQ0KKyAj ZGVmaW5lIFZlcnRleE1hbmlwIF9saWJfaXYoVmVydGV4TWFuaXApDQorICNk ZWZpbmUgVmVydGljZXMgX2xpYl9pdihWZXJ0aWNlcykNCisgI2RlZmluZSBW ZXJ0aWNlc0NvbXAgX2xpYl9pdihWZXJ0aWNlc0NvbXApDQorICNkZWZpbmUg VmVydGljZXNWaWV3IF9saWJfaXYoVmVydGljZXNWaWV3KQ0KKyAjZGVmaW5l IFZpZXdDb21wQ21kIF9saWJfaXYoVmlld0NvbXBDbWQpDQogICNkZWZpbmUg Vmlld0xpc3QgX2xpYl9pdihWaWV3TGlzdCkNCisgI2RlZmluZSBWaWV3ZXIg X2xpYl9pdihWaWV3ZXIpDQorICNkZWZpbmUgVmlld2VyVmlldyBfbGliX2l2 KFZpZXdlclZpZXcpDQogICNkZWZpbmUgVmlld3BvcnQgX2xpYl9pdihWaWV3 cG9ydCkNCisgI2RlZmluZSBWb2lkRGF0YSBfbGliX2l2KFZvaWREYXRhKQ0K ICAjZGVmaW5lIFdpZGdldEtpdCBfbGliX2l2KFdpZGdldEtpdCkNCiAgI2Rl ZmluZSBXaWRnZXRLaXRJbXBsIF9saWJfaXYoV2lkZ2V0S2l0SW1wbCkNCiAg I2RlZmluZSBXaW5kb3cgX2xpYl9pdihXaW5kb3cpDQorICNkZWZpbmUgV2lu ZG93Q3Vyc29yU3RhY2sgX2xpYl9pdihXaW5kb3dDdXJzb3JTdGFjaykNCiAg I2RlZmluZSBXaW5kb3dSZXAgX2xpYl9pdihXaW5kb3dSZXApDQogICNkZWZp bmUgV2luZG93VGFibGUgX2xpYl9pdihXaW5kb3dUYWJsZSkNCiAgI2RlZmlu ZSBXaW5kb3dWaXN1YWwgX2xpYl9pdihXaW5kb3dWaXN1YWwpDQogICNkZWZp bmUgV29ybGQgX2xpYl9pdihXb3JsZCkNCisgI2RlZmluZSBYRGlzcGxheSBf bGliX2l2KFhEaXNwbGF5KQ0KKyAjZGVmaW5lIFhEcmFnIF9saWJfaXYoWERy YWcpDQogICNkZWZpbmUgWFNsaWRlciBfbGliX2l2KFhTbGlkZXIpDQogICNk ZWZpbmUgWFlNYXJrZXIgX2xpYl9pdihYWU1hcmtlcikNCiAgI2RlZmluZSBY WVNsaWRlciBfbGliX2l2KFhZU2xpZGVyKQ0KICAjZGVmaW5lIFlTbGlkZXIg X2xpYl9pdihZU2xpZGVyKQ0KICAjZGVmaW5lIFpvb21lciBfbGliX2l2KFpv b21lcikNCisgI2RlZmluZSBab29taW5nIF9saWJfaXYoWm9vbWluZykNCmRp ZmYgLXJjIC0tZXhjbHVkZT1NYWtlZmlsZSAtLWV4Y2x1ZGU9RlJFRUJTRCB3 b3JrLW9yaWcvaXYvc3JjL2luY2x1ZGUvSW50ZXJWaWV3cy9fbmFtZXMuaCB3 b3JrL2l2L3NyYy9pbmNsdWRlL0ludGVyVmlld3MvX25hbWVzLmgNCioqKiB3 b3JrLW9yaWcvaXYvc3JjL2luY2x1ZGUvSW50ZXJWaWV3cy9fbmFtZXMuaAlG cmkgTWFyIDIwIDA3OjQ2OjQ5IDE5OTINCi0tLSB3b3JrL2l2L3NyYy9pbmNs dWRlL0ludGVyVmlld3MvX25hbWVzLmgJTW9uIE1heSAyOSAxOToyMzo1NiAx OTk1DQoqKioqKioqKioqKioqKioNCioqKiAzNiw0MSAqKioqDQotLS0gMzYs NDggLS0tLQ0KICAjdW5kZWYgQ29vcmQNCiAgI3VuZGVmIERlY2sNCiAgI3Vu ZGVmIERpYWxvZw0KKyAjdW5kZWYgUmFzdGVyUmVjdA0KKyAjdW5kZWYgUG9p bnQNCisgI3VuZGVmIExpbmUNCisgI3VuZGVmIEVsbGlwc2UNCisgI3VuZGVm IE11bHRpTGluZQ0KKyAjdW5kZWYgUG9seWdvbg0KKyAjdW5kZWYgQ2xvc2Vk QlNwbGluZQ0KICAjdW5kZWYgRmlsZUJyb3dzZXINCiAgI3VuZGVmIEZpbGVD aG9vc2VyDQogICN1bmRlZiBHbHVlDQoqKioqKioqKioqKioqKioNCioqKiA2 OCw3MyAqKioqDQotLS0gNzUsODcgLS0tLQ0KICAjZGVmaW5lIENvb3JkIF9s aWJfaXYoQ29vcmQpDQogICNkZWZpbmUgRGVjayBfbGliX2l2KERlY2spDQog ICNkZWZpbmUgRGlhbG9nIF9saWJfaXYoRGlhbG9nKQ0KKyAjZGVmaW5lIFJh c3RlclJlY3QgX2xpYl9pdihSYXN0ZXJSZWN0KQ0KKyAjZGVmaW5lIFBvaW50 IF9saWJfaXYoUG9pbnQpDQorICNkZWZpbmUgTGluZSBfbGliX2l2KExpbmUp DQorICNkZWZpbmUgRWxsaXBzZSBfbGliX2l2KEVsbGlwc2UpDQorICNkZWZp bmUgTXVsdGlMaW5lIF9saWJfaXYoTXVsdGlMaW5lKQ0KKyAjZGVmaW5lIFBv bHlnb24gX2xpYl9pdihQb2x5Z29uKQ0KKyAjZGVmaW5lIENsb3NlZEJTcGxp bmUgX2xpYl9pdihDbG9zZWRCU3BsaW5lKQ0KICAjZGVmaW5lIEZpbGVCcm93 c2VyIF9saWJfaXYoRmlsZUJyb3dzZXIpDQogICNkZWZpbmUgRmlsZUNob29z ZXIgX2xpYl9pdihGaWxlQ2hvb3NlcikNCiAgI2RlZmluZSBHbHVlIF9saWJf aXYoR2x1ZSkNCmRpZmYgLXJjIC0tZXhjbHVkZT1NYWtlZmlsZSAtLWV4Y2x1 ZGU9RlJFRUJTRCB3b3JrLW9yaWcvaXYvc3JjL2luY2x1ZGUvSW50ZXJWaWV3 cy9fdW5kZWZzLmggd29yay9pdi9zcmMvaW5jbHVkZS9JbnRlclZpZXdzL191 bmRlZnMuaA0KKioqIHdvcmstb3JpZy9pdi9zcmMvaW5jbHVkZS9JbnRlclZp ZXdzL191bmRlZnMuaAlXZWQgTWF5IDEzIDA2OjI5OjA5IDE5OTINCi0tLSB3 b3JrL2l2L3NyYy9pbmNsdWRlL0ludGVyVmlld3MvX3VuZGVmcy5oCU1vbiBN YXkgMjkgMTg6MTU6MzYgMTk5NQ0KKioqKioqKioqKioqKioqDQoqKiogNjUs NzAgKioqKg0KLS0tIDY1LDcxIC0tLS0NCiAgI3VuZGVmIENvbXBvc2l0b3IN CiAgI3VuZGVmIENvbnRyb2wNCiAgI3VuZGVmIENvbnRyb2xTdGF0ZQ0KKyAj dW5kZWYgQ29vcmRpbmF0ZVNwYWNlDQogICN1bmRlZiBDdXJzb3INCiAgI3Vu ZGVmIEN1cnNvclJlcA0KICAjdW5kZWYgQ3Vyc29yUmVwQml0bWFwDQoqKioq KioqKioqKioqKioNCioqKiA3Niw4NCAqKioqDQotLS0gNzcsOTIgLS0tLQ0K ICAjdW5kZWYgRGVjaw0KICAjdW5kZWYgRGlhbG9nDQogICN1bmRlZiBEaWFs b2dLaXQNCisgI3VuZGVmIERpYWxvZ0tpdEltcGwNCiAgI3VuZGVmIERpc3Bs YXkNCiAgI3VuZGVmIERpc3BsYXlSZXANCiAgI3VuZGVmIERvd25Nb3Zlcg0K KyAjdW5kZWYgRHJhZw0KKyAjdW5kZWYgRHJhZ1JlcA0KKyAjdW5kZWYgRHJh Z1pvbmUNCisgI3VuZGVmIERyYWdab25lUmVwDQorICN1bmRlZiBEcmFnWm9u ZVNpbmsNCisgI3VuZGVmIERyYWdab25lU2lua0hhbmRsZXINCiAgI3VuZGVm IEVubGFyZ2VyDQogICN1bmRlZiBFdmVudA0KICAjdW5kZWYgRXZlbnRSZXAN CioqKioqKioqKioqKioqKg0KKioqIDE0MCwxNDUgKioqKg0KLS0tIDE0OCwx NTQgLS0tLQ0KICAjdW5kZWYgTUZLaXQNCiAgI3VuZGVmIE1GS2l0SW1wbA0K ICAjdW5kZWYgTWFjcm8NCisgI3VuZGVmIE1hY3JvQWN0aW9uTGlzdA0KICAj dW5kZWYgTWFuYWdlZFdpbmRvdw0KICAjdW5kZWYgTWFuYWdlZFdpbmRvd0hp bnRJbmZvDQogICN1bmRlZiBNYW5hZ2VkV2luZG93UmVwDQoqKioqKioqKioq KioqKioNCioqKiAxNTIsMTYwICoqKioNCi0tLSAxNjEsMTc0IC0tLS0NCiAg I3VuZGVmIE1lbnVJdGVtDQogICN1bmRlZiBNZXNzYWdlDQogICN1bmRlZiBN b25vR2x5cGgNCisgI3VuZGVmIE1vbm9LaXQNCisgI3VuZGVmIE1vbm9LaXRJ bXBsDQogICN1bmRlZiBNb25vU2NlbmUNCiAgI3VuZGVmIE1vdmVyDQogICN1 bmRlZiBOYXR1cmFsTGF5b3V0DQorICN1bmRlZiBPTERpYWxvZ0tpdA0KKyAj dW5kZWYgT0xLaXQNCisgI3VuZGVmIE9MS2l0SW1wbA0KICAjdW5kZWYgT2Jz ZXJ2YWJsZQ0KICAjdW5kZWYgT2JzZXJ2ZXINCiAgI3VuZGVmIE9ic2VydmVy TGlzdA0KKioqKioqKioqKioqKioqDQoqKiogMjkzLDMwMiAqKioqDQotLS0g MzA3LDMxOSAtLS0tDQogICN1bmRlZiBXaWRnZXRLaXQNCiAgI3VuZGVmIFdp ZGdldEtpdEltcGwNCiAgI3VuZGVmIFdpbmRvdw0KKyAjdW5kZWYgV2luZG93 Q3Vyc29yU3RhY2sNCiAgI3VuZGVmIFdpbmRvd1JlcA0KICAjdW5kZWYgV2lu ZG93VGFibGUNCiAgI3VuZGVmIFdpbmRvd1Zpc3VhbA0KICAjdW5kZWYgV29y bGQNCisgI3VuZGVmIFhEaXNwbGF5DQorICN1bmRlZiBYRHJhZw0KICAjdW5k ZWYgWFNsaWRlcg0KICAjdW5kZWYgWFlNYXJrZXINCiAgI3VuZGVmIFhZU2xp ZGVyDQpkaWZmIC1yYyAtLWV4Y2x1ZGU9TWFrZWZpbGUgLS1leGNsdWRlPUZS RUVCU0Qgd29yay1vcmlnL2l2L3NyYy9pbmNsdWRlL1VuaWRyYXcvX2RlZmlu ZXMuaCB3b3JrL2l2L3NyYy9pbmNsdWRlL1VuaWRyYXcvX2RlZmluZXMuaA0K KioqIHdvcmstb3JpZy9pdi9zcmMvaW5jbHVkZS9VbmlkcmF3L19kZWZpbmVz LmgJU2F0IE9jdCAzMSAwOTo1MjozNSAxOTkyDQotLS0gd29yay9pdi9zcmMv aW5jbHVkZS9VbmlkcmF3L19kZWZpbmVzLmgJTW9uIE1heSAyOSAxODozNDox NyAxOTk1DQoqKioqKioqKioqKioqKioNCioqKiAxNTYsMTYyICoqKioNCiAg I2RlZmluZSBQYWRDb21wIF9saWJfaXYoUGFkQ29tcCkNCiAgI2RlZmluZSBQ YWRHcmFwaGljIF9saWJfaXYoUGFkR3JhcGhpYykNCiAgI2RlZmluZSBQYWRW aWV3IF9saWJfaXYoUGFkVmlldykNCi0gI2RlZmluZSBQYWdlIF9saWJfaXYo UGFnZSkNCiAgI2RlZmluZSBQYW5lbENvbnRyb2wgX2xpYl9pdihQYW5lbENv bnRyb2wpDQogICNkZWZpbmUgUGFuZWxJbnRlcmFjdG9yIF9saWJfaXYoUGFu ZWxJbnRlcmFjdG9yKQ0KICAjZGVmaW5lIFBhc3RlQ21kIF9saWJfaXYoUGFz dGVDbWQpDQotLS0gMTU2LDE2MSAtLS0tDQpkaWZmIC1yYyAtLWV4Y2x1ZGU9 TWFrZWZpbGUgLS1leGNsdWRlPUZSRUVCU0Qgd29yay1vcmlnL2l2L3NyYy9p bmNsdWRlL1VuaWRyYXcvX3VuZGVmcy5oIHdvcmsvaXYvc3JjL2luY2x1ZGUv VW5pZHJhdy9fdW5kZWZzLmgNCioqKiB3b3JrLW9yaWcvaXYvc3JjL2luY2x1 ZGUvVW5pZHJhdy9fdW5kZWZzLmgJU2F0IE9jdCAzMSAwOTo1MjozNSAxOTky DQotLS0gd29yay9pdi9zcmMvaW5jbHVkZS9VbmlkcmF3L191bmRlZnMuaAlN b24gTWF5IDI5IDE4OjM0OjE3IDE5OTUNCioqKioqKioqKioqKioqKg0KKioq IDE1NiwxNjIgKioqKg0KICAjdW5kZWYgUGFkQ29tcA0KICAjdW5kZWYgUGFk R3JhcGhpYw0KICAjdW5kZWYgUGFkVmlldw0KLSAjdW5kZWYgUGFnZQ0KICAj dW5kZWYgUGFuZWxDb250cm9sDQogICN1bmRlZiBQYW5lbEludGVyYWN0b3IN CiAgI3VuZGVmIFBhc3RlQ21kDQotLS0gMTU2LDE2MSAtLS0tDQpkaWZmIC1y YyAtLWV4Y2x1ZGU9TWFrZWZpbGUgLS1leGNsdWRlPUZSRUVCU0Qgd29yay1v cmlnL2l2L3NyYy9saWIvSVYtMl82L3BhaW50ZXIuYyB3b3JrL2l2L3NyYy9s aWIvSVYtMl82L3BhaW50ZXIuYw0KKioqIHdvcmstb3JpZy9pdi9zcmMvbGli L0lWLTJfNi9wYWludGVyLmMJV2VkIEZlYiAxMiAwNzoxOTo0NCAxOTkyDQot LS0gd29yay9pdi9zcmMvbGliL0lWLTJfNi9wYWludGVyLmMJTW9uIE1heSAy OSAxNTowMToyNyAxOTk1DQoqKioqKioqKioqKioqKioNCioqKiAzOSw0NCAq KioqDQotLS0gMzksNDcgLS0tLQ0KICAjaW5jbHVkZSA8c3RkbGliLmg+DQog ICNpbmNsdWRlIDxzdHJpbmcuaD4NCiAgDQorICNpbmNsdWRlIDxJbnRlclZp ZXdzL19uYW1lcy5oPg0KKyAjaW5jbHVkZSA8SW50ZXJWaWV3cy9fZW50ZXIu aD4NCisgDQogIC8qDQogICAqIEZvciByZWFzb25zIG9mIGNhY2hpbmcsIGl0 IGlzIGltcG9ydGFudCB0aGF0IHRoZSBhdHRyaWJ1dGVzDQogICAqIGFyZSBz ZXQgdG8gbmlsIChvciAwKSBiZWZvcmUgYmVpbmcgc2V0IHRvIHRoZWlyIGRl ZmF1bHQgdmFsdWVzLg0KZGlmZiAtcmMgLS1leGNsdWRlPU1ha2VmaWxlIC0t ZXhjbHVkZT1GUkVFQlNEIHdvcmstb3JpZy9pdi9zcmMvbGliL0lWLTJfNi94 cGFpbnRlci5jIHdvcmsvaXYvc3JjL2xpYi9JVi0yXzYveHBhaW50ZXIuYw0K KioqIHdvcmstb3JpZy9pdi9zcmMvbGliL0lWLTJfNi94cGFpbnRlci5jCVR1 ZSBPY3QgMjAgMDY6MDI6NDIgMTk5Mg0KLS0tIHdvcmsvaXYvc3JjL2xpYi9J Vi0yXzYveHBhaW50ZXIuYwlNb24gTWF5IDI5IDE5OjE5OjEzIDE5OTUNCioq KioqKioqKioqKioqKg0KKioqIDU2LDYxICoqKioNCi0tLSA1Niw2MiAtLS0t DQogICNpbmNsdWRlIDxPUy9tYXRoLmg+DQogICNpbmNsdWRlIDxPUy9zdHJp bmcuaD4NCiAgI2luY2x1ZGUgPE9TL3RhYmxlMi5oPg0KKyAjaW5jbHVkZSA8 SW50ZXJWaWV3cy9fbmFtZXMuaD4NCiAgDQogIFBhaW50ZXJSZXA6OlBhaW50 ZXJSZXAoKSB7DQogICAgICBkaXNwbGF5ID0gU2Vzc2lvbjo6aW5zdGFuY2Uo KS0+ZGVmYXVsdF9kaXNwbGF5KCk7DQpkaWZmIC1yYyAtLWV4Y2x1ZGU9TWFr ZWZpbGUgLS1leGNsdWRlPUZSRUVCU0Qgd29yay1vcmlnL2l2L3NyYy9saWIv VElGRi9wcm90b3R5cGVzLmggd29yay9pdi9zcmMvbGliL1RJRkYvcHJvdG90 eXBlcy5oDQoqKiogd29yay1vcmlnL2l2L3NyYy9saWIvVElGRi9wcm90b3R5 cGVzLmgJV2VkIE1heSAzMSAwODo1MjoxMiAxOTk1DQotLS0gd29yay9pdi9z cmMvbGliL1RJRkYvcHJvdG90eXBlcy5oCVN1biBNYXkgMjggMTQ6MjE6MDQg MTk5NQ0KKioqKioqKioqKioqKioqDQoqKiogMjUsMzEgKioqKg0KICAgKi8N CiAgDQogICNpZiBVU0VfUFJPVE9UWVBFUw0KLSB2YV9kY2wNCiAgI2RlZmlu ZQlERUNMQVJFMShmLHQxLGExKQkJZih0MSBhMSkNCiAgI2RlZmluZQlERUNM QVJFMihmLHQxLGExLHQyLGEyKQkJZih0MSBhMSwgdDIgYTIpDQogICNkZWZp bmUJREVDTEFSRTMoZix0MSxhMSx0MixhMix0MyxhMykJZih0MSBhMSwgdDIg YTIsIHQzIGEzKQ0KLS0tIDI1LDMwIC0tLS0NCmRpZmYgLXJjIC0tZXhjbHVk ZT1NYWtlZmlsZSAtLWV4Y2x1ZGU9RlJFRUJTRCB3b3JrLW9yaWcvaXYvc3Jj L2xpYi9USUZGL3RpZl9hdXguYyB3b3JrL2l2L3NyYy9saWIvVElGRi90aWZf YXV4LmMNCioqKiB3b3JrLW9yaWcvaXYvc3JjL2xpYi9USUZGL3RpZl9hdXgu YwlTYXQgTWFyIDI4IDA4OjIzOjA2IDE5OTINCi0tLSB3b3JrL2l2L3NyYy9s aWIvVElGRi90aWZfYXV4LmMJU3VuIE1heSAyOCAxNDoxNTo1MCAxOTk1DQoq KioqKioqKioqKioqKioNCioqKiA0Miw0NyAqKioqDQotLS0gNDIsNDkgLS0t LQ0KICAgKglleHBsY2l0IHZhbHVlcyBzbyB0aGF0IGRlZmF1bHRzIGV4aXN0 IG9ubHkgb25lDQogICAqCXBsYWNlIGluIHRoZSBsaWJyYXJ5IC0tIGluIFRJ RkZEZWZhdWx0RGlyZWN0b3J5Lg0KICAgKi8NCisgIDsNCisgIC8qIGZvciBz b21lIHJlYXNvbiBpdCBuZWVkcyBhIDsgYmVmb3JlIHRoaXMgbGluZSAqLw0K ICBUSUZGVkdldEZpZWxkRGVmYXVsdGVkKHRpZiwgdGFnLCBhcCkNCiAgCVRJ RkYgKnRpZjsNCiAgCWludCB0YWc7DQpkaWZmIC1yYyAtLWV4Y2x1ZGU9TWFr ZWZpbGUgLS1leGNsdWRlPUZSRUVCU0Qgd29yay1vcmlnL2l2L3NyYy9saWIv VElGRi90aWZfZGlyLmMgd29yay9pdi9zcmMvbGliL1RJRkYvdGlmX2Rpci5j DQoqKiogd29yay1vcmlnL2l2L3NyYy9saWIvVElGRi90aWZfZGlyLmMJU2F0 IE1hciAgNyAwNjoyOTo1MSAxOTkyDQotLS0gd29yay9pdi9zcmMvbGliL1RJ RkYvdGlmX2Rpci5jCVN1biBNYXkgMjggMTM6MDA6MDMgMTk5NQ0KKioqKioq KioqKioqKioqDQoqKiogOTUwLDk1NiAqKioqDQogIAkJfQ0KICAJCWlmICh0 aWYtPnRpZl9mbGFncyAmIFRJRkZfU1dBQikNCiAgCQkJVElGRlN3YWJTaG9y dCgmZGlyY291bnQpOw0KISAJCWxzZWVrKHRpZi0+dGlmX2ZkLCBkaXJjb3Vu dCpzaXplb2YgKFRJRkZEaXJFbnRyeSksIExfSU5DUik7DQogIAkJaWYgKCFS ZWFkT0sodGlmLT50aWZfZmQsICZuZXh0ZGlyLCBzaXplb2YgKG5leHRkaXIp KSkgew0KICAJCQlUSUZGRXJyb3IobW9kdWxlLCAiJXM6IEVycm9yIGZldGNo aW5nIGRpcmVjdG9yeSBsaW5rIiwNCiAgCQkJICAgIHRpZi0+dGlmX25hbWUp Ow0KLS0tIDk1MCw5NTcgLS0tLQ0KICAJCX0NCiAgCQlpZiAodGlmLT50aWZf ZmxhZ3MgJiBUSUZGX1NXQUIpDQogIAkJCVRJRkZTd2FiU2hvcnQoJmRpcmNv dW50KTsNCiEgCQkvKmFkZGVkIChvZmZfdCkgLi4gampAbGRqcGMuYXBhbmEu b3JnLmF1Ki8NCiEgCQlsc2Vlayh0aWYtPnRpZl9mZCwgKG9mZl90KShkaXJj b3VudCpzaXplb2YgKFRJRkZEaXJFbnRyeSkpLCBMX0lOQ1IpOw0KICAJCWlm ICghUmVhZE9LKHRpZi0+dGlmX2ZkLCAmbmV4dGRpciwgc2l6ZW9mIChuZXh0 ZGlyKSkpIHsNCiAgCQkJVElGRkVycm9yKG1vZHVsZSwgIiVzOiBFcnJvciBm ZXRjaGluZyBkaXJlY3RvcnkgbGluayIsDQogIAkJCSAgICB0aWYtPnRpZl9u YW1lKTsNCmRpZmYgLXJjIC0tZXhjbHVkZT1NYWtlZmlsZSAtLWV4Y2x1ZGU9 RlJFRUJTRCB3b3JrLW9yaWcvaXYvc3JjL2xpYi9USUZGL3RpZl9kaXJ3cml0 ZS5jIHdvcmsvaXYvc3JjL2xpYi9USUZGL3RpZl9kaXJ3cml0ZS5jDQoqKiog d29yay1vcmlnL2l2L3NyYy9saWIvVElGRi90aWZfZGlyd3JpdGUuYwlXZWQg TWFyIDE4IDA1OjM5OjI5IDE5OTINCi0tLSB3b3JrL2l2L3NyYy9saWIvVElG Ri90aWZfZGlyd3JpdGUuYwlTdW4gTWF5IDI4IDEyOjU3OjExIDE5OTUNCioq KioqKioqKioqKioqKg0KKioqIDE3NywxODMgKioqKg0KICAJZGF0YW9mZiA9 IHRpZi0+dGlmX2Rpcm9mZiArIHNpemVvZiAoc2hvcnQpICsgZGlyc2l6ZSAr IHNpemVvZiAobG9uZyk7DQogIAlpZiAoZGF0YW9mZiAmIDEpDQogIAkJZGF0 YW9mZisrOw0KISAJKHZvaWQpIGxzZWVrKHRpZi0+dGlmX2ZkLCBkYXRhb2Zm LCBMX1NFVCk7DQogIAl0aWYtPnRpZl9jdXJkaXIrKzsNCiAgCWRpciA9IChU SUZGRGlyRW50cnkgKilkYXRhOw0KICAJLyoNCi0tLSAxNzcsMTg0IC0tLS0N CiAgCWRhdGFvZmYgPSB0aWYtPnRpZl9kaXJvZmYgKyBzaXplb2YgKHNob3J0 KSArIGRpcnNpemUgKyBzaXplb2YgKGxvbmcpOw0KICAJaWYgKGRhdGFvZmYg JiAxKQ0KICAJCWRhdGFvZmYrKzsNCiEgCS8qIGFkZGVkIChvZmZfdCkgYmVs b3cuLi4uLmpqQGxkanBjLmFwYW5hLm9yZy5hdSovDQohIAkodm9pZCkgbHNl ZWsodGlmLT50aWZfZmQsIChvZmZfdCkoZGF0YW9mZiksIExfU0VUKTsNCiAg CXRpZi0+dGlmX2N1cmRpcisrOw0KICAJZGlyID0gKFRJRkZEaXJFbnRyeSAq KWRhdGE7DQogIAkvKg0KKioqKioqKioqKioqKioqDQoqKiogMzE0LDMyMCAq KioqDQogIAkvKg0KICAJICogV3JpdGUgZGlyZWN0b3J5Lg0KICAJICovDQoh IAkodm9pZCkgbHNlZWsodGlmLT50aWZfZmQsIHRpZi0+dGlmX2Rpcm9mZiwg TF9TRVQpOw0KICAJZGlyY291bnQgPSBuZmllbGRzOw0KICAJaWYgKCFXcml0 ZU9LKHRpZi0+dGlmX2ZkLCAmZGlyY291bnQsIHNpemVvZiAoc2hvcnQpKSkg ew0KICAJCVRJRkZFcnJvcih0aWYtPnRpZl9uYW1lLCAiRXJyb3Igd3JpdGlu ZyBkaXJlY3RvcnkgY291bnQiKTsNCi0tLSAzMTUsMzIyIC0tLS0NCiAgCS8q DQogIAkgKiBXcml0ZSBkaXJlY3RvcnkuDQogIAkgKi8NCiEgCS8qYWRkZWQg KG9mZl90KSBiZWxvdy4uLi4uampAbGRqcGMuYXBhbmEub3JnLmF1Ki8NCiEg CSh2b2lkKSBsc2Vlayh0aWYtPnRpZl9mZCwgKG9mZl90KSh0aWYtPnRpZl9k aXJvZmYpLCBMX1NFVCk7DQogIAlkaXJjb3VudCA9IG5maWVsZHM7DQogIAlp ZiAoIVdyaXRlT0sodGlmLT50aWZfZmQsICZkaXJjb3VudCwgc2l6ZW9mIChz aG9ydCkpKSB7DQogIAkJVElGRkVycm9yKHRpZi0+dGlmX25hbWUsICJFcnJv ciB3cml0aW5nIGRpcmVjdG9yeSBjb3VudCIpOw0KKioqKioqKioqKioqKioq DQoqKiogNzYyLDc3NCAqKioqDQogIAl1X3Nob3J0IGRpcmNvdW50Ow0KICAJ bG9uZyBuZXh0ZGlyOw0KICANCiEgCXRpZi0+dGlmX2Rpcm9mZiA9IChsc2Vl ayh0aWYtPnRpZl9mZCwgMEwsIExfWFRORCkrMSkgJn4gMUw7DQogIAlpZiAo dGlmLT50aWZfaGVhZGVyLnRpZmZfZGlyb2ZmID09IDApIHsNCiAgCQkvKg0K ICAJCSAqIEZpcnN0IGRpcmVjdG9yeSwgb3ZlcndyaXRlIGhlYWRlci4NCiAg CQkgKi8NCiAgCQl0aWYtPnRpZl9oZWFkZXIudGlmZl9kaXJvZmYgPSB0aWYt PnRpZl9kaXJvZmY7DQohIAkJKHZvaWQpIGxzZWVrKHRpZi0+dGlmX2ZkLCAw TCwgTF9TRVQpOw0KICAJCWlmICghV3JpdGVPSyh0aWYtPnRpZl9mZCwgJnRp Zi0+dGlmX2hlYWRlciwNCiAgCQkgICAgc2l6ZW9mICh0aWYtPnRpZl9oZWFk ZXIpKSkgew0KICAJCQlUSUZGRXJyb3IodGlmLT50aWZfbmFtZSwgIkVycm9y IHdyaXRpbmcgVElGRiBoZWFkZXIiKTsNCi0tLSA3NjQsNzc4IC0tLS0NCiAg CXVfc2hvcnQgZGlyY291bnQ7DQogIAlsb25nIG5leHRkaXI7DQogIA0KISAJ LyogY2hhbmdlZCAwTCB0byAob2ZmX3QpMCBiZWxvdy4uLmpqQGxkanBjLmFw YW5hLm9yZy5hdSovDQohIAl0aWYtPnRpZl9kaXJvZmYgPSAobHNlZWsodGlm LT50aWZfZmQsIChvZmZfdCkwLCBMX1hUTkQpKzEpICZ+IDFMOw0KICAJaWYg KHRpZi0+dGlmX2hlYWRlci50aWZmX2Rpcm9mZiA9PSAwKSB7DQogIAkJLyoN CiAgCQkgKiBGaXJzdCBkaXJlY3RvcnksIG92ZXJ3cml0ZSBoZWFkZXIuDQog IAkJICovDQogIAkJdGlmLT50aWZfaGVhZGVyLnRpZmZfZGlyb2ZmID0gdGlm LT50aWZfZGlyb2ZmOw0KISAJCS8qIGNoYW5nZWQgMEwgdG8gKG9mZl90KTAg Li4gampAbGRqcGMuYXBhbmEub3JnLmF1Ki8NCiEgCQkodm9pZCkgbHNlZWso dGlmLT50aWZfZmQsIChvZmZfdCkwLCBMX1NFVCk7DQogIAkJaWYgKCFXcml0 ZU9LKHRpZi0+dGlmX2ZkLCAmdGlmLT50aWZfaGVhZGVyLA0KICAJCSAgICBz aXplb2YgKHRpZi0+dGlmX2hlYWRlcikpKSB7DQogIAkJCVRJRkZFcnJvcih0 aWYtPnRpZl9uYW1lLCAiRXJyb3Igd3JpdGluZyBUSUZGIGhlYWRlciIpOw0K KioqKioqKioqKioqKioqDQoqKiogNzg4LDc5NCAqKioqDQogIAkJfQ0KICAJ CWlmICh0aWYtPnRpZl9mbGFncyAmIFRJRkZfU1dBQikNCiAgCQkJVElGRlN3 YWJTaG9ydCgmZGlyY291bnQpOw0KISAJCWxzZWVrKHRpZi0+dGlmX2ZkLCBk aXJjb3VudCAqIHNpemVvZiAoVElGRkRpckVudHJ5KSwgTF9JTkNSKTsNCiAg CQlpZiAoIVJlYWRPSyh0aWYtPnRpZl9mZCwgJm5leHRkaXIsIHNpemVvZiAo bmV4dGRpcikpKSB7DQogIAkJCVRJRkZFcnJvcihtb2R1bGUsICJFcnJvciBm ZXRjaGluZyBkaXJlY3RvcnkgbGluayIpOw0KICAJCQlyZXR1cm4gKDApOw0K LS0tIDc5Miw3OTkgLS0tLQ0KICAJCX0NCiAgCQlpZiAodGlmLT50aWZfZmxh Z3MgJiBUSUZGX1NXQUIpDQogIAkJCVRJRkZTd2FiU2hvcnQoJmRpcmNvdW50 KTsNCiEgCQkvKmFkZGVkIChvZmZfdCkgYmVsb3cuLi4uampAbGRqcGMuYXBh bmEub3JnLmF1Ki8NCiEgCQlsc2Vlayh0aWYtPnRpZl9mZCwgKG9mZl90KShk aXJjb3VudCAqIHNpemVvZiAoVElGRkRpckVudHJ5KSksIExfSU5DUik7DQog IAkJaWYgKCFSZWFkT0sodGlmLT50aWZfZmQsICZuZXh0ZGlyLCBzaXplb2Yg KG5leHRkaXIpKSkgew0KICAJCQlUSUZGRXJyb3IobW9kdWxlLCAiRXJyb3Ig ZmV0Y2hpbmcgZGlyZWN0b3J5IGxpbmsiKTsNCiAgCQkJcmV0dXJuICgwKTsN CioqKioqKioqKioqKioqKg0KKioqIDc5Niw4MDIgKioqKg0KICAJCWlmICh0 aWYtPnRpZl9mbGFncyAmIFRJRkZfU1dBQikNCiAgCQkJVElGRlN3YWJMb25n KCh1X2xvbmcgKikmbmV4dGRpcik7DQogIAl9IHdoaWxlIChuZXh0ZGlyICE9 IDApOw0KISAJKHZvaWQpIGxzZWVrKHRpZi0+dGlmX2ZkLCAtc2l6ZW9mIChu ZXh0ZGlyKSwgTF9JTkNSKTsNCiAgCWlmICghV3JpdGVPSyh0aWYtPnRpZl9m ZCwgJnRpZi0+dGlmX2Rpcm9mZiwgc2l6ZW9mICh0aWYtPnRpZl9kaXJvZmYp KSkgew0KICAJCVRJRkZFcnJvcihtb2R1bGUsICJFcnJvciB3cml0aW5nIGRp cmVjdG9yeSBsaW5rIik7DQogIAkJcmV0dXJuICgwKTsNCi0tLSA4MDEsODA4 IC0tLS0NCiAgCQlpZiAodGlmLT50aWZfZmxhZ3MgJiBUSUZGX1NXQUIpDQog IAkJCVRJRkZTd2FiTG9uZygodV9sb25nICopJm5leHRkaXIpOw0KICAJfSB3 aGlsZSAobmV4dGRpciAhPSAwKTsNCiEgCS8qYWRkZWQgKG9mZl90KSBiZWxv dyAuLi4gampAbGRqcGMuYXBhbmEub3JnLmF1Ki8NCiEgCSh2b2lkKSBsc2Vl ayh0aWYtPnRpZl9mZCwgKG9mZl90KSgtc2l6ZW9mIChuZXh0ZGlyKSksIExf SU5DUik7DQogIAlpZiAoIVdyaXRlT0sodGlmLT50aWZfZmQsICZ0aWYtPnRp Zl9kaXJvZmYsIHNpemVvZiAodGlmLT50aWZfZGlyb2ZmKSkpIHsNCiAgCQlU SUZGRXJyb3IobW9kdWxlLCAiRXJyb3Igd3JpdGluZyBkaXJlY3RvcnkgbGlu ayIpOw0KICAJCXJldHVybiAoMCk7DQpkaWZmIC1yYyAtLWV4Y2x1ZGU9TWFr ZWZpbGUgLS1leGNsdWRlPUZSRUVCU0Qgd29yay1vcmlnL2l2L3NyYy9saWIv VElGRi90aWZfd3JpdGUuYyB3b3JrL2l2L3NyYy9saWIvVElGRi90aWZfd3Jp dGUuYw0KKioqIHdvcmstb3JpZy9pdi9zcmMvbGliL1RJRkYvdGlmX3dyaXRl LmMJVHVlIEZlYiAxMSAxMzozNjo0NyAxOTkyDQotLS0gd29yay9pdi9zcmMv bGliL1RJRkYvdGlmX3dyaXRlLmMJU3VuIE1heSAyOCAxMjo1Nzo1NyAxOTk1 DQoqKioqKioqKioqKioqKioNCioqKiA1NTAsNTU2ICoqKioNCiAgCQkJfQ0K ICAJCX0gZWxzZQ0KICAJCQl0ZC0+dGRfc3RyaXBvZmZzZXRbc3RyaXBdID0N CiEgCQkJICAgIGxzZWVrKHRpZi0+dGlmX2ZkLCAwTCwgTF9YVE5EKTsNCiAg CQl0aWYtPnRpZl9jdXJvZmYgPSB0ZC0+dGRfc3RyaXBvZmZzZXRbc3RyaXBd Ow0KICAJfQ0KICAJaWYgKCFXcml0ZU9LKHRpZi0+dGlmX2ZkLCBkYXRhLCBj YykpIHsNCi0tLSA1NTAsNTU3IC0tLS0NCiAgCQkJfQ0KICAJCX0gZWxzZQ0K ICAJCQl0ZC0+dGRfc3RyaXBvZmZzZXRbc3RyaXBdID0NCiEgCQkJICAgIC8q Y2hhbmdlZCAwTCB0byAob2ZmX3QpMCAuLiBqakBsZGpwYy5hcGFuYS5vcmcu YXUqLw0KISAJCQkgICAgbHNlZWsodGlmLT50aWZfZmQsIChvZmZfdCkwLCBM X1hUTkQpOw0KICAJCXRpZi0+dGlmX2N1cm9mZiA9IHRkLT50ZF9zdHJpcG9m ZnNldFtzdHJpcF07DQogIAl9DQogIAlpZiAoIVdyaXRlT0sodGlmLT50aWZf ZmQsIGRhdGEsIGNjKSkgew0KZGlmZiAtcmMgLS1leGNsdWRlPU1ha2VmaWxl IC0tZXhjbHVkZT1GUkVFQlNEIHdvcmstb3JpZy9pdi9zcmMvbGliL1RJRkYv dGlmZmNvbXBhdC5oIHdvcmsvaXYvc3JjL2xpYi9USUZGL3RpZmZjb21wYXQu aA0KKioqIHdvcmstb3JpZy9pdi9zcmMvbGliL1RJRkYvdGlmZmNvbXBhdC5o CVR1ZSBNYXIgMzEgMTI6MDE6MDQgMTk5Mg0KLS0tIHdvcmsvaXYvc3JjL2xp Yi9USUZGL3RpZmZjb21wYXQuaAlTdW4gTWF5IDI4IDE0OjEzOjU5IDE5OTUN CioqKioqKioqKioqKioqKg0KKioqIDE1NCwxNjAgKioqKg0KICAjZGVmaW5l CWxzZWVrCW1wd19sc2Vlaw0KICBleHRlcm4gbG9uZyBtcHdfbHNlZWsoaW50 LCBsb25nLCBpbnQpOw0KICAjZWxzZQ0KISBleHRlcm4JbG9uZyBsc2Vlaygp Ow0KICAjZW5kaWYNCiAgDQogIC8qDQotLS0gMTU0LDE2MSAtLS0tDQogICNk ZWZpbmUJbHNlZWsJbXB3X2xzZWVrDQogIGV4dGVybiBsb25nIG1wd19sc2Vl ayhpbnQsIGxvbmcsIGludCk7DQogICNlbHNlDQohIC8qY2hhbmdlZCB0byB0 aGUgY29ycmVjdCBvbmUuLi5qakBsZGpwYy5hcGFuYS5vcmcuYXUqLw0KISBl eHRlcm4Jb2ZmX3QgbHNlZWsoKTsNCiAgI2VuZGlmDQogIA0KICAvKg0KKioq KioqKioqKioqKioqDQoqKiogMTYzLDE3MCAqKioqDQogICNpZm5kZWYgUmVh ZE9LDQogICNkZWZpbmUJUmVhZE9LKGZkLCBidWYsIHNpemUpCShyZWFkKGZk LCAoY2hhciAqKWJ1Ziwgc2l6ZSkgPT0gc2l6ZSkNCiAgI2VuZGlmDQogICNp Zm5kZWYgU2Vla09LDQohICNkZWZpbmUJU2Vla09LKGZkLCBvZmYpCShsc2Vl ayhmZCwgKGxvbmcpb2ZmLCBMX1NFVCkgPT0gKGxvbmcpb2ZmKQ0KICAjZW5k aWYNCiAgI2lmbmRlZiBXcml0ZU9LDQogICNkZWZpbmUJV3JpdGVPSyhmZCwg YnVmLCBzaXplKQkod3JpdGUoZmQsIChjaGFyICopYnVmLCBzaXplKSA9PSBz aXplKQ0KLS0tIDE2NCwxNzIgLS0tLQ0KICAjaWZuZGVmIFJlYWRPSw0KICAj ZGVmaW5lCVJlYWRPSyhmZCwgYnVmLCBzaXplKQkocmVhZChmZCwgKGNoYXIg KilidWYsIHNpemUpID09IHNpemUpDQogICNlbmRpZg0KKyAvKmNoYW5nZWQg KGxvbmcpIHRvIChvZmZfdCkgdG8gY29tcGlsZS4uLi5qakBsZGpwYy5hcGFu YS5vcmcuYXUqLw0KICAjaWZuZGVmIFNlZWtPSw0KISAjZGVmaW5lCVNlZWtP SyhmZCwgb2ZmKQkobHNlZWsoZmQsIChvZmZfdClvZmYsIExfU0VUKSA9PSAo b2ZmX3Qpb2ZmKQ0KICAjZW5kaWYNCiAgI2lmbmRlZiBXcml0ZU9LDQogICNk ZWZpbmUJV3JpdGVPSyhmZCwgYnVmLCBzaXplKQkod3JpdGUoZmQsIChjaGFy ICopYnVmLCBzaXplKSA9PSBzaXplKQ0KKioqKioqKioqKioqKioqDQoqKiog MjAyLDIxMSAqKioqDQogICAqLw0KICAjaWYgZGVmaW5lZChfX1NURENfXykg JiYgIWRlZmluZWQoVVNFX1ZBUkFSR1MpDQogICNkZWZpbmUJVVNFX1ZBUkFS R1MJMA0KICAjZW5kaWYNCiAgDQogICNpZiBkZWZpbmVkKFVTRV9WQVJBUkdT KQ0KISAjaWYgVVNFX1ZBUkFSR1MNCiAgI2luY2x1ZGUgPHZhcmFyZ3MuaD4N CiAgI2RlZmluZQlWQV9TVEFSVChhcCwgcGFybU4pCXZhX3N0YXJ0KGFwKQ0K ICAjZWxzZQ0KLS0tIDIwNCwyMTggLS0tLQ0KICAgKi8NCiAgI2lmIGRlZmlu ZWQoX19TVERDX18pICYmICFkZWZpbmVkKFVTRV9WQVJBUkdTKQ0KICAjZGVm aW5lCVVTRV9WQVJBUkdTCTANCisgI2Vsc2UgDQorICNpZiBkZWZpbmVkKF9f RnJlZUJTRF9fKQ0KKyAjdW5kZWYgVVNFX1ZBUkFSR1MNCisgI2RlZmluZSBV U0VfVkFSQVJHUyAgICAgMA0KKyAjZW5kaWYNCiAgI2VuZGlmDQogIA0KICAj aWYgZGVmaW5lZChVU0VfVkFSQVJHUykNCiEgI2lmIFVTRV9WQVJBUkdTICYm ICFkZWZpbmVkKF9fRnJlZUJTRF9fKQ0KICAjaW5jbHVkZSA8dmFyYXJncy5o Pg0KICAjZGVmaW5lCVZBX1NUQVJUKGFwLCBwYXJtTikJdmFfc3RhcnQoYXAp DQogICNlbHNlDQo= --0-1509080783-801876776=:9480-- From owner-freebsd-bugs Tue May 30 19:30:11 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id TAA20404 for bugs-outgoing; Tue, 30 May 1995 19:30:11 -0700 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id TAA20385 ; Tue, 30 May 1995 19:30:06 -0700 Date: Tue, 30 May 1995 19:30:06 -0700 Message-Id: <199505310230.TAA20385@freefall.cdrom.com> From: ywliu@psi.wsl.sinica.edu.tw Reply-To: ywliu@psi.wsl.sinica.edu.tw To: freebsd-bugs Subject: kern/462: uname() bug In-Reply-To: Your message of Wed, 31 May 1995 10:30:47 GMT <199505311030.KAA24252@psi.wsl.sinica.edu.tw> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 462 >Category: kern >Synopsis: struct utsname.version corrupted after calling uname() >Confidential: yes >Severity: non-critical >Priority: low >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue May 30 19:30:02 1995 >Originator: Yen-Wei Liu >Organization: >Release: FreeBSD 2.0.950412-SNAP i386 >Environment: Generic motherboard with Intel i486DX-33. SCSI 650MB HD. >Description: For a struct utsname, after calling uname(), uts.version seems to contain corrupted string. >How-To-Repeat: For the following period of code. struct utsname uts; uname(&uts); printf("on %s %s.%s",uts.sysname,uts.release, uts.version); Printf results : on FreeBSD 2.0.950412-SNAP.Ý¿ï`ðÍàÞ¿ï  the uts.version seems corrupted. >Fix: None. Is it my problem or uname's ? Since I didn't build world, just kernel and uname() were rebuilt... >Audit-Trail: >Unformatted: From owner-freebsd-bugs Tue May 30 21:01:39 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA06997 for bugs-outgoing; Tue, 30 May 1995 21:01:39 -0700 Received: from forgery.CS.Berkeley.EDU (forgery.CS.Berkeley.EDU [128.32.33.75]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id VAA06989 for ; Tue, 30 May 1995 21:01:38 -0700 Received: (from asami@localhost) by forgery.CS.Berkeley.EDU (8.6.11/8.6.9) id UAA02516; Tue, 30 May 1995 20:58:55 -0700 Date: Tue, 30 May 1995 20:58:55 -0700 Message-Id: <199505310358.UAA02516@forgery.CS.Berkeley.EDU> To: Lucas.James@ldjpc.apana.org.au CC: Lucas.James@ldjpc.apana.org.au, chuckr@Glue.umd.edu, krebs@faps.uni-erlangen.de, freebsd-bugs@FreeBSD.org In-reply-to: (message from Lucas James on Wed, 31 May 1995 09:02:56 +0930 (CST)) Subject: Re: GCC 2.6.2 / InterViews won't compile From: asami@CS.Berkeley.EDU (Satoshi Asami | =?ISO-2022-JP?B?GyRCQHUbKEI=?= =?ISO-2022-JP?B?GyRCOCsbKEIgGyRCOC0bKEI=?=) Sender: bugs-owner@FreeBSD.org Precedence: bulk * It should be mime-attached to this message tho. (fingers crossed) * It is a patch that takes the tree that was extracted and patched (ie the one * in port/x11/iv/work) and brings it to a state where it can compile and run. Thanks...now trying.... * Unless someone mails me Thomas' patch, I can't test it (on the end * of a very slow link. :( I'll send it to you.... Satoshi From owner-freebsd-bugs Tue May 30 21:20:02 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA08243 for bugs-outgoing; Tue, 30 May 1995 21:20:02 -0700 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA08236 ; Tue, 30 May 1995 21:20:01 -0700 Date: Tue, 30 May 1995 21:20:01 -0700 Message-Id: <199505310420.VAA08236@freefall.cdrom.com> From: seki@sysrap.cs.fujitsu.co.jp Reply-To: seki@sysrap.cs.fujitsu.co.jp To: freebsd-bugs Subject: i386/463: Exitting sysinstall w/o installation In-Reply-To: Your message of Wed, 31 May 1995 13:16:16 +0900 <199505310416.NAA00344@hawk.sysrap.cs.fujitsu.co.jp> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 463 >Category: i386 >Synopsis: sysinstall just stops after exitting w/o installation >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue May 30 21:20:01 1995 >Originator: Masahiro Sekiguchi >Organization: Fujitsu Limited >Release: FreeBSD 2.0.5-ALPHA i386 >Environment: i486DX2/66, ISA, 16MB AHA-1542C, M2694ESA, no IDE drive >Description: I grabbed boot.flp from FreeBSD 2.0.5-ALPHA, put it on a 3.5" floppy, and booted the machine with it. The system booted fine, and sysinstall started properly. When I selected CANCEL button to exit sysinstall without installing the system, the screen told me the system will be rebooted, but it stopped just silently. No reboot happened. I waited two or three minutes before pressing a reset switch. I did the same thing two more times, and it behaved just the same. >How-To-Repeat: Boot with the boot floppy, then select CANCEL button. >Fix: Not known. >Audit-Trail: >Unformatted: From owner-freebsd-bugs Tue May 30 22:12:33 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA14651 for bugs-outgoing; Tue, 30 May 1995 22:12:33 -0700 Received: from relay3.UU.NET (relay3.UU.NET [192.48.96.8]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id WAA14616 for ; Tue, 30 May 1995 22:12:22 -0700 Received: from ast.com by relay3.UU.NET with SMTP id QQysbc08009; Wed, 31 May 1995 01:12:15 -0400 Received: from trsvax.fw.ast.com (fw.ast.com) by ast.com with SMTP id AA12092 (5.67b/IDA-1.5 for uunet!freebsd.org!bugs); Tue, 30 May 1995 22:12:34 -0700 Received: by trsvax.fw.ast.com (/\=-/\ Smail3.1.18.1 #18.1) id ; Wed, 31 May 95 00:10 CDT Received: by nemesis.lonestar.org (Smail3.1.27.1 #18) id m0sGfzV-0004wAC; Wed, 31 May 95 00:06 CDT Message-Id: Date: Wed, 31 May 95 00:06 CDT To: bugs@FreeBSD.org From: uhclem@nemesis.lonestar.org (Frank Durda IV) Sent: Wed May 31 1995, 00:06:49 CDT Subject: Problems with 2.0.5-Alpha Sender: bugs-owner@FreeBSD.org Precedence: bulk I have two existing systems that were running SNAP-0412 without incident that I have tried to install 2.0.5-Alpha on. This has been a failure. The system is a DEC 1027, also known as a GRid 433, also known as a Tandy 4833, also, well you get the idea. These are 486DX-33 systems, with external cache modules, 8Meg RAM, a single 540 IDE drive. No SCSI, CD-ROMs removed, WD8013 network card (0x2, 0x280, 0xd400), standard COM1, COM2, LPT1 and nothing else. OAK or WDC VGA adapters, depending on the machine. With 8Meg present (what they have had for months), I note on the F2 screen that dozens of processes are aborting with: Process 402 Killed by vm_pageout -- out of swap The installation appears to be working although many help files appear missing. I expected some to be missing, but not all - the true error may be a killed process rather than a missing file. Anyway, the installation gets to "Making device files" and just sits there forever. I suspect it didn't actually make file systems as that step reportedly took about one second. I halted the system and added memory from an identical system, bringing it up to 12 Meg thinking the additional RAM might avoid the swap altogether. But now the system starts up: Booting the kernelel...done (yes, it is displayed that way) BIOS basemem (639K) != RTC basemem (640K) and it just hangs at this point. So I tried 4Meg, as the system is supposed to work with just 4Meg. The system also hangs after the BIOS BASEMEM message. So I returned to 8Meg memory size and it boots but by monitoring screen 2 it is obvious it is killing processes left and right, starting with process 6. Then I switched to 16Meg. It also hangs. But if I move the same plug-in memory board loaded with the 16Meg on it to the second machine that system gets a trap when booting 2.0.5-Alpha: Booting the kernel BIOS basemem (639K) != RTC basemem (640K) Fatal trap 12: page fault while in kernel mode fault virtual address = 0x1c fault code = supervisor read, page not present instruction pointer = 0x8:0xf0186235 code segment = base 0x0, limit 0xfffff, type 0x1b, gran 1 processor eflags = resume, IOPL=0 current process = 0 () interrupt mask = net tty bio panic: page fault hit reset please This is 100% reproducible on one system and doesn't seem to happen on the other. The only difference was that the machine that paniced had video shadowing disabled in the BIOS. Again, both these systems ran 1.1.5.1, and every the SNAPs since February and have been used for numerous "make worlds" without incident. The system with the panic hasn't had its hard disk wiped yet, so after the panic, I simply let the system boot the last snap from hard disk and it ran fine with no hardware changes at all with the 16Meg present. So with 2.0.5-Alpha, neither system runs at all unless exactly 8Meg is present and it gets out of swap errors with 8Meg present. Constructive suggestions are welcome and I'll be happy to try any experiments to resolve this. Fastest address is uhclem%nemesis@fw.ast.com 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 Tue May 30 22:18:56 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA15909 for bugs-outgoing; Tue, 30 May 1995 22:18:56 -0700 Received: (from jkh@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA15890 ; Tue, 30 May 1995 22:18:54 -0700 Date: Tue, 30 May 1995 22:18:54 -0700 From: "Jordan K. Hubbard" Message-Id: <199505310518.WAA15890@freefall.cdrom.com> To: seki@sysrap.cs.fujitsu.co.jp, jkh, freebsd-bugs Subject: Changed information for PR i386/463 Sender: bugs-owner@FreeBSD.org Precedence: bulk Synopsis: sysinstall just stops after exitting w/o installation State-Changed-From-To: open-closed State-Changed-By: jkh State-Changed-When: Tue May 30 22:18:10 PDT 1995 State-Changed-Why: This bug is both known and documented in the README.FIRST file accompanying the 2.0.5A distribution. What's more, it should be fixed in the latest internal build! From owner-freebsd-bugs Tue May 30 22:19:05 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA15933 for bugs-outgoing; Tue, 30 May 1995 22:19:05 -0700 Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id WAA15926 ; Tue, 30 May 1995 22:19:03 -0700 X-Authentication-Warning: freefall.cdrom.com: Host localhost.cdrom.com didn't use HELO protocol To: seki@sysrap.cs.fujitsu.co.jp cc: freebsd-bugs@freefall.cdrom.com Subject: Re: i386/463: Exitting sysinstall w/o installation In-reply-to: Your message of "Tue, 30 May 95 21:20:01 PDT." <199505310420.VAA08236@freefall.cdrom.com> Date: Tue, 30 May 1995 22:19:03 -0700 Message-ID: <15925.801897543@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: bugs-owner@FreeBSD.org Precedence: bulk > When I selected CANCEL button to exit sysinstall without installing > the system, the screen told me the system will be rebooted, but > it stopped just silently. No reboot happened. I waited two or > three minutes before pressing a reset switch. You need to read the README.FIRST file - this is documented! :-) I'm closing the PR, since I already have this open on my own internal bugs list. Jordan From owner-freebsd-bugs Tue May 30 23:14:11 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id XAA20129 for bugs-outgoing; Tue, 30 May 1995 23:14:11 -0700 Received: from lirmm.lirmm.fr (lirmm.lirmm.fr [193.49.104.10]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id XAA20123 for ; Tue, 30 May 1995 23:14:09 -0700 Received: from lirmm.fr (baobab.lirmm.fr [193.49.106.14]) by lirmm.lirmm.fr (8.6.10/8.6.4) with ESMTP id IAA29278; Wed, 31 May 1995 08:13:51 +0200 Message-Id: <199505310613.IAA29278@lirmm.lirmm.fr> To: seki@sysrap.cs.fujitsu.co.jp cc: freebsd-bugs@freefall.cdrom.com Subject: Re: i386/463: Exitting sysinstall w/o installation In-reply-to: Your message of "Tue, 30 May 1995 21:20:01 PDT." <199505310420.VAA08236@freefall.cdrom.com> Date: Wed, 31 May 1995 08:13:49 +0200 From: "Philippe Charnier" Sender: bugs-owner@FreeBSD.org Precedence: bulk Salut, In the message i386/463: Exitting sysinstall w/o installation, seki@sysrap.cs.fujitsu.co.jp wrote : > >>Number: 463 >>Category: i386 >>Synopsis: sysinstall just stops after exitting w/o installation >>Release: FreeBSD 2.0.5-ALPHA i386 >>Description: > When I selected CANCEL button to exit sysinstall without installing > the system, the screen told me the system will be rebooted, but > it stopped just silently. No reboot happened. I waited two or > three minutes before pressing a reset switch. > > I did the same thing two more times, and it behaved just the same. > It worked for me after pushing the key, multiple times (one will maybe suffice). -------- -------- Philippe Charnier charnier@lirmm.fr LIRMM, 161 rue Ada, 34392 Montpellier cedex 5 -- France ------------------------------------------------------------------------ From owner-freebsd-bugs Tue May 30 23:34:45 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id XAA20817 for bugs-outgoing; Tue, 30 May 1995 23:34:45 -0700 Received: from ame2.math.arizona.edu (ame2.math.arizona.edu [128.196.224.60]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id XAA20811 for ; Tue, 30 May 1995 23:34:44 -0700 Received: (from jlackey@localhost) by ame2.math.arizona.edu (8.6.10/8.6.10) id XAA16170 for bugs@freebsd.org; Tue, 30 May 1995 23:34:22 -0700 From: Joshua Lackey Message-Id: <199505310634.XAA16170@ame2.math.arizona.edu> Subject: FreeBSD 2.0.5a To: bugs@FreeBSD.org Date: Tue, 30 May 1995 23:34:22 -0700 (MST) X-Mailer: ELM [version 2.4 PL13] Content-Type: text Content-Length: 563 Sender: bugs-owner@FreeBSD.org Precedence: bulk Hope this is the right address to send this to. I just decided to upgrade to 2.0.5a and I couldn't wait the week or so for 2.0.5. The main bug I have noticed is that the whole install process stops at: DEBUG: Generating /etc/fstab file There are some other little bugs in the instalation, I'm trying to write them all down as I find them. I would really like to finish the instalation first though. If you need any more information, like what I have on my system and what instalation options I used, just ask! Thanks! Josh. -- jlackey@math.arizona.edu From owner-freebsd-bugs Wed May 31 00:00:26 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA19212 for bugs-outgoing; Tue, 30 May 1995 22:51:30 -0700 Received: from forgery.CS.Berkeley.EDU (forgery.CS.Berkeley.EDU [128.32.33.75]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id WAA19206 ; Tue, 30 May 1995 22:51:29 -0700 Received: (from asami@localhost) by forgery.CS.Berkeley.EDU (8.6.11/8.6.9) id WAA02624; Tue, 30 May 1995 22:49:30 -0700 Date: Tue, 30 May 1995 22:49:30 -0700 Message-Id: <199505310549.WAA02624@forgery.CS.Berkeley.EDU> To: Lucas.James@ldjpc.apana.org.au CC: chuckr@Glue.umd.edu, krebs@faps.uni-erlangen.de, freebsd-bugs@freebsd.org, ports@freebsd.org In-reply-to: <199505310358.UAA02516@forgery.CS.Berkeley.EDU> (asami@cs.berkeley.edu) Subject: Re: GCC 2.6.2 / InterViews won't compile From: asami@cs.berkeley.edu (Satoshi Asami | =?ISO-2022-JP?B?GyRCQHUbKEI=?= =?ISO-2022-JP?B?GyRCOCsbKEIgGyRCOC0bKEI=?=) Sender: bugs-owner@freebsd.org Precedence: bulk (Intentionally crossposted to "bugs" and "ports", if you are going to follow up please send it to ports only. --S) Ok, I used Lucas' patch and InterViews now compiles and installs fine. I'll commit the change shortly. Thanks for your help guys! Satoshi From owner-freebsd-bugs Wed May 31 00:20:02 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA22299 for bugs-outgoing; Wed, 31 May 1995 00:20:02 -0700 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA22292 ; Wed, 31 May 1995 00:20:01 -0700 Date: Wed, 31 May 1995 00:20:01 -0700 Message-Id: <199505310720.AAA22292@freefall.cdrom.com> From: "Jordan K. Hubbard" Reply-To: "Jordan K. Hubbard" To: freebsd-bugs Subject: bin/464: dialog_gauge goes one char too far for 100% value In-Reply-To: Your message of Wed, 31 May 1995 00:15:39 -0700 <199505310715.AAA22133@freefall.cdrom.com> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 464 >Category: bin >Synopsis: dialog_gauge goes one char too far for 100% value >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed May 31 00:20:00 1995 >Originator: Jordan K. Hubbard >Organization: Walnut Creek CDROM >Release: FreeBSD 2.1.0-Development i386 >Environment: 2.0.5-ALPHA >Description: Set a dialog_gauge() to 100% - it overflows past the right edge and into the border area. >How-To-Repeat: See above. >Fix: >Audit-Trail: >Unformatted: From owner-freebsd-bugs Wed May 31 00:51:08 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA27705 for bugs-outgoing; Wed, 31 May 1995 00:51:08 -0700 Received: from relay.philips.nl (relay.philips.nl [130.144.65.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id AAA27678 for ; Wed, 31 May 1995 00:51:01 -0700 Received: from cnps.lss.cp.philips.com ([130.144.198.1]) by relay.philips.nl (8.6.9/8.6.9-950414) with SMTP id JAA20662 for ; Wed, 31 May 1995 09:50:21 +0200 Received: from spooky.lss.cp.philips.com by cnps.lss.cp.philips.com with smtp (Smail3.1.28.1 #1) id m0sGjfv-0000iuC; Wed, 31 May 95 10:02 MET Received: by spooky.lss.cp.philips.com (Smail3.1.28.1 #1) id m0sGiVq-00010GC; Wed, 31 May 95 09:48 MET DST Message-Id: From: guido@spooky.lss.cp.philips.com (Guido van Rooij) Subject: 2.0.5 completely hangs at boot To: freebsd-bugs@FreeBSD.org Date: Wed, 31 May 1995 09:48:22 +0200 (MET DST) Reply-To: Guido.vanRooij@nl.cis.philips.com (Guido van Rooij) X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 495 Sender: bugs-owner@FreeBSD.org Precedence: bulk I wanted to try 2.0.5 on a Digital XL590 pentium PC. So I rawrited the boot.flp on a floppy and booted form it. The probing worked fine. At the point where the kernel announces a 1075K big root in MFS everything hangs. (ctrtl-alt-del is non functional as are the *lock keys). I tried it on another PC (another digital, now a 433sx) and it had exactly the same symptoms. The only `strange' hardware they have are an ep0 in UTP mode on irq10. I'll try and boot without the network card. -Guido From owner-freebsd-bugs Wed May 31 01:08:06 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id BAA01648 for bugs-outgoing; Wed, 31 May 1995 01:08:06 -0700 Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id BAA01630 ; Wed, 31 May 1995 01:08:01 -0700 X-Authentication-Warning: freefall.cdrom.com: Host localhost.cdrom.com didn't use HELO protocol To: Joshua Lackey cc: bugs@FreeBSD.org Subject: Re: FreeBSD 2.0.5a In-reply-to: Your message of "Tue, 30 May 95 23:34:22 PDT." <199505310634.XAA16170@ame2.math.arizona.edu> Date: Wed, 31 May 1995 01:07:59 -0700 Message-ID: <1625.801907679@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: bugs-owner@FreeBSD.org Precedence: bulk This may be a bug I just fixed - do you have a DOS partition you didn't assign a mountpoint to? If so, assign it a mountpoint and things should go smoother. Jordan > Hope this is the right address to send this to. > > I just decided to upgrade to 2.0.5a and I couldn't wait the week or so > for 2.0.5. > > The main bug I have noticed is that the whole install process stops at: > > DEBUG: Generating /etc/fstab file > > > There are some other little bugs in the instalation, I'm trying to write > them all down as I find them. > > I would really like to finish the instalation first though. If you need > any more information, like what I have on my system and what instalation > options I used, just ask! > > Thanks! > > Josh. > > -- > jlackey@math.arizona.edu From owner-freebsd-bugs Wed May 31 01:58:06 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id BAA06618 for bugs-outgoing; Wed, 31 May 1995 01:58:06 -0700 Received: from relay.philips.nl (relay.philips.nl [130.144.65.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id BAA06609 for ; Wed, 31 May 1995 01:58:03 -0700 Received: from cnps.lss.cp.philips.com ([130.144.198.1]) by relay.philips.nl (8.6.9/8.6.9-950414) with SMTP id KAA24571; Wed, 31 May 1995 10:57:28 +0200 Received: from spooky.lss.cp.philips.com by cnps.lss.cp.philips.com with smtp (Smail3.1.28.1 #1) id m0sGkir-0000iuC; Wed, 31 May 95 11:09 MET Received: by spooky.lss.cp.philips.com (Smail3.1.28.1 #1) id m0sGjYl-00010UC; Wed, 31 May 95 10:55 MET DST Message-Id: From: guido@spooky.lss.cp.philips.com (Guido van Rooij) Subject: Re: 2.0.5 completely hangs at boot To: Guido.vanRooij@nl.cis.philips.com Date: Wed, 31 May 1995 10:55:27 +0200 (MET DST) Cc: freebsd-bugs@FreeBSD.org In-Reply-To: from "Guido van Rooij" at May 31, 95 09:48:22 am Reply-To: Guido.vanRooij@nl.cis.philips.com (Guido van Rooij) X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 660 Sender: bugs-owner@FreeBSD.org Precedence: bulk Guido van Rooij wrote: > > I wanted to try 2.0.5 on a Digital XL590 pentium PC. > So I rawrited the boot.flp on a floppy and booted form it. The probing > worked fine. At the point where the kernel announces a 1075K big > root in MFS everything hangs. (ctrtl-alt-del is non functional as > are the *lock keys). > > I tried it on another PC (another digital, now a 433sx) and it had exactly > the same symptoms. The only `strange' hardware they have are an ep0 in UTP > mode on irq10. I'll try and boot without the network card. > I just removed the card and then it worked...(on the 486 33 MHz) The network card is: 3com EtherlinkIII (3c509b-c). -Guido From owner-freebsd-bugs Wed May 31 02:25:44 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id CAA09522 for bugs-outgoing; Wed, 31 May 1995 02:25:44 -0700 Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id CAA09503 ; Wed, 31 May 1995 02:25:38 -0700 Message-Id: <199505310925.CAA09503@freefall.cdrom.com> X-Authentication-Warning: freefall.cdrom.com: Host localhost.cdrom.com didn't use HELO protocol To: Guido.vanRooij@nl.cis.philips.com (Guido van Rooij) cc: freebsd-bugs@FreeBSD.org Subject: Re: 2.0.5 completely hangs at boot In-reply-to: Your message of "Wed, 31 May 95 10:55:27 +0200." Date: Wed, 31 May 1995 02:25:36 -0700 From: "Justin T. Gibbs" Sender: bugs-owner@FreeBSD.org Precedence: bulk >Guido van Rooij wrote: >> >> I wanted to try 2.0.5 on a Digital XL590 pentium PC. >> So I rawrited the boot.flp on a floppy and booted form it. The probing >> worked fine. At the point where the kernel announces a 1075K big >> root in MFS everything hangs. (ctrtl-alt-del is non functional as >> are the *lock keys). >> >> I tried it on another PC (another digital, now a 433sx) and it had exactly >> the same symptoms. The only `strange' hardware they have are an ep0 in UTP >> mode on irq10. I'll try and boot without the network card. >> > >I just removed the card and then it worked...(on the 486 33 MHz) >The network card is: >3com EtherlinkIII (3c509b-c). > > >-Guido Disable mcd0, mcd1, wt0, and ie0 via the "kernel -c" userconfig menu. -- Justin T. Gibbs ============================================== TCS Instructional Group - Programmer/Analyst 1 Cory | Po | Danube | Volga | Parker | Torus ============================================== From owner-freebsd-bugs Wed May 31 03:27:24 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id DAA15617 for bugs-outgoing; Wed, 31 May 1995 03:27:24 -0700 Received: from relay.philips.nl (relay.philips.nl [130.144.65.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id DAA15601 ; Wed, 31 May 1995 03:27:21 -0700 Received: from cnps.lss.cp.philips.com ([130.144.198.1]) by relay.philips.nl (8.6.9/8.6.9-950414) with SMTP id MAA29621; Wed, 31 May 1995 12:26:47 +0200 Received: from spooky.lss.cp.philips.com by cnps.lss.cp.philips.com with smtp (Smail3.1.28.1 #1) id m0sGm7J-0000PjC; Wed, 31 May 95 12:39 MET Received: by spooky.lss.cp.philips.com (Smail3.1.28.1 #1) id m0sGkxC-00010HC; Wed, 31 May 95 12:24 MET DST Message-Id: From: guido@spooky.lss.cp.philips.com (Guido van Rooij) Subject: Re: 2.0.5 completely hangs at boot To: gibbs@freefall.cdrom.com (Justin T. Gibbs) Date: Wed, 31 May 1995 12:24:45 +0200 (MET DST) Cc: Guido.vanRooij@nl.cis.philips.com, freebsd-bugs@FreeBSD.org In-Reply-To: <199505310925.CAA09503@freefall.cdrom.com> from "Justin T. Gibbs" at May 31, 95 02:25:36 am Reply-To: Guido.vanRooij@nl.cis.philips.com (Guido van Rooij) X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 105 Sender: bugs-owner@FreeBSD.org Precedence: bulk > > Disable mcd0, mcd1, wt0, and ie0 via the "kernel -c" userconfig menu. Thanks, that did it. -Guido From owner-freebsd-bugs Wed May 31 04:13:05 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id EAA20782 for bugs-outgoing; Wed, 31 May 1995 04:13:05 -0700 Received: from gw.itfs.nsk.su (gw.itfs.nsk.su [193.124.36.33]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id EAA20753 for ; Wed, 31 May 1995 04:12:43 -0700 Received: (nnd@localhost) by gw.itfs.nsk.su (8.6.12/8.6.12) id SAA23714 for bugs@freebsd.org; Wed, 31 May 1995 18:12:13 +0700 Date: Wed, 31 May 1995 18:12:13 +0700 From: "Nickolay N. Dudorov" Message-Id: <199505311112.SAA23714@gw.itfs.nsk.su> To: bugs@FreeBSD.org Subject: Re: 2.0.5 completely hangs at boot Sender: bugs-owner@FreeBSD.org Precedence: bulk >From: guido@spooky.lss.cp.philips.com (Guido van Rooij) > >I wanted to try 2.0.5 on a Digital XL590 pentium PC. >So I rawrited the boot.flp on a floppy and booted form it. The probing >worked fine. At the point where the kernel announces a 1075K big >root in MFS everything hangs. (ctrtl-alt-del is non functional as >are the *lock keys). > >I tried it on another PC (another digital, now a 433sx) and it had exactly >the same symptoms. The only `strange' hardware they have are an ep0 in UTP ^^^^^^^^^ >mode on irq10. I'll try and boot without the network card. > >-Guido I've already write about this problem - there is a conflict between 'ep' and 'ie' drivers. You must boot with '-c' and disable ie0. N.Dudorov From owner-freebsd-bugs Wed May 31 08:51:53 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA17939 for bugs-outgoing; Wed, 31 May 1995 08:51:53 -0700 Received: from gw.itfs.nsk.su (gw.itfs.nsk.su [193.124.36.33]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id IAA17914 for ; Wed, 31 May 1995 08:50:59 -0700 Received: (nnd@localhost) by gw.itfs.nsk.su (8.6.12/8.6.12) id WAA24944 for bugs@freebsd.org; Wed, 31 May 1995 22:47:48 +0700 Date: Wed, 31 May 1995 22:47:48 +0700 From: "Nickolay N. Dudorov" Message-Id: <199505311547.WAA24944@gw.itfs.nsk.su> To: bugs@FreeBSD.org Subject: ep and ie drivers conflict Sender: bugs-owner@FreeBSD.org Precedence: bulk After applying the next patch to if_ep.c I now can boot GENERIC kernel on my computer with 3C509 without disabling 'ie0' (and without hung :-). I have no 3C507 to test this hack on, but comment in elink.c about elink_reset() gives some kind of 'correctness proof' ;-) (This is a HACK, because it requires elink.o for 'ep' driver and I dont know exactly how to write this down - but it seems to solve the conflict AND I think that 'ep' and 'ie' drivers MUST use some common parts (and this was the role of elink.c)) N.Dudorov =============================================================== --- if_ep.c.orig Wed May 31 21:42:17 1995 +++ if_ep.c Wed May 31 21:43:43 1995 @@ -209,7 +209,11 @@ ep_current_tag--; /* Look for the ISA boards. Init and leave them actived */ +#if 0 outb(id_port, 0xc0); /* Global reset */ +#else + elink_reset(); +#endif DELAY(10000); for (i = 0; i < EP_MAX_BOARDS; i++) { outb(id_port, 0); From owner-freebsd-bugs Wed May 31 10:22:13 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA00794 for bugs-outgoing; Wed, 31 May 1995 10:22:13 -0700 Received: from ame2.math.arizona.edu (ame2.math.arizona.edu [128.196.224.60]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id KAA00788 ; Wed, 31 May 1995 10:22:11 -0700 Received: (from jlackey@localhost) by ame2.math.arizona.edu (8.6.10/8.6.10) id KAA12865; Wed, 31 May 1995 10:22:10 -0700 From: Joshua Lackey Message-Id: <199505311722.KAA12865@ame2.math.arizona.edu> Subject: Re: FreeBSD 2.0.5a To: jkh@freefall.cdrom.com (Jordan K. Hubbard) Date: Wed, 31 May 1995 10:22:09 -0700 (MST) Cc: bugs@FreeBSD.org In-Reply-To: <1625.801907679@freefall.cdrom.com> from "Jordan K. Hubbard" at May 31, 95 01:07:59 am X-Mailer: ELM [version 2.4 PL13] Content-Type: text Content-Length: 2234 Sender: bugs-owner@FreeBSD.org Precedence: bulk Another few bugs. 0. It seems there are some inconcistencies in the menu program. (Which, by the way, I like very much.) Sometimes esc gets you out of the menu you are in, and sometimes it gives you a shell. Sometimes space bar gets you out of the menu you are in, etc. It would also be nice to have the program remember the options I selected, I mean if I go back into the custom system menu (where you decide what you want to include beyond just the binaries and the man pages) I have to re-select everything each time I go there. Well, you get my drift. These are not bugs really, you probably shouldn't worry about them until 2.1. 1. If I don't newfs my filesystems (at least /) I get a error that my root filesystem is not writable. 2. No matter what instalation option I choose, mounted filesystem, dos partition, floppy disk, etc., I don't get prompted to put in the root.flp disk. (It has prompted me before, but now it has totally stopped. I found that if I swap the boot and the root at just the right time I can get it past that problem.) 3. The msdos directory has uid 4022324436 and gid 153986. 4. When trying to install by floppies, it asks you to "put the media into floppy drive unit A and press return." When I do this, it dosen't even check drive A but it gives me, "Error mounting floppy rfd0 (/dev/rfd0) on /mnt." It goes through that twice, and then tells me installation was successful. :) I think this problem has something to do with the way you mount the filesystems. In the shell on screen 4, mount gives me: mfs_root on / (local) /dev/wd0a on /mnt (local) /mnt/dev/wd0s1 on /mnt/msdos (local) /mnt/dev/wd0s4e on /mnt/usr (local) /mnt/dev/wd1s1e on /mnt/usr/X386 (local) /mnt/dev/wd1s1f on /mnt/home (local) Perhaps if you mount the floppy on /mnt/mnt? Anyway, this is the farthest I could get this morning. Hope to hear some suggestions from you soon! (And I hope these bug reports help! I have been running FreeBSD ever since it came out -- heck, I was running 386bsd just after they fixed that little core dump all over the hardrive bug. In any case, keep up the great work! (Where the hell do you find the time to do this???)) Thanks, Josh. -- jlackey@math.arizona.edu From owner-freebsd-bugs Wed May 31 11:18:20 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA04141 for bugs-outgoing; Wed, 31 May 1995 11:18:20 -0700 Received: from ofelia (lsi.poli.usp.br [143.107.103.5]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id LAA04092 for ; Wed, 31 May 1995 11:18:03 -0700 Received: from jaguar.lsi.usp.br (jaguar.lsi.usp.br [143.107.3.253]) by ofelia (8.6.12/8.6.9) with ESMTP id OAA20024 for ; Wed, 31 May 1995 14:55:59 -0300 Received: (from mario@localhost) by jaguar.lsi.usp.br (8.6.12/8.6.9) id SAA01170 for bugs@freebsd.org; Wed, 31 May 1995 18:04:25 GMT Date: Wed, 31 May 1995 18:04:25 GMT From: Mario Donato Marino Message-Id: <199505311804.SAA01170@jaguar.lsi.usp.br> Apparently-To: bugs@FreeBSD.org Sender: bugs-owner@FreeBSD.org Precedence: bulk Is there some version of FreeBSD that supports big IDE disks (1 GB) ? Thanks, Mario From owner-freebsd-bugs Wed May 31 15:26:28 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id PAA06118 for bugs-outgoing; Wed, 31 May 1995 15:26:28 -0700 Received: from ame2.math.arizona.edu (ame2.math.arizona.edu [128.196.224.60]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id PAA06111 for ; Wed, 31 May 1995 15:26:25 -0700 Received: (from jlackey@localhost) by ame2.math.arizona.edu (8.6.10/8.6.10) id PAA27016 for bugs@freebsd.org; Wed, 31 May 1995 15:26:24 -0700 From: Joshua Lackey Message-Id: <199505312226.PAA27016@ame2.math.arizona.edu> Subject: FreeBSD 2.0.5a To: bugs@FreeBSD.org Date: Wed, 31 May 1995 15:26:24 -0700 (MST) X-Mailer: ELM [version 2.4 PL13] Content-Type: text Content-Length: 2450 Sender: bugs-owner@FreeBSD.org Precedence: bulk I just finished, I think, installing 2.0.5a -- looks great! Here are some bugs I have come across, this is not an exhaustive list but it is all I thought to write down. Installing from a dos partition does not work. It has something to do with your mount command. Installing from a floppy does not work, again something to do with the mount command. I eventually installed from a dos partition -- but I told the install program that it was just a regular filesystem. (Since I have my dos partition mounted anyway.) Your script also tries to mount the dos partition as /dos, this could cause some problems if I already had something named /dos there. I also had to reboot and put all the bin.* files in a directory named bin, the compat* files in a directory named compat1x, and compat20, etc. I was just thinking you could make that part a little smarter, you could first look in the directory bin/ for the bin.* files and if you don't find them there look in the current directory. During installation, the error handling is messed up. (Real messed up. Sorry I can't be more exact. It randomly tells you that it can't extract something, and then it does. It tells you it wasn't able to extract the whole set, and then it says that installation is completed...) At the end of gunzip'ing the bin.* files, it gives a: gunzip: stdin: invalid compressed data -- crc error. Still, it seems to work, at least I haven't found anything missing yet. :) It extracted everything I told it to, but I still get a "not everything requested extracted" error. (Or something to that effect.) And then it says it completed satisfactorily. (Again your error handling.) During the post-installation configuration there are also some minor (?) bugs. When you add a user, the user's password shows as you type it in. (While root's password does not.) I gave routed some flags but they didn't get added to the correct file in /etc. I can't even telnet localhost but that might be my fault... Well, reading this over I see I am kinda rambling -- I hope you can extract some useful information from this piece of mail. In any case I am very impressed with the whole distribution and I really like the installation interface!!! You should make a version of it available on the system so that we could use it to reconfigure the network, add users, install and configure X, etc. Keep up the great work! Thanks, Josh. -- jlackey@math.arizona.edu From owner-freebsd-bugs Wed May 31 16:33:27 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id QAA10696 for bugs-outgoing; Wed, 31 May 1995 16:33:27 -0700 Received: from jolt.eng.umd.edu (jolt.eng.umd.edu [129.2.102.5]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id QAA10690 for ; Wed, 31 May 1995 16:33:25 -0700 Received: from latte.eng.umd.edu (latte.eng.umd.edu [129.2.98.15]) by jolt.eng.umd.edu (8.6.10/8.6.4) with ESMTP id TAA07449; Wed, 31 May 1995 19:27:56 -0400 Received: (chuckr@localhost) by latte.eng.umd.edu (8.6.10/8.6.4) id TAA08175; Wed, 31 May 1995 19:27:52 -0400 Date: Wed, 31 May 1995 19:27:52 -0400 (EDT) From: Chuck Robey To: Satoshi Asami | =?ISO-2022-JP?B?GyRCQHUbKEI=?= =?ISO-2022-JP?B?GyRCOCsbKEIgGyRCOC0bKEI=?= cc: Lucas.James@ldjpc.apana.org.au, krebs@faps.uni-erlangen.de, freebsd-bugs@FreeBSD.org Subject: Re: GCC 2.6.2 / InterViews won't compile In-Reply-To: <199505300905.CAA10288@silvia.HIP.Berkeley.EDU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: bugs-owner@FreeBSD.org Precedence: bulk Satoshi I find that I can't make InterViews using Lucas script on my 2.0R system, but I can do that using my won script on my own 1.1.5.1 system. I bet Lucas's script would work fine on 1.1.5.1 too. If you have made InteViews on a more recent system, well, I guess it's upgrade time at last. I want to make one thing sure, however ... check your make listing for the stuff in the iv/src/bin directories, especially idraw and ibuild. That's what bombed for me, although the libs built fine. Please reassure me. Then I'll get mad at myself for spending all that time fighting a 2.0R problem, that wasn't in code ... sheesh! ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 7608 Topton St. | New Carrollton, MD 20784 | I run Journey2 (Freebsd 2.0) and n3lxx (301) 459-2316 | (FreeBSD 1.1.5.1) and am I happy! ----------------------------+----------------------------------------------- From owner-freebsd-bugs Wed May 31 21:00:04 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA27233 for bugs-outgoing; Wed, 31 May 1995 21:00:04 -0700 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA27223 ; Wed, 31 May 1995 21:00:02 -0700 Date: Wed, 31 May 1995 21:00:02 -0700 Message-Id: <199506010400.VAA27223@freefall.cdrom.com> From: "Gil Kloepfer Jr." Reply-To: "Gil Kloepfer Jr." To: freebsd-bugs Subject: conf/465: Freebsd 2.0.5a no way to access host w/o anon ftp In-Reply-To: Your message of Wed, 31 May 1995 22:58:31 -0500 <199506010358.WAA06652@limbic.ssdl.com> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 465 >Category: conf >Synopsis: Cannot ftp install from non-anonymous ftp site >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: change-request >Submitter-Id: current-users >Arrival-Date: Wed May 31 21:00:00 1995 >Originator: Gil Kloepfer Jr. >Organization: SSDL >Release: FreeBSD 2.0.5-ALPHA i386 >Environment: i386DX/40 on local Ethernet with FreeBSD distribution on another machine on local net >Description: Cannot specify a local machine to ftp files from. The installation process *requires* that the host containing the distribution support anonymous ftp, and I do not want anonymous ftp enabled on the system with the distribution files. This is a change of functionality from 2.0-RELEASE, where a non-anonymous site was able to be specified by entering a site name without a URL >How-To-Repeat: Attempt to load from a machine on a local net without anon ftp >Fix: Correct installation system to allow loading of distribution files from a non-anonymous ftp site, like was done in 2.0-RELEASE >Audit-Trail: >Unformatted: From owner-freebsd-bugs Wed May 31 21:36:07 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA28088 for bugs-outgoing; Wed, 31 May 1995 21:36:07 -0700 Received: (from jkh@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA28066 ; Wed, 31 May 1995 21:36:04 -0700 Date: Wed, 31 May 1995 21:36:04 -0700 From: "Jordan K. Hubbard" Message-Id: <199506010436.VAA28066@freefall.cdrom.com> To: gil@limbic.ssdl.com, jkh, freebsd-bugs Subject: Changed information for PR conf/465 Sender: bugs-owner@FreeBSD.org Precedence: bulk Synopsis: Cannot ftp install from non-anonymous ftp site State-Changed-From-To: open-closed State-Changed-By: jkh State-Changed-When: Wed May 31 21:34:21 PDT 1995 State-Changed-Why: This is not a bug, this is a feature. Given the structure of the ftp installation now, especially as it no longer "hits the disk" for intermediate files, I feel the trade-off to be worth it and will not be changing this. Those wishing a different local installation method can use NFS. From owner-freebsd-bugs Wed May 31 21:40:02 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA28177 for bugs-outgoing; Wed, 31 May 1995 21:40:02 -0700 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA28170 ; Wed, 31 May 1995 21:40:01 -0700 Date: Wed, 31 May 1995 21:40:01 -0700 Message-Id: <199506010440.VAA28170@freefall.cdrom.com> From: "Gil Kloepfer Jr." Reply-To: "Gil Kloepfer Jr." To: freebsd-bugs Subject: kern/466: Disk error on newfs In-Reply-To: Your message of Wed, 31 May 1995 23:35:51 -0500 <199506010435.XAA07012@limbic.ssdl.com> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 466 >Category: kern >Synopsis: Unexpected disk errors during installation/newfs >Confidential: no >Severity: critical >Priority: high >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed May 31 21:40:01 1995 >Originator: Gil Kloepfer Jr. >Organization: SSDL >Release: FreeBSD 2.0.5-ALPHA i386 >Environment: 386DX/40 ISA bus, no mathco, 8MB memory Adaptec 2322B ESDI controller 2 Maxtor XT-4380E ESDI drives **IMPORTANT** Disks are configured using sector sparing through controller low-level format. This reserves 1 sec/trk for bad blocks so that the disk appears "flawless" at low-level format time. This means that the advertised disk geometry of 1222cyl/15h/36sec is hardware changed to 1222cyl/15h/35sec >Description: After completing configuration questions, started install, and the following message appeared on the screen: Unable to make root filesystem! Command returned status 36 The debug window had the following messages (messages not pertaining to problem deleted): Warning: calculated sectors per cylinder (4096) disagrees with disk label (525) /dev/rwd0a: 40960 sectors in 10 cylinders of 1 tracks, 4096 sectors 20.0MB in 1 cyl groups (16 c/g, 32.00MB/g, 7680 i/g) wd0a: hard error writing fsbn 68 or 64-79 (wd0 bn 68; cn 0 tn 1 sn 33) wd0: status 51 error 10 super-block backups (for fsck -b #) at:write error: 64 wtfs: input/output error Another note that may help ... I noticed that the kernel message describing the disk when the kernel was booting identified the disk's physical geometry, and not the geometry as handled by the controller (using sector sparing). The disk layout that I configured in the earlier part of the installation was a 60MB DOS partition (existing), 20MB root, 32MB swap, 80MB /usr, 10MB /var, remaining /source. >How-To-Repeat: Perform installation again. Note...I am more than willing to test different kernels and/or procedures in an effort to help track the problem. The machine I am using is currently specifically for FreeBSD staging before moving the new OS to my production machine. >Fix: Unknown. >Audit-Trail: >Unformatted: From owner-freebsd-bugs Wed May 31 22:11:54 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA29308 for bugs-outgoing; Wed, 31 May 1995 22:11:54 -0700 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id WAA29299 for ; Wed, 31 May 1995 22:11:51 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id WAA03800; Wed, 31 May 1995 22:11:35 -0700 From: "Rodney W. Grimes" Message-Id: <199506010511.WAA03800@gndrsh.aac.dev.com> Subject: Re: kern/466: Disk error on newfs To: gil@limbic.ssdl.com Date: Wed, 31 May 1995 22:11:35 +1700 (PDT) Cc: freebsd-bugs@freefall.cdrom.com In-Reply-To: <199506010440.VAA28170@freefall.cdrom.com> from "Gil Kloepfer Jr." at May 31, 95 09:40:01 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: 3344 Sender: bugs-owner@FreeBSD.org Precedence: bulk > >Number: 466 > >Category: kern ... > >Synopsis: Unexpected disk errors during installation/newfs > > 386DX/40 ISA bus, no mathco, 8MB memory > Adaptec 2322B ESDI controller > 2 Maxtor XT-4380E ESDI drives > > **IMPORTANT** Disks are configured using sector sparing through > controller low-level format. This reserves 1 sec/trk for bad > blocks so that the disk appears "flawless" at low-level format > time. This means that the advertised disk geometry of > 1222cyl/15h/36sec is hardware changed to 1222cyl/15h/35sec A wd controller reset probably wipes this setting out and goes back to 1222/15/36 without sparing. If you can infact wipe this disk I suggest you stop using the sector sparing, get a little more capacity and tell the install that the drive needs bad144 mapping done on it. There is a bug in the first set of 2.0.5A floppies that currently prevents the bad144 stuff from working correctly. I have seen some commits that make me believe this will be fixed in the next set of floppies (probably due out some time in the morning PST on June 1st). Could you try this for us?? > >Description: > > After completing configuration questions, started install, and > the following message appeared on the screen: > > Unable to make root filesystem! Command returned status 36 > > The debug window had the following messages (messages not pertaining > to problem deleted): > > Warning: calculated sectors per cylinder (4096) disagrees with disk > label (525) > /dev/rwd0a: 40960 sectors in 10 cylinders of 1 tracks, 4096 sectors > 20.0MB in 1 cyl groups (16 c/g, 32.00MB/g, 7680 i/g) > wd0a: hard error writing fsbn 68 or 64-79 (wd0 bn 68; cn 0 tn 1 sn 33) > wd0: status 51 error 10 > super-block backups (for fsck -b #) at:write error: 64 > wtfs: input/output error > > Another note that may help ... I noticed that the kernel message > describing the disk when the kernel was booting identified the > disk's physical geometry, and not the geometry as handled by the > controller (using sector sparing). That is because we did a hard controller reset which cleared any setting values done by the BIOS at boot time. This sector sparing is usually a BIOS handled wdsetparam thing. See above... > The disk layout that I configured in the earlier part of the > installation was a 60MB DOS partition (existing), 20MB root, > 32MB swap, 80MB /usr, 10MB /var, remaining /source. You'll have to reinstall the *WHOLE* disk, means wipping the DOS parition and reformatting with DOS :-(. > >How-To-Repeat: > > Perform installation again. > > Note...I am more than willing to test different kernels and/or > procedures in an effort to help track the problem. The machine ^^^^^^^^^^^^^^^^ I would like you to try my procedure. I can understand that it may not be possible due to DOS data on the disk. (You could probably do it if you did not want to access the DOS data from FreeBSD). > I am using is currently specifically for FreeBSD staging before > moving the new OS to my production machine. > > >Fix: > > Unknown. > > >Audit-Trail: > >Unformatted: > > > -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-bugs Wed May 31 22:41:20 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA00635 for bugs-outgoing; Wed, 31 May 1995 22:41:20 -0700 Received: from mg1.cdsnet.net (mrcpu@mg1.cdsnet.net [204.118.244.5]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id WAA00629 ; Wed, 31 May 1995 22:41:19 -0700 Received: (from mrcpu@localhost) by mg1.cdsnet.net (8.6.12/8.6.10) id WAA04768; Wed, 31 May 1995 22:41:20 -0700 Date: Wed, 31 May 1995 22:41:19 -0700 (PDT) From: Jaye Mathisen To: "Jordan K. Hubbard" cc: gil@limbic.ssdl.com, jkh@freefall.cdrom.com, freebsd-bugs@freefall.cdrom.com Subject: Re: Changed information for PR conf/465 In-Reply-To: <199506010436.VAA28066@freefall.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: bugs-owner@FreeBSD.org Precedence: bulk Since the URL spec allows ftp to have an account and password specified, why not set it up to use that? Then it can work both ways... On Wed, 31 May 1995, Jordan K. Hubbard wrote: > Synopsis: Cannot ftp install from non-anonymous ftp site > > State-Changed-From-To: open-closed > State-Changed-By: jkh > State-Changed-When: Wed May 31 21:34:21 PDT 1995 > State-Changed-Why: > This is not a bug, this is a feature. Given the structure > of the ftp installation now, especially as it no longer > "hits the disk" for intermediate files, I feel the trade-off > to be worth it and will not be changing this. Those wishing > a different local installation method can use NFS. > From owner-freebsd-bugs Wed May 31 22:46:11 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA00812 for bugs-outgoing; Wed, 31 May 1995 22:46:11 -0700 Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id WAA00804 ; Wed, 31 May 1995 22:46:09 -0700 Message-Id: <199506010546.WAA00804@freefall.cdrom.com> X-Authentication-Warning: freefall.cdrom.com: Host localhost.cdrom.com didn't use HELO protocol To: "Jordan K. Hubbard" cc: gil@limbic.ssdl.com, freebsd-bugs@freefall.cdrom.com Subject: Re: Changed information for PR conf/465 In-reply-to: Your message of "Wed, 31 May 95 21:36:04 PDT." <199506010436.VAA28066@freefall.cdrom.com> Date: Wed, 31 May 1995 22:46:08 -0700 From: "Justin T. Gibbs" Sender: bugs-owner@FreeBSD.org Precedence: bulk >Synopsis: Cannot ftp install from non-anonymous ftp site > >State-Changed-From-To: open-closed >State-Changed-By: jkh >State-Changed-When: Wed May 31 21:34:21 PDT 1995 >State-Changed-Why: >This is not a bug, this is a feature. Given the structure >of the ftp installation now, especially as it no longer >"hits the disk" for intermediate files, I feel the trade-off >to be worth it and will not be changing this. Those wishing >a different local installation method can use NFS. Is there something that precludes asking for a login and password? -- Justin T. Gibbs ============================================== TCS Instructional Group - Programmer/Analyst 1 Cory | Po | Danube | Volga | Parker | Torus ============================================== From owner-freebsd-bugs Wed May 31 22:57:38 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA01101 for bugs-outgoing; Wed, 31 May 1995 22:57:38 -0700 Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id WAA01094 ; Wed, 31 May 1995 22:57:37 -0700 X-Authentication-Warning: freefall.cdrom.com: Host localhost.cdrom.com didn't use HELO protocol To: Jaye Mathisen cc: gil@limbic.ssdl.com, freebsd-bugs@freefall.cdrom.com Subject: Re: Changed information for PR conf/465 In-reply-to: Your message of "Wed, 31 May 95 22:41:19 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 31 May 1995 22:57:37 -0700 Message-ID: <1093.801986257@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: bugs-owner@FreeBSD.org Precedence: bulk > Since the URL spec allows ftp to have an account and password specified, > why not set it up to use that? Then it can work both ways... That would probably have been cleaner, but more parsing work.. :-) I did it another way, and the feature will be in tonite's floppies. Jordan From owner-freebsd-bugs Thu Jun 1 01:11:26 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id BAA03191 for bugs-outgoing; Thu, 1 Jun 1995 01:11:26 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id BAA03181 for ; Thu, 1 Jun 1995 01:11:18 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id SAA25484; Thu, 1 Jun 1995 18:05:35 +1000 Date: Thu, 1 Jun 1995 18:05:35 +1000 From: Bruce Evans Message-Id: <199506010805.SAA25484@godzilla.zeta.org.au> To: gil@limbic.ssdl.com, rgrimes@gndrsh.aac.dev.com Subject: Re: kern/466: Disk error on newfs Cc: freebsd-bugs@freefall.cdrom.com Sender: bugs-owner@FreeBSD.org Precedence: bulk >> **IMPORTANT** Disks are configured using sector sparing through >> controller low-level format. This reserves 1 sec/trk for bad >> blocks so that the disk appears "flawless" at low-level format >> time. This means that the advertised disk geometry of >> 1222cyl/15h/36sec is hardware changed to 1222cyl/15h/35sec >A wd controller reset probably wipes this setting out and goes back >to 1222/15/36 without sparing. If you can infact wipe this disk I It goes back to the original setting which is also apparently 36 sectors. Rewriting of the geometry to match the partition table and again to match the disk label got lost in the slice changes :-(. >suggest you stop using the sector sparing, get a little more capacity >and tell the install that the drive needs bad144 mapping done on it. Then there would be a problem with cylinders >= 1024. It used to be possible to handle this by changing the geometry, but this also depends on rewriting the geometry. >> >Description: >> ... >> Warning: calculated sectors per cylinder (4096) disagrees with disk >> label (525) This is normal, but sysinstall should do something to avoid it. >> /dev/rwd0a: 40960 sectors in 10 cylinders of 1 tracks, 4096 sectors >> 20.0MB in 1 cyl groups (16 c/g, 32.00MB/g, 7680 i/g) >> wd0a: hard error writing fsbn 68 or 64-79 (wd0 bn 68; cn 0 tn 1 sn 33) >> wd0: status 51 error 10 sn 35 (0 based) in the middle of the block is apparently inaccessible. You might be able to enable translation. This is selectable by a jumper on my ESDI controller (WD1007V-SE/1). Then sector 35 would be writable, but there would appear to be only (1222 * 35 / 36 = 1188) cylinders and it would be relatively easy to avoid using the cylinders >= 1188. However, there would probably still be a conflict with the BIOS geometry. >> Another note that may help ... I noticed that the kernel message >> describing the disk when the kernel was booting identified the >> disk's physical geometry, and not the geometry as handled by the >> controller (using sector sparing). >That is because we did a hard controller reset which cleared any setting >values done by the BIOS at boot time. This sector sparing is usually >a BIOS handled wdsetparam thing. See above... The reset is almost irrelevant. The driver reprograms the geometry after all resets to tell the controller what it thinks it is. The problems are that translation is disabled so reprogramming fails, but no error is detected, and the number of cylinders is a little too high. Bruce From owner-freebsd-bugs Thu Jun 1 03:20:25 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id DAA10045 for bugs-outgoing; Thu, 1 Jun 1995 03:20:25 -0700 Received: from ie.tiasur.tomsk.su (ie.tiasur.tomsk.su [193.125.215.163]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id DAA09986 for ; Thu, 1 Jun 1995 03:19:26 -0700 Received: by ie.tiasur.tomsk.su id SAA01430; Thu, 1 Jun 1995 18:16:41 +0800 From: Pavel Gubin Message-Id: <199506011016.SAA01430@ie.tiasur.tomsk.su> Subject: NFS bug... To: FreeBSD-bugs@FreeBSD.org Date: Thu, 1 Jun 1995 18:16:40 +0800 (TSD) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 768 Sender: bugs-owner@FreeBSD.org Precedence: bulk Hello, Seems to me I've found some bug in FreeBSD's NFS. Bug appears when my BSD works as NFS client connected to NetWare NFS server. When NFS is heavily loaded, like untaring archive from NFS to NFS, system more or less regularily crashes with "page fault while in kernel mode". Kernel debugger's trace shows that trap occurs in nfs_reply at offset 0xc4 (in my kernel). This location matches source line 750 in file nfs_socket.c when function nfsm_disct called (from nfsm_dissect macro). Actually offset 0xc4 is immediately after call to nfsm_disct. I'm wondering if you already know about this bug and should I continue to dig in that direction? ;-) PS: Please reply with email(to pg@ie.tiasur.tomsk.su), because I'm not a mailing list subscriber. From owner-freebsd-bugs Thu Jun 1 04:10:03 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id EAA12962 for bugs-outgoing; Thu, 1 Jun 1995 04:10:03 -0700 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id EAA12955 ; Thu, 1 Jun 1995 04:10:02 -0700 Date: Thu, 1 Jun 1995 04:10:02 -0700 Message-Id: <199506011110.EAA12955@freefall.cdrom.com> From: paepcke@arcway.snafu.de Reply-To: paepcke@arcway.snafu.de To: freebsd-bugs Subject: ports/467: utils/kp wrong distfile place after make fetch In-Reply-To: Your message of Thu, 1 Jun 1995 12:53:48 GMT <199506011253.MAA01402@arcway.snafu.de> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 467 >Category: ports >Synopsis: utils/kp wrong distfile place after make fetch >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Jun 1 04:10:01 1995 >Originator: Michael Paepcke >Organization: ArcWay >Release: FreeBSD 2.0-BUILT-19950523 i386 >Environment: >Description: ports/utils/kp put the distfile after make [fetch] to /pub/kp-0.95.tar.gz ... should be ports/distfiles/kp-0.95.tar.gz >How-To-Repeat: [rm ports/distfiles/kp-0.95.tar.gz] cd ports/utils/kp ; make >Fix: >Audit-Trail: >Unformatted: From owner-freebsd-bugs Thu Jun 1 07:14:26 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id HAA19249 for bugs-outgoing; Thu, 1 Jun 1995 07:14:26 -0700 Received: from hutcs.cs.hut.fi (root@hutcs.cs.hut.fi [130.233.192.2]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id HAA19242 ; Thu, 1 Jun 1995 07:14:19 -0700 Received: from shadows.cs.hut.fi by hutcs.cs.hut.fi with SMTP id AA00958 (5.65c8/HUTCS-S 1.4); Thu, 1 Jun 1995 17:12:47 +0300 From: Heikki Suonsivu Received: (hsu@localhost) by shadows.cs.hut.fi (8.6.10/8.6.10) id RAA26390; Thu, 1 Jun 1995 17:12:33 +0300 Date: Thu, 1 Jun 1995 17:12:33 +0300 Message-Id: <199506011412.RAA26390@shadows.cs.hut.fi> To: "Jordan K. Hubbard" Cc: freebsd-bugs@freefall.cdrom.com In-Reply-To: "Jordan K. Hubbard"'s message of 1 Jun 1995 08:22:04 +0300 Subject: Changed information for PR conf/465 Organization: Helsinki University of Technology, Otaniemi, Finland Sender: bugs-owner@FreeBSD.org Precedence: bulk State-Changed-From-To: open-closed State-Changed-By: jkh State-Changed-When: Wed May 31 21:34:21 PDT 1995 State-Changed-Why: This is not a bug, this is a feature. Given the structure of the ftp installation now, especially as it no longer "hits the disk" for intermediate files, I feel the trade-off to be worth it and will not be changing this. Those wishing a different local installation method can use NFS. Bad idea; NFS is usually filtered out everywhere as it has been a major security hole. -- Heikki Suonsivu, T{ysikuu 10 C 83/02210 Espoo/FINLAND, hsu@cs.hut.fi home +358-0-8031121 work -4513377 fax -4555276 riippu SN From owner-freebsd-bugs Thu Jun 1 08:06:05 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA21916 for bugs-outgoing; Thu, 1 Jun 1995 08:06:05 -0700 Received: from insanus.matematik.su.se (insanus.matematik.su.se [130.237.198.12]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id IAA21907 for ; Thu, 1 Jun 1995 08:05:58 -0700 Received: from localhost (jocosus.matematik.su.se [130.237.198.7]) by insanus.matematik.su.se (8.6.10/8.6.9) with ESMTP id PAA05866 for ; Thu, 1 Jun 1995 15:05:51 GMT Message-Id: <199506011505.PAA05866@insanus.matematik.su.se> X-Address: Department of Mathematics, Stockholm University S-106 91 Stockholm SWEDEN X-Phone: int+8162000 X-Fax: int+86126717 X-Url: http://www.matematik.su.se To: bugs@FreeBSD.org Subject: 3 problems using FreeBSD 2.0.950412-SNAP Date: Thu, 01 Jun 1995 17:05:46 +0200 From: Torbjorn Granlund Sender: bugs-owner@FreeBSD.org Precedence: bulk * Using an Adaptec 2940 and a Quantum Atlas 34301 (a 4.1GB fast SCSI-II drive) I don't get more than 5MB/s. I actually get *exactly* 5MB/s for large transfers. Since both the controller and the drive handles 10MB/s, and the BIOS is set up properly, and the SCSI bus is terminated properly, I would expect a sustained transfer rate of close to 10MB/s. The way I time this is with dd if=/dev/rds0 of=/dev/null bs=1024k count=100 * /usr/bin/file doesn't report some native file types correctly. The line, echo 'main(){}' >foo.c; cc -n foo.c; file a.out outputs the bogus a.out: PDP-11 pure executable not stripped * /usr/bin/which doesn't work if a complete path is passed to it. This is incompatible with other flavours of Unix, Here is a suggested patch: *** /usr/bin/which Thu Apr 13 15:43:55 1995 --- which Wed May 31 17:58:37 1995 *************** *** 47,59 **** } foreach $prog (@ARGV) { ! foreach $e (@path) { ! if (-x "$e/$prog") { ! print "$e/$prog\n" unless $silent; $found = 1; ! last unless $all; ! } ! } } exit (!$found); --- 47,64 ---- } foreach $prog (@ARGV) { ! if (-x "$prog") { ! print "$prog\n" unless $silent; $found = 1; ! } else { ! foreach $e (@path) { ! if (-x "$e/$prog") { ! print "$e/$prog\n" unless $silent; ! $found = 1; ! last unless $all; ! } ! } ! } } exit (!$found); From owner-freebsd-bugs Thu Jun 1 09:06:27 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA23012 for bugs-outgoing; Thu, 1 Jun 1995 09:06:27 -0700 Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id JAA23005 ; Thu, 1 Jun 1995 09:06:26 -0700 Message-Id: <199506011606.JAA23005@freefall.cdrom.com> X-Authentication-Warning: freefall.cdrom.com: Host localhost.cdrom.com didn't use HELO protocol To: Torbjorn Granlund cc: bugs@FreeBSD.org Subject: Re: 3 problems using FreeBSD 2.0.950412-SNAP In-reply-to: Your message of "Thu, 01 Jun 95 17:05:46 +0200." <199506011505.PAA05866@insanus.matematik.su.se> Date: Thu, 01 Jun 1995 09:06:25 -0700 From: "Justin T. Gibbs" Sender: bugs-owner@FreeBSD.org Precedence: bulk >* Using an Adaptec 2940 and a Quantum Atlas 34301 (a 4.1GB fast SCSI-II > drive) I don't get more than 5MB/s. I actually get *exactly* 5MB/s for > large transfers. Since both the controller and the drive handles 10MB/s, > and the BIOS is set up properly, and the SCSI bus is terminated properly, > I would expect a sustained transfer rate of close to 10MB/s. The bus runs at 10Mhz which means 10MB/s during data transfers. You need to take into consideration bus arbitration, selection, reconnection, and message phases in order to get a more realistic number. My guess would be 8.5->9MB/s max on an 8bit, fast, bus. I don't have the drive specs on the Atlas handy, but just because it can run the bus at 10MHz doesn't mean it can dump data at that speed. You need to take into consideration the spindle speed, head possition, and data density. For example, the theoretical max on an Empire 2100 is 5.12MB/s. Now, this is not to say that there aren't improvements that can be made to the 2940 (aic7xxx) driver. There are quite a few things I have planned to improve transactional overhead (FreeBSD does does at most 64k in a transfer, so transactional overhead is important), but I'm much more interested in killing any and all compatibility problems with the sequencer code first. -- Justin T. Gibbs ============================================== TCS Instructional Group - Programmer/Analyst 1 Cory | Po | Danube | Volga | Parker | Torus ============================================== From owner-freebsd-bugs Thu Jun 1 09:53:11 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA25261 for bugs-outgoing; Thu, 1 Jun 1995 09:53:11 -0700 Received: from longvalley.dsg.cs.tcd.ie (longvalley.dsg.cs.tcd.ie [134.226.36.37]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id JAA25240 for ; Thu, 1 Jun 1995 09:52:38 -0700 Received: from dedanann.dsg.cs.tcd.ie by longvalley.dsg.cs.tcd.ie id aa23766; 1 Jun 95 17:51 BST To: bugs@FreeBSD.org Subject: Install problem with 2.0.5-ALPHA (UPDATE floppy image) Date: Thu, 01 Jun 1995 17:51:46 +0100 From: Alan Judge Message-ID: <9506011751.aa23766@longvalley.dsg.cs.tcd.ie> Sender: bugs-owner@FreeBSD.org Precedence: bulk I don't know if this is a known problem (if not, mail me and I'll provide more info). I can't get FTP/other to work at all. Something seems to corrupt the URL that I type before it gets to the FTP stage. I get a popup dialog complaining about some garbage URL (like '', or '^A', or ' ^Gwish sd'). The machine and install seem to be otherwise OK and I managed to do an custom install via NFS. (Though it complained with: Could't extract all of the dists. Residue: 80 it seems to have worked ok.) -- Alan P.S. Am I correct in thinking that the default distribution is now using crypt-style passwords instead of MD5? From owner-freebsd-bugs Thu Jun 1 10:55:10 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA29462 for bugs-outgoing; Thu, 1 Jun 1995 10:55:10 -0700 Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id KAA29454 ; Thu, 1 Jun 1995 10:55:09 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14565(2)>; Thu, 1 Jun 1995 10:53:21 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <49859>; Thu, 1 Jun 1995 10:53:07 -0700 X-Mailer: exmh version 1.6 4/21/95 To: "Jordan K. Hubbard" cc: gil@limbic.ssdl.com, freebsd-bugs@freefall.cdrom.com Subject: Re: Changed information for PR conf/465 In-reply-to: Your message of "Wed, 31 May 95 21:36:04 PDT." <199506010436.VAA28066@freefall.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 1 Jun 1995 10:53:03 PDT From: Bill Fenner Message-Id: <95Jun1.105307pdt.49859@crevenia.parc.xerox.com> Sender: bugs-owner@FreeBSD.org Precedence: bulk In message <199506010436.VAA28066@freefall.cdrom.com> you write: >Synopsis: Cannot ftp install from non-anonymous ftp site > >State-Changed-Why: >This is not a bug, this is a feature. Given the structure >of the ftp installation now, especially as it no longer >"hits the disk" for intermediate files, I feel the trade-off >to be worth it and will not be changing this. Those wishing >a different local installation method can use NFS. Sigh. I used the "non-anonymous" feature to get through our firewall (you do "ftp internet-gateway ftp-passthru" and log on as "user@site"). This change means that I have to find a machine inside the firewall with lots of disk to ftp the install to first and then NFS-mount that... Bill From owner-freebsd-bugs Thu Jun 1 11:51:24 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA03224 for bugs-outgoing; Thu, 1 Jun 1995 11:51:24 -0700 Received: from truelies.rs.itd.umich.edu (truelies.rs.itd.umich.edu [141.211.83.38]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id LAA03218 for ; Thu, 1 Jun 1995 11:51:23 -0700 Received: from grenade.ifs.umich.edu by truelies.rs.itd.umich.edu (8.6.12/2.2) with ESMTP id OAA01325; Thu, 1 Jun 1995 14:51:20 -0400 Message-Id: <199506011851.OAA01325@truelies.rs.itd.umich.edu> To: bugs@FreeBSD.org Subject: bug report From: Paul.H.Anderson@umich.edu Date: Thu, 01 Jun 1995 14:50:24 -0400 Sender: bugs-owner@FreeBSD.org Precedence: bulk [awesome job on FreeBSD, folks! The new install program looks much more tightly integrated with itself...] You may already know about these, but what the heck... Release: FreeBSD 2.0.5-ALPHA, pulled over from ftp.cdrom.com Thu Jun 1, 1995 HW: P-90, adaptec 1542-B, SCSI QIC(st0), 8mm exabyte(st1), NCR xxx25 FW SCSI, 4 2GB baracuda FW SCSI drives (sd0...sd3), primary boot drive 800MB IDE General problem: install doesn't work for me problem 1: when selecting media, I can specify filesystems (I put the distribution files all on my 2GB drives), but I have no apparent documented means of going to the root shell to MAKEDEV and mount the filesystem. So, no dice. problem 2: failing the above, I try SCSI tape. After I select tape, the menu program tells me there are no tape devices. There is no media in st0 (QIC), and the install tape in st1 (8mm), both of which were probed during boot, but the install program doesn't see either one. So, no dice on install... (*: Anyhow, unless I'm missing something obvious, it looks like I'm hosed (I can get loaded in other ways if I really have to, so don't worry about that). Paul Anderson pha@umich.edu From owner-freebsd-bugs Thu Jun 1 12:00:03 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA05581 for bugs-outgoing; Thu, 1 Jun 1995 12:00:03 -0700 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA05568 ; Thu, 1 Jun 1995 12:00:02 -0700 Date: Thu, 1 Jun 1995 12:00:02 -0700 Message-Id: <199506011900.MAA05568@freefall.cdrom.com> From: knarf@nasim.cube.net (Frank Bartels) Reply-To: knarf@nasim.cube.net (Frank Bartels) To: freebsd-bugs Subject: bin/468: passwd changes wrong password In-Reply-To: Your message of Thu, 1 Jun 1995 20:58:16 +0200 <199506011858.UAA18801@ivanhoe.nasim.cube.net> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 468 >Category: bin >Synopsis: passwd changes wrong password >Confidential: no >Severity: critical >Priority: medium >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Jun 1 12:00:01 1995 >Originator: Frank Bartels >Organization: Frank Bartels | UUCP/ZModem/Fax: + 49 89 5469593 | MiNT is knarf@nasim.cube.net | Login: nuucp Index: /pub/ls-lR.nasim.gz | Now TOS! >Release: FreeBSD 2.0-RELEASE i386 >Environment: 2.0R, secrdist, no YP. >Description: passwd changes the wrong password after su. >How-To-Repeat: [su to root] sogand:/root# passwd Changing local password for knarf. ^^^^^ >Fix: >Audit-Trail: >Unformatted: From owner-freebsd-bugs Thu Jun 1 12:04:26 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA06665 for bugs-outgoing; Thu, 1 Jun 1995 12:04:26 -0700 Received: from racer.dkrz.de (racer.dkrz.de [136.172.110.55]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id MAA06630 for ; Thu, 1 Jun 1995 12:04:12 -0700 Received: by racer.dkrz.de (4.1/SMI-4.1) id AA09513; Thu, 1 Jun 95 21:02:32 +0200 Date: Thu, 1 Jun 95 21:02:32 +0200 From: gwk@racer.dkrz.de (Georg-W. Koltermann) Message-Id: <9506011902.AA09513@racer.dkrz.de> To: amjudge@dsg.cs.tcd.ie Cc: bugs@FreeBSD.org In-Reply-To: <9506011751.aa23766@longvalley.dsg.cs.tcd.ie> (message from Alan Judge on Thu, 01 Jun 1995 17:51:46 +0100) Subject: Re: Install problem with 2.0.5-ALPHA (UPDATE floppy image) Reply-To: gwk@cray.com Sender: bugs-owner@FreeBSD.org Precedence: bulk > > I can't get FTP/other to work at all. Something seems to corrupt the > URL that I type before it gets to the FTP stage. I get a popup dialog > complaining about some garbage URL (like '', or '^A', or ' ^Gwish > sd'). > Same for me. And I can't get floppy installation to work. It seems to try to mount the root.flp floppy, which I have rawritten. Who's wrong, the machine or me? And I can't get NFS installation to work, something like permission problems. When the NFS filesystem is mounted, I cannot even cd into the mountpoint directory, "permission denied". And I can't get installation from a DOS partition to work, some kind of error during mounting, I don't recall exactly what. The one time that I tricked the system (actually I switched to VT4 and manually extracted the root.flp, then configured the ethernet, ftp-ed the bindist to /tmp, switched back to the menu and let it go installing from UFS), I actually got *something* installed. But when I booted from the harddisk, I got tons of "signal 11"s. Guess it's time to give up for today. My previous experience with the installation menu of 2.0R and various snapshots was not this bad. Georg-W. Koltermann, gwk@cray.com From owner-freebsd-bugs Thu Jun 1 12:23:05 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA10263 for bugs-outgoing; Thu, 1 Jun 1995 12:23:05 -0700 Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id MAA10248 ; Thu, 1 Jun 1995 12:23:03 -0700 Message-Id: <199506011923.MAA10248@freefall.cdrom.com> X-Authentication-Warning: freefall.cdrom.com: Host localhost.cdrom.com didn't use HELO protocol To: gwk@cray.com cc: amjudge@dsg.cs.tcd.ie, bugs@FreeBSD.org Subject: Re: Install problem with 2.0.5-ALPHA (UPDATE floppy image) In-reply-to: Your message of "Thu, 01 Jun 95 21:02:32 +0200." <9506011902.AA09513@racer.dkrz.de> Date: Thu, 01 Jun 1995 12:23:01 -0700 From: "Justin T. Gibbs" Sender: bugs-owner@FreeBSD.org Precedence: bulk >> >> I can't get FTP/other to work at all. Something seems to corrupt the >> URL that I type before it gets to the FTP stage. I get a popup dialog >> complaining about some garbage URL (like '', or '^A', or ' ^Gwish >> sd'). >> > >Same for me. And I can't get floppy installation to work. It seems >to try to mount the root.flp floppy, which I have rawritten. Who's >wrong, the machine or me? And I can't get NFS installation to work, >something like permission problems. When the NFS filesystem is Do you have the partion exported with root permissions? Sysinstall runs as root, so it will become user "nobody" on the mounted partition if you don't allow root access to the partition. >mounted, I cannot even cd into the mountpoint directory, "permission >denied". And I can't get installation from a DOS partition to work, >some kind of error during mounting, I don't recall exactly what. > >The one time that I tricked the system (actually I switched to VT4 and >manually extracted the root.flp, then configured the ethernet, ftp-ed >the bindist to /tmp, switched back to the menu and let it go >installing from UFS), I actually got *something* installed. But when >I booted from the harddisk, I got tons of "signal 11"s. > >Guess it's time to give up for today. My previous experience with the >installation menu of 2.0R and various snapshots was not this bad. > >Georg-W. Koltermann, gwk@cray.com -- Justin T. Gibbs ============================================== TCS Instructional Group - Programmer/Analyst 1 Cory | Po | Danube | Volga | Parker | Torus ============================================== From owner-freebsd-bugs Thu Jun 1 12:23:44 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA10378 for bugs-outgoing; Thu, 1 Jun 1995 12:23:44 -0700 Received: from racer.dkrz.de (racer.dkrz.de [136.172.110.55]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id MAA10346 for ; Thu, 1 Jun 1995 12:23:34 -0700 Received: by racer.dkrz.de (4.1/SMI-4.1) id AA09555; Thu, 1 Jun 95 21:22:19 +0200 Date: Thu, 1 Jun 95 21:22:19 +0200 From: gwk@racer.dkrz.de (Georg-W. Koltermann) Message-Id: <9506011922.AA09555@racer.dkrz.de> To: freebsd-bugs@FreeBSD.org Subject: ed0 irq not probed correctly by 2.0.5A Reply-To: gwk@cray.com Sender: bugs-owner@FreeBSD.org Precedence: bulk When installing 2.0.5-ALPHA (both with the original an UPDATE floppies), the kernel thinks my WD ethernet card is at irq 5. It actually is at irq 10, and the February snap probed it correctly. 80386/40 clone 8MB RAM, IDE disks, WD8013EPC. Georg-W. Koltermann, gwk@cray.com From owner-freebsd-bugs Thu Jun 1 12:30:03 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA11705 for bugs-outgoing; Thu, 1 Jun 1995 12:30:03 -0700 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA11698 ; Thu, 1 Jun 1995 12:30:02 -0700 Date: Thu, 1 Jun 1995 12:30:02 -0700 Message-Id: <199506011930.MAA11698@freefall.cdrom.com> From: J Wunsch Reply-To: J Wunsch To: freebsd-bugs Subject: misc/469: ctm leaves temp files after errors In-Reply-To: Your message of Thu, 1 Jun 1995 21:03:00 +0200 <199506011903.VAA11960@uriah.heep.sax.de> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 469 >Category: misc >Synopsis: ctm leaves temp files after errors >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Jun 1 12:30:01 1995 >Originator: J Wunsch >Organization: >Release: FreeBSD 2.1.0-Development i386 >Environment: >Description: In case ctm exits due to some MD5 checksum error (actually, a missing CTM delta in the sequence), it leaves a temp file named CTMclient in the temp directory. >How-To-Repeat: Feed a bunch of CTM deltas into ctm, with one of them missing in the sequence. Ctm will (correctly) complain that the .ctm_status file mismatches its MD5 checksum, and exit. After this, the temp file will be left. >Fix: >Audit-Trail: >Unformatted: From owner-freebsd-bugs Thu Jun 1 12:35:51 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA13091 for bugs-outgoing; Thu, 1 Jun 1995 12:35:51 -0700 Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id MAA13079 ; Thu, 1 Jun 1995 12:35:49 -0700 Message-Id: <199506011935.MAA13079@freefall.cdrom.com> X-Authentication-Warning: freefall.cdrom.com: Host localhost.cdrom.com didn't use HELO protocol To: gwk@cray.com cc: freebsd-bugs@FreeBSD.org Subject: Re: ed0 irq not probed correctly by 2.0.5A In-reply-to: Your message of "Thu, 01 Jun 95 21:22:19 +0200." <9506011922.AA09555@racer.dkrz.de> Date: Thu, 01 Jun 1995 12:35:48 -0700 From: "Justin T. Gibbs" Sender: bugs-owner@FreeBSD.org Precedence: bulk > >When installing 2.0.5-ALPHA (both with the original an UPDATE >floppies), the kernel thinks my WD ethernet card is at irq 5. It >actually is at irq 10, and the February snap probed it correctly. > >80386/40 clone 8MB RAM, IDE disks, WD8013EPC. > >Georg-W. Koltermann, gwk@cray.com Boot using the -c flag and set the irq correctly within the "userconfig" program. The driver will not "autoprobe" the IRQ of the card unless you set the IRQ to -1 in userconfig or use an "irq ?" entry in the kernel config file. The current GENERIC kernel always looks for the card on irq 5 for the ed1 entry which is most likely why you are seeing this. -- Justin T. Gibbs ============================================== TCS Instructional Group - Programmer/Analyst 1 Cory | Po | Danube | Volga | Parker | Torus ============================================== From owner-freebsd-bugs Thu Jun 1 12:51:16 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA16197 for bugs-outgoing; Thu, 1 Jun 1995 12:51:16 -0700 Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id MAA16191 for ; Thu, 1 Jun 1995 12:51:12 -0700 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.11/8.6.9) id MAA01859; Thu, 1 Jun 1995 12:46:50 -0700 Date: Thu, 1 Jun 1995 12:46:50 -0700 Message-Id: <199506011946.MAA01859@silvia.HIP.Berkeley.EDU> To: chuckr@Glue.umd.edu CC: Lucas.James@ldjpc.apana.org.au, krebs@faps.uni-erlangen.de, freebsd-bugs@FreeBSD.org In-reply-to: (message from Chuck Robey on Wed, 31 May 1995 19:27:52 -0400 (EDT)) Subject: Re: GCC 2.6.2 / InterViews won't compile From: asami@CS.Berkeley.EDU (Satoshi Asami | =?ISO-2022-JP?B?GyRCQHUbKEI=?= =?ISO-2022-JP?B?GyRCOCsbKEIgGyRCOC0bKEI=?=) Sender: bugs-owner@FreeBSD.org Precedence: bulk * I want to make one thing sure, however ... check your make listing for * the stuff in the iv/src/bin directories, especially idraw and ibuild. * That's what bombed for me, although the libs built fine. Yes, it has idraw and ibuild. In fact, idraw was the program I ran when I tested it! :) Satoshi From owner-freebsd-bugs Thu Jun 1 13:25:40 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id NAA21837 for bugs-outgoing; Thu, 1 Jun 1995 13:25:40 -0700 Received: from wc.cdrom.com (wc.cdrom.com [192.216.223.37]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id NAA21809 ; Thu, 1 Jun 1995 13:25:35 -0700 Received: from eikon.regent.e-technik.tu-muenchen.de (root@eikon.regent.e-technik.tu-muenchen.de [129.187.42.3]) by wc.cdrom.com (8.6.12/8.6.12) with SMTP id NAA10071 ; Thu, 1 Jun 1995 13:25:32 -0700 Received: from vector.eikon.e-technik.tu-muenchen.de ([129.187.142.36]) by eikon.regent.e-technik.tu-muenchen.de with SMTP id <43145>; Thu, 1 Jun 1995 22:23:22 +0200 Received: from localhost (localhost [127.0.0.1]) by vector.eikon.e-technik.tu-muenchen.de (8.6.11/8.6.9) with SMTP id JAA10765; Thu, 1 Jun 1995 09:34:36 +0200 Message-Id: <199506010734.JAA10765@vector.eikon.e-technik.tu-muenchen.de> X-Authentication-Warning: vector.eikon.e-technik.tu-muenchen.de: Host localhost didn't use HELO protocol To: Satoshi Asami cc: paepcke@arcway.snafu.de, freebsd-bugs@freefall.cdrom.com, me@FreeBSD.org Subject: Re: Changed information for PR ports/456 In-reply-to: Your message of "Tue, 30 May 1995 11:54:51 +0200." <199505300954.CAA18718@freefall.cdrom.com> Date: Thu, 1 Jun 1995 09:34:35 +0200 From: Julian Howard Stacey Sender: bugs-owner@FreeBSD.org Precedence: bulk > Synopsis: (new) x11/fvwm make do not look for xpm built > Proposed fix applied to revision 1.18 of ports/x11/fvwm/Makefile. After reading this, I fixed my broken autoraise with: cd /usr/ports/graphics/xpm; make clean; make all ; make reinstall PS My working /usr/X11R6/lib has: 55940 Jun 1 00:27 libXpm.a 56439 Apr 4 12:52 libXpm.so.4.4 56439 Jun 1 00:27 libXpm.so.4.5 A system backup copy (with non functional autoraise) from a few days ago has: 55956 Apr 4 12:52 libXpm.a 56439 Apr 4 12:52 libXpm.so.4.4 Julian S jhs@freebsd.org From owner-freebsd-bugs Thu Jun 1 14:08:06 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA01341 for bugs-outgoing; Thu, 1 Jun 1995 14:08:06 -0700 Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id OAA01326 ; Thu, 1 Jun 1995 14:08:03 -0700 X-Authentication-Warning: freefall.cdrom.com: Host localhost.cdrom.com didn't use HELO protocol To: Alan Judge cc: bugs@FreeBSD.org Subject: Re: Install problem with 2.0.5-ALPHA (UPDATE floppy image) In-reply-to: Your message of "Thu, 01 Jun 95 17:51:46 BST." <9506011751.aa23766@longvalley.dsg.cs.tcd.ie> Date: Thu, 01 Jun 1995 14:08:02 -0700 Message-ID: <1318.802040882@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: bugs-owner@FreeBSD.org Precedence: bulk > I can't get FTP/other to work at all. Something seems to corrupt the > URL that I type before it gets to the FTP stage. I get a popup dialog > complaining about some garbage URL (like '', or '^A', or ' ^Gwish I believe I've just fixed this, thanks! > The machine and install seem to be otherwise OK and I managed to do > an custom install via NFS. (Though it complained with: > Could't extract all of the dists. Residue: 80 I'm still looking for this one.. :-) >P.S. Am I correct in thinking that the default distribution is now >using crypt-style passwords instead of MD5? That is correct! Jordan From owner-freebsd-bugs Thu Jun 1 14:12:17 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA01985 for bugs-outgoing; Thu, 1 Jun 1995 14:12:17 -0700 Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id OAA01975 for ; Thu, 1 Jun 1995 14:12:15 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14512(2)>; Thu, 1 Jun 1995 14:11:25 PDT Received: by crevenia.parc.xerox.com id <49859>; Thu, 1 Jun 1995 14:11:17 -0700 From: Bill Fenner To: bugs@FreeBSD.org Subject: FTP install failures Message-Id: <95Jun1.141117pdt.49859@crevenia.parc.xerox.com> Date: Thu, 1 Jun 1995 14:11:12 PDT Sender: bugs-owner@FreeBSD.org Precedence: bulk I got the new boot floppies from /pub/FreeBSD/2.0.5-ALPHA/UPDATE, and tried installing on the machine on my desk. After going through and not being completely sure how it was going to deal with my existing partitions (I wasn't really sure what I was supposed to do at the disklabel editing screen; was I supposed to tell it to newfs / and /usr?...), I set the FTP options to username "fenner@ftp.freebsd.org", password "fenner@", and chose the FTP install method. After selecting "other" and typing in "ftp://beta.xerox.com:4514/pub/FreeBSD/2.0.5-ALPHA" as the URL, it mounted and newfs'd my old filesystems and then brought up a dialog that says Invalid URL (`') passed to FTP routines! (must start with `ftp://') ---------------------------------(100%)- EXIT I hit enter, and it brought up another dialog: Invalid URL (`^A') passed to FTP routines! (must start with `ftp://') ---------------------------------(100%)- EXIT I hit enter, and it said that the installation completed successfully. I tried again, after going through the media selection again just in case, and got different garbage: Invalid URL (`it from how eA/'wish^A') passed to FTP routines! (must start with `ftp://') ---------------------------------------------------------(100%)- EXIT and then installation completed successfully (note only one Invalid URL dialog box this time, not two.) I also had a hard time finding the "options" menu; I had forgotten that the install menu was not the root menu and was actually a sub-menu of the "welcome" menu. Perhaps the "FTP options" menu should be located closer to the FTP install option? It's also hard to tell what the current value is when going back to the "FTP options" menu; perhaps a set of radio buttons for the first three options (which seem to be mutually exclusive) and checkboxes for the last two? When I go back to the FTP options menu, and pick "set FTP user and password" again, it asks for the username, and prompts me with a default value of the password I had previously selected -- it looks like both the username and the password got set to the password that I entered. (I typed in username "anonymous@ftp.freebsd.org", password "fenner@", but when I came back the default for username was "fenner@".) About the "Installation Options" -- it seems like most of these things should be checkboxes, not menu items. For example, to make sure that the extra debugging flag is on when you don't know the state, it looks like you need to select "No debugging" and then "Toggle debugging" -- a checkbox makes lots more sense. The "language selection" menu should probably come up with the currently-selected language highlighted, not "danish", since if I go there and hit enter by mistake I will suddenly start getting Danish instructions =) I very much liked the fact that the network setup screen remembered my previous answers, unlike the SNAP install. That helps a lot! Bill From owner-freebsd-bugs Thu Jun 1 14:51:28 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA04954 for bugs-outgoing; Thu, 1 Jun 1995 14:51:28 -0700 Received: (from jkh@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA04929 ; Thu, 1 Jun 1995 14:51:21 -0700 Date: Thu, 1 Jun 1995 14:51:21 -0700 From: "Jordan K. Hubbard" Message-Id: <199506012151.OAA04929@freefall.cdrom.com> To: knarf@nasim.cube.net, jkh, freebsd-bugs Subject: Changed information for PR bin/468 Sender: bugs-owner@FreeBSD.org Precedence: bulk Synopsis: passwd changes wrong password State-Changed-From-To: open-closed State-Changed-By: jkh State-Changed-When: Thu Jun 1 14:50:17 PDT 1995 State-Changed-Why: This is not a bug. su changes only the effective uid, and if you wish to change the password for someone else then this isn't the way to do it. Do a `passwd root' or login to root properly. From owner-freebsd-bugs Thu Jun 1 15:02:33 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id PAA05724 for bugs-outgoing; Thu, 1 Jun 1995 15:02:33 -0700 Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id PAA05717 ; Thu, 1 Jun 1995 15:02:31 -0700 X-Authentication-Warning: freefall.cdrom.com: Host localhost.cdrom.com didn't use HELO protocol To: gwk@cray.com cc: amjudge@dsg.cs.tcd.ie, bugs@FreeBSD.org Subject: Re: Install problem with 2.0.5-ALPHA (UPDATE floppy image) In-reply-to: Your message of "Thu, 01 Jun 95 21:02:32 +0200." <9506011902.AA09513@racer.dkrz.de> Date: Thu, 01 Jun 1995 15:02:29 -0700 Message-ID: <5708.802044149@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: bugs-owner@FreeBSD.org Precedence: bulk > Same for me. And I can't get floppy installation to work. It seems > to try to mount the root.flp floppy, which I have rawritten. Who's > wrong, the machine or me? And I can't get NFS installation to work, Hmmm! Well, if it's trying to mount root.flp then it's definitely not you! :-) Let me look into this. I've just fixed the FTP and DOS installations (knock on wood) and will move to the floppy install next. Now I just need some blank floppies to test on.. :-) > something like permission problems. When the NFS filesystem is > mounted, I cannot even cd into the mountpoint directory, "permission > denied". And I can't get installation from a DOS partition to work, I think you're suffering from a slight change I made to the NFS install semantics. Rather than doing it as a base dir and a prefix, I attempt to mount the target directory directly, that is to say: ziggy:/foo/bar/blatt/FreeBSD Rather than: ziggy:/foo + prefix of /bar/blatt/FreeBSD I know that this makes it a pain for some people who don't have submounts enabled (-alldirs option in FreeBSD) in their exports, but it's comparatively easy to work around and it makes my life a lot easier to not have to keep the extra info around. The new install framework is considerably more generic in its handling of media, but there are certain limitations to it also. I may change this in the future if there is sufficient demand, but for now I recommend simply adding a new export entry for the base directory where you have FreeBSD or enabling subdir mounts. >Guess it's time to give up for today. My previous experience with the >installation menu of 2.0R and various snapshots was not this bad. I'm sorry it's making your life miserable. Please do bear in mind that this was a _total rewrite_ of the install code and as such is going to have some teething troubles. I'm working practically 24 hours a day on fixing it and have already made significant improvements. Please try to be patient! Jordan From owner-freebsd-bugs Thu Jun 1 17:36:34 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id RAA16833 for bugs-outgoing; Thu, 1 Jun 1995 17:36:34 -0700 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id RAA16823 ; Thu, 1 Jun 1995 17:36:33 -0700 Date: Thu, 1 Jun 1995 17:36:33 -0700 Message-Id: <199506020036.RAA16823@freefall.cdrom.com> From: Lapinsky Alexander Reply-To: Lapinsky Alexander To: freebsd-bugs Subject: bin/470: timed & timedc bugs In-Reply-To: Your message of Mon, 20 Mar 1995 21:05:28 +0300 <199503201805.VAA01545@flox.kiam1.rssi.ru> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 470 >Category: bin >Synopsis: timed & timedc bugs >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Jun 1 17:36:30 1995 >Originator: Lapinsky Alexander >Organization: Keldysh Institute of Applied Mathematics, >Organization: Moscow, Russia >Release: FreeBSD 2.0-RELEASE i386 >Environment: >Description: time daemon -- timed: Message displayed: "bind: Can't assign requested address" and very big time difference displayed by timedc clockdiff lotos >How-To-Repeat: I can fix it. I guess, it will be better. >Fix: directory: usr/src/usr.sbin/timed/timed files to patch: measure.c timed.c rebuild: timed timedc -------------------------------- Cut here ---------------------------- *** measure.c.orig Mon Mar 20 16:46:47 1995 --- measure.c Mon Mar 20 20:07:49 1995 *************** *** 151,157 **** */ if (trials < TRIALS) { trials++; ! oicp->icmp_otime = ((tcur.tv_sec % SECDAY) * 1000 + tcur.tv_usec / 1000); oicp->icmp_cksum = 0; oicp->icmp_cksum = in_cksum((u_short*)oicp, --- 151,157 ---- */ if (trials < TRIALS) { trials++; ! oicp->icmp_otime = htonl((tcur.tv_sec % SECDAY) * 1000 + tcur.tv_usec / 1000); oicp->icmp_cksum = 0; oicp->icmp_cksum = in_cksum((u_short*)oicp, *** timed.c.orig Fri Jan 7 18:25:16 1994 --- timed.c Fri Jan 7 18:27:00 1994 *************** *** 312,317 **** --- 312,318 ---- exit(1); } port = srvp->s_port; + bzero(&server,sizeof(struct sockaddr_in)); server.sin_port = srvp->s_port; server.sin_family = AF_INET; sock = socket(AF_INET, SOCK_DGRAM, 0); -------------------------- End of message ---------------------------- >Audit-Trail: >Unformatted: From owner-freebsd-bugs Thu Jun 1 17:38:59 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id RAA16968 for bugs-outgoing; Thu, 1 Jun 1995 17:38:59 -0700 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id RAA16961 ; Thu, 1 Jun 1995 17:38:58 -0700 Date: Thu, 1 Jun 1995 17:38:58 -0700 Message-Id: <199506020038.RAA16961@freefall.cdrom.com> From: kubus@Austran.Unibase.COM Reply-To: kubus@Austran.Unibase.COM To: freebsd-bugs Subject: kern/471: SCSI DDS tape does not work In-Reply-To: Your message of Tue, 23 May 1995 09:41:39 -0600 <199505231541.JAA00945@Austran.Unibase.COM> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 471 >Category: kern >Synopsis: System can not access SCSI DAT tape. >Confidential: no >Severity: critical >Priority: high >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Jun 1 17:38:57 1995 >Originator: Jake J Sadowski >Organization: Home, sweet home. >Release: FreeBSD 2.1.0-Development i386 >Environment: Look at the description, all devices are listed. >Description: /kern: FreeBSD 2.0.950418-SNAP #0: Tue May 23 06:57:31 CST 1995 /kern: root@Austran.Unibase.COM:/usr/src/sys/compile/AUSTRAN /kern: CPU: i486 DX2 (486-class CPU) /kern: Origin = "GenuineIntel" Id = 0x435 Stepping=5 Features=0x3 /kern: real memory = 16384000 (4000 pages) /kern: avail memory = 15257600 (3725 pages) /kern: Probing for devices on the ISA bus: /kern: sc0 at 0x60-0x6f irq 1 on motherboard /kern: sc0: VGA color <16 virtual consoles, flags=0x0> /kern: sio0 at 0x3f8-0x3ff irq 4 on isa /kern: sio0: type 16450 /kern: sio1 at 0x2f8-0x2ff irq 3 on isa /kern: sio1: type 16550A /kern: sio2 at 0x3e8-0x3ef irq 5 on isa /kern: sio2: type 16550A /kern: lpt0 at 0x378-0x37f irq 7 on isa /kern: lpt0: Interrupt-driven port /kern: lp0: TCP/IP capable interface /kern: fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa /kern: fdc0: NEC 765 /kern: fd0: 1.44MB 3.5in /kern: fd1: 1.2MB 5.25in /kern: wdc0 at 0x1f0-0x1f7 irq 14 on isa /kern: wdc0: unit 0 (wd0): /kern: wd0: 813MB (1665216 sectors), 1652 cyls, 16 heads, 63 S/T, 512 B/S /kern: npx0 on motherboard /kern: npx0: INT 16 interface /kern: Probing for devices on the pci0 bus: /kern: configuration mode 1 allows 32 devices. /kern: pci0:0: vendor=0x1080, device=0x600, class=bridge [not supported] /kern: ncr0 rev 2 int a irq 9 on pci0:2 /kern: reg20: virtual=0xf2a91000 physical=0x80000000 size=0x100 /kern: ncr0: restart (scsi reset). /kern: ncr0 scanning for targets 0..6 (V2 pl21 95/03/21) /kern: ncr0 waiting for scsi devices to settle /kern: (ncr0:0:0): 250ns (4 Mb/sec) offset 8. /kern: (ncr0:0:0): "FUJITSU M2263S-512 0189" type 0 fixed SCSI 2 /kern: sd0(ncr0:0:0): Direct-Access 640MB (1312344 512 byte sectors) /kern: (ncr0:6:0): "SONY SDT-5000 3.02" type 1 removable SCSI 2 /kern: st0(ncr0:6:0): Sequential-Access /kern: st0(ncr0:6:0): 200ns (5 Mb/sec) offset 8. /kern: density code 0x13, /kern: ncr0 targ 6?: ERROR (80:140) (e-2e-0) (88/13) @ (3a8:87030000). /kern: reg: da 10 80 13 47 88 6 1f 6 e 86 af 80 0 7 0. /kern: ncr0: restart (fatal error). /kern: /kern: st0(ncr0:6:0): COMMAND FAILED (9 2) @f0503a00. /kern: drive empty /kern: pci0:4: vendor=0x1095, device=0x640, class=storage [not supported] /kern: pci0: uses 256 bytes of memory from 80000000 upto 800000ff. /kern: pci0: uses 256 bytes of I/O space from f000 upto f0ff. I tried the 2.0 release, snap-shots and the most current sources. The tape drive (SONY SDT-5000) works fine with Linux (sorry...) so I do not think that it is any hardware problem. I do not have any access to news, so I do not know if any poor soul already reported any similar problem. I wonder if anyone succeeded with any DAT tape on a NCR53C810 controller. Thanks. ... Jake >How-To-Repeat: It looks rather obvious. >Fix: I wish I knew. >Audit-Trail: >Unformatted: From owner-freebsd-bugs Thu Jun 1 18:40:02 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA21631 for bugs-outgoing; Thu, 1 Jun 1995 18:40:02 -0700 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA21624 ; Thu, 1 Jun 1995 18:40:01 -0700 Date: Thu, 1 Jun 1995 18:40:01 -0700 Message-Id: <199506020140.SAA21624@freefall.cdrom.com> From: Stephen McKay Reply-To: Stephen McKay To: freebsd-bugs Subject: kern/472: bad mount causes panic: ufs_lock In-Reply-To: Your message of Fri, 2 Jun 1995 11:06:11 +1000 <199506020106.LAA00224@stupid.devetir.qld.gov.au> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 472 >Category: kern >Synopsis: 'mount /foo /foo' causes panic: ufs_lock >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Jun 1 18:40:00 1995 >Originator: Stephen McKay >Organization: >Release: FreeBSD 2.0-BUILT-19950510 i386 >Environment: 386SX16 4Mb ram, IDE 80Mb, 10Mb swap FreeBSD-current CTM src-cur 681 (1995-05-31 01:19:48) Perhaps you think of this as 2.0.5-ALPHA. >Description: One hazy afternoon, I mistyped a floppy mount command and got: mount -t msdos /fd0 /fd0 Result: panic: ufs_lock: recursive lock not expected, pid: 267 To be sure of this, I rebooted and tried: mount /fd0 /fd0 Result: panic: ufs_lock: recursive lock not expected, pid: 11 >How-To-Repeat: 'mount /mnt /mnt' should do the trick. >Fix: Unknown. >Audit-Trail: >Unformatted: From owner-freebsd-bugs Thu Jun 1 19:10:10 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id TAA23109 for bugs-outgoing; Thu, 1 Jun 1995 19:10:10 -0700 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id TAA23102 ; Thu, 1 Jun 1995 19:10:07 -0700 Date: Thu, 1 Jun 1995 19:10:07 -0700 Message-Id: <199506020210.TAA23102@freefall.cdrom.com> From: wpaul@ctr.columbia.edu Reply-To: wpaul@ctr.columbia.edu To: freebsd-bugs Subject: bin/473: getpwent.c/NIS bug and fix In-Reply-To: Your message of Thu, 1 Jun 1995 22:06:29 -0400 <199506020206.WAA00680@bootserv.ctr.columbia.edu> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 473 >Category: bin >Synopsis: getpwent.c/NIS bug and fix >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Jun 1 19:10:05 1995 >Originator: Bill Paul >Organization: Center for Telecommunications Research, Columbia University >Release: FreeBSD 2.0-BUILT-19950527 i386 >Environment: FreeBSD 2.0.5-ALPHA i386sx/16Mhz system with 387sx FPU 4 MB RAM 20 MB XT-class hard disk generic VGA 3c503 ethernet (8-bit) >Description: The +@netgroup/-@netgroup NIS password overrides can fail in some cases due to a subtle bug. Specifically, if you override an NIS user's shell, /usr/bin/login and /usr/bin/su (and probably other commands) can end up with bogus data for the pw_shell member of the passwd structure *if* the do an endpwent(), thereby preventing logins. This happpens because the text fields in the passwd structure (pw_name, pw_passwd, pw_gecos, pw_class, pw_dir and pw_shell) are returned to the calling program as pointers to dycamically allocated buffers, rather than pointers to static buffers as they should be. Once endpwent() is called, the dynamic buffers are free()ed, which invalidates the data returned by the library functions. >How-To-Repeat: 1) enable NIS 2) put an entry in the master.passwd file that overrides the shell field for a user in the NIS database, like this: +testuser:::::::::/bin/csh 3) attempt to login as user 'testuser'. The result will be that /usr/bin/login will end up with some random value for pw_shell and the login will fail. >Fix: This is a context diff for /usr/src/lib/libc/gen/getpwent.c that fixes the problem. A more elegant solution would be preferable, and I intend implement one for 2.1 just as soon as the code lockout for 2.0.5 is lifted. *** getpwent.c.orig Thu Jun 1 21:16:00 1995 --- getpwent.c Thu Jun 1 21:20:01 1995 *************** *** 496,501 **** --- 496,510 ---- _pw_breakout_yp(struct passwd *pw, char *result, int master) { char *s; + static char name[UT_NAMESIZE+2], passwd[_PASSWORD_LEN], class[1024]; + static char gecos[1024], dir[MAXPATHLEN], shell[MAXPATHLEN]; + + strcpy(name, pw->pw_name); pw->pw_name = (char *)&name; + strcpy(passwd, pw->pw_passwd); pw->pw_passwd = (char *)&passwd; + strcpy(class, pw->pw_class); pw->pw_class = (char *)&class; + strcpy(gecos, pw->pw_gecos); pw->pw_gecos = (char *)&gecos; + strcpy(dir, pw->pw_dir); pw->pw_dir = (char *)&dir; + strcpy(shell, pw->pw_shell); pw->pw_shell = (char *)&shell; s = strsep(&result, ":"); /* name */ if(!(pw->pw_fields & _PWF_NAME) || (pw->pw_name[0] == '+')) { >Audit-Trail: >Unformatted: From owner-freebsd-bugs Thu Jun 1 19:20:07 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id TAA23777 for bugs-outgoing; Thu, 1 Jun 1995 19:20:07 -0700 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id TAA23770 ; Thu, 1 Jun 1995 19:20:05 -0700 Date: Thu, 1 Jun 1995 19:20:05 -0700 Message-Id: <199506020220.TAA23770@freefall.cdrom.com> From: wpaul@ctr.columbia.edu Reply-To: wpaul@ctr.columbia.edu To: freebsd-bugs Subject: gnu/474: typos in /usr/src/gnu/usr.bin/yppush/yppush.c In-Reply-To: Your message of Thu, 1 Jun 1995 22:16:35 -0400 <199506020216.WAA00800@bootserv.ctr.columbia.edu> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 474 >Category: gnu >Synopsis: typos in /usr/src/gnu/usr.bin/yppush/yppush.c >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Jun 1 19:20:03 1995 >Originator: Bill Paul >Organization: Center for Telecommunications Research, Columbia University >Release: FreeBSD 2.0-BUILT-19950527 i386 >Environment: FreeBSD 2.0.5-ALPHA >Description: There are some embarassing typos (which I made) in yppush.c. Some fprintf()s are improperly formatted as a result. >How-To-Repeat: Pay careful attention while reading the yppush.c source. >Fix: This is a unified diff to /usr/src/gnu/usr.bin/yppush/yppush.c that corrects the typos. --- yppush.c.orig Tue May 30 22:19:33 1995 +++ yppush.c Tue May 30 22:21:50 1995 @@ -203,7 +203,7 @@ perror("svc_run: - select failed"); return; case 0: - fprintf(stderr, "%sh: callback timed out\n, progname"); + fprintf(stderr, "%s: callback timed out\n", progname); exit(0); default: svc_getreqset(&readfds); @@ -421,16 +421,16 @@ if (DomainName==NULL) { if (yp_get_default_domain(&DomainName)!=0) { - fprintf(stderr, "%s: cannot get default domain\n, - progname"); + fprintf(stderr, "%s: cannot get default domain\n", + progname); exit(1); } } ThisHost=getHostName(); if (ThisHost==NULL) { - fprintf(stderr, "%s: cannot determine local hostname\n, - progname"); + fprintf(stderr, "%s: cannot determine local hostname\n", + progname); exit(1); } >Audit-Trail: >Unformatted: From owner-freebsd-bugs Thu Jun 1 22:10:02 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA03853 for bugs-outgoing; Thu, 1 Jun 1995 22:10:02 -0700 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA03846 ; Thu, 1 Jun 1995 22:10:01 -0700 Date: Thu, 1 Jun 1995 22:10:01 -0700 Message-Id: <199506020510.WAA03846@freefall.cdrom.com> From: Noses Reply-To: Noses To: freebsd-bugs Subject: kern/475: can't compile a kernel In-Reply-To: Your message of Fri, 2 Jun 1995 07:05:44 +0200 <199506020505.HAA16043@oink.rhein.de> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 475 >Category: kern >Synopsis: can't compile a kernel >Confidential: yes >Severity: critical >Priority: high >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Jun 1 22:10:00 1995 >Originator: Noses >Organization: >Release: FreeBSD 2.0-RELEASE i386 >Environment: unmodified 2.0.5-ALPHA source >Description: My configuration: machine "i386" cpu "I486_CPU" # # This is the ``identification'' of the kernel. Usually this should # be the same as the name of your kernel. # ident INTELLIGENCE # # The `maxusers' parameter controls the static sizing of a number of # internal system tables by a complicated formula defined in param.c. # maxusers 32 # # Under some circumstances it is necessary to make the default max # number of processes per user and open files per user more than the # defaults on bootup. (an example is a large news server in which # the uid, news, can sometimes need > 100 simultaneous processes running) options "CHILD_MAX=256" options "OPEN_MAX=256" # # A math emulator is mandatory if you wish to run on hardware which # does not have a floating-point processor. Pick either the original, # bogus (but freely-distributable) math emulator, or a much more # fully-featured but GPL-licensed emulator taken from Linux. # #options MATH_EMULATE #Support for x87 emulation #options GPL_MATH_EMULATE #Support for x87 emualtion via #new math emulator # # This directive defines a number of things: # - The compiled kernel is to be called `kernel' # - The root filesystem might be on partition wd0a # - Crash dumps will be written to wd0b, if possible. Specifying the # dump device here is not recommended. Use dumpon(8). # config kernel root on sd0 swap on sd0 dumps on sd0 ##################################################################### # COMPATIBILITY OPTIONS # # Implement system calls compatible with 4.3BSD and older versions of # FreeBSD. # options "COMPAT_43" # # Allow user-mode programs to manipulat their local descriptor tables. # This option is required for the WINE Windows(tm) emulator, and is # not used by anything else (that we know of). # #options USER_LDT #allow user-level control of i386 ldt # # These three options provide support for System V Interface # Definition-style interprocess communication, in the form of shared # memory, semaphores, and message queues, respectively. # options SYSVSHM options SYSVSEM options SYSVMSG ##################################################################### # DEBUGGING OPTIONS # # Enable the kernel debugger. # #options DDB # # KTRACE enables the system-call tracing facility ktrace(2). # options KTRACE #kernel tracing # # The DIAGNOSTIC option is used in a number of source files to enable # extra sanity checking of internal structures. This support is not # enabled by default because of the extra time it would take to check # for these conditions, which can only occur as a result of # programming errors. # #options DIAGNOSTIC # # Allow ordinary users to take the console - this is useful for X. #options UCONSOLE ##################################################################### # NETWORKING OPTIONS # # Protocol families: # Only the INET (Internet) family is officially supported in FreeBSD. # Source code for the NS (Xerox Network Service), ISO (OSI), and # CCITT (X.25) families is provided for amusement value, although we # try to ensure that it actually compiles. # options INET #Internet communications protocols #options CCITT #X.25 network layer #options NS #Xerox NS communications protocols # These are currently broken and don't compile #options ISO #options TPIP #ISO TP class 4 over IP #options TPCONS #ISO TP class 0 over X.25 # # Network interfaces: # The `loop' pseudo-device is mandatory when networking is enabled. # The `ether' pseudo-device provides generic code to handle # Ethernets; it is mandatory when a Ethernet device driver is # configured. # The 'fddi' pseudo-device provides generic code to support FDDI. # The `sppp' pseudo-device serves a similar role for certain types # of synchronous PPP links (like `cx'). # The `sl' pseudo-device implements the Serial Line IP (SLIP) service. # The `ppp' pseudo-device implements the Point-to-Point Protocol. # The `bpfilter' pseudo-device enables the Berkeley Packet Filter. Be # aware of the legal and administrative consequences of enabling this # option. The number of devices determines the maximum number of # simultaneous BPF clients programs runnable. # The `disc' pseudo-device implements a minimal network interface, # which throws away all packets sent and never receives any. It is # included for testing purposes. # The `tun' pseudo-device implements the User Process PPP (iijppp) # pseudo-device ether #Generic Ethernet #pseudo-device fddi #Generic FDDI #pseudo-device sppp #Generic Synchronous PPP pseudo-device loop #Network loopback device pseudo-device sl 4 #Serial Line IP pseudo-device ppp 4 #Point-to-point protocol pseudo-device bpfilter 9 #Berkeley packet filter pseudo-device disc #Discard device pseudo-device tun 4 #Tunnel driver(user process ppp) #options NSIP #XNS over IP #options LLC #X.25 link layer for Ethernets #options HDLC #X.25 link layer for serial lines # broken #options EON #ISO CLNP over IP # # Internet family options: # # TCP_COMPAT_42 causes the TCP code to emulate certain bugs present in # 4.2BSD. This option should not be used unless you have a 4.2BSD # machine and TCP connections fail. # # GATEWAY allows the machine to forward packets, and also configures # larger static sizes of a number of system tables. # # MROUTING enables the kernel multicast packet forwarder, which works # with mrouted(8). # # IPFIREWALL enables support for IP firewall construction, in # conjunction with the `ipfw' program. IPFIREWALL_VERBOSE does # the obvious thing. # IPACCT enables IP accounting. # # ARP_PROXYALL enables global proxy ARP. Beware! This can burn # your house down! See netinet/if_ether.c for the gory details. # (Eventually there will be a better management interface.) # options "TCP_COMPAT_42" #emulate 4.2BSD TCP bugs options GATEWAY #internetwork gateway options MROUTING # Multicast routing options IPFIREWALL #firewall options IPFIREWALL_VERBOSE #print information about options IPACCT #ipaccounting # dropped packets options ARP_PROXYALL # global proxy ARP ##################################################################### # FILESYSTEM OPTIONS # # Only the root, /usr, and /tmp filesystems need be statically # compiled; everything else will be automatically loaded at mount # time. (Exception: the UFS family---FFS, MFS, and LFS---cannot # currently be demand-loaded.) Some people still prefer to statically # compile other filesystems as well. # # NB: The LFS, PORTAL, and UNION filesystems are known to be buggy, # and WILL panic your system if you attempt to do anything with them. # They are included here as an incentive for some enterprising soul to # sit down and fix them. # # Note: 4.4BSD NQNFS lease checking has relatively high cost for # _local_ I/O as well as remote I/O. Don't use it unless you will # using NQNFS. # # One of these is mandatory: options FFS #Fast filesystem options NFS #Network File System # The rest are optional: #options NQNFS #Enable NQNFS lease checking #options "CD9660" #ISO 9660 filesystem options FDESC #File descriptor filesystem options KERNFS #Kernel filesystem #options LFS #Log filesystem options MFS #Memory File System options MSDOSFS #MS DOS File System options NULLFS #NULL filesystem options PORTAL #Portal filesystem options PROCFS #Process filesystem options UMAPFS #UID map filesystem options UNION #Union filesystem # Make space in the kernel for a MFS rootfilesystem. Define to the number # of kilobytes to reserve for the filesystem. #options "MFS_ROOT=10" # Allow this many swap-devices. options "NSWAPDEV=4" # Disk quotas are supported when this option is enabled. If you # change the value of this option, you must do a `make clean' in your # kernel compile directory in order to get a working kernel. # options QUOTA #enable disk quotas ##################################################################### # SCSI DEVICES # SCSI DEVICE CONFIGURATION # The SCSI subsystem consists of the `base' SCSI code, a number of # high-level SCSI device `type' drivers, and the low-level host-adapter # device drivers. The host adapters are listed in the ISA and PCI # device configuration sections below. # # Beginning with FreeBSD 2.0.5 you can wire down your SCSI devices so # that a given bus, target, and LUN always come on line as the same # device unit. In earlier versions the unit numbers were assigned # in the order that the devices were probed on the SCSI bus. This # means that if you removed a disk drive, you may have had to rewrite # your /etc/fstab file, and also that you had to be careful when adding # a new disk as it may have been probed earlier and moved your device # configuration around. # This old behavior is maintained as the default behavior. The unit # assignment begins with the first non-wired down unit for a device # type. For example, if you wire a disk as "sd3" then the first # non-wired disk will be assigned sd4. # The syntax for wiring down devices is: # disk sd0 at scbus0 target 0 unit 0 # disk sd1 at scbus0 target 1 # disk sd2 at scbus0 target 3 # tape st1 at scbus0 target 6 # device cd0 at scbus? # "units" (SCSI logical unit number) that are not specified are # treated as if specified as LUN 0. # All SCSI devices allocate as many units as are required. # The "unknown" device (uk? in pre-2.0.5) is now part of the base SCSI # configuration and doesn't have to be explicitly configured. controller scbus0 #base SCSI code #device ch0 #SCSI media changers device sd0 #SCSI disks device st0 #SCSI tapes #device cd0 #SCSI CD-ROMs # The previous devices (ch, sd, st, cd) are recognized by config. # config doesn't (and shouldn't) know about these newer ones, # so we have to specify that they are on a SCSI bus with the "at scbus?" # clause. #device worm0 at scbus? # SCSI worm #device pt0 at scbus? # SCSI processor type #device sctarg0 at scbus? # SCSI target # SCSI OPTIONS: # SCSIDEBUG: When defined enables debugging macros # NO_SCSI_SENSE: When defined disables sense descriptions (about 4k) # SCSI_REPORT_GEOMETRY: Always report disk geometry at boot up instead # of only when booting verbosely. #options SCSIDEBUG #options NO_SCSI_SENSE #options SCSI_REPORT_GEOMETRY ##################################################################### # MISCELLANEOUS DEVICES AND OPTIONS # # Of these, only the `log' device is truly mandatory. The `pty' # device usually turns out to be ``effectively mandatory'', as it is # required for `telnetd', `rlogind', `screen', `emacs', and `xterm', # among others. The `isdn', `ii', `ity', `itel', and `ispy' devices # are all required when ISDN support is used. # pseudo-device pty 64 #Pseudo ttys - can go as high as 64 pseudo-device speaker #Play IBM BASIC-style noises out your speaker pseudo-device log #Kernel syslog interface (/dev/klog) pseudo-device gzip #Exec gzipped a.out's pseudo-device vn #Vnode driver (turns a file into a device) pseudo-device snp 8 #Snoop device - to look at pty/vty/etc.. # These are non-optional for ISDN #pseudo-device isdn #pseudo-device ii 4 #pseudo-device ity 4 #pseudo-device itel 2 #pseudo-device ispy 1 ##################################################################### # HARDWARE DEVICE CONFIGURATION # ISA and EISA devices: # Currently there is no separate support for EISA. There should be. # Micro Channel is not supported at all. # # Mandatory ISA devices: isa, sc or vt, npx # controller isa0 # # Options for `isa': # # AUTO_EOI_1 enables the `automatic EOI' feature for the master 8259A # interrupt controller. This saves about 1.25 usec for each interrupt. # No problems are known to be caused by this option. # # AUTO_EOI_2 enables the `automatic EOI' feature for the slave 8259A # interrupt controller. This saves about 1.25 usec for each interrupt. # Automatic EOI is documented not to work for for the slave with the # original i8259A, but it works for some clones and some integrated # versions. # # BOUNCE_BUFFERS provides support for ISA DMA on machines with more # than 16 megabytes of memory. It doesn't hurt on other machines. # Some broken EISA and VLB hardware may need this, too. # # DUMMY_NOPS disables extra delays for some bus operations. The delays # are mostly for older systems and aren't used consistently. Probably # works OK on most EISA bus machines. # # TUNE_1542 enables the automatic ISA bus speed selection for the # Adaptec 1542 boards. Does not work for all boards, use it with caution. # # BROKEN_KEYBOARD_RESET disables the use of the keyboard controller to # reset the CPU for reboot. This is needed on some systems with broken # keyboard controllers. options "AUTO_EOI_1" #options "AUTO_EOI_2" options BOUNCE_BUFFERS #options DUMMY_NOPS #options "TUNE_1542" #options "BROKEN_KEYBOARD_RESET" # Enable this and PCVT_FREEBSD for pcvt vt220 compatible console driver device vt0 at isa? port "IO_KBD" tty irq 1 vector pcrint options "PCVT_FREEBSD=210" # pcvt running on FreeBSD 2.0.5 #options XSERVER # include code for XFree86 #options FAT_CURSOR # start with block cursor # The syscons console driver (sco color console compatible) - default. #device sc0 at isa? port "IO_KBD" tty irq 1 vector scintr # # Options for `sc': # # HARDFONTS allows the driver to load an ISO-8859-1 font to replace # the default font in your display adapter's memory. # options HARDFONTS # # MAXCONS is maximum number of virtual consoles, no more than 16 # default value: 12 # options "MAXCONS=12" device npx0 at isa? port "IO_NPX" irq 13 vector npxintr # # Optional ISA and EISA devices: # # # SCSI host adapters: `aha', `ahb', `aic', `bt', `nca' # # aha: Adaptec 154x # ahb: Adaptec 174x # ahc: Adaptec 274x/284x/294x # aic: Adaptec 152x and sound cards using the Adaptec AIC-6360 (slow!) # bt: Most Buslogic controllers # nca: ProAudioSpectrum cards using the NCR 5380 or Trantor T130 # uha: UltraStore 14F and 34F # sea: Seagate ST01/02 8 bit controller (slow!) # wds: Western Digital WD7000 controller (no scatter/gather!). # # Note that the order is important in order for Buslogic cards to be # probed correctly. # #controller bt0 at isa? port "IO_BT0" bio irq ? vector btintr #controller ahc0 at isa? bio irq ? vector ahcintr # port??? iomem? #controller ahb0 at isa? bio irq ? vector ahbintr controller aha0 at isa? port "IO_AHA0" bio irq ? drq 5 vector ahaintr #controller uha0 at isa? port "IO_UHA0" bio irq ? drq 5 vector uhaintr #controller aic0 at isa? port 0x340 bio irq 11 vector aicintr #controller nca0 at isa? port 0x1f88 bio irq 10 vector ncaintr #controller nca1 at isa? port 0x1f84 #controller nca2 at isa? port 0x1f8c #controller nca3 at isa? port 0x1e88 #controller nca4 at isa? port 0x350 bio irq 5 vector ncaintr #controller sea0 at isa? bio irq 5 iomem 0xdc000 iosiz 0x2000 vector seaintr #controller wds0 at isa? port 0x350 bio irq 15 drq 6 vector wdsintr # # ST-506, ESDI, and IDE hard disks: `wdc' and `wd' # # NB: ``Enhanced IDE'' is NOT supported at this time. # # The flags fields are used to enable the multi-sector I/O and # the 32BIT I/O modes. The flags may be used in either the controller # definition or in the individual disk definitions. The controller # definition is supported for the boot configuration stuff. # # Each drive has a 16 bit flags value defined: # The low 8 bits are the maximum value for the multi-sector I/O, # where 0xff defaults to the maximum that the drive can handle. # The high bit of the 16 bit flags (0x8000) allows probing for # 32 bit transfers. # # The flags field for the drives can be specified in the controller # specification with the low 16 bits for drive 0, and the high 16 bits # for drive 1. # e.g.: #controller wdc0 at isa? port "IO_WD1" bio irq 14 flags 0x00ff8004 vector wdintr # # specifies that drive 0 will be allowed to probe for 32 bit transfers and # a maximum multi-sector transfer of 4 sectors, and drive 1 will not be # allowed to probe for 32 bit transfers, but will allow multi-sector # transfers up to the maximum that the drive supports. # # #controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr #disk wd0 at wdc0 drive 0 #disk wd1 at wdc0 drive 1 #controller wdc1 at isa? port "IO_WD2" bio irq 15 vector wdintr #disk wd2 at wdc1 drive 0 #disk wd3 at wdc1 drive 1 # # Standard floppy disk controllers and floppy tapes: `fdc', `fd', and `ft' # controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr # # Activate this line instead of the fdc0 line above if you happen to # have an Insight floppy tape. Probing them proved to be dangerous # for people with floppy disks only, so it's "hidden" behind a flag: #controller fdc0 at isa? port "IO_FD1" bio flags 1 irq 6 drq 2 vector fdintr disk fd0 at fdc0 drive 0 disk fd1 at fdc0 drive 1 #tape ft0 at fdc0 drive 2 # # Options for `fd': # # FDSEEKWAIT selects a non-default head-settle time (i.e., the time to # wait after a seek is performed). The default value (1/32 s) is # usually sufficient. The units are inverse seconds, so a value of 16 # here means to wait 1/16th of a second; you should choose a power of # two. # options FDSEEKWAIT="32" # # Other standard PC hardware: `lpt', `mse', `psm', `sio', etc. # # lpt: printer port # mse: Logitech and ATI InPort bus mouse ports # psm: PS/2 mouse port [note: conflicts with sc0/vt0, thus "conflicts" keywd] # sio: serial ports (see sio(4)) device lpt0 at isa? port "IO_LPT3" tty irq 7 vector lptintr #device mse0 at isa? port 0x23c tty irq 5 vector mseintr #device psm0 at isa? port "IO_KBD" conflicts tty irq 12 vector psmintr device sio0 at isa? port "IO_COM1" tty irq 4 vector siointr device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr device sio2 at isa? port "IO_COM3" tty irq 5 vector siointr device sio3 at isa? port "IO_COM4" tty irq 9 vector siointr # Options for sio: #options COMCONSOLE #prefer serial console to video console #options COM_MULTIPORT #code for some cards with shared IRQs #options DSI_SOFT_MODEM #code for DSI Softmodems #options BREAK_TO_DEBUGGER #a BREAK on a comconsole goes to #DDB, if available. # # Network interfaces: `cx', `ed', `el', `ep', `ie', `is', `le', `lnc' # # cx: Cronyx/Sigma multiport sync/async (with Cisco or PPP framing) # ed: Western Digital and SMC 80xx; Novell NE1000 and NE2000; 3Com 3C503 # el: 3Com 3C501 (slow!) # ep: 3Com 3C509 (buggy) # fe: Fujitsu MB86960A/MB86965A Ethernet # fea: DEC DEFEA EISA FDDI adapter # ie: AT&T StarLAN 10 and EN100; 3Com 3C507; unknown NI5210 # le: Digital Equipment EtherWorks 2 and EtherWorks 3 (DEPCA, DE100, # DE101, DE200, DE201, DE202, DE203, DE204, DE205, DE422) # lnc: Lance/PCnet cards (Isolan, Novell NE2100, NE32-VL) # ze: IBM/National Semiconductor PCMCIA ethernet controller. # zp: 3Com PCMCIA Etherlink III (It does not require shared memory for # send/receive operation, but it needs 'iomem' to read/write the # attribute memory) # device ed0 at isa? port 0x300 net irq 10 iomem 0xd8000 vector edintr # # ISDN drivers - `isdn'. # # Uncomment one (and only one) of the following two drivers for the appropriate # ISDN device you have. For more information on what's considered appropriate # for your given set of circumstances, please read # /usr/src/gnu/usr.sbin/docs/INSTALL. It's a bit sparse at present, but it's # the best we have right now. The snic driver is also disabled at present, # waiting for someone to upgrade the driver to 2.0 (it's in /sys/gnu/scsi/). # #device nic0 at isa? port "IO_COM3" iomem 0xe0000 tty irq 9 vector nicintr #device nnic0 at isa? port 0x150 iomem 0xe0000 tty irq 12 vector nnicintr # # Audio drivers: `snd', `sb', `pas', `gus', `pca' # # snd: Voxware sound support code # sb: SoundBlaster PCM - SoundBlaster, SB Pro, SB16, ProAudioSpectrum # sbxvi: SoundBlaster 16 # sbmidi: SoundBlaster 16 MIDI interface # pas: ProAudioSpectrum PCM and MIDI # gus: Gravis Ultrasound - Ultrasound, Ultrasound 16, Ultrasound MAX # gusxvi: Gravis Ultrasound 16-bit PCM # gusmax: Gravis Ultrasound MAX (currently broken) # mss: Microsoft Sound System # opl: Yamaha OPL-2 and OPL-3 FM - SB, SB Pro, SB 16, ProAudioSpectrum # uart: stand-alone 6850 UART for MIDI # mpu: Roland MPU-401 stand-alone card # # Beware! The addresses specified below are also hard-coded in # i386/isa/sound/sound_config.h. If you change the values here, you # must also change the values in the include file. # # pca: PCM audio through your PC speaker # # If you don't have a lpt0 device at IRQ 7, you can remove the # ``conflicts'' specification in the appropriate device entries below. # # Controls all sound devices #controller snd0 #device sb0 at isa? port 0x220 irq 7 conflicts drq 1 vector sbintr #device sbxvi0 at isa? drq 5 #device sbmidi0 at isa? port 0x330 #device pas0 at isa? port 0x388 irq 10 drq 6 vector pasintr #device gus0 at isa? port 0x220 irq 11 drq 1 vector gusintr #device gusxvi0 at isa? port 0x530 irq 7 conflicts drq 3 vector adintr #device gusmax0 at isa? port 0x32c #device mss0 at isa? port 0x530 irq 10 drq 1 vector adintr #device opl0 at isa? port 0x388 #device mpu0 at isa? port 0x330 irq 6 drq 0 #device uart0 at isa? port 0x330 irq 5 vector "m6850intr" # Not controlled by `snd' device pca0 at isa? port IO_TIMER1 tty # # Miscellaneous hardware: `mcd', `wt', `ctx', `apm' # # mcd: Mitsumi CD-ROM # scd: Sony CD-ROM # matcd: Matsushita/Panasonic CD-ROM # wt: Wangtek and Archive QIC-02/QIC-36 tape drives # ctx: Cortex-I frame grabber # apm: Laptop Advanced Power Management (experimental) # spigot: The Creative Labs Video Spigot video-aquisition board # cy: Cyclades high-speed serial driver (ALPHA QUALITY!) # gp: National Instruments AT-GPIB and AT-GPIB/TNT board # gsc: Genius GS-4500 hand scanner. # joy: joystick # labpc: National Instrument's Lab-PC and Lab-PC+ # rc: RISCom/8 multiport card # # Notes on the spigot: # The video spigot is at 0xad6. This port address can not be changed. # The irq values may only be 10, 11, or 15 # I/O memory is an 8kb region. Possible values are: # 0a0000, 0a2000, ..., 0fffff, f00000, f02000, ..., ffffff # Note that the start address must be on an even boundary. #device mcd0 at isa? port 0x300 bio irq 10 vector mcdintr # for the Sony CDU31/33A CDROM #device scd0 at isa? port 0x230 bio # for the soundblaster 16 multicd - up to 4 devices #controller matcd0 at isa? port ? bio #device wt0 at isa? port 0x300 bio irq 5 drq 1 vector wtintr #device ctx0 at isa? port 0x230 iomem 0xd0000 #device spigot0 at isa? port 0xad6 irq 15 iomem 0xee000 vector spigintr #device apm0 at isa? #device gp0 at isa? port 0x2c0 tty #device gsc0 at isa? port "IO_GSC1" tty drq 3 #device joy0 at isa? port "IO_GAME" #device cy0 at isa? tty irq 10 iomem 0xd4000 vector cyintr #device labpc0 at isa? port 0x260 tty irq 5 vector labpcintr #device rc0 at isa? port 0x220 tty irq 12 vector rcintr # # PCI devices: # # The main PCI bus device is `pci'. It provides auto-detection and # configuration support for all devices on the PCI bus, using either # configuration mode defined in the PCI specification. # # The `ncr' device provides support for the NCR 53C810 and 53C825 # self-contained SCSI host adapters. # # The `de' device provides support for the Digital Equipment DC21040 # self-contained Ethernet adapter. # # The `fpa' device provides support for the Digital DEFPA PCI FDDI # adapter. pseudo-device fddi is also needed. # # The PROBE_VERBOSE option enables a long listing of chip set registers # for supported PCI chip sets (currently only intel Saturn and Mercury). # #controller pci0 #device ncr0 #device de0 #device fpa0 #options PROBE_VERBOSE After compiling this the structure swdevt is duplicated. >How-To-Repeat: config INTELLIGENCE; make it >Fix: Disable the following section of code in swapkernel.c (automatically generated file): #if 0 struct swdevt swdevt[] = { { makedev(4, 0x00000001), 0, 0 }, /* sd0b */ { NODEV, 0, 0 }, /* for NFS diskless */ { NODEV, 0, 0 } }; #endif I guess someone forgot something somewhere. Achim >Audit-Trail: >Unformatted: From owner-freebsd-bugs Thu Jun 1 22:30:21 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA04323 for bugs-outgoing; Thu, 1 Jun 1995 22:30:21 -0700 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id WAA04315 for ; Thu, 1 Jun 1995 22:30:18 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id WAA06642; Thu, 1 Jun 1995 22:29:54 -0700 From: "Rodney W. Grimes" Message-Id: <199506020529.WAA06642@gndrsh.aac.dev.com> Subject: Re: kern/475: can't compile a kernel To: noses@oink.rhein.de Date: Thu, 1 Jun 1995 22:29:54 -0700 (PDT) Cc: freebsd-bugs@freefall.cdrom.com In-Reply-To: <199506020510.WAA03846@freefall.cdrom.com> from "Noses" at Jun 1, 95 10:10:01 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: 524 Sender: bugs-owner@FreeBSD.org Precedence: bulk ... > Disable the following section of code in swapkernel.c (automatically > generated file): > > #if 0 > struct swdevt swdevt[] = { > { makedev(4, 0x00000001), 0, 0 }, /* sd0b */ > { NODEV, 0, 0 }, /* for NFS diskless */ > { NODEV, 0, 0 } > }; > #endif > > I guess someone forgot something somewhere. Yes, you did, you forgot to recompile and install config!!! -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-bugs Thu Jun 1 22:57:59 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA06150 for bugs-outgoing; Thu, 1 Jun 1995 22:57:59 -0700 Received: (from gibbs@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA06135 ; Thu, 1 Jun 1995 22:57:58 -0700 Date: Thu, 1 Jun 1995 22:57:58 -0700 From: "Justin T. Gibbs" Message-Id: <199506020557.WAA06135@freefall.cdrom.com> To: noses@oink.rhein.de, gibbs, freebsd-bugs Subject: Changed information for PR kern/475 Sender: bugs-owner@FreeBSD.org Precedence: bulk Synopsis: can't compile a kernel State-Changed-From-To: open-closed State-Changed-By: gibbs State-Changed-When: Thu Jun 1 22:56:25 PDT 1995 State-Changed-Why: This is not a bug, but an incompatibility with old versions of config. Rebuilding config with 2.0.5A or later sources should cure the problem. From owner-freebsd-bugs Fri Jun 2 00:20:03 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA10802 for bugs-outgoing; Fri, 2 Jun 1995 00:20:03 -0700 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA10791 ; Fri, 2 Jun 1995 00:20:02 -0700 Date: Fri, 2 Jun 1995 00:20:02 -0700 Message-Id: <199506020720.AAA10791@freefall.cdrom.com> From: Jeffrey Hsu Reply-To: Jeffrey Hsu To: freebsd-bugs Subject: bin/476: kvm_openfiles called w/ too small error buffer In-Reply-To: Your message of Fri, 2 Jun 1995 00:15:06 -0700 <199506020715.AAA10426@freefall.cdrom.com> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 476 >Category: bin >Synopsis: kvm_openfiles called w/ too small error buffer >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Jun 2 00:20:00 1995 >Originator: Jeffrey & >Organization: >Release: FreeBSD 2.1.0-Development i386 >Environment: FreeBSD-current >Description: bin/ps.c calls kvm_openfiles w/ errbuf[256] while the man page for kvm_openfiles says the size of the error buffer should be _POSIX2_LINE_MAX, which is 2048. >How-To-Repeat: Eyeball the code. >Fix: Change 256 to _POSIX2_LINE_MAX. Or change documentation, whichever is appropriate. >Audit-Trail: >Unformatted: From owner-freebsd-bugs Fri Jun 2 00:34:26 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA11966 for bugs-outgoing; Fri, 2 Jun 1995 00:34:26 -0700 Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id AAA11958 for ; Fri, 2 Jun 1995 00:34:25 -0700 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.11/8.6.9) id AAA03141; Fri, 2 Jun 1995 00:34:12 -0700 Date: Fri, 2 Jun 1995 00:34:12 -0700 Message-Id: <199506020734.AAA03141@silvia.HIP.Berkeley.EDU> To: paepcke@arcway.snafu.de CC: freebsd-bugs@freefall.cdrom.com In-reply-to: <199506011110.EAA12955@freefall.cdrom.com> (paepcke@arcway.snafu.de) Subject: Re: ports/467: utils/kp wrong distfile place after make fetch From: asami@CS.Berkeley.EDU (Satoshi Asami) Sender: bugs-owner@FreeBSD.org Precedence: bulk * ports/utils/kp put the distfile after make [fetch] to * /pub/kp-0.95.tar.gz ... should be ports/distfiles/kp-0.95.tar.gz Sorry, I can't reproduce it around here. kp isn't doing anything fancy, it is a standard "port" and it's ncftp that's doing the fetch, and it's doing it after cd'ing to ${DISTDIR}. Are you sure you don't have DISTDIR set to /pub or something? Also, what version of /usr/share/mk/bsd.port.mk do you have? The latest one is 1.163 (look in the $Id$ string). Satoshi From owner-freebsd-bugs Fri Jun 2 02:40:02 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id CAA17860 for bugs-outgoing; Fri, 2 Jun 1995 02:40:02 -0700 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id CAA17853 ; Fri, 2 Jun 1995 02:40:01 -0700 Date: Fri, 2 Jun 1995 02:40:01 -0700 Message-Id: <199506020940.CAA17853@freefall.cdrom.com> From: Anthony Graphics Reply-To: Anthony Graphics To: freebsd-bugs Subject: bin/477: bugs in telnet client In-Reply-To: Your message of Fri, 2 Jun 1995 13:32:38 +0400 <199506020932.NAA02432@ns2.redline.ru> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 477 >Category: bin >Synopsis: telnet autologin ain't working >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Jun 2 02:40:00 1995 >Originator: Anthony Graphics >Organization: REDLINE >Release: FreeBSD 2.1.0-Development i386 >Environment: >Description: I'm trying to telnet to mail.redline.ru (that is machine running linux 1.2.8) with the command: telnet -l agl -8 -a 194.87.69.17 and I'm getting login: prompt instead of the password: however I'm getting Password: prompt when telnetting from OSF/1 t3.0b-3 box, so I think telnetd daemon is working properly in linux. _And_ I'm getting password when logging with 'telnet -a' from linux to osf/1 and get login prompt when logging from fbsd to osf/1, see? >How-To-Repeat: telnet -l agl 194.87.69.17 >Fix: have no idea >Audit-Trail: >Unformatted: From owner-freebsd-bugs Fri Jun 2 04:25:32 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id EAA23177 for bugs-outgoing; Fri, 2 Jun 1995 04:25:32 -0700 Received: (from davidg@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id EAA23161 ; Fri, 2 Jun 1995 04:25:31 -0700 Date: Fri, 2 Jun 1995 04:25:31 -0700 From: David Greenman Message-Id: <199506021125.EAA23161@freefall.cdrom.com> To: wpaul@ctr.columbia.edu, davidg, freebsd-bugs Subject: Changed information for PR bin/473 Sender: bugs-owner@FreeBSD.org Precedence: bulk Synopsis: getpwent.c/NIS bug and fix State-Changed-From-To: open-closed State-Changed-By: davidg State-Changed-When: Fri Jun 2 04:23:47 PDT 1995 State-Changed-Why: Fixed in rev 1.23.2.1 by applying Bill's suggested fix. From owner-freebsd-bugs Fri Jun 2 04:28:38 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id EAA23423 for bugs-outgoing; Fri, 2 Jun 1995 04:28:38 -0700 Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id EAA23411 ; Fri, 2 Jun 1995 04:28:35 -0700 X-Authentication-Warning: freefall.cdrom.com: Host localhost.cdrom.com didn't use HELO protocol To: Noses cc: freebsd-bugs@freefall.cdrom.com Subject: Re: kern/475: can't compile a kernel In-reply-to: Your message of "Thu, 01 Jun 95 22:10:01 PDT." <199506020510.WAA03846@freefall.cdrom.com> Date: Fri, 02 Jun 1995 04:28:33 -0700 Message-ID: <23410.802092513@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: bugs-owner@FreeBSD.org Precedence: bulk When sending reports like this, PLEASE PLEASE PLEASE take the comments out of your kernel config file! They only bloat it up to many times the necessary size. We don't need all the comments for the kernel config file in the bug report - we know them already! :-) It's a very simple command: sed -e '/^#/D' Thanks! Jordan From owner-freebsd-bugs Fri Jun 2 06:44:40 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id GAA01990 for bugs-outgoing; Fri, 2 Jun 1995 06:44:40 -0700 Received: from racer.dkrz.de (racer.dkrz.de [136.172.110.55]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id GAA01977 for ; Fri, 2 Jun 1995 06:44:28 -0700 Received: by racer.dkrz.de (4.1/SMI-4.1) id AA12340; Fri, 2 Jun 95 15:42:44 +0200 Date: Fri, 2 Jun 95 15:42:44 +0200 From: gwk@racer.dkrz.de (Georg-W. Koltermann) Message-Id: <9506021342.AA12340@racer.dkrz.de> To: freebsd-bugs@FreeBSD.org Subject: 2.0.5a install: ftp username/password does not work Reply-To: gwk@cray.com Sender: bugs-owner@FreeBSD.org Precedence: bulk Jordan, I tried again with your floppy-of-the-day, but still can't get installing via FTP to work. I use my workstation as FTP server and want to retrieve the files with username and password (no anonymous ftp configured). Permission denied. The debug screen tells me that the install forgets about the username that I specified in the options menu and instead uses the password that I specified for both the ftp USER and PASS commands. Did you really try this before you released it? Anyway, installing via NFS seems to work once I set the 'NFS priviledged port' option. How about making this the default anyway? Would it break something? Georg-W. Koltermann, gwk@cray.com From owner-freebsd-bugs Fri Jun 2 07:25:40 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id HAA04586 for bugs-outgoing; Fri, 2 Jun 1995 07:25:40 -0700 Received: from racer.dkrz.de (racer.dkrz.de [136.172.110.55]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id HAA04571 for ; Fri, 2 Jun 1995 07:25:32 -0700 Received: by racer.dkrz.de (4.1/SMI-4.1) id AA12398; Fri, 2 Jun 95 16:22:49 +0200 Date: Fri, 2 Jun 95 16:22:49 +0200 From: gwk@racer.dkrz.de (Georg-W. Koltermann) Message-Id: <9506021422.AA12398@racer.dkrz.de> To: freebsd-bugs@FreeBSD.org Subject: Signal 11 after installing 2.0.5a Reply-To: gwk@cray.com Sender: bugs-owner@FreeBSD.org Precedence: bulk Why do I keep getting signal 11 on every other command right after installing 2.0.5a? The same hardware ran the Feb snap without a hickup, the only hardware change is the addition of a second IDE disk (850 MB Maxtor) for 2.0.5a. It's always the same commands that get SIG11. swapinfo, for example, or ifconfig ed0, or iostat. Things like date, vi, ls, df work o. k.. Maybe the distribution was damaged? I got a message from gzip 'premature end of file' on the debug screen when the bindist was installed. However I checked the number and sizes of all bin.?? files, it looks allright. I didn't see any chksum files, so I cannot easily check the integrity of the distribution (short of transferring it all again, which I won't do since I'm located in Germany). Hardware is a 386/40 clone with 8MB of mem, ET4000 SVGA, 2 IDE disks (primary ST3283A, secondary MAXTOR 7850AR), WD8013EPC at irq 10, no 80387. 2.0.5a is being installed on the secondary harddisk. Any idea? Georg-W. Koltermann, gwk@cray.com P.S.: It almost looks like it could be related to libkvm? From owner-freebsd-bugs Fri Jun 2 07:44:32 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id HAA07043 for bugs-outgoing; Fri, 2 Jun 1995 07:44:32 -0700 Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id HAA07020 ; Fri, 2 Jun 1995 07:44:27 -0700 X-Authentication-Warning: freefall.cdrom.com: Host localhost.cdrom.com didn't use HELO protocol To: gwk@cray.com cc: freebsd-bugs@FreeBSD.org Subject: Re: 2.0.5a install: ftp username/password does not work In-reply-to: Your message of "Fri, 02 Jun 95 15:42:44 +0200." <9506021342.AA12340@racer.dkrz.de> Date: Fri, 02 Jun 1995 07:44:25 -0700 Message-ID: <7016.802104265@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: bugs-owner@FreeBSD.org Precedence: bulk > the install forgets about the username that I specified in the options > menu and instead uses the password that I specified for both the ftp > USER and PASS commands. Did you really try this before you released > it? Ahem. I'm sorry, this was simply a brain-o.. I looked at the code in this case and said "this can't possibly fail, I don't even need to test it" and I committed it. Mistake, of course. I forgot that msgGetInput() returns a pointer to a static array which is clobbered between calls. Whoops! Password laid right over username and that's all she wrote. I fixed this one a few hours ago and will be rolling a new set of floppies soon! Quite a few more problems fixed, actually. > Anyway, installing via NFS seems to work once I set the 'NFS > priviledged port' option. How about making this the default anyway? > Would it break something? AFAIK, only Suns use this by default. Jordan From owner-freebsd-bugs Fri Jun 2 07:47:06 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id HAA07253 for bugs-outgoing; Fri, 2 Jun 1995 07:47:06 -0700 Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id HAA07244 ; Fri, 2 Jun 1995 07:47:04 -0700 X-Authentication-Warning: freefall.cdrom.com: Host localhost.cdrom.com didn't use HELO protocol To: gwk@cray.com cc: freebsd-bugs@FreeBSD.org Subject: Re: Signal 11 after installing 2.0.5a In-reply-to: Your message of "Fri, 02 Jun 95 16:22:49 +0200." <9506021422.AA12398@racer.dkrz.de> Date: Fri, 02 Jun 1995 07:47:04 -0700 Message-ID: <7243.802104424@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: bugs-owner@FreeBSD.org Precedence: bulk > It's always the same commands that get SIG11. swapinfo, for example, > or ifconfig ed0, or iostat. Things like date, vi, ls, df work o. k.. > Maybe the distribution was damaged? I got a message from gzip > 'premature end of file' on the debug screen when the bindist was > installed. However I checked the number and sizes of all bin.?? > files, it looks allright. I didn't see any chksum files, so I cannot > easily check the integrity of the distribution (short of transferring > it all again, which I won't do since I'm located in Germany). The info files may be out of sync with the bin dist and not actually extracting all of it; I need to go verify this. Otherwise, it's hard to say.. Unless it was the kernel that was corrupted in the bad bin extract! Jordan From owner-freebsd-bugs Fri Jun 2 08:27:52 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA12018 for bugs-outgoing; Fri, 2 Jun 1995 08:27:52 -0700 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id IAA12008 for ; Fri, 2 Jun 1995 08:27:50 -0700 Received: from crmunich0 (crmunich0.cray.com [134.14.1.1]) by timbuk.cray.com (8.6.11/CRI-gw-8-1.4) with SMTP id KAA03934 for ; Fri, 2 Jun 1995 10:27:44 -0500 Received: by crmunich0 id AA14064; 4.1/CRI-5.6a; Fri, 2 Jun 95 17:27:50 +0200 Date: Fri, 2 Jun 95 17:27:50 +0200 From: gwk@crmunich0.cray.com (Georg-Wilhelm Koltermann) Message-Id: <9506021527.AA14064@crmunich0> To: Marino.Ladavac@aut.alcatel.at Subject: Re: Signal 11 after installing 2.0.5a Cc: freebsd-bugs@FreeBSD.org Sender: bugs-owner@FreeBSD.org Precedence: bulk > From Marino.Ladavac@aut.alcatel.at Fri Jun 2 16:53:41 1995 > From: Marino.Ladavac@aut.alcatel.at > Subject: Re: Signal 11 after installing 2.0.5a > To: gwk@cray.com > Date: Fri, 2 Jun 95 16:53:14 METDST > In-Reply-To: <9506021422.AA12398@racer.dkrz.de>; from "Georg-W. Koltermann" at Jun 2, 95 4:22 pm > Mailer: Elm [revision: 70.85] > Status: RO > > > > Maybe the distribution was damaged? I got a message from gzip > > 'premature end of file' on the debug screen when the bindist was > > installed. However I checked the number and sizes of all bin.?? > > files, it looks allright. I didn't see any chksum files, so I cannot > > easily check the integrity of the distribution (short of transferring > > it all again, which I won't do since I'm located in Germany). > > You have it all, but the sysinstall is a little hosed (it expects a file > too few. cat the last two together and try. worked for me, and > Jordan is fixing it :) > > /Alby > > > P.S.: It almost looks like it could be related to libkvm? > > Hopefully not. I didn't have sig11 problems after the trick above. > Maybe I should take a look what was skipped (a library perhaps) and > that caused the above behavior. > THANKS!!! The last file is /kernel.GENERIC, so I was missing a minor peace of the kernel! It's a miracle that it worked at all. The kernel that the installation extracted was size 1012224 while it should be 1108154. Now my SIG11's are gone. Thank you so much. Georg From owner-freebsd-bugs Fri Jun 2 10:24:31 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA18840 for bugs-outgoing; Fri, 2 Jun 1995 10:24:31 -0700 Received: from salyko.cube.net (root@salyko.cube.net [193.141.73.2]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id KAA18834 for ; Fri, 2 Jun 1995 10:24:29 -0700 Received: from nasim.nasim.cube.net by salyko.cube.net with smtp (Smail3.1.29.1 #1) id m0sHaSJ-0016GlC; Fri, 2 Jun 95 19:24 MET DST Received: by nasim.nasim.cube.net (Smail3.1.29.0 #1) id m0sHaSC-000O9fC; Fri, 2 Jun 95 19:24 MET DST To: freebsd-bugs@freefall.cdrom.com Path: not-for-mail From: knarf@nasim.cube.net (Frank Bartels) Newsgroups: muc.lists.freebsd.bugs Subject: Re: Changed information for PR bin/468 Date: 2 Jun 1995 19:24:09 +0200 Organization: The Sunsite for ATARI-Friends Lines: 36 Message-ID: <3qnhfp$ngv@nasim.nasim.cube.net> References: <199506012151.OAA04929@freefall.cdrom.com> X-Newsreader: TIN [version 1.2 PL2] Sender: bugs-owner@FreeBSD.org Precedence: bulk Jordan K. Hubbard (jkh@freefall.cdrom.com) wrote: > Synopsis: passwd changes wrong password > This is not a bug. su changes only the effective uid, and if you > wish to change the password for someone else then this isn't the way to do it. Anyway, I'm not the only one who noticed this annoying behaviour. I changed root's password this way and tried it out doing another su (to root) and as you might guess, it did not work. I changed the password back to the old password and it worked again. I tried this several times until I saw I was changing the wrong password all the time. Perhaps passwd should warn you, if you run passwd without arguments. A much better and easy to implement solution would be: % su [...] # passwd Changing local password for knarf. knarf's new password: [...] What do you think about this? I think I've seen something similar on AIX, if you rlogin there and get asked for a password it asks for "'s password" instead of just "password:". Nice feature. > Do a `passwd root' or login to root properly. Log in as root? Hmm, `last' says I did not do this this year ;) Bye, Knarf -- Frank Bartels | UUCP/ZModem/Fax: + 49 89 5469593 | MiNT is knarf@nasim.cube.net | Login: nuucp Index: /pub/ls-lR.nasim.gz | Now TOS! From owner-freebsd-bugs Fri Jun 2 10:47:08 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA20691 for bugs-outgoing; Fri, 2 Jun 1995 10:47:08 -0700 Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id KAA20678 ; Fri, 2 Jun 1995 10:47:05 -0700 Message-Id: <199506021747.KAA20678@freefall.cdrom.com> X-Authentication-Warning: freefall.cdrom.com: Host localhost.cdrom.com didn't use HELO protocol To: knarf@nasim.cube.net (Frank Bartels) cc: freebsd-bugs@freefall.cdrom.com Subject: Re: Changed information for PR bin/468 In-reply-to: Your message of "02 Jun 95 19:24:09 +0200." <3qnhfp$ngv@nasim.nasim.cube.net> Date: Fri, 02 Jun 1995 10:47:04 -0700 From: "Justin T. Gibbs" Sender: bugs-owner@FreeBSD.org Precedence: bulk >Jordan K. Hubbard (jkh@freefall.cdrom.com) wrote: > >> Synopsis: passwd changes wrong password > >> This is not a bug. su changes only the effective uid, and if you >> wish to change the password for someone else then this isn't the way to do i >t. > >Anyway, I'm not the only one who noticed this annoying behaviour. I >changed root's password this way and tried it out doing another su (to >root) and as you might guess, it did not work. I changed the password >back to the old password and it worked again. I tried this several >times until I saw I was changing the wrong password all the time. > >Perhaps passwd should warn you, if you run passwd without arguments. A >much better and easy to implement solution would be: > >% su >[...] ># passwd >Changing local password for knarf. >knarf's new password: >[...] > >What do you think about this? I think I've seen something similar >on AIX, if you rlogin there and get asked for a password it asks for >"'s password" instead of just "password:". Nice feature. > >> Do a `passwd root' or login to root properly. > >Log in as root? Hmm, `last' says I did not do this this year ;) > >Bye, >Knarf FreeBSD already tells you who's password it is changing: [aslan::gibbs]$ su su: kerberos: not in root's ACL. Password: Warning: imported path contains relative components aslan# passwd Changing local password for gibbs. New password: ... aslan# passwd root Changing local password for root. New password: ... >-- > Frank Bartels | UUCP/ZModem/Fax: + 49 89 5469593 | MiNT is >knarf@nasim.cube.net | Login: nuucp Index: /pub/ls-lR.nasim.gz | Now TOS! -- Justin T. Gibbs ============================================== TCS Instructional Group - Programmer/Analyst 1 Cory | Po | Danube | Volga | Parker | Torus ============================================== From owner-freebsd-bugs Fri Jun 2 12:50:02 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA03475 for bugs-outgoing; Fri, 2 Jun 1995 12:50:02 -0700 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA03466 ; Fri, 2 Jun 1995 12:50:01 -0700 Date: Fri, 2 Jun 1995 12:50:01 -0700 Message-Id: <199506021950.MAA03466@freefall.cdrom.com> From: mpp@legarto.minn.net Reply-To: mpp@legarto.minn.net To: freebsd-bugs Subject: kern/478: Multicast not supported on PPP interfaces In-Reply-To: Your message of Fri, 2 Jun 1995 14:44:13 -0500 <199506021944.OAA00418@mpp.com> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 478 >Category: kern >Synopsis: Multicast not supported on PPP interfaces >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Jun 2 12:50:00 1995 >Originator: Mike Pritchard >Organization: >Release: FreeBSD BUILT-19950525 i386 >Environment: FreeBSD-current >Description: Multicast is not supported on PPP interfaces. It looks like someone goofed when they checked in revision 1.4 of sys/net/if_ppp.c, since it deleted the changes made in revision 1.3 to add the multicast stuff. >How-To-Repeat: Run "ifconfig ppp0" and note that MULTICAST doesn't appear as one of the flags. >Fix: Here is a patch that re-adds the multicast stuff that was previosly in revision 1.3 of if_ppp.c. I think this is all that is needed, but someone who knows more about this stuff should double check and make sure. *** orig/if_ppp.c Fri Jun 2 12:52:30 1995 --- if_ppp.c Fri Jun 2 14:09:12 1995 *************** *** 200,206 **** sc->sc_if.if_name = "ppp"; sc->sc_if.if_unit = i++; sc->sc_if.if_mtu = PPP_MTU; ! sc->sc_if.if_flags = IFF_POINTOPOINT; sc->sc_if.if_type = IFT_PPP; sc->sc_if.if_hdrlen = PPP_HDRLEN; sc->sc_if.if_ioctl = pppioctl; --- 200,206 ---- sc->sc_if.if_name = "ppp"; sc->sc_if.if_unit = i++; sc->sc_if.if_mtu = PPP_MTU; ! sc->sc_if.if_flags = IFF_POINTOPOINT | IFF_MULTICAST; sc->sc_if.if_type = IFT_PPP; sc->sc_if.if_hdrlen = PPP_HDRLEN; sc->sc_if.if_ioctl = pppioctl; *************** *** 1525,1530 **** --- 1525,1542 ---- case SIOCGIFMTU: ifr->ifr_mtu = sc->sc_if.if_mtu; + break; + case SIOCADDMULTI: + case SIOCDELMULTI: + switch(ifr->ifr_addr.sa_family) { + #ifdef INET + case AF_INET: + break; + #endif + default: + error = EAFNOSUPPORT; + break; + } break; default: >Audit-Trail: >Unformatted: From owner-freebsd-bugs Fri Jun 2 14:30:05 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA15759 for bugs-outgoing; Fri, 2 Jun 1995 14:30:05 -0700 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA15749 ; Fri, 2 Jun 1995 14:30:03 -0700 Date: Fri, 2 Jun 1995 14:30:03 -0700 Message-Id: <199506022130.OAA15749@freefall.cdrom.com> From: mpp@legarto.minn.net Reply-To: mpp@legarto.minn.net To: freebsd-bugs Subject: gnu/479: ld -s sometimes produces bad binaries. mmap problem? In-Reply-To: Your message of Fri, 2 Jun 1995 16:07:09 -0500 <199506022107.QAA00881@mpp.com> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 479 >Category: gnu >Synopsis: ld -s sometimes produces bad binaries. mmap problem? >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Jun 2 14:30:01 1995 >Originator: Mike Pritchard >Organization: >Release: FreeBSD BUILT-19950525 i386 >Environment: -current ld & kernel >Description: Various binaries dump core with "bus error" when linked with the -s option (strip the binary). Linking with -s doesn't always produce a bad binary. The resulting core file is not usable by gdb, and it reports that it is truncated. The core file is always 8192 bytes in length. This looks to be some type of kernel problem, possibly with mmap. Running "cmp binary.ld binary.strip" causes cmp to dump core with "bus error". Debugging the cmp core dump shows that it is failing when it tries to scan through the files after mmap'ing them. The binary stays unrunnable until a system reboot. After that the binary is just fine. Making a copy of the "bad" binary and trying to run that file will also work. I added a little bit of debug code to the coredump() routine in kern_sig.c to see why the core file doesn't get written out, and the following chunk of code gets an EFAULT error from the vn_rdwr routine. error = vn_rdwr(UIO_WRITE, vp, vm->vm_daddr, (int)ctob(vm->vm_dsize), (off_t)ctob(UPAGES), UIO_USERSPACE, IO_NODELOCKED|IO_UNIT, cred, (int *) NULL, p); The EFAULT above is probably that same reason why the binary fails in the first place. >How-To-Repeat: I was able to duplicate this with the "id" command, but your mileage may vary. I had to try out about 5 different small commands until I found a nice small one that would reproduce the problem. Once you find a binary that does fail, it will fail consistently. Linking with "-static" produces a good binary in the example below. Note: "cc -s -o..." below expands to: /usr/bin/ld -e start -dc -dp -o id -s /usr/lib/crt0.o id.o /usr/lib/libgcc.a -lc /usr/lib/libgcc.a Script started on Fri Jun 2 14:56:44 1995 mpp 1# cc -c id.c mpp 2# cc -o id id.o mpp 3# ./id uid=0(root) gid=0(wheel) groups=0(wheel), ... mpp 4# ls -l id -rwx--x--x 1 root wheel 13100 Jun 2 14:56 id* mpp 5# strip id mpp 6# ./id uid=0(root) gid=0(wheel) groups=0(wheel), ... mpp 7# ls -l id -rwx--x--x 1 root wheel 12288 Jun 2 14:57 id* mpp 8# cp id id.strip mpp 9# cc -s -o id id.o mpp 10# ./id Bus error mpp 11# ls -l id -rwx--x--x 1 root wheel 12288 Jun 2 14:57 id* mpp 12# cmp id id.strip Bus error (core dumped) mpp 13# cp id id.ld mpp 14# ./id.ld uid=0(root) gid=0(wheel) groups=0(wheel), ... mpp 15# cmp id.ld id.strip mpp 16# Script done on Fri Jun 2 14:58:12 1995 >Fix: None yet. >Audit-Trail: >Unformatted: From owner-freebsd-bugs Fri Jun 2 18:25:53 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA10292 for bugs-outgoing; Fri, 2 Jun 1995 18:25:53 -0700 Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id SAA10286 for ; Fri, 2 Jun 1995 18:25:52 -0700 X-Authentication-Warning: freefall.cdrom.com: Host localhost.cdrom.com didn't use HELO protocol Prev-Resent: Fri, 02 Jun 1995 18:25:51 -0700 Prev-Resent: "bugs " Received: from elxr.jpl.nasa.gov (elxr-fddi.jpl.nasa.gov [137.78.160.8]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id OAA17652 for ; Fri, 2 Jun 1995 14:52:58 -0700 Received: from localhost.jpl.nasa.gov (localhost.jpl.nasa.gov [127.0.0.1]) by elxr.jpl.nasa.gov (8.6.10/8.6.6) with SMTP id OAA00755 for ; Fri, 2 Jun 1995 14:57:17 -0700 Message-Id: <199506022157.OAA00755@elxr.jpl.nasa.gov> To: jkh@FreeBSD.org Subject: 2.0.5A Panic on install Date: Fri, 02 Jun 1995 14:57:12 -0700 From: Dave Hayes Resent-To: bugs@freefall.cdrom.com Resent-Date: Fri, 02 Jun 1995 18:25:51 -0700 Resent-Message-ID: <10285.802142751@freefall.cdrom.com> Resent-From: "Jordan K. Hubbard" Sender: bugs-owner@FreeBSD.org Precedence: bulk I have an AST Bravo LC 486 DX2/66 with an Adaptec 1542CF (sigh) SCSI-2 card. The card is at 0x130, so when the default 2.0.5A doesn't see it, it boots fine. However, when I "kernel -c" and then "port aha0 0x130" and then "quit", it dies with the following: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xefc00000 fault code = supervisor read, page not present instruction pointer = 0x8:0xf019e950 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor flags = interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) interrupt mask = panic:page fault What am I doing wrong? I looked in archives and saw some people had problems with the Adaptec 1542CF. Is this not the card to use? Help! ------ Dave Hayes -- Institutional NETworks - Section 394 -- JPL/NASA - Pasadena CA dave@elxr.jpl.nasa.gov dave@jato.jpl.nasa.gov ...usc!elroy!dxh The practice of study only too often makes people mere repeaters and producers of cliches and sayings. Such study has been all but wasted. The product has taken the form in which we find it because it is an unsuitable graft upon an unprepared basis. From owner-freebsd-bugs Fri Jun 2 18:33:49 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA10749 for bugs-outgoing; Fri, 2 Jun 1995 18:33:49 -0700 Received: (from davidg@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA10735 ; Fri, 2 Jun 1995 18:33:48 -0700 Date: Fri, 2 Jun 1995 18:33:48 -0700 From: David Greenman Message-Id: <199506030133.SAA10735@freefall.cdrom.com> To: mpp@legarto.minn.net, davidg, freebsd-bugs Subject: Changed information for PR gnu/479 Sender: bugs-owner@FreeBSD.org Precedence: bulk Synopsis: ld -s sometimes produces bad binaries. mmap problem? State-Changed-From-To: open-closed State-Changed-By: davidg State-Changed-When: Fri Jun 2 18:32:46 PDT 1995 State-Changed-Why: This bug was fixed in rev 1.8 of sys/ufs/ffs/ffs_balloc.c. It was caused by a bogus vnode_pager_setsize() call. From owner-freebsd-bugs Fri Jun 2 19:15:04 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id TAA13305 for bugs-outgoing; Fri, 2 Jun 1995 19:15:04 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id TAA13273 for ; Fri, 2 Jun 1995 19:14:58 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA04665; Fri, 2 Jun 95 20:08:15 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9506030208.AA04665@cs.weber.edu> Subject: Some notes on UFS To: freebsd-bugs@FreeBSD.org Date: Fri, 2 Jun 95 20:08:14 MDT Cc: terry@cs.weber.edu (Terry Lambert) X-Mailer: ELM [version 2.4dev PL52] Sender: bugs-owner@FreeBSD.org Precedence: bulk OK, I have some notes on UFS; sorry they are not formatted as diffs, but I'm still partially machine-less on this. I've been looking arounf for 64 bit clean/unclean, and here's what Iive found (so far): ufs_bmap.c: line 152: is_sequential(ump, ip->i_db[ ... because the is_sequential macro forces evaluation, there should be an explicit cast in the macro when doing address aritmatic to ensure the sign of the values being compared (address cast), since addresses can be compared as signed values. This is definitely a nit. The is_sequential macro is in ufs_mount.h. line 201: for (bn = xap->in_off + 1; ... using bn ( a daddr_t: types.h: long) this way is potentially wrong; I don't know if it should be passed into bmaparray as unsigned in the first place or not (comparing against ump->um_nindir: MNINDIR, an unsigned long value: ufs_mount.h is definitely bad). line 201: is_sequential(ump, ((daddr_t ... another nit. ufs_disksubr.c: There's some PREDISKSLOCE stuff I'll ignore. in the routine diskerr(): the bp->b_bcount vs. lp->d_secsize is signed vs. unsigned. This points up a potential problem in struct buf, with b_bcount being a long (else why have d_secsize unsigned?). ufs_lookup.c: line 158: int vpid; This should be: u_long vpid; line 244: endsearch = roundup(dp->i_size, DIRBLKSIZ); endsearch is a doff_t (inode.h: unsigned long); the conversion from a quad (dp->i_size) should be explicit (via a macro from inode.h where long is used instead of quad for doff_t typedef?). line 387: dp->i_offset = roundup(dp->i_size, DIRBLKSIZ); same conversion as @ 244. line 665: newdir.d_namlen = cnp->cn_namelen; cn_namelen (namei.h: long) seems to be a long for no good reason? otherwise, this is a potential loss of precision. line 763: if (spacefree + dsize < newentrysize) dsize is an unsigned int, while the other two variables are int. According to ANSI, the lvalue of the addition is unsigned, so the compare for an unsigned less than a signed is probably buggy at the boundry conditions. line 825: ep->d_reclen += dp->i_reclen; d_reclen (dirent.h: unsigned short) is potentially smaller than i_reclen (inode.h: unsigned long), so this is a potential overflow. line 878: for (off = 0; off < ip->i_size; ... off is an off_t (signed quad) and i_size is an alias for i_din.di_size which is (dinode.h: u_quad_t) an unsigned quad. This is probably a nit. line 941: if (target->i_number == rootino) If this isn't going to be referenced as a manifest constant (ROOTINO) for no good reason, at least declare it as an ino_t instead of as an int (ino_t: types.h: unsigned long). line 972: if (dirbuf.dotdot_ino == rootino) same problem here. ufs_quota.c: line 169: ncurblocks should be declared unsigned. line 285: ncurinodes should be declared unsigned. ufs_vnops.c: line 769: oldparent, newparent should be ino_t, not int. line 1474: ...VTOI(ap->a_vp)->i_size <= uio->uio_offset; i_size is unsigned, uio_offset is signed (off_t). line 1494: isize = ip->i_size; since a path can not exceed MAXPATHLEN, this should be an explicit cast. The int = quad here is an intentional loss of precision. Well, that's all for right now. 8-). Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-bugs Fri Jun 2 20:22:04 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id UAA16733 for bugs-outgoing; Fri, 2 Jun 1995 20:22:04 -0700 Received: from limbic.ssdl.com (limbic.ssdl.com [192.111.251.33]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id UAA16725 for ; Fri, 2 Jun 1995 20:21:59 -0700 Received: (from gil@localhost) by limbic.ssdl.com (8.6.11/8.6.6) id WAA23819 for bugs@freebsd.org; Fri, 2 Jun 1995 22:21:54 -0500 From: "Gil Kloepfer Jr." Message-Id: <199506030321.WAA23819@limbic.ssdl.com> Subject: Update on kern/466 + more To: bugs@FreeBSD.org Date: Fri, 2 Jun 1995 22:21:52 -0500 (CDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 4640 Sender: bugs-owner@FreeBSD.org Precedence: bulk Okay... Here are the gory details on my continuing problems with installing 2.0.5-A on an ESDI drive with some bad blocks... As suggested previously, I disabled sector sparing by low-level formatting the disk with the option off in the controller. We're now back to the physical geometry of the disk. Turned on verbose mode... First problem I noticed right away was with the partition table editor. I don't know about the rest of you, but I get different flag values every time I enter and exit this beast. Because of this, it's extremely hard to tell if I've selected "bad block handling" or not. It seems like if you press the B key more than once, you start creating all sorts of interesting values for 'flag'... This also happens with the "set active partition" ... so I would look at this a bit and see if the flag bits are being toggled right. Eventually I did select what I wanted here-- 60MB (existing) DOS partition, and the rest of the disk for FreeBSD. Set-up the slices, as mentioned before: 20MB /, 32MB sw, 80MB /usr, 10MB /var, 120MB /source. This worked as advertised. Did everything else...you know all this by now, if you've been through the installation as much as I have... :) Went to Install ... started checking for bad blocks as it should be. I looked over at the debug screen to see what was going on. The first nasty I noticed is that it looked like it was trying to write the bad block file off the end of the disk. I'm not 100% sure about this (sure would be nice to get to a shell prompt...)...but in any case, it had a disk error each time it tried to do its magic with the bad block file. I'm not going to pretend to know what it was doing here -- I'm trying to relay as much as I can before it all went off the screen. I'm supping -current now to see if I can provide some more intelligent feedback... Anyhow, bad block scanning then went as it should -- there's about 36 bad sectors on this disk, as I recall...and this looked about right. That's a new first for bad144 -- it never used to detect the bad blocks right. BUT...when it was done scanning for bad blocks (at least this is what appeared to have happened), it SIG11'd (memory fault) and tried to dump core to the floppy and obviously failed (out of space). The last message from bad144 was: Block: 536861 will be marked BAD. >From here, I can do nothing but reboot the machine by hitting escape. Answering questions only produces nasty error messages and out of space errors. If you get an error back from a program like bad144, I'd say that in most cases you can abort the installation. There are several problems I see with the bad144 stuff that gives me a bad (no pun intended) feeling. First off, I it took me a while but I finally discovered that the offsets it was reporting at the beginning (when bad144 first ran) are relative to the beginning of the FreeBSD slice. It looks like it's trying to put a bad block table at the end of my 1223 cyl. disk. Back a long time ago, this was not a good thing because of the BIOS 1024 cyl limitations. The other thing I recall is that when you made the disklabel, you were suppose to leave some space before the end of the FreeBSD slice for the bad144 table. I don't know if this has changed, but I didn't do this when I used the label editor, and it didn't say I had to either. In any case, I think I may be off in left field about the memory fault, but I thought that bringing this up may raise the red flag about some old problems that may need to be addressed. It takes a good part of an hour or so to low-level format this disk... so I don't want to do what I'm about to suggest unless necessary. My controller has a 63 sector translation mode that allows drives with >1024 cyl to be used (works like IDE translation works now). I want to avoid using this because it just complicates debugging ("is it the controller or FreeBSD causing the problem?") and makes it hard to take advantage of the physical geometry of the disk. Not to harp on this much more ... I enabled sector sparing way back when bad144 was just not reliable and I found myself spending hours building a system. It has worked up though 2.0-RELEASE... so something is different that keeps it from working in 2.0.5-ALPHA. I don't see any need to go to sector sparing (and waste disk space) if bad144 works, but it seems like it still is kind of in a funny state yet. I'm more than happy to help, but I'm going to need some way of finding the offending part of bad144 that's causing the problem. Hope this helps. -- Gil Kloepfer e-mail: gil@SSDL.COM WWW: http://www.ssdl.com/~gil/ From owner-freebsd-bugs Fri Jun 2 21:05:27 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA19377 for bugs-outgoing; Fri, 2 Jun 1995 21:05:27 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id VAA19342 for ; Fri, 2 Jun 1995 21:05:06 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id OAA31672; Sat, 3 Jun 1995 14:03:19 +1000 Date: Sat, 3 Jun 1995 14:03:19 +1000 From: Bruce Evans Message-Id: <199506030403.OAA31672@godzilla.zeta.org.au> To: freebsd-bugs@FreeBSD.org, terry@cs.weber.edu Subject: Re: Some notes on UFS Sender: bugs-owner@FreeBSD.org Precedence: bulk >I've been looking arounf for 64 bit clean/unclean, and here's what Iive >found (so far): >ufs_bmap.c: > line 152: is_sequential(ump, ip->i_db[ ... > > because the is_sequential macro forces evaluation, there should be > an explicit cast in the macro when doing address aritmatic to ensure > the sign of the values being compared (address cast), since addresses > can be compared as signed values. This is definitely a nit. The > is_sequential macro is in ufs_mount.h. Erm, addresses are always compared as unsigned values, there are no addresses involved (only positive daddr_t values), and the comparison is for equality anyway. > line 201: for (bn = xap->in_off + 1; ... > using bn ( a daddr_t: types.h: long) this way is potentially wrong; > I don't know if it should be passed into bmaparray as unsigned in > the first place or not (comparing against ump->um_nindir: MNINDIR, > an unsigned long value: ufs_mount.h is definitely bad). This depends on whether daddr_t is supposed to be for the in-core or the on-disk representation of block numbers. It is currently supposed to be for both, but this is impossible in general (there may be no type with the same size as the on-disk object, and the on-disk object may have the bytes in a different order...). I think the correct approach is for daddr_t to be the in-core type and for the on-disk object to be converted iff necessary, but this takes a lot of work; it's easier to specify a compiler that supports a 32 bit type and abuse this type no matter how inefficient it is. >ufs_disksubr.c: > in the routine diskerr(): > the bp->b_bcount vs. lp->d_secsize is signed vs. unsigned. > This points up a potential problem in struct buf, with b_bcount > being a long (else why have d_secsize unsigned?). I don't think there are any actual problems here. b_bcount and d_secsize are always relatively small positive values. Even 16-bit signed ints could be used for them without losing much. I prefer to use unsigned ints for all such counters, but there are advantages to using [long] ints in sloppy code that doesn't worry about underflow or overflow: underflow from 0 to -1 is often useful, and the compiler is allowed to check for overflow of ints. >ufs_lookup.c: > line 158: int vpid; > This should be: u_long vpid; Yes. But do we really want 64-bit vpids if u_longs are 64 bits? > line 244: endsearch = roundup(dp->i_size, DIRBLKSIZ); > endsearch is a doff_t (inode.h: unsigned long); the conversion from > a quad (dp->i_size) should be explicit (via a macro from inode.h > where long is used instead of quad for doff_t typedef?). The conversion is wrong iff the directory is larger than 2G :-). There are more important overflows to worry about. > line 387: dp->i_offset = roundup(dp->i_size, DIRBLKSIZ); > same conversion as @ 244. Similarly. I don't think directories larger than 2G are worth worrying about. This is probably best enforced at directory extension time. > line 665: newdir.d_namlen = cnp->cn_namelen; > cn_namelen (namei.h: long) seems to be a long for no good reason? > otherwise, this is a potential loss of precision. It should probably have type size_t to avoid gratuitous conversions after strlen is used. However perhaps it needs to be signed so that it can be counted down from 0 to -1. > line 763: if (spacefree + dsize < newentrysize) > dsize is an unsigned int, while the other two variables are int. > According to ANSI, the lvalue of the addition is unsigned, so the > compare for an unsigned less than a signed is probably buggy at > the boundry conditions. I think all the values here are <= the block size so there are no problems. The mixture of types is just ugly. If there is a bug, then it is not checking for overflow of the addition. > line 825: ep->d_reclen += dp->i_reclen; > d_reclen (dirent.h: unsigned short) is potentially smaller than > i_reclen (inode.h: unsigned long), so this is a potential overflow. Even int + int can overflow. I try not to worry about this too much :-). > line 878: for (off = 0; off < ip->i_size; ... > > off is an off_t (signed quad) and i_size is an alias for i_din.di_size > which is (dinode.h: u_quad_t) an unsigned quad. This is probably > a nit. Another problem with directories larger than 2G. > line 941: if (target->i_number == rootino) > If this isn't going to be referenced as a manifest constant (ROOTINO) > for no good reason, at least declare it as an ino_t instead of as > an int (ino_t: types.h: unsigned long). > line 972: if (dirbuf.dotdot_ino == rootino) > same problem here. Yes. >ufs_quota.c: > line 169: ncurblocks should be declared unsigned. > line 285: ncurinodes should be declared unsigned. Yes (u_long). >ufs_vnops.c: > line 769: oldparent, newparent should be ino_t, not int. Yes. > line 1474: ...VTOI(ap->a_vp)->i_size <= uio->uio_offset; > i_size is unsigned, uio_offset is signed (off_t). Not a problem. Files >= 2^63 bytes are not supported. > line 1494: isize = ip->i_size; > since a path can not exceed MAXPATHLEN, this should be an explicit > cast. The int = quad here is an intentional loss of precision. Maybe a damaged symlink can be larger than 2G :-). Summary: the problems reported aren't serious yet. I'm sure there are thousands of similar problems and that they could best be found by the compiler, but the poorly chosen types should result in hundreds of thousands of warnings about suspicious conversions. Bruce From owner-freebsd-bugs Sat Jun 3 01:18:41 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id BAA15840 for bugs-outgoing; Sat, 3 Jun 1995 01:18:41 -0700 Received: from larry.infi.net (root@larry.infi.net [198.22.1.114]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id BAA15834 for ; Sat, 3 Jun 1995 01:18:37 -0700 From: rknapp@infi.net Received: from test by larry.infi.net with SMTP (8.6.12/Server1.12) id EAA17884; Sat, 3 Jun 1995 04:19:38 -0400 Date: Sat, 3 Jun 1995 04:19:38 -0400 Message-Id: <199506030819.EAA17884@larry.infi.net> X-Sender: rknapp@infi.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: bugs@FreeBSD.org Subject: installation bug 2.0.5-ALPHA X-Mailer: Sender: bugs-owner@FreeBSD.org Precedence: bulk The file root.flp in ../UPDATES directory is truncated, i had to resort to using !ROOT.OLD in the floppies directory. Also, where is the ../kern files? Thanks Rob From owner-freebsd-bugs Sat Jun 3 11:20:09 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA09035 for bugs-outgoing; Sat, 3 Jun 1995 11:20:09 -0700 Received: from mstr.hgc.edu (mstr.hgc.edu [129.5.16.228]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id LAA09025 for ; Sat, 3 Jun 1995 11:20:08 -0700 Date: Sat, 3 Jun 1995 14:20:07 -0400 From: noni4737@mstr.hgc.edu (walter noniewicz) Received: from sd2.hgc.edu ([129.5.160.2]) by mstr.hgc.edu (5.67a/IDA-1.5/HGC-1.8) id AA08271; Sat, 3 Jun 1995 14:20:07 -0400 Message-Id: <199506031820.AA08271@mstr.hgc.edu> To: freebsd-bugs@FreeBSD.org Subject: kernel page fault while doing tar to /dev/rft0 Sender: bugs-owner@FreeBSD.org Precedence: bulk I added a Conner floppy tape drive to a machine running 2.0R. When a tried to "tar cvf /dev/rft0" the machine choked: Fatal tray 12: page fault while in kernel mode fault virtual address = 0x4 fault code = supervisor read, page not present instruction pointer = 0x8:0xf0191906 code segment = base 0x0, limit 0xffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 100 (tar) interrupt mask = panic: page fault syncing disk... 5 5 2 done It then goes into an automatic reboot. I'll be happy to supply configuration details if any one cares. Otherwise, consider this just an FYI item. Thanks. Walter From owner-freebsd-bugs Sat Jun 3 11:46:56 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA11591 for bugs-outgoing; Sat, 3 Jun 1995 11:46:56 -0700 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id LAA11580 for ; Sat, 3 Jun 1995 11:46:54 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id LAA15718; Sat, 3 Jun 1995 11:46:28 -0700 From: "Rodney W. Grimes" Message-Id: <199506031846.LAA15718@gndrsh.aac.dev.com> Subject: Re: kernel page fault while doing tar to /dev/rft0 To: noni4737@mstr.hgc.edu (walter noniewicz) Date: Sat, 3 Jun 1995 11:46:28 -0700 (PDT) Cc: freebsd-bugs@FreeBSD.org In-Reply-To: <199506031820.AA08271@mstr.hgc.edu> from "walter noniewicz" at Jun 3, 95 02:20:07 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: 1342 Sender: bugs-owner@FreeBSD.org Precedence: bulk > > I added a Conner floppy tape drive to a machine running 2.0R. When a tried > to "tar cvf /dev/rft0" the machine choked: man ft: ft is used primarily as a filter for tape i/o. For example, to save and compress the /usr directory to tape: % tar cvzf - /usr | ft "/usr save" To extract /usr from tape: % ft | tar xvzf - > > Fatal tray 12: page fault while in kernel mode > fault virtual address = 0x4 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xf0191906 > code segment = base 0x0, limit 0xffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 100 (tar) > interrupt mask = > panic: page fault Yes, it is a derefernced null some place in the Driver, some one is suppose to be working on fixing this but I have not heard from them in 2 months :-(. You are not suppose to open /dev/ft directly, allow ft to do that for you!!! > syncing disk... 5 5 2 done > > It then goes into an automatic reboot. I'll be happy to supply configuration > details if any one cares. Otherwise, consider this just an FYI item. > Thanks. > Walter > -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-bugs Sat Jun 3 11:58:14 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA12805 for bugs-outgoing; Sat, 3 Jun 1995 11:58:14 -0700 Received: from mailhost.primenet.com (root@mailhost.primenet.com [198.68.32.50]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id LAA12796 for ; Sat, 3 Jun 1995 11:58:13 -0700 Received: from ip191.sna.primenet.com (ip191.sna.primenet.com [204.212.53.191]) by mailhost.primenet.com (8.6.11/wjp-h2.0) with SMTP id LAA00453 for ; Sat, 3 Jun 1995 11:58:10 -0700 Date: Sat, 3 Jun 1995 11:58:10 -0700 Message-Id: <199506031858.LAA00453@mailhost.primenet.com> X-Sender: sjs1@mailhost.primenet.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: freebsd-bugs@FreeBSD.org From: sjs1@primenet.com (Scott Story) Subject: NCR53c400 Magoptic Problem Sender: bugs-owner@FreeBSD.org Precedence: bulk Any help or a refferal would be apprieciated. I am trying to install freeBSD 2.0 on to a SCSI 1 Sony MagOptic drive. (486,33 one SCSI device) These are the messages I am getting. Durring kernel boot: nca1: NCR-53C400 nca1: wating for SCSI devices to settle nca1: "Sony SMO-C501-00 2.22" is a type 0 removeable SCSI 1 sd0 (nca1) Direct Access sd0 (nca1) Illegal Request ASC:24,0 invalid field in CDB sdo could not mode sense (4), Using Fictitious Geometry, 281 (576999, 512 byte sectors) During sysinstall Select Complete install nca1/0/0/sd0/timed out Fatal Trap 12: page fault in kernel mode Fault Address=0x8 Fault Code=supervisor read, page np install pointer=0x8:0xf0172c1b code sequence= base 0x0, limit 0xfffff, type ox1b=DPL 0,pres 1, def 32, gran 1 Processor eflags=interupt enabled, resume,10 PL=0 Current Process= 1 (sysinstall) int. mask= bio panic=page fault THANKS IN ADVANCE! I want to die quietly in my sleep like my grandfather, NOT screaming, like his passengers! From owner-freebsd-bugs Sat Jun 3 12:30:17 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA16244 for bugs-outgoing; Sat, 3 Jun 1995 12:30:17 -0700 Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id MAA16236 for ; Sat, 3 Jun 1995 12:30:16 -0700 Message-Id: <199506031930.MAA16236@freefall.cdrom.com> Received: by crh.cl.msu.edu (1.38.193.4/16.2) id AA27547; Sat, 3 Jun 1995 15:30:14 -0400 From: Charles Henrich Subject: Hey Neato To: freebsd-bugs@FreeBSD.org Date: Sat, 3 Jun 1995 15:30:14 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 231 Sender: bugs-owner@FreeBSD.org Precedence: bulk I have a strange bug, if I cd to /stand and run ./sysinstall the machine panics and reboots.. -Crh Charles Henrich Michigan State University henrich@crh.cl.msu.edu http://rs560.msu.edu/~henrich/ From owner-freebsd-bugs Sat Jun 3 13:10:07 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id NAA20426 for bugs-outgoing; Sat, 3 Jun 1995 13:10:07 -0700 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id NAA20412 ; Sat, 3 Jun 1995 13:10:04 -0700 Date: Sat, 3 Jun 1995 13:10:04 -0700 Message-Id: <199506032010.NAA20412@freefall.cdrom.com> From: "Justin T. Gibbs" Reply-To: "Justin T. Gibbs" To: freebsd-bugs Subject: docs/480: Missing rhosts.5 man page In-Reply-To: Your message of Sat, 3 Jun 1995 13:01:40 -0700 <199506032001.NAA00428@narnia.hip.berkeley.edu> Sender: bugs-owner@FreeBSD.org Precedence: bulk >Number: 480 >Category: docs >Synopsis: We don't have an rhosts.5 man page >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Sat Jun 3 13:10:01 1995 >Originator: Justin T. Gibbs >Organization: Walnut Creek CDROM >Release: FreeBSD 2.0-BUILT-19950603 i386 >Environment: 2.0.5A >Description: We need a man page for .rhost files. Ultrix has one, but I haven't tested other environments. >How-To-Repeat: man rhosts man -k rhosts >Fix: Write an rhosts man page >Audit-Trail: >Unformatted: From owner-freebsd-bugs Sat Jun 3 13:37:31 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id NAA23603 for bugs-outgoing; Sat, 3 Jun 1995 13:37:31 -0700 Received: from mailhost.primenet.com (root@mailhost.primenet.com [198.68.32.50]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id NAA23588 for ; Sat, 3 Jun 1995 13:37:28 -0700 Received: from ip191.sna.primenet.com (ip191.sna.primenet.com [204.212.53.191]) by mailhost.primenet.com (8.6.11/wjp-h2.0) with SMTP id NAA13138 for ; Sat, 3 Jun 1995 13:37:24 -0700 Date: Sat, 3 Jun 1995 13:37:24 -0700 Message-Id: <199506032037.NAA13138@mailhost.primenet.com> X-Sender: sjs1@mailhost.primenet.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: freebsd-bugs@FreeBSD.org From: sjs1@primenet.com (Scott Story) Subject: NCR53c400 Magoptic Problem Sender: bugs-owner@FreeBSD.org Precedence: bulk >Scott Story writes: >> >> Any help or a refferal would be apprieciated. >> I am trying to install freeBSD 2.0 on to a SCSI 1 Sony MagOptic drive. >> (486,33 one SCSI device) >> These are the messages I am getting. >> Durring kernel boot: >> nca1: NCR-53C400 >> nca1: wating for SCSI devices to settle >> nca1: "Sony SMO-C501-00 2.22" is a type 0 removeable SCSI 1 >> sd0 (nca1) Direct Access >> sd0 (nca1) Illegal Request ASC:24,0 invalid field in CDB >> sdo could not mode sense (4), Using Fictitious Geometry, 281 (576999, 512 >> byte sectors) > >Does this happen even if you have the formatted media installed? YES with 512 Media There is 512 or 1024 byte sector media for the SMO501. > >> During sysinstall >> >> Select Complete install >> >> nca1/0/0/sd0/timed out >> Fatal Trap 12: page fault in kernel mode >> Fault Address=0x8 >> Fault Code=supervisor read, page np >> install pointer=0x8:0xf0172c1b >> code sequence= base 0x0, limit 0xfffff, type ox1b=DPL 0,pres 1, def 32, gran 1 >> Processor eflags=interupt enabled, resume,10 PL=0 >> Current Process= 1 (sysinstall) >> int. mask= bio >> panic=page fault > >Oops. Do you have a stack back trace? NO stack back trace. >-- >Peter Dufault Real Time Machine Control and Simulation >HD Associates, Inc. Voice: 508 433 6936 >dufault@hda.com Fax: 508 433 5267 > > I want to die quietly in my sleep like my grandfather, NOT screaming, like his passengers! From owner-freebsd-bugs Sat Jun 3 17:33:37 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id RAA20597 for bugs-outgoing; Sat, 3 Jun 1995 17:33:37 -0700 Received: from mailhost.primenet.com (root@mailhost.primenet.com [198.68.32.50]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id RAA20591 for ; Sat, 3 Jun 1995 17:33:36 -0700 Received: from ip217.sna.primenet.com (ip217.sna.primenet.com [204.212.53.217]) by mailhost.primenet.com (8.6.11/wjp-h2.0) with SMTP id RAA11626 for ; Sat, 3 Jun 1995 17:33:32 -0700 Date: Sat, 3 Jun 1995 17:33:32 -0700 Message-Id: <199506040033.RAA11626@mailhost.primenet.com> X-Sender: sjs1@mailhost.primenet.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: freebsd-bugs@FreeBSD.org From: sjs1@primenet.com (Scott Story) Subject: NCR53c400 Magoptic Problem Sender: bugs-owner@FreeBSD.org Precedence: bulk >Scott Story writes: >> >> Any help or a refferal would be apprieciated. >> I am trying to install freeBSD 2.0 on to a SCSI 1 Sony MagOptic drive. >> (486,33 one SCSI device) >> These are the messages I am getting. >> Durring kernel boot: >> nca1: NCR-53C400 >> nca1: wating for SCSI devices to settle >> nca1: "Sony SMO-C501-00 2.22" is a type 0 removeable SCSI 1 >> sd0 (nca1) Direct Access >> sd0 (nca1) Illegal Request ASC:24,0 invalid field in CDB >> sdo could not mode sense (4), Using Fictitious Geometry, 281 (576999, 512 >> byte sectors) > >Does this happen even if you have the formatted media installed? YES with 512 Media There is 512 or 1024 byte sector media for the SMO501. > >> During sysinstall >> >> Select Complete install >> >> nca1/0/0/sd0/timed out >> Fatal Trap 12: page fault in kernel mode >> Fault Address=0x8 >> Fault Code=supervisor read, page np >> install pointer=0x8:0xf0172c1b >> code sequence= base 0x0, limit 0xfffff, type ox1b=DPL 0,pres 1, def 32, gran 1 >> Processor eflags=interupt enabled, resume,10 PL=0 >> Current Process= 1 (sysinstall) >> int. mask= bio >> panic=page fault > >Oops. Do you have a stack back trace? NO stack back trace. >-- >Peter Dufault Real Time Machine Control and Simulation >HD Associates, Inc. Voice: 508 433 6936 >dufault@hda.com Fax: 508 433 5267 > > I want to die quietly in my sleep like my grandfather, NOT screaming, like his passengers! From owner-freebsd-bugs Sat Jun 3 18:08:24 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA24468 for bugs-outgoing; Sat, 3 Jun 1995 18:08:24 -0700 Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id SAA24460 for ; Sat, 3 Jun 1995 18:08:23 -0700 Received: from limbic.ssdl.com (limbic.ssdl.com [192.111.251.33]) by who.cdrom.com (8.6.11/8.6.11) with ESMTP id SAA12425 for ; Sat, 3 Jun 1995 18:00:36 -0700 Received: (from gil@localhost) by limbic.ssdl.com (8.6.11/8.6.6) id UAA17089 for bugs@freebsd.org; Sat, 3 Jun 1995 20:03:20 -0500 From: "Gil Kloepfer Jr." Message-Id: <199506040103.UAA17089@limbic.ssdl.com> Subject: Invalid variable format????? To: bugs@FreeBSD.org Date: Sat, 3 Jun 1995 20:03:19 -0500 (CDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 359 Sender: bugs-owner@FreeBSD.org Precedence: bulk This is the June 3, 12:06pm floppies: DEBUG: Scanning disk wd0 for root filesystem DEBUG: Scanning disk wd0 for swap partitions DEBUG: Scanning disk wd1 for swap partitions DEBUG: Fatal error: `Fatal error: Invalid variable format: '! Main screen says to PRESS ANY KEY TO REBOOT -- Gil Kloepfer e-mail: gil@SSDL.COM WWW: http://www.ssdl.com/~gil/ From owner-freebsd-bugs Sat Jun 3 18:55:41 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA05466 for bugs-outgoing; Sat, 3 Jun 1995 18:55:41 -0700 Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id SAA05455 ; Sat, 3 Jun 1995 18:55:39 -0700 X-Authentication-Warning: freefall.cdrom.com: Host localhost.cdrom.com didn't use HELO protocol To: "Gil Kloepfer Jr." cc: bugs@FreeBSD.org Subject: Re: Invalid variable format????? In-reply-to: Your message of "Sat, 03 Jun 95 20:03:19 CDT." <199506040103.UAA17089@limbic.ssdl.com> Date: Sat, 03 Jun 1995 18:55:39 -0700 Message-ID: <5454.802230939@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: bugs-owner@FreeBSD.org Precedence: bulk Fixed it. This was a bogus result of selecting `None' for the boot manager. > This is the June 3, 12:06pm floppies: > > DEBUG: Scanning disk wd0 for root filesystem > DEBUG: Scanning disk wd0 for swap partitions > DEBUG: Scanning disk wd1 for swap partitions > DEBUG: Fatal error: `Fatal error: Invalid variable format: '! > > Main screen says to PRESS ANY KEY TO REBOOT > > -- > Gil Kloepfer > e-mail: gil@SSDL.COM > WWW: http://www.ssdl.com/~gil/ From owner-freebsd-bugs Sat Jun 3 23:52:21 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id XAA20536 for bugs-outgoing; Sat, 3 Jun 1995 23:52:21 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id XAA20490 for ; Sat, 3 Jun 1995 23:52:17 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA20610; Sun, 4 Jun 1995 08:52:15 +0200 Received: by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id IAA27886; Sun, 4 Jun 1995 08:52:13 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id IAA26049; Sun, 4 Jun 1995 08:45:16 +0200 From: J Wunsch Message-Id: <199506040645.IAA26049@uriah.heep.sax.de> Subject: Re: Hey Neato To: henrich@crh.cl.msu.edu (Charles Henrich) Date: Sun, 4 Jun 1995 08:45:16 +0200 (MET DST) Cc: freebsd-bugs@FreeBSD.org In-Reply-To: <199506031930.MAA16236@freefall.cdrom.com> from "Charles Henrich" at Jun 3, 95 03:30:14 pm Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 322 Sender: bugs-owner@FreeBSD.org Precedence: bulk As Charles Henrich wrote: > > I have a strange bug, if I cd to /stand and run ./sysinstall the machine panics > and reboots.. Don't you think this is a bit few on information? -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-)