From owner-freebsd-bugs Sun Sep 28 04:30:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA26447 for bugs-outgoing; Sun, 28 Sep 1997 04:30:07 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA26436; Sun, 28 Sep 1997 04:30:02 -0700 (PDT) Resent-Date: Sun, 28 Sep 1997 04:30:02 -0700 (PDT) Resent-Message-Id: <199709281130.EAA26436@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, rb@gid.co.uk Received: from isbalham.ist.co.uk (isbalham.ist.co.uk [192.31.26.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA26218 for ; Sun, 28 Sep 1997 04:21:11 -0700 (PDT) Received: from gid.co.uk (uucp@localhost) by isbalham.ist.co.uk (8.8.4/8.8.4) with UUCP id MAA26571 for freebsd.org!FreeBSD-gnats-submit; Sun, 28 Sep 1997 12:11:15 +0100 (BST) Message-Id: <12830.199709281108@seagoon.gid.co.uk> Date: Sun, 28 Sep 1997 12:08:44 +0100 From: Bob Bishop Reply-To: rb@gid.co.uk To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: misc/4646: Can't fixit with an NFS-mounted CD. Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4646 >Category: misc >Synopsis: Can't fixit with an NFS-mounted CD. >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Class: change-request >Submitter-Id: current-users >Arrival-Date: Sun Sep 28 04:30:01 PDT 1997 >Last-Modified: >Originator: Bob Bishop >Organization: GID ltd >Release: FreeBSD 2.2.2-RELEASE i386 >Environment: No CD drive on machine >Description: Sysinstall doesn't offer the ability to go into fixit mode using an NFS-mounted CD. This would be *really useful* on machines with no CDROM drive. >How-To-Repeat: Boot from the install floppy; select fixit; observe the contents of the menu; swear profusely. >Fix: You can of course do it by hand from the holographic shell. >Audit-Trail: >Unformatted: From owner-freebsd-bugs Sun Sep 28 04:34:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA26632 for bugs-outgoing; Sun, 28 Sep 1997 04:34:53 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA26619; Sun, 28 Sep 1997 04:34:46 -0700 (PDT) From: Martin Cracauer Received: (from cracauer@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id EAA23493; Sun, 28 Sep 1997 04:29:34 -0700 (PDT) Date: Sun, 28 Sep 1997 04:29:34 -0700 (PDT) Message-Id: <199709281129.EAA23493@freefall.freebsd.org> To: tri@pooh.tky.hut.fi, cracauer@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: bin/4625 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: fetch(3) doesn't get asctime(3) format State-Changed-From-To: open-closed State-Changed-By: cracauer State-Changed-When: Sun Sep 28 04:28:12 PDT 1997 State-Changed-Why: Provided patch reviewed and commited. Thanks! Martin From owner-freebsd-bugs Sun Sep 28 09:20:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA11240 for bugs-outgoing; Sun, 28 Sep 1997 09:20:06 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA11196; Sun, 28 Sep 1997 09:20:02 -0700 (PDT) Resent-Date: Sun, 28 Sep 1997 09:20:02 -0700 (PDT) Resent-Message-Id: <199709281620.JAA11196@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, blank@fox.uni-trier.de Received: from sliphost37.uni-trier.de (blank@sliphost37.uni-trier.de [136.199.240.37]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA10753 for ; Sun, 28 Sep 1997 09:13:29 -0700 (PDT) Received: (from blank@localhost) by sliphost37.uni-trier.de (8.8.7/8.8.7) id SAA00484; Sun, 28 Sep 1997 18:12:42 +0200 (CEST) Message-Id: <199709281612.SAA00484@sliphost37.uni-trier.de> Date: Sun, 28 Sep 1997 18:12:42 +0200 (CEST) From: blank@fox.uni-trier.de (Sascha Blank) Reply-To: blank@fox.uni-trier.de To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: docs/4647: Wrong relnote for upcoming 2.2.5-RELEASE in sysinstall Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4647 >Category: docs >Synopsis: Wrong relnote for upcoming 2.2.5-RELEASE in sysinstall >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-bugs >State: open >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Sun Sep 28 09:20:01 PDT 1997 >Last-Modified: >Originator: Sascha Blank >Organization: >Release: FreeBSD 2.2-STABLE i386 >Environment: A very recent 2.2-STABLE system. The file /usr/src/release/sysinstall/help/relnotes.hlp has no version tag. Therefore I give a md5 sum instead: MD5 (help/relnotes.hlp) = 6fa9ab94eca22f9063db4d9453f35f69 >Description: The relnotes mention in the paragraph "What's new since 2.2.2" the "Support for parallel port ZIP drives as well as a new parallel port 'bus' architecture for devices sharing the printer port". This statement only applies to 3.0-CURRENT, but neither to 2.2-STABLE nor to the upcoming 2.2.5-RELEASE. And with the beginning of the code freeze for 2.2.5 only hours away it is highly unlikely that it will be introduced as a last minute act. >How-To-Repeat: >Fix: The statement should be removed from the relnotes so that users will not get the impression that a stock 2.2.5-RELEASE is able to handle ZIP-Drives connected to the parallel port. -- Sascha Blank - mailto:blank@fox.uni-trier.de Student and System Administrator at the University of Trier, Germany Finger my account to receive my Public PGP key I don't speak for my employers, they don't pay me enough for that. >Audit-Trail: >Unformatted: From owner-freebsd-bugs Sun Sep 28 09:20:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA11283 for bugs-outgoing; Sun, 28 Sep 1997 09:20:15 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA11237; Sun, 28 Sep 1997 09:20:07 -0700 (PDT) Resent-Date: Sun, 28 Sep 1997 09:20:07 -0700 (PDT) Resent-Message-Id: <199709281620.JAA11237@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, blank@fox.uni-trier.de Received: from sliphost37.uni-trier.de (blank@sliphost37.uni-trier.de [136.199.240.37]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA10757 for ; Sun, 28 Sep 1997 09:13:32 -0700 (PDT) Received: (from blank@localhost) by sliphost37.uni-trier.de (8.8.7/8.8.7) id RAA00361; Sun, 28 Sep 1997 17:58:49 +0200 (CEST) Message-Id: <199709281558.RAA00361@sliphost37.uni-trier.de> Date: Sun, 28 Sep 1997 17:58:49 +0200 (CEST) From: blank@fox.uni-trier.de (Sascha Blank) Reply-To: blank@fox.uni-trier.de To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: bin/4648: Double menu entry in 2.2-STABLE's sysinstall Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4648 >Category: bin >Synopsis: Double menu entry in 2.2-STABLE's sysinystall >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Sep 28 09:20:03 PDT 1997 >Last-Modified: >Originator: Sascha Blank >Organization: >Release: FreeBSD 2.2-STABLE i386 >Environment: A very recent 2.2-STABLE system. /usr/src/release/sysinstall/menus.c: $Id: menus.c,v 1.89.2.49 1997/09/16 18:58:57 jkh Exp $ >Description: The menu entry "Root Password" appears twice in the Index menu of sysinstall. >How-To-Repeat: >Fix: *** menus.c.ctm Sun Sep 28 17:49:59 1997 --- menus.c Sun Sep 28 17:50:05 1997 *************** *** 274,280 **** { "PCNFSD", "Run authentication server for PC-NFS.", dmenuVarCheck, configPCNFSD, NULL, "pcnfsd" }, { "Register", "Register yourself or company as a FreeBSD user.", dmenuVarCheck, configRegister, NULL, "registered" }, { "Root Password", "Set the system manager's password.", NULL, dmenuSystemCommand, NULL, "passwd root" }, - { "Root Password", "Set the system manager's password.", NULL, dmenuSystemCommand, NULL, "passwd root" }, { "Router", "Select routing daemon (default: routed)", NULL, configRouter, NULL, "router" }, { "Syscons", "The system console configuration menu.", NULL, dmenuSubmenu, NULL, &MenuSyscons }, { "Syscons, Font", "The console screen font.", NULL, dmenuSubmenu, NULL, &MenuSysconsFont }, --- 274,279 ---- -- Sascha Blank - mailto:blank@fox.uni-trier.de Student and System Administrator at the University of Trier, Germany Finger my account to receive my Public PGP key I don't speak for my employers, they don't pay me enough for that. >Audit-Trail: >Unformatted: From owner-freebsd-bugs Sun Sep 28 11:49:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA17418 for bugs-outgoing; Sun, 28 Sep 1997 11:49:32 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA17402; Sun, 28 Sep 1997 11:49:20 -0700 (PDT) From: "Jordan K. Hubbard" Received: (from jkh@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id LAA09950; Sun, 28 Sep 1997 11:44:05 -0700 (PDT) Date: Sun, 28 Sep 1997 11:44:05 -0700 (PDT) Message-Id: <199709281844.LAA09950@freefall.freebsd.org> To: blank@fox.uni-trier.de, jkh@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: docs/4647 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: Wrong relnote for upcoming 2.2.5-RELEASE in sysinstall State-Changed-From-To: open-closed State-Changed-By: jkh State-Changed-When: Sun Sep 28 11:43:51 PDT 1997 State-Changed-Why: Fix applied. From owner-freebsd-bugs Sun Sep 28 11:49:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA17464 for bugs-outgoing; Sun, 28 Sep 1997 11:49:48 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA17445; Sun, 28 Sep 1997 11:49:40 -0700 (PDT) From: "Jordan K. Hubbard" Received: (from jkh@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id LAA10030; Sun, 28 Sep 1997 11:44:25 -0700 (PDT) Date: Sun, 28 Sep 1997 11:44:25 -0700 (PDT) Message-Id: <199709281844.LAA10030@freefall.freebsd.org> To: blank@fox.uni-trier.de, jkh@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: bin/4648 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: Double menu entry in 2.2-STABLE's sysinystall State-Changed-From-To: open-closed State-Changed-By: jkh State-Changed-When: Sun Sep 28 11:44:12 PDT 1997 State-Changed-Why: Fix applied. From owner-freebsd-bugs Sun Sep 28 15:02:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA25822 for bugs-outgoing; Sun, 28 Sep 1997 15:02:56 -0700 (PDT) Received: from pat.idi.ntnu.no (0@pat.idi.ntnu.no [129.241.103.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA25809; Sun, 28 Sep 1997 15:02:46 -0700 (PDT) Received: from idt.unit.no (tegge@ikke.idi.ntnu.no [129.241.111.65]) by pat.idi.ntnu.no (8.8.6/8.8.6) with ESMTP id AAA27999; Mon, 29 Sep 1997 00:02:38 +0200 (MET DST) Message-Id: <199709282202.AAA27999@pat.idi.ntnu.no> To: FreeBSD-gnats-submit@FreeBSD.ORG cc: freebsd-bugs@FreeBSD.ORG Subject: Re: kern/4630: buffer_map might become corrupted In-Reply-To: Your message of "Thu, 25 Sep 1997 22:36:41 +0200 (CEST)" References: <199709252036.WAA19179@skarven.itea.ntnu.no> X-Mailer: Mew version 1.70 on Emacs 19.34.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 29 Sep 1997 00:02:37 +0200 From: Tor Egge Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk A new crash. ----- (kgdb) print intr_nesting_level $1 = 2 (kgdb) where #0 boot (howto=260) at ../../kern/kern_shutdown.c:266 #1 0xe0117676 in panic (fmt=0xe01b0013 "vm_map_entry_dispose in interrupt") at ../../kern/kern_shutdown.c:393 #2 0xe01b009b in vm_map_entry_dispose (map=0xe25a1f00, entry=0xe3c4c2c0) at ../../vm/vm_map.c:344 #3 0xe01b09af in vm_map_simplify_entry (map=0xe25a1f00, entry=0xe3e16640) at ../../vm/vm_map.c:883 #4 0xe01b0a7d in _vm_map_clip_start (map=0xe25a1f00, entry=0xe3e16640, start=3881472000) at ../../vm/vm_map.c:943 #5 0xe01b1f6e in vm_map_delete (map=0xe25a1f00, start=3881472000, end=3881480192) at ../../vm/vm_map.c:1891 #6 0xe012fe0d in bfreekva (bp=0xe7015f94) at ../../kern/vfs_bio.c:240 #7 0xe01307ec in brelse (bp=0xe7015f94) at ../../kern/vfs_bio.c:696 #8 0xe0132150 in biodone (bp=0xe7015f94) at ../../kern/vfs_bio.c:1888 #9 0xe0101610 in ccdintr (cs=0xe2faf198, bp=0xe7015f94) at ../../dev/ccd/ccd.c:966 #10 0xe01016ea in ccdiodone (cbp=0xe3caae00) at ../../dev/ccd/ccd.c:1026 #11 0xe0131f04 in biodone (bp=0xe3caae00) at ../../kern/vfs_bio.c:1774 #12 0xe019846c in scsi_done (xs=0xe3e1a480) at ../../scsi/scsi_base.c:450 #13 0xe01f292c in ahc_done (ahc=0xe2fa5000, scb=0xe336e300) at ../../i386/scsi/aic7xxx.c:1969 #14 0xe01f0497 in ahc_intr (arg=0xe2fa5000) at ../../i386/scsi/aic7xxx.c:843 #15 0xe0119160 in tsleep (ident=0xe35e0fb8, priority=17, wmesg=0xe01a4a2a "ffsfsn", timo=0) at ../../kern/kern_synch.c:330 #16 0xe01a4b3d in ffs_fsync (ap=0xe9478ce8) at ../../ufs/ffs/ffs_vnops.c:313 #17 0xe01b45b2 in vm_object_page_clean (object=0xe375f680, start=0, end=0, syncio=1, lockflag=1) at vnode_if.h:479 #18 0xe0136cd6 in vfs_msync (mp=0xe3083800, flags=2) at ../../kern/vfs_subr.c:2127 #19 0xe01376d4 in sync (p=0xe021c670, uap=0x0, retval=0x0) at ../../kern/vfs_syscalls.c:479 #20 0xe0117251 in boot (howto=256) at ../../kern/kern_shutdown.c:203 #21 0xe0117676 in panic (fmt=0xe01b0013 "vm_map_entry_dispose in interrupt") at ../../kern/kern_shutdown.c:393 #22 0xe01b009b in vm_map_entry_dispose (map=0xe25a1f00, entry=0xe34af280) at ../../vm/vm_map.c:344 #23 0xe01b09af in vm_map_simplify_entry (map=0xe25a1f00, entry=0xe3ac1700) at ../../vm/vm_map.c:883 #24 0xe01b0a7d in _vm_map_clip_start (map=0xe25a1f00, entry=0xe3ac1700, start=3882176512) at ../../vm/vm_map.c:943 #25 0xe01b1f6e in vm_map_delete (map=0xe25a1f00, start=3882176512, end=3882184704) at ../../vm/vm_map.c:1891 #26 0xe012fe0d in bfreekva (bp=0xe700e064) at ../../kern/vfs_bio.c:240 #27 0xe01307ec in brelse (bp=0xe700e064) at ../../kern/vfs_bio.c:696 #28 0xe0132150 in biodone (bp=0xe700e064) at ../../kern/vfs_bio.c:1888 #29 0xe0101610 in ccdintr (cs=0xe2faf198, bp=0xe700e064) at ../../dev/ccd/ccd.c:966 #30 0xe01016ea in ccdiodone (cbp=0xe37cb300) at ../../dev/ccd/ccd.c:1026 #31 0xe0131f04 in biodone (bp=0xe37cb300) at ../../kern/vfs_bio.c:1774 #32 0xe019846c in scsi_done (xs=0xe30eee00) at ../../scsi/scsi_base.c:450 #33 0xe01f292c in ahc_done (ahc=0xe2fa5000, scb=0xe336e300) at ../../i386/scsi/aic7xxx.c:1969 #34 0xe01f0497 in ahc_intr (arg=0xe2fa5000) at ../../i386/scsi/aic7xxx.c:843 #35 0x3d51 in ?? () ----- This means that both vm_map_entry_dispose and vm_map_entry_create might be called in an interrupt context, manipulating buffer_map and the free pool of vm map entries. A simple spl protection of vm_map_entry_dispose/vm_map_entry_create is not sufficient. For 2.2-STABLE, MALLOC might be called with M_WAITOK during during the interrupt (vm_map_entry_create -> MALLOC) For CURRENT, kmem_alloc might be called during an interrupt. (vm_map_entry_create -> zalloc -> _zalloc -> _zget -> kmem_alloc) Thus, it might be better to not call bfreekva in brelse if it occurs during an interrupt. An alternate solution is to not call brelse in biodone, but instead push the buffer onto a list that is emptied by a dedicated high priority kernel process. - Tor Egge From owner-freebsd-bugs Sun Sep 28 15:10:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA26068 for bugs-outgoing; Sun, 28 Sep 1997 15:10:10 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA26061; Sun, 28 Sep 1997 15:10:02 -0700 (PDT) Date: Sun, 28 Sep 1997 15:10:02 -0700 (PDT) Message-Id: <199709282210.PAA26061@hub.freebsd.org> To: freebsd-bugs Cc: From: Tor Egge Subject: Re: kern/4630: buffer_map might become corrupted Reply-To: Tor Egge Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The following reply was made to PR kern/4630; it has been noted by GNATS. From: Tor Egge To: FreeBSD-gnats-submit@FreeBSD.ORG Cc: freebsd-bugs@FreeBSD.ORG Subject: Re: kern/4630: buffer_map might become corrupted Date: Mon, 29 Sep 1997 00:02:37 +0200 A new crash. ----- (kgdb) print intr_nesting_level $1 = 2 (kgdb) where #0 boot (howto=260) at ../../kern/kern_shutdown.c:266 #1 0xe0117676 in panic (fmt=0xe01b0013 "vm_map_entry_dispose in interrupt") at ../../kern/kern_shutdown.c:393 #2 0xe01b009b in vm_map_entry_dispose (map=0xe25a1f00, entry=0xe3c4c2c0) at ../../vm/vm_map.c:344 #3 0xe01b09af in vm_map_simplify_entry (map=0xe25a1f00, entry=0xe3e16640) at ../../vm/vm_map.c:883 #4 0xe01b0a7d in _vm_map_clip_start (map=0xe25a1f00, entry=0xe3e16640, start=3881472000) at ../../vm/vm_map.c:943 #5 0xe01b1f6e in vm_map_delete (map=0xe25a1f00, start=3881472000, end=3881480192) at ../../vm/vm_map.c:1891 #6 0xe012fe0d in bfreekva (bp=0xe7015f94) at ../../kern/vfs_bio.c:240 #7 0xe01307ec in brelse (bp=0xe7015f94) at ../../kern/vfs_bio.c:696 #8 0xe0132150 in biodone (bp=0xe7015f94) at ../../kern/vfs_bio.c:1888 #9 0xe0101610 in ccdintr (cs=0xe2faf198, bp=0xe7015f94) at ../../dev/ccd/ccd.c:966 #10 0xe01016ea in ccdiodone (cbp=0xe3caae00) at ../../dev/ccd/ccd.c:1026 #11 0xe0131f04 in biodone (bp=0xe3caae00) at ../../kern/vfs_bio.c:1774 #12 0xe019846c in scsi_done (xs=0xe3e1a480) at ../../scsi/scsi_base.c:450 #13 0xe01f292c in ahc_done (ahc=0xe2fa5000, scb=0xe336e300) at ../../i386/scsi/aic7xxx.c:1969 #14 0xe01f0497 in ahc_intr (arg=0xe2fa5000) at ../../i386/scsi/aic7xxx.c:843 #15 0xe0119160 in tsleep (ident=0xe35e0fb8, priority=17, wmesg=0xe01a4a2a "ffsfsn", timo=0) at ../../kern/kern_synch.c:330 #16 0xe01a4b3d in ffs_fsync (ap=0xe9478ce8) at ../../ufs/ffs/ffs_vnops.c:313 #17 0xe01b45b2 in vm_object_page_clean (object=0xe375f680, start=0, end=0, syncio=1, lockflag=1) at vnode_if.h:479 #18 0xe0136cd6 in vfs_msync (mp=0xe3083800, flags=2) at ../../kern/vfs_subr.c:2127 #19 0xe01376d4 in sync (p=0xe021c670, uap=0x0, retval=0x0) at ../../kern/vfs_syscalls.c:479 #20 0xe0117251 in boot (howto=256) at ../../kern/kern_shutdown.c:203 #21 0xe0117676 in panic (fmt=0xe01b0013 "vm_map_entry_dispose in interrupt") at ../../kern/kern_shutdown.c:393 #22 0xe01b009b in vm_map_entry_dispose (map=0xe25a1f00, entry=0xe34af280) at ../../vm/vm_map.c:344 #23 0xe01b09af in vm_map_simplify_entry (map=0xe25a1f00, entry=0xe3ac1700) at ../../vm/vm_map.c:883 #24 0xe01b0a7d in _vm_map_clip_start (map=0xe25a1f00, entry=0xe3ac1700, start=3882176512) at ../../vm/vm_map.c:943 #25 0xe01b1f6e in vm_map_delete (map=0xe25a1f00, start=3882176512, end=3882184704) at ../../vm/vm_map.c:1891 #26 0xe012fe0d in bfreekva (bp=0xe700e064) at ../../kern/vfs_bio.c:240 #27 0xe01307ec in brelse (bp=0xe700e064) at ../../kern/vfs_bio.c:696 #28 0xe0132150 in biodone (bp=0xe700e064) at ../../kern/vfs_bio.c:1888 #29 0xe0101610 in ccdintr (cs=0xe2faf198, bp=0xe700e064) at ../../dev/ccd/ccd.c:966 #30 0xe01016ea in ccdiodone (cbp=0xe37cb300) at ../../dev/ccd/ccd.c:1026 #31 0xe0131f04 in biodone (bp=0xe37cb300) at ../../kern/vfs_bio.c:1774 #32 0xe019846c in scsi_done (xs=0xe30eee00) at ../../scsi/scsi_base.c:450 #33 0xe01f292c in ahc_done (ahc=0xe2fa5000, scb=0xe336e300) at ../../i386/scsi/aic7xxx.c:1969 #34 0xe01f0497 in ahc_intr (arg=0xe2fa5000) at ../../i386/scsi/aic7xxx.c:843 #35 0x3d51 in ?? () ----- This means that both vm_map_entry_dispose and vm_map_entry_create might be called in an interrupt context, manipulating buffer_map and the free pool of vm map entries. A simple spl protection of vm_map_entry_dispose/vm_map_entry_create is not sufficient. For 2.2-STABLE, MALLOC might be called with M_WAITOK during during the interrupt (vm_map_entry_create -> MALLOC) For CURRENT, kmem_alloc might be called during an interrupt. (vm_map_entry_create -> zalloc -> _zalloc -> _zget -> kmem_alloc) Thus, it might be better to not call bfreekva in brelse if it occurs during an interrupt. An alternate solution is to not call brelse in biodone, but instead push the buffer onto a list that is emptied by a dedicated high priority kernel process. - Tor Egge From owner-freebsd-bugs Sun Sep 28 22:10:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA16946 for bugs-outgoing; Sun, 28 Sep 1997 22:10:05 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA16935; Sun, 28 Sep 1997 22:10:01 -0700 (PDT) Resent-Date: Sun, 28 Sep 1997 22:10:01 -0700 (PDT) Resent-Message-Id: <199709290510.WAA16935@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, nsayer@quack.kfu.com Received: from quack.kfu.com (0@quack.kfu.com [204.147.226.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA16880 for ; Sun, 28 Sep 1997 22:08:47 -0700 (PDT) Received: from icarus.kfu.com (icarus.kfu.com [204.147.226.3]) by quack.kfu.com (8.8.5/8.8.5) with ESMTP id WAA11240 for ; Sun, 28 Sep 1997 22:08:45 -0700 (PDT) Received: by icarus.kfu.com (8.8.2//ident-1.0) id WAA09986; Sun, 28 Sep 1997 22:08:44 -0700 (PDT) Message-Id: <199709290508.WAA09986@icarus.kfu.com> Date: Sun, 28 Sep 1997 22:08:44 -0700 (PDT) From: Reply-To: nsayer@quack.kfu.com To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: kern/4650: Cirrus Logic pcic chips need audio bit & LPDM bit set. Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4650 >Category: kern >Synopsis: Cirrus Logic pcic chips need audio bit & LPDM bit set >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-bugs >State: open >Class: support >Submitter-Id: current-users >Arrival-Date: Sun Sep 28 22:10:00 PDT 1997 >Last-Modified: >Originator: Nick Sayer >Organization: >Release: FreeBSD 2.2.2-RELEASE i386 >Environment: Laptops (or desktops) with Cirrus Logic PD672x chipsets. >Description: PCMCIA modem cards send the speaker audio (dialing noises) to the host to be sent to the speaker. Cirrus Logic PCIC chips have a bit to enable or disable this, and it is disabled by default. There is also a Low Power Dynamic Mode bit (this one is one per chip rather than one per slot, but it doesn't hurt to set it per slot - extras are ignored) that the docco claims will reduce PCIC power consumption by 30% or so. I have seen no ill effects from turning this bit on. >How-To-Repeat: >Fix: *** pcic.c.orig Sun Jul 6 09:11:53 1997 --- pcic.c Sun Jul 6 10:19:03 1997 *************** *** 949,954 **** --- 949,961 ---- printf("pcic: controller irq %d\n", pcic_irq); } #endif /* PCIC_NO_IRQ */ + #ifndef NOCIRRUSHACK + if (sp->controller == PCIC_PD672X) + { + setb (sp, PCIC_MISC1, PCIC_SPKR_EN); + setb (sp, PCIC_MISC2, PCIC_LPDM_EN); + } + #endif /* * Check for a card in this slot. */ *************** *** 1331,1334 **** --- 1338,1348 ---- if (pcic_irq > 0) sp->putb(sp, PCIC_STAT_INT, (pcic_irq << 4) | 0xF); + #ifndef NOCIRRUSHACK + if (sp->controller == PCIC_PD672X) + { + setb (sp, PCIC_MISC1, PCIC_SPKR_EN); + setb (sp, PCIC_MISC2, PCIC_LPDM_EN); + } + #endif } *** i82365.h.orig Sun Jul 6 09:11:52 1997 --- i82365.h Sun Jul 6 09:15:04 1997 *************** *** 84,90 **** --- 84,92 ---- #define PCIC_IO1 0x0c /* I/O Address 1 */ #define PCIC_MEMBASE 0x10 /* Base of memory window registers */ #define PCIC_CDGC 0x16 /* Card Detect and General Control */ + #define PCIC_MISC1 0x16 /* PD672x: Misc control register 1 per slot */ #define PCIC_GLO_CTRL 0x1e /* Global Control Register */ + #define PCIC_MISC2 0x1e /* PD672x: Misc control register 2 per chip */ #define PCIC_TIME_SETUP0 0x3a #define PCIC_TIME_CMD0 0x3b *************** *** 205,210 **** --- 207,215 ---- #define PCIC_CDRES_EN 0x10 /* card detect resume enable */ #define PCIC_SW_CD_INT 0x20 /* s/w card detect interrupt */ + /* For Misc. Control Register 1 */ + #define PCIC_SPKR_EN 0x10 /* Cirrus PD672x: speaker enable */ + /* For Global Control register (PCIC_GLO_CTRL) */ #define PCIC_PWR_DOWN 0x01 /* power down */ #define PCIC_LVL_MODE 0x02 /* level mode interrupt enable */ *************** *** 212,217 **** --- 217,224 ---- #define PCIC_IRQ0_LEVEL 0x08 /* irq 14 pulse mode enable */ #define PCIC_IRQ1_LEVEL 0x10 + /* For Misc. Control Register 2 */ + #define PCIC_LPDM_EN 0x02 /* Cirrus PD672x: low power dynamic mode */ /* * Mask of allowable interrupts. * Ints are 3,4,5,7,9,10,11,12,14,15 >Audit-Trail: >Unformatted: From owner-freebsd-bugs Sun Sep 28 22:19:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA17300 for bugs-outgoing; Sun, 28 Sep 1997 22:19:02 -0700 (PDT) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA17282; Sun, 28 Sep 1997 22:18:45 -0700 (PDT) Received: from spinner.netplex.com.au (localhost.dialix.com.au [127.0.0.1]) by spinner.netplex.com.au with ESMTP id NAA08603; Mon, 29 Sep 1997 13:18:23 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199709290518.NAA08603@spinner.netplex.com.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Tor Egge cc: FreeBSD-gnats-submit@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG, dyson@FreeBSD.ORG Subject: Re: kern/4630: buffer_map might become corrupted In-reply-to: Your message of "Mon, 29 Sep 1997 00:02:37 +0200." <199709282202.AAA27999@pat.idi.ntnu.no> Date: Mon, 29 Sep 1997 13:18:22 +0800 From: Peter Wemm Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Tor Egge wrote: > A new crash. > > ----- > (kgdb) print intr_nesting_level > $1 = 2 > (kgdb) where > #0 boot (howto=260) at ../../kern/kern_shutdown.c:266 > #1 0xe0117676 in panic (fmt=0xe01b0013 "vm_map_entry_dispose in interrupt") > at ../../kern/kern_shutdown.c:393 > #2 0xe01b009b in vm_map_entry_dispose (map=0xe25a1f00, entry=0xe3c4c2c0) > at ../../vm/vm_map.c:344 > #3 0xe01b09af in vm_map_simplify_entry (map=0xe25a1f00, entry=0xe3e16640) > at ../../vm/vm_map.c:883 > #4 0xe01b0a7d in _vm_map_clip_start (map=0xe25a1f00, entry=0xe3e16640, > start=3881472000) at ../../vm/vm_map.c:943 > #5 0xe01b1f6e in vm_map_delete (map=0xe25a1f00, start=3881472000, > end=3881480192) at ../../vm/vm_map.c:1891 > #6 0xe012fe0d in bfreekva (bp=0xe7015f94) at ../../kern/vfs_bio.c:240 > #7 0xe01307ec in brelse (bp=0xe7015f94) at ../../kern/vfs_bio.c:696 > #8 0xe0132150 in biodone (bp=0xe7015f94) at ../../kern/vfs_bio.c:1888 > #9 0xe0101610 in ccdintr (cs=0xe2faf198, bp=0xe7015f94) > at ../../dev/ccd/ccd.c:966 > #10 0xe01016ea in ccdiodone (cbp=0xe3caae00) at ../../dev/ccd/ccd.c:1026 > #11 0xe0131f04 in biodone (bp=0xe3caae00) at ../../kern/vfs_bio.c:1774 > #12 0xe019846c in scsi_done (xs=0xe3e1a480) at ../../scsi/scsi_base.c:450 > #13 0xe01f292c in ahc_done (ahc=0xe2fa5000, scb=0xe336e300) > at ../../i386/scsi/aic7xxx.c:1969 > #14 0xe01f0497 in ahc_intr (arg=0xe2fa5000) at ../../i386/scsi/aic7xxx.c:843 > #15 0xe0119160 in tsleep (ident=0xe35e0fb8, priority=17, > wmesg=0xe01a4a2a "ffsfsn", timo=0) at ../../kern/kern_synch.c:330 > #16 0xe01a4b3d in ffs_fsync (ap=0xe9478ce8) at ../../ufs/ffs/ffs_vnops.c:313 > #17 0xe01b45b2 in vm_object_page_clean (object=0xe375f680, start=0, end=0, > syncio=1, lockflag=1) at vnode_if.h:479 > #18 0xe0136cd6 in vfs_msync (mp=0xe3083800, flags=2) > at ../../kern/vfs_subr.c:2127 > #19 0xe01376d4 in sync (p=0xe021c670, uap=0x0, retval=0x0) > at ../../kern/vfs_syscalls.c:479 > #20 0xe0117251 in boot (howto=256) at ../../kern/kern_shutdown.c:203 > #21 0xe0117676 in panic (fmt=0xe01b0013 "vm_map_entry_dispose in interrupt") ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > at ../../kern/kern_shutdown.c:393 > #22 0xe01b009b in vm_map_entry_dispose (map=0xe25a1f00, entry=0xe34af280) > at ../../vm/vm_map.c:344 > #23 0xe01b09af in vm_map_simplify_entry (map=0xe25a1f00, entry=0xe3ac1700) > at ../../vm/vm_map.c:883 > #24 0xe01b0a7d in _vm_map_clip_start (map=0xe25a1f00, entry=0xe3ac1700, > start=3882176512) at ../../vm/vm_map.c:943 > #25 0xe01b1f6e in vm_map_delete (map=0xe25a1f00, start=3882176512, > end=3882184704) at ../../vm/vm_map.c:1891 > #26 0xe012fe0d in bfreekva (bp=0xe700e064) at ../../kern/vfs_bio.c:240 > #27 0xe01307ec in brelse (bp=0xe700e064) at ../../kern/vfs_bio.c:696 > #28 0xe0132150 in biodone (bp=0xe700e064) at ../../kern/vfs_bio.c:1888 > #29 0xe0101610 in ccdintr (cs=0xe2faf198, bp=0xe700e064) > at ../../dev/ccd/ccd.c:966 > #30 0xe01016ea in ccdiodone (cbp=0xe37cb300) at ../../dev/ccd/ccd.c:1026 > #31 0xe0131f04 in biodone (bp=0xe37cb300) at ../../kern/vfs_bio.c:1774 > #32 0xe019846c in scsi_done (xs=0xe30eee00) at ../../scsi/scsi_base.c:450 > #33 0xe01f292c in ahc_done (ahc=0xe2fa5000, scb=0xe336e300) > at ../../i386/scsi/aic7xxx.c:1969 > #34 0xe01f0497 in ahc_intr (arg=0xe2fa5000) at ../../i386/scsi/aic7xxx.c:843 ^^^^^^^^^^^^^^^^^^^ > #35 0x3d51 in ?? () > ----- > > This means that both vm_map_entry_dispose and vm_map_entry_create might > be called in an interrupt context, manipulating buffer_map and the free > pool of vm map entries. > > A simple spl protection of vm_map_entry_dispose/vm_map_entry_create > is not sufficient. > > For 2.2-STABLE, MALLOC might be called with M_WAITOK during during the > interrupt (vm_map_entry_create -> MALLOC) > > For CURRENT, kmem_alloc might be called during an interrupt. > (vm_map_entry_create -> zalloc -> _zalloc -> _zget -> kmem_alloc) > > Thus, it might be better to not call bfreekva in brelse if it occurs > during an interrupt. An alternate solution is to not call brelse in > biodone, but instead push the buffer onto a list that is emptied by a > dedicated high priority kernel process. > > - Tor Egge I've spotted something possibly related from at least one 2.2-STABLE system.. From the console log during a relatively quiet time: 3:45PM up 6 days, 5:56, 15 users, load averages: 0.01, 0.00, 0.00 Sun Sep 28 16:00:00 CST 1997 4:00PM up 6 days, 6:11, 16 users, load averages: 0.00, 0.00, 0.00 4:15PM up 6 days, 6:26, 15 users, load averages: 0.00, 0.00, 0.00 4:30PM up 6 days, 6:41, 15 users, load averages: 0.03, 0.01, 0.00 panic: vm_object_deallocate: object deallocated too many times Debugger("panic") Choose: b)oot, d)ebugger, p)anic, q)uit? Timeout after 30 seconds; Rebooting.. syncing disks... Fatal trap 12: page fault while in kernel mode fault virtual address = 0x10 fault code = supervisor read, page not present instruction pointer = 0x8:0xf012c806 [..] This particular panic has happend twice on this machine. It's configured identically to a dozen others (P5-133, 32MB, ASUS 430HX mboard, quantum ide drives). Cheers, -Peter From owner-freebsd-bugs Sun Sep 28 22:20:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA17396 for bugs-outgoing; Sun, 28 Sep 1997 22:20:14 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA17384; Sun, 28 Sep 1997 22:20:06 -0700 (PDT) Date: Sun, 28 Sep 1997 22:20:06 -0700 (PDT) Message-Id: <199709290520.WAA17384@hub.freebsd.org> To: freebsd-bugs Cc: From: Peter Wemm Subject: Re: kern/4630: buffer_map might become corrupted Reply-To: Peter Wemm Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The following reply was made to PR kern/4630; it has been noted by GNATS. From: Peter Wemm To: Tor Egge Cc: FreeBSD-gnats-submit@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG, dyson@FreeBSD.ORG Subject: Re: kern/4630: buffer_map might become corrupted Date: Mon, 29 Sep 1997 13:18:22 +0800 Tor Egge wrote: > A new crash. > > ----- > (kgdb) print intr_nesting_level > $1 = 2 > (kgdb) where > #0 boot (howto=260) at ../../kern/kern_shutdown.c:266 > #1 0xe0117676 in panic (fmt=0xe01b0013 "vm_map_entry_dispose in interrupt") > at ../../kern/kern_shutdown.c:393 > #2 0xe01b009b in vm_map_entry_dispose (map=0xe25a1f00, entry=0xe3c4c2c0) > at ../../vm/vm_map.c:344 > #3 0xe01b09af in vm_map_simplify_entry (map=0xe25a1f00, entry=0xe3e16640) > at ../../vm/vm_map.c:883 > #4 0xe01b0a7d in _vm_map_clip_start (map=0xe25a1f00, entry=0xe3e16640, > start=3881472000) at ../../vm/vm_map.c:943 > #5 0xe01b1f6e in vm_map_delete (map=0xe25a1f00, start=3881472000, > end=3881480192) at ../../vm/vm_map.c:1891 > #6 0xe012fe0d in bfreekva (bp=0xe7015f94) at ../../kern/vfs_bio.c:240 > #7 0xe01307ec in brelse (bp=0xe7015f94) at ../../kern/vfs_bio.c:696 > #8 0xe0132150 in biodone (bp=0xe7015f94) at ../../kern/vfs_bio.c:1888 > #9 0xe0101610 in ccdintr (cs=0xe2faf198, bp=0xe7015f94) > at ../../dev/ccd/ccd.c:966 > #10 0xe01016ea in ccdiodone (cbp=0xe3caae00) at ../../dev/ccd/ccd.c:1026 > #11 0xe0131f04 in biodone (bp=0xe3caae00) at ../../kern/vfs_bio.c:1774 > #12 0xe019846c in scsi_done (xs=0xe3e1a480) at ../../scsi/scsi_base.c:450 > #13 0xe01f292c in ahc_done (ahc=0xe2fa5000, scb=0xe336e300) > at ../../i386/scsi/aic7xxx.c:1969 > #14 0xe01f0497 in ahc_intr (arg=0xe2fa5000) at ../../i386/scsi/aic7xxx.c:843 > #15 0xe0119160 in tsleep (ident=0xe35e0fb8, priority=17, > wmesg=0xe01a4a2a "ffsfsn", timo=0) at ../../kern/kern_synch.c:330 > #16 0xe01a4b3d in ffs_fsync (ap=0xe9478ce8) at ../../ufs/ffs/ffs_vnops.c:313 > #17 0xe01b45b2 in vm_object_page_clean (object=0xe375f680, start=0, end=0, > syncio=1, lockflag=1) at vnode_if.h:479 > #18 0xe0136cd6 in vfs_msync (mp=0xe3083800, flags=2) > at ../../kern/vfs_subr.c:2127 > #19 0xe01376d4 in sync (p=0xe021c670, uap=0x0, retval=0x0) > at ../../kern/vfs_syscalls.c:479 > #20 0xe0117251 in boot (howto=256) at ../../kern/kern_shutdown.c:203 > #21 0xe0117676 in panic (fmt=0xe01b0013 "vm_map_entry_dispose in interrupt") ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > at ../../kern/kern_shutdown.c:393 > #22 0xe01b009b in vm_map_entry_dispose (map=0xe25a1f00, entry=0xe34af280) > at ../../vm/vm_map.c:344 > #23 0xe01b09af in vm_map_simplify_entry (map=0xe25a1f00, entry=0xe3ac1700) > at ../../vm/vm_map.c:883 > #24 0xe01b0a7d in _vm_map_clip_start (map=0xe25a1f00, entry=0xe3ac1700, > start=3882176512) at ../../vm/vm_map.c:943 > #25 0xe01b1f6e in vm_map_delete (map=0xe25a1f00, start=3882176512, > end=3882184704) at ../../vm/vm_map.c:1891 > #26 0xe012fe0d in bfreekva (bp=0xe700e064) at ../../kern/vfs_bio.c:240 > #27 0xe01307ec in brelse (bp=0xe700e064) at ../../kern/vfs_bio.c:696 > #28 0xe0132150 in biodone (bp=0xe700e064) at ../../kern/vfs_bio.c:1888 > #29 0xe0101610 in ccdintr (cs=0xe2faf198, bp=0xe700e064) > at ../../dev/ccd/ccd.c:966 > #30 0xe01016ea in ccdiodone (cbp=0xe37cb300) at ../../dev/ccd/ccd.c:1026 > #31 0xe0131f04 in biodone (bp=0xe37cb300) at ../../kern/vfs_bio.c:1774 > #32 0xe019846c in scsi_done (xs=0xe30eee00) at ../../scsi/scsi_base.c:450 > #33 0xe01f292c in ahc_done (ahc=0xe2fa5000, scb=0xe336e300) > at ../../i386/scsi/aic7xxx.c:1969 > #34 0xe01f0497 in ahc_intr (arg=0xe2fa5000) at ../../i386/scsi/aic7xxx.c:843 ^^^^^^^^^^^^^^^^^^^ > #35 0x3d51 in ?? () > ----- > > This means that both vm_map_entry_dispose and vm_map_entry_create might > be called in an interrupt context, manipulating buffer_map and the free > pool of vm map entries. > > A simple spl protection of vm_map_entry_dispose/vm_map_entry_create > is not sufficient. > > For 2.2-STABLE, MALLOC might be called with M_WAITOK during during the > interrupt (vm_map_entry_create -> MALLOC) > > For CURRENT, kmem_alloc might be called during an interrupt. > (vm_map_entry_create -> zalloc -> _zalloc -> _zget -> kmem_alloc) > > Thus, it might be better to not call bfreekva in brelse if it occurs > during an interrupt. An alternate solution is to not call brelse in > biodone, but instead push the buffer onto a list that is emptied by a > dedicated high priority kernel process. > > - Tor Egge I've spotted something possibly related from at least one 2.2-STABLE system.. From the console log during a relatively quiet time: 3:45PM up 6 days, 5:56, 15 users, load averages: 0.01, 0.00, 0.00 Sun Sep 28 16:00:00 CST 1997 4:00PM up 6 days, 6:11, 16 users, load averages: 0.00, 0.00, 0.00 4:15PM up 6 days, 6:26, 15 users, load averages: 0.00, 0.00, 0.00 4:30PM up 6 days, 6:41, 15 users, load averages: 0.03, 0.01, 0.00 panic: vm_object_deallocate: object deallocated too many times Debugger("panic") Choose: b)oot, d)ebugger, p)anic, q)uit? Timeout after 30 seconds; Rebooting.. syncing disks... Fatal trap 12: page fault while in kernel mode fault virtual address = 0x10 fault code = supervisor read, page not present instruction pointer = 0x8:0xf012c806 [..] This particular panic has happend twice on this machine. It's configured identically to a dozen others (P5-133, 32MB, ASUS 430HX mboard, quantum ide drives). Cheers, -Peter From owner-freebsd-bugs Mon Sep 29 00:24:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA24205 for bugs-outgoing; Mon, 29 Sep 1997 00:24:59 -0700 (PDT) Received: from schizo.dk.tfs.com (mail.trw.dk [195.8.133.123]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA24190 for ; Mon, 29 Sep 1997 00:24:52 -0700 (PDT) Received: from critter.freebsd.dk (critter.dk.tfs.com [140.145.230.252]) by schizo.dk.tfs.com (8.8.7/8.7.3) with ESMTP id JAA22029; Mon, 29 Sep 1997 09:24:20 +0200 (MET DST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id IAA00244; Mon, 29 Sep 1997 08:46:46 +0200 (CEST) To: Tor Egge cc: freebsd-bugs@freebsd.org Subject: Re: kern/4630: buffer_map might become corrupted In-reply-to: Your message of "Sun, 28 Sep 1997 15:10:02 PDT." <199709282210.PAA26061@hub.freebsd.org> Date: Mon, 29 Sep 1997 08:46:45 +0200 Message-ID: <242.875515605@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > This means that both vm_map_entry_dispose and vm_map_entry_create might > be called in an interrupt context, manipulating buffer_map and the free > pool of vm map entries. I think the problem here is calling brelse() at interrupt time, isn't it ? Poul-Henning From owner-freebsd-bugs Mon Sep 29 01:07:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA26288 for bugs-outgoing; Mon, 29 Sep 1997 01:07:28 -0700 (PDT) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA26282; Mon, 29 Sep 1997 01:07:15 -0700 (PDT) Received: from spinner.netplex.com.au (localhost.dialix.com.au [127.0.0.1]) by spinner.netplex.com.au with ESMTP id QAA10988; Mon, 29 Sep 1997 16:05:19 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199709290805.QAA10988@spinner.netplex.com.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Poul-Henning Kamp cc: Tor Egge , freebsd-bugs@FreeBSD.ORG, dyson@FreeBSD.ORG Subject: Re: kern/4630: buffer_map might become corrupted In-reply-to: Your message of "Mon, 29 Sep 1997 08:46:45 +0200." <242.875515605@critter.freebsd.dk> Date: Mon, 29 Sep 1997 16:05:18 +0800 From: Peter Wemm Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Poul-Henning Kamp wrote: > > > This means that both vm_map_entry_dispose and vm_map_entry_create might > > be called in an interrupt context, manipulating buffer_map and the free > > pool of vm map entries. > > I think the problem here is calling brelse() at interrupt time, isn't it ? IMHO We _really_ need some low-cost assertions of assumptions that are on by default but can be disabled via compile option perhaps.. Kinda like an inverse of DIAGNOSTIC. Simple catching of things like 'must be called at splbio or greater', 'must not be called from interrupt' etc at strategic points (eg: tsleep and the various VM and bio utility functions etc) would help shake out these sorts of problems once and for all. After all, we still don't know the cause of the runqueue trashing under 2.2 unless swapping is disabled.. Perhaps a series of machine-independent macros that are implemented per-arch as needed might help. eg: assert_nointerrupt("tsleep"); assert_splbio("vm_function_foo()"); etc. BTW2; I wish there was an easy way of producing a stack trace automatically on a panic or fatal trap, or as a diagnostic tool. Having a machine panic and reboot is near for unattended machines. Having a stack trace in the console log would be fantastic. :-) > Poul-Henning > Cheers, -Peter -- Peter Wemm Netplex Consulting From owner-freebsd-bugs Mon Sep 29 01:16:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA26740 for bugs-outgoing; Mon, 29 Sep 1997 01:16:18 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA26728 for ; Mon, 29 Sep 1997 01:16:07 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.8.6/8.8.5) id DAA05524; Mon, 29 Sep 1997 03:13:57 -0500 (EST) From: "John S. Dyson" Message-Id: <199709290813.DAA05524@dyson.iquest.net> Subject: Re: kern/4630: buffer_map might become corrupted In-Reply-To: <242.875515605@critter.freebsd.dk> from Poul-Henning Kamp at "Sep 29, 97 08:46:45 am" To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Mon, 29 Sep 1997 03:13:57 -0500 (EST) Cc: Tor.Egge@idi.ntnu.no, freebsd-bugs@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Poul-Henning Kamp said: > > > This means that both vm_map_entry_dispose and vm_map_entry_create might > > be called in an interrupt context, manipulating buffer_map and the free > > pool of vm map entries. > > I think the problem here is calling brelse() at interrupt time, isn't it ? > The problem is that brelse isn't meant to be called to free the buffer at interrupt time. Brelse can be called at interrupt time under certain circumstances. Geesh, I hate those layered drivers (like CCD and VN.) Both of them need to be looked at. We need to look at a way of handling this type of problem without just sprinkling SPL's around. -- John dyson@freebsd.org jdyson@nc.com From owner-freebsd-bugs Mon Sep 29 01:27:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA27105 for bugs-outgoing; Mon, 29 Sep 1997 01:27:20 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA27097 for ; Mon, 29 Sep 1997 01:27:05 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.8.6/8.8.5) id DAA05585; Mon, 29 Sep 1997 03:26:05 -0500 (EST) From: "John S. Dyson" Message-Id: <199709290826.DAA05585@dyson.iquest.net> Subject: Re: kern/4630: buffer_map might become corrupted In-Reply-To: <242.875515605@critter.freebsd.dk> from Poul-Henning Kamp at "Sep 29, 97 08:46:45 am" To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Mon, 29 Sep 1997 03:26:05 -0500 (EST) Cc: Tor.Egge@idi.ntnu.no, freebsd-bugs@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Poul-Henning Kamp said: > > > This means that both vm_map_entry_dispose and vm_map_entry_create might > > be called in an interrupt context, manipulating buffer_map and the free > > pool of vm map entries. > > I think the problem here is calling brelse() at interrupt time, isn't it ? > My previous comment was nonsense... Sorry... I still hate CCD and VN though... I will have a solution tomorrow. -- John dyson@freebsd.org jdyson@nc.com From owner-freebsd-bugs Mon Sep 29 01:43:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA28031 for bugs-outgoing; Mon, 29 Sep 1997 01:43:19 -0700 (PDT) Received: from schizo.dk.tfs.com (mail.trw.dk [195.8.133.123]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA28025; Mon, 29 Sep 1997 01:43:11 -0700 (PDT) Received: from critter.freebsd.dk (critter.dk.tfs.com [140.145.230.252]) by schizo.dk.tfs.com (8.8.7/8.7.3) with ESMTP id KAA22334; Mon, 29 Sep 1997 10:42:40 +0200 (MET DST) Received: from critter.freebsd.dk (localhost.dk.tfs.com [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id KAA00729; Mon, 29 Sep 1997 10:41:44 +0200 (CEST) To: Peter Wemm cc: Tor Egge , freebsd-bugs@freebsd.org, dyson@freebsd.org Subject: Re: kern/4630: buffer_map might become corrupted In-reply-to: Your message of "Mon, 29 Sep 1997 16:05:18 +0800." <199709290805.QAA10988@spinner.netplex.com.au> Date: Mon, 29 Sep 1997 10:41:43 +0200 Message-ID: <727.875522503@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199709290805.QAA10988@spinner.netplex.com.au>, Peter Wemm writes: >Poul-Henning Kamp wrote: >> >> > This means that both vm_map_entry_dispose and vm_map_entry_create might >> > be called in an interrupt context, manipulating buffer_map and the free >> > pool of vm map entries. >> >> I think the problem here is calling brelse() at interrupt time, isn't it ? > >IMHO We _really_ need some low-cost assertions of assumptions that are on >by default but can be disabled via compile option perhaps.. Kinda like an >inverse of DIAGNOSTIC. yes. >BTW2; I wish there was an easy way of producing a stack trace automatically >on a panic or fatal trap, or as a diagnostic tool. Having a machine panic >and reboot is near for unattended machines. Having a stack trace in the >console log would be fantastic. :-) I looked at putting DDB output in the buffer and have DDB do a "trace" when it is entered, but it didn't prove much help. I can try to dig up the code... -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-bugs Mon Sep 29 02:05:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA29152 for bugs-outgoing; Mon, 29 Sep 1997 02:05:01 -0700 (PDT) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA29139; Mon, 29 Sep 1997 02:04:55 -0700 (PDT) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id CAA00880; Mon, 29 Sep 1997 02:05:01 -0700 (PDT) Message-Id: <199709290905.CAA00880@implode.root.com> To: Peter Wemm cc: Poul-Henning Kamp , Tor Egge , freebsd-bugs@FreeBSD.ORG, dyson@FreeBSD.ORG Subject: Re: kern/4630: buffer_map might become corrupted In-reply-to: Your message of "Mon, 29 Sep 1997 16:05:18 +0800." <199709290805.QAA10988@spinner.netplex.com.au> From: David Greenman Reply-To: dg@root.com Date: Mon, 29 Sep 1997 02:05:01 -0700 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >BTW2; I wish there was an easy way of producing a stack trace automatically >on a panic or fatal trap, or as a diagnostic tool. Having a machine panic >and reboot is near for unattended machines. Having a stack trace in the >console log would be fantastic. :-) John and I were talking about this exact thing just last night. :-) I think the best approach would be to create a 'cda' crash dump analyzer that generates a report on reboot (stores the report in a file) that includes a traceback, register info, dumps of important data structures and lists, etc. The alternative is to try to output a traceback on the console at crash time, but this is likely going to scroll other important information off the screen. Anyway, this has been on my wishlist for years. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-bugs Mon Sep 29 02:13:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA29533 for bugs-outgoing; Mon, 29 Sep 1997 02:13:38 -0700 (PDT) Received: from schizo.dk.tfs.com (mail.trw.dk [195.8.133.123]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA29524; Mon, 29 Sep 1997 02:13:31 -0700 (PDT) Received: from critter.freebsd.dk (critter.dk.tfs.com [140.145.230.252]) by schizo.dk.tfs.com (8.8.7/8.7.3) with ESMTP id LAA22456; Mon, 29 Sep 1997 11:12:59 +0200 (MET DST) Received: from critter.freebsd.dk (localhost.dk.tfs.com [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id LAA00946; Mon, 29 Sep 1997 11:12:04 +0200 (CEST) To: dg@root.com cc: Peter Wemm , Tor Egge , freebsd-bugs@freebsd.org, dyson@freebsd.org Subject: Re: kern/4630: buffer_map might become corrupted In-reply-to: Your message of "Mon, 29 Sep 1997 02:05:01 PDT." <199709290905.CAA00880@implode.root.com> Date: Mon, 29 Sep 1997 11:12:03 +0200 Message-ID: <944.875524323@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199709290905.CAA00880@implode.root.com>, David Greenman writes: >>BTW2; I wish there was an easy way of producing a stack trace automatically >>on a panic or fatal trap, or as a diagnostic tool. Having a machine panic >>and reboot is near for unattended machines. Having a stack trace in the >>console log would be fantastic. :-) > > John and I were talking about this exact thing just last night. :-) I >think the best approach would be to create a 'cda' crash dump analyzer >that generates a report on reboot (stores the report in a file) that includes >a traceback, register info, dumps of important data structures and lists, etc. And optionally emails it to some configurable address. >The alternative is to try to output a traceback on the console at crash time, >but this is likely going to scroll other important information off the screen. Well, if scroll-lock works this is no big loss. >Anyway, this has been on my wishlist for years. mine too. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-bugs Mon Sep 29 02:39:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA00795 for bugs-outgoing; Mon, 29 Sep 1997 02:39:40 -0700 (PDT) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA00790; Mon, 29 Sep 1997 02:39:30 -0700 (PDT) Received: from spinner.netplex.com.au (localhost.dialix.com.au [127.0.0.1]) by spinner.netplex.com.au with ESMTP id RAA11950; Mon, 29 Sep 1997 17:38:23 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199709290938.RAA11950@spinner.netplex.com.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: dg@root.com cc: Poul-Henning Kamp , Tor Egge , freebsd-bugs@FreeBSD.ORG, dyson@FreeBSD.ORG Subject: Re: kern/4630: buffer_map might become corrupted In-reply-to: Your message of "Mon, 29 Sep 1997 02:05:01 MST." <199709290905.CAA00880@implode.root.com> Date: Mon, 29 Sep 1997 17:38:22 +0800 From: Peter Wemm Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk David Greenman wrote: > >BTW2; I wish there was an easy way of producing a stack trace automatically > >on a panic or fatal trap, or as a diagnostic tool. Having a machine panic > >and reboot is near for unattended machines. Having a stack trace in the > >console log would be fantastic. :-) > > John and I were talking about this exact thing just last night. :-) I > think the best approach would be to create a 'cda' crash dump analyzer > that generates a report on reboot (stores the report in a file) that includes > a traceback, register info, dumps of important data structures and lists, etc . > The alternative is to try to output a traceback on the console at crash time, > but this is likely going to scroll other important information off the screen . > Anyway, this has been on my wishlist for years. Careful David, your VMS stripes are showing through again.. :-) Seriously though, it would be wonderful. I liked the interactive SVR4 crash(8M) program too, but it lacked extensibility. However, the other problem is that most of the crashes that I see these days usually prevent a crashdump from happening in the first place, leaving the savecore nothing to work with. cda couldn't do anything in for most of the crashes I see on 2.2. > -DG Cheers, -Peter -- Peter Wemm Netplex Consulting From owner-freebsd-bugs Mon Sep 29 02:46:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA01141 for bugs-outgoing; Mon, 29 Sep 1997 02:46:25 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA01135; Mon, 29 Sep 1997 02:46:17 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id CAA11226; Mon, 29 Sep 1997 02:44:32 -0700 (PDT) To: Peter Wemm cc: Poul-Henning Kamp , Tor Egge , freebsd-bugs@FreeBSD.ORG, dyson@FreeBSD.ORG Subject: Re: kern/4630: buffer_map might become corrupted In-reply-to: Your message of "Mon, 29 Sep 1997 16:05:18 +0800." <199709290805.QAA10988@spinner.netplex.com.au> Date: Mon, 29 Sep 1997 02:44:32 -0700 Message-ID: <11222.875526272@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > BTW2; I wish there was an easy way of producing a stack trace automatically > on a panic or fatal trap, or as a diagnostic tool. Having a machine panic Me too - I could use this to very good effect in usermode, e.g. sysinstall. ;) Jordan From owner-freebsd-bugs Mon Sep 29 03:30:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA03077 for bugs-outgoing; Mon, 29 Sep 1997 03:30:25 -0700 (PDT) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA03070; Mon, 29 Sep 1997 03:30:15 -0700 (PDT) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id DAA01797; Mon, 29 Sep 1997 03:30:18 -0700 (PDT) Message-Id: <199709291030.DAA01797@implode.root.com> To: Peter Wemm cc: Poul-Henning Kamp , Tor Egge , freebsd-bugs@FreeBSD.ORG, dyson@FreeBSD.ORG Subject: Re: kern/4630: buffer_map might become corrupted In-reply-to: Your message of "Mon, 29 Sep 1997 17:38:22 +0800." <199709290938.RAA11950@spinner.netplex.com.au> From: David Greenman Reply-To: dg@root.com Date: Mon, 29 Sep 1997 03:30:18 -0700 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >However, the other problem is that most of the crashes that I see these >days usually prevent a crashdump from happening in the first place, >leaving the savecore nothing to work with. cda couldn't do anything in >for most of the crashes I see on 2.2. The dump code should always work unless memory has been horribly corrupted...we should fix it. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-bugs Mon Sep 29 04:04:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA04617 for bugs-outgoing; Mon, 29 Sep 1997 04:04:08 -0700 (PDT) Received: from home.shvetc.marka.net.ua (home.shvetc.marka.net.ua [193.193.219.253]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA04571 for ; Mon, 29 Sep 1997 04:03:45 -0700 (PDT) Received: (from eugene@localhost) by home.shvetc.marka.net.ua (8.8.7/8.8.5) id OAA02286 for freebsd-bugs@freebsd.org; Mon, 29 Sep 1997 14:03:20 +0300 (EEST) Date: Mon, 29 Sep 1997 14:03:20 +0300 (EEST) From: Eugene Shvetc Message-Id: <199709291103.OAA02286@home.shvetc.marka.net.ua> To: freebsd-bugs@freebsd.org Subject: error in slip. Sender: owner-freebsd-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi! slattach runs only few times if -S option is used. I have two slip interfaces, and i can start slattach three three times, after what it does not start with error: ioctl(TIOCSETD) Device not configured. I have architecture of my lines, what me need using preferred SLIP unit...In case to solve this problems i am use -u option in slattach, but this is not best way, SLIP units can connect in another order, and SLIP unit does not correspond specific line. This error (Device not configured) also appear after few reconnects of lines. If it is possible, please correct this problem in near FreeBSD-stable release, and write me response. Beforehand grateful. From owner-freebsd-bugs Mon Sep 29 07:39:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA14197 for bugs-outgoing; Mon, 29 Sep 1997 07:39:41 -0700 (PDT) Received: from mauve.csi.cam.ac.uk (exim@mauve.csi.cam.ac.uk [131.111.8.38]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id HAA14189 for ; Mon, 29 Sep 1997 07:39:32 -0700 (PDT) Received: from g.pet.cam.ac.uk [131.111.209.233] by mauve.csi.cam.ac.uk with smtp (Exim 1.71 #1) id 0xFgyQ-0001RQ-00; Mon, 29 Sep 1997 15:38:58 +0100 Received: from g.pet.cam.ac.uk [127.0.0.1] by g.pet.cam.ac.uk with esmtp (Exim 1.59 #1) id 0xFgyQ-0006sX-00; Mon, 29 Sep 1997 15:38:58 +0100 To: freebsd-bugs@freebsd.org Subject: bin/4520 and fmt Date: Mon, 29 Sep 1997 15:38:57 +0100 From: Gareth McCaughan Message-Id: Sender: owner-freebsd-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Mikhail Teterin reported a bug in fmt whereby it dumps core when given a long line (more precisely, it happens when it's given a line that contains a long "word"). I offer two solutions. 1. The following patch, which also fixes a so-far-unreported bug (fmt allows backslashed whitespace inside words, but it only counts each such as one character long). (It's relative to the version of fmt.c in 2.2-stable as of early August.) --------------------------- patch begins --------------------------- *** fmt.c.orig Mon Sep 29 14:35:34 1997 --- fmt.c Mon Sep 29 15:04:55 1997 *************** *** 335,347 **** char line[]; { register char *cp, *cp2; ! char word[BUFSIZ]; int wordl; /* LIZ@UOM 6/18/85 */ cp = line; while (*cp) { cp2 = word; wordl = 0; /* LIZ@UOM 6/18/85 */ /* * Collect a 'word,' allowing it to contain escaped white --- 335,354 ---- char line[]; { register char *cp, *cp2; ! char *word; int wordl; /* LIZ@UOM 6/18/85 */ + int wordsize, wordleft; + + word = malloc(BUFSIZ); + if (word == 0) + abort(); + wordsize=BUFSIZ; cp = line; while (*cp) { cp2 = word; wordl = 0; /* LIZ@UOM 6/18/85 */ + wordleft = wordsize; /* * Collect a 'word,' allowing it to contain escaped white *************** *** 349,357 **** */ while (*cp && *cp != ' ') { if (*cp == '\\' && isspace(cp[1])) ! *cp2++ = *cp++; *cp2++ = *cp++; wordl++;/* LIZ@UOM 6/18/85 */ } /* --- 356,372 ---- */ while (*cp && *cp != ' ') { if (*cp == '\\' && isspace(cp[1])) ! *cp2++ = *cp++, wordl++, wordleft--; *cp2++ = *cp++; wordl++;/* LIZ@UOM 6/18/85 */ + if (--wordleft < 4) { + char *oldword = word; + wordleft += wordsize; wordsize *= 2; + word = realloc(word, wordsize); + if (word == 0) + abort(); + cp2 += word-oldword; + } } /* *************** *** 363,376 **** if (index(".:!", cp[-1])) *cp2++ = ' '; } ! while (*cp == ' ') *cp2++ = *cp++; *cp2 = '\0'; /* * LIZ@UOM 6/18/85 pack(word); */ pack(word, wordl); } } /* --- 378,401 ---- if (index(".:!", cp[-1])) *cp2++ = ' '; } ! while (*cp == ' ') { *cp2++ = *cp++; + if (--wordleft < 3) { /* yes, 3. Sorry. */ + char *oldword = word; + wordleft += wordsize; wordsize *= 2; + word = realloc(word, wordsize); + if (word == 0) + abort(); + cp2 += word-oldword; + } + } *cp2 = '\0'; /* * LIZ@UOM 6/18/85 pack(word); */ pack(word, wordl); } + free(word); } /* *************** *** 382,389 **** * there ain't nothing in there yet. At the bottom of this whole mess, * leading tabs are reinserted. */ ! char outbuf[BUFSIZ]; /* Sandbagged output line image */ char *outp; /* Pointer in above */ /* * Initialize the output section. --- 407,415 ---- * there ain't nothing in there yet. At the bottom of this whole mess, * leading tabs are reinserted. */ ! char *outbuf; /* Sandbagged output line image */ char *outp; /* Pointer in above */ + int outbuf_size; /* er, size of outbuf */ /* * Initialize the output section. *************** *** 391,396 **** --- 417,426 ---- void setout() { + outbuf = malloc(BUFSIZ); + if (outbuf == 0) + abort(); + outbuf_size = BUFSIZ; outp = NOSTR; } *************** *** 421,426 **** --- 451,463 ---- { register char *cp; register int s, t; + + if (((outp==NOSTR) ? wl : outp-outbuf + wl) >= outbuf_size) { + outbuf_size *= 2; + outbuf = realloc(outbuf, outbuf_size); + if (outbuf == 0) + abort(); + } if (outp == NOSTR) leadin(); ---------------------------- patch ends ---------------------------- 2. The source for fmt is a real mess. It's full of fixed-size buffers and calls to |abort| and basically it's horrible. This will still be the case no matter how many fixes of the above type get contributed. I have a drop-in replacement for it, written by me, which the FreeBSD project can have on any reasonable terms. It contains no fixed-size buffers, no calls to |abort| and no ghastly ad-hockery. It's also significantly faster (not that that matters). Official FreeBSD People: Are you interested in this? A couple of other fmt things: - It also appears that my patch for bin/2968 has been applied to fix bin/4607 (fine) and that bin/4607 hasn't been closed (not fine). - When fmt sees a mailbox From line (`From foo@bar Mon Sep 12 ...') it attempts to put it and any following To:, Cc:, Subject: lines on output lines of their own. It seems to me that this is the Wrong Thing to do. Either mail headers should be treated specially all the time (and not just those three, of course), even when not preceded by a mailbox From line, or they should be treated exactly like ordinary text all the time. I vote for the latter. The only reason I can see for doing special things with mail headers is because people might want to use fmt to format mail messages. Mail messages do not generally contain mailbox headers; only the mail headers themselves. Does anyone really do `fmt /var/mail/me'? -- Gareth McCaughan Dept. of Pure Mathematics & Mathematical Statistics, gjm11@dpmms.cam.ac.uk Cambridge University, England. From owner-freebsd-bugs Mon Sep 29 08:53:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA18219 for bugs-outgoing; Mon, 29 Sep 1997 08:53:32 -0700 (PDT) Received: from imdave.pr.mcs.net (imdave@imdave.pr.mcs.net [205.164.3.77]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA18200; Mon, 29 Sep 1997 08:53:21 -0700 (PDT) Received: (from imdave@localhost) by imdave.pr.mcs.net (8.8.7/8.8.7) id KAA07346; Mon, 29 Sep 1997 10:52:57 -0500 (CDT) Date: Mon, 29 Sep 1997 10:52:57 -0500 (CDT) From: Dave Bodenstab Message-Id: <199709291552.KAA07346@imdave.pr.mcs.net> To: dg@root.com, phk@critter.freebsd.dk Subject: Re: kern/4630: buffer_map might become corrupted Cc: dyson@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG, peter@netplex.com.au, Tor.Egge@idi.ntnu.no Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > From: Poul-Henning Kamp > In message <199709290905.CAA00880@implode.root.com>, David Greenman writes: > >>BTW2; I wish there was an easy way of producing a stack trace automatically > >>on a panic or fatal trap, or as a diagnostic tool. Having a machine panic > >>and reboot is near for unattended machines. Having a stack trace in the > >>console log would be fantastic. :-) > > > > John and I were talking about this exact thing just last night. :-) I > >think the best approach would be to create a 'cda' crash dump analyzer > >that generates a report on reboot (stores the report in a file) that includes > >a traceback, register info, dumps of important data structures and lists, etc. > > And optionally emails it to some configurable address. > > >The alternative is to try to output a traceback on the console at crash time, > >but this is likely going to scroll other important information off the screen. > Well, if scroll-lock works this is no big loss. > > >Anyway, this has been on my wishlist for years. > mine too. I guess I'm a pack rat, but I saved a copy of a ``crash'' clone back when I was running Microport's system V/AT on my 286. It was written by John F. Haugh II around 1988, with a copyright allowing non-commercial derivatives. As I recall, I compared it with the stock "crash" command that came with my system. It compared favorably, but since the stock version had a couple of more options, there was no reason for me to pursue it. It's system V based, but if you'd like a copy upon which to base a FreeBSD version, let me know and I can email it. Dave Bodenstab imdave@mcs.net From owner-freebsd-bugs Mon Sep 29 09:50:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA21928 for bugs-outgoing; Mon, 29 Sep 1997 09:50:07 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA21922; Mon, 29 Sep 1997 09:50:01 -0700 (PDT) Resent-Date: Mon, 29 Sep 1997 09:50:01 -0700 (PDT) Resent-Message-Id: <199709291650.JAA21922@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, jlind@skypoint.com Received: (from nobody@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA21495; Mon, 29 Sep 1997 09:43:11 -0700 (PDT) Message-Id: <199709291643.JAA21495@hub.freebsd.org> Date: Mon, 29 Sep 1997 09:43:11 -0700 (PDT) From: jlind@skypoint.com To: freebsd-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: www-1.0 Subject: bin/4652: fclose on NULL pointer causes rdist to Seg V with remote rdist can't run Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4652 >Category: bin >Synopsis: fclose on NULL pointer causes rdist to Seg V with remote rdist can't run >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Sep 29 09:50:00 PDT 1997 >Last-Modified: >Originator: John Lind >Organization: SkyPoint Communications, Inc. >Release: 2.2.2 >Environment: FreeBSD mirage.skypoint.com 2.2.2-RELEASE FreeBSD 2.2.2-RELEASE #0: Tue Aug 26 1 4:41:47 CDT 1997 root@oasis.skypoint.net:/usr/src/sys/compile/OASIS i386 >Description: The setjmp in doarrow (docmd.c line 145) happens before the makeconn and logfile opens. If the rsh->rdist remote execution fails early on, lostconn will be called in makeconn before the log file open occurs, causing the longjmp to occur, transfer to the label "done" and there try to do an fclose on lfp, which is uninitialized. >How-To-Repeat: One easy way -- remove the execute permission on rdist on the remote system. >Fix: I simply protected the fclose(lfp) with a test for NULL and made sure that lfp was initialized to NULL (for systems that don't do clearcore or whatever). It is arguable whether this is correct. Perhaps moving the setjmp down or the logfile open up would be better. I didn't have sufficient familiarity with the code to propose the "correct" solution and send in a patch. >Audit-Trail: >Unformatted: From owner-freebsd-bugs Mon Sep 29 10:07:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA23147 for bugs-outgoing; Mon, 29 Sep 1997 10:07:53 -0700 (PDT) Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA22560 for freebsd-bugs@freebsd.org; Mon, 29 Sep 1997 10:00:16 -0700 (PDT) Date: Mon, 29 Sep 1997 10:00:16 -0700 (PDT) Message-Id: <199709291700.KAA22560@hub.freebsd.org> From: FreeBSD bugmaster To: FreeBSD bugs list Subject: Current problem reports Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Current FreeBSD problem reports The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. Bugs can be in one of several states: o - open A problem report has been submitted, no sanity checking performed. a - analyzed The report has been examined by a team member and evaluated. f - feedback The problem has been solved, and the originator has been given a patch or a fix has been committed. The PR remains in this state pending a response from the originator. s - suspended Work on the problem has been postponed. This happens if a timely solution is not possible or is not cost-effective at the present time. The PR continues to exist, though a solution is not being actively sought. If the problem cannot be solved at all, it will be closed, rather than suspended. c - closed A problem report is closed when any changes have been integrated, documented, and tested. Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- a [1995/01/11] i386/105 bde Distributed libm (msun) has non-standard o [1995/02/14] kern/216 davidg /kernel: panic: ffs_alloccg: map corrupte a [1996/01/22] kern/965 bde 2.0.5: system crashes daily because of "m o [1996/04/06] kern/1121 dyson System crashes on boot up just after the o [1996/05/07] kern/1177 dyson Machine hangs with message "vm_fork: no p o [1996/06/05] kern/1293 brian Fatal trap 12: page fault while in kernel o [1996/06/11] kern/1311 dyson Panic: vm_page_free while installing new a [1996/07/15] bin/1387 davidn Group file errors cause absolute havoc a [1996/08/09] kern/1487 bde bug in exec(2) o [1996/09/11] kern/1599 panic: locking against myself s [1996/09/13] conf/1608 FreeBSD's bug tracking system does not re o [1996/09/30] kern/1698 sup from around 21:51 GMT 28th very unsta o [1996/10/08] kern/1744 run queue or proc list smashed 4 times in o [1996/10/13] kern/1790 access to /dev/kmem panics system f [1996/10/28] kern/1919 se access to files/directories fails, gives o [1996/11/01] kern/1940 TCP doesn't time out of FIN_WAIT_1 and fl o [1996/11/29] kern/2121 MAXBSIZE in param.h causes kernel panic i o [1996/12/14] i386/2218 cy.c XON/XOFF handling crashes kernel o [1996/12/20] bin/2258 wollman route add/delete [network] xxx.yyy.zzz.0 f [1997/01/01] ports/2352 torstenb wu-ftp port does not work with DES crypte o [1997/01/03] conf/2367 gibbs Buslogic SCSI driver bad probe of 742A EI f [1997/01/04] kern/2371 gibbs SCSI disk corruption o [1997/01/25] bin/2581 imp security holes in libtermcap o [1997/02/11] kern/2717 Panic with daily script (find) o [1997/02/14] bin/2740 wpaul root-fs full erases password table ! o [1997/02/21] misc/2795 Cyclades 8YO -- Not working under 2.1.6-S o [1997/03/04] kern/2877 Fatal Trap 12: page fault while in kernel o [1997/03/05] kern/2890 System panic after kernel compiled for 12 o [1997/03/08] kern/2923 panic: vm_fault: fault on nofault entry, o [1997/03/13] kern/2980 2.2 crashes after accessing DAT-tape. bot o [1997/03/15] kern/3000 Kernel Panic in 2.2-CURRENT Kernel o [1997/03/17] kern/3017 panic: page fault as of March 11th v2.2 o [1997/03/17] bin/3019 Can't use SCSI disk (SCSI ID>3) on instal o [1997/03/23] misc/3070 Cannot do post install mods to UNIX from o [1997/03/23] kern/3072 Kernel Page Fault During Install of 2.1.7 o [1997/03/25] kern/3103 vi large_file --> reboot without panic o [1997/03/26] ports/3106 torstenb pidentd exits with signal 6 o [1997/03/30] kern/3150 Cyrix 6x86L-P200+ crashes w/ page fault o [1997/04/01] ports/3165 jmz tex-3.14159.tgz lacks file o [1997/04/08] kern/3234 ipfilter.shar - integration complete o [1997/04/12] kern/3267 dyson mtime/ctime sometimes updated when a prog o [1997/04/27] ports/3394 max jp-Wnn-4.2 fails to make personal diction o [1997/04/28] kern/3404 frequent kernel panics o [1997/05/01] i386/3462 using a PS/2 mouse causes kernel trap in o [1997/05/05] bin/3510 xsm does not work! o [1997/05/07] ports/3536 jmz MakeTexPK calls gftopk with wron argument o [1997/05/12] misc/3586 The boot.flp file is too large to image t o [1997/05/13] kern/3594 EAGAIN and garbage data when reading sock o [1997/05/16] kern/3609 fs on remote host is mounted via NFS, rec o [1997/05/17] misc/3615 Error in /usr/src/lib/libc/gen/sigsetops. o [1997/05/21] bin/3650 Ypserv dumps core randomly. o [1997/05/23] kern/3671 SCSI tape drive with AHA 2940 locks up sy o [1997/05/24] kern/3674 NFS in 2.2 RELEASE hangs. o [1997/05/27] kern/3696 kernel panic during wd hard disk probe if o [1997/05/27] misc/3700 FPE error in "normal" math code o [1997/05/30] kern/3721 kernel panic with netatalk o [1997/06/01] kern/3752 NFS dirs under -current still have proble o [1997/06/01] kern/3753 "make" hangs when building in an NFS dir o [1997/06/02] kern/3761 Inlel EtherExpress pro/100B more than on o [1997/06/11] misc/3846 The sample /etc/amd.map has a security ho o [1997/06/14] ports/3872 ports Enter key not working properly in trn por o [1997/06/16] kern/3887 fxp driver looses packets o [1997/06/17] i386/3895 False FPE (floating point exception) sign o [1997/06/25] kern/3949 sos The WD controller probe can fail when it o [1997/06/26] misc/3959 files in /usr/local/etc are randomly beco o [1997/07/02] bin/4018 Will not install in 2nd partition of my C o [1997/07/03] kern/4021 Local mount of a local NFS exported direc o [1997/07/10] kern/4074 Kernel panics when accessing a ccd device o [1997/07/11] kern/4076 Adaptec 2940 and non-wide devices o [1997/07/14] ports/4093 ports [oleo] Calculating 1/1 becomes infinity. o [1997/07/31] kern/4200 "vm_fault: fault on nofault entry" when r o [1997/08/11] kern/4273 kernel page faults with heavy disk access o [1997/08/12] bin/4288 brian PPP and PPPD do not stay up after shell e o [1997/08/12] kern/4289 kernel panic: vm_fault: fault on nofault o [1997/08/13] bin/4299 named is vulnerable to DNS spoofing o [1997/08/13] kern/4301 adding a default route lags all network f o [1997/08/17] kern/4328 Degenerate network performance o [1997/08/18] kern/4332 gibbs System crash after SCSI DAT tape access. o [1997/08/18] bin/4333 gibbs Dump backup utility completely crashes th o [1997/08/20] kern/4345 Kernel panic is caused by passing file de o [1997/08/22] kern/4355 Executor does not work with sound configu o [1997/09/02] kern/4453 2.2.2 lockup on restart with ASUS-TX97 mo o [1997/09/03] ports/4458 sanpei Japanese MH's packf command dumps core o [1997/09/07] gnu/4480 cc crashes with Internal compiler error w o [1997/09/07] bin/4491 combination of null-FS , NFS and chroot c o [1997/09/21] bin/4592 sos kbdcontrol reboting machine f [1997/09/24] kern/4619 ix0: ifconfig causes kernel panic o [1997/09/25] ports/4626 ports inn port, active file contains control ch o [1997/09/26] kern/4633 Software unstability under 2.2-STABLE (as o [1997/09/27] ports/4637 ports current xfig-3.2 is unable to compile und 90 problems total. Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [1995/03/02] misc/229 bde acos() core dump a [1995/03/20] kern/260 davidg msync and munmap don't bother to update m s [1995/04/01] kern/291 se PCI devices still probe/attach after bein o [1995/05/16] kern/425 wollman arp entries not getting removed when inte a [1995/06/17] kern/527 dufault dump causes assertion in ncr.c o [1995/06/23] kern/546 pci_bus_config() does not init parent poi o [1995/07/02] kern/579 bde sio: RS_IBUFSIZE at 256 bytes serial line s [1995/07/21] i386/631 if_ix does not support bpf, nor does it a s [1995/07/29] kern/638 Transmitted packets not passed to bpf in f [1995/08/11] gnu/672 Nor all ph headers get created f [1995/09/20] kern/730 gibbs 3Com 3C5x9 probe problem a [1995/10/07] bin/771 telnet character mode not set and broken o [1995/10/18] bin/786 wpaul Problem with NIS and large group maps o [1995/11/12] kern/820 gibbs scsi tape problems f [1995/11/16] bin/826 mpp tcpmux listener in inetd does not work o [1995/12/20] i386/906 davidg /sys/i386/boot/netboot/nb8390.com cannot o [1996/01/01] bin/926 Mounting nfs disks before starting mountd o [1996/02/12] kern/1020 .Boca 16-port board still hangs a [1996/02/17] bin/1030 steve /bin/sh does not pass environment variabl s [1996/03/06] kern/1067 panic: ufs_lock: recursive lock not expec o [1996/03/09] bin/1073 telnet -8 does not work with SunOS or Sol o [1996/03/23] kern/1098 File system corruption (2 cases) o [1996/03/30] bin/1111 scrappy mail.local will happily deliver mail to a f [1996/05/14] kern/1204 umount -f after SCSI reset -> reboot o [1996/05/24] misc/1247 bde Conflicting header files f [1996/05/26] i386/1251 aha0 and bt0(eisa) conflicts again. o [1996/05/26] kern/1256 ZNYX 314 mysterously looses packets o [1996/05/28] kern/1271 phk Kernel panic using PLIP in 27/05 current o [1996/05/31] kern/1284 dyson panic: vm_page_free: freeing busy page o [1996/06/02] i386/1288 bde wdgetctlr (wd.c) return incorrect number o [1996/06/07] kern/1301 davidg DEC FDDI/PCI Adapter: halt code = 6 (DMA o [1996/06/10] kern/1308 dyson vm_page_free: wire count > 1 in 960501-SN a [1996/06/12] bin/1315 ls(1) a [1996/06/18] kern/1333 davidg free vnode isn't: another -stable coredum f [1996/07/03] bin/1364 ps(1) bugs o [1996/07/19] docs/1402 steve sh(1) manual f [1996/07/24] kern/1423 wollman route causes kernel page fault. o [1996/07/25] bin/1429 steve sh(1) and getopts f [1996/08/01] bin/1454 steve /bin/sh bug handling <<[n] FD processing a [1996/08/02] docs/1457 ache ed(1) man o [1996/08/03] bin/1461 Incorrect address binding of Kerberized r o [1996/08/04] kern/1467 gibbs scsi_prevent causing tape problems on clo o [1996/08/18] kern/1512 dyson Use of madvise may may cause bad memory m o [1996/08/22] kern/1533 dyson Machine can be panicked by a userland pro f [1996/09/05] kern/1570 Setting SHMALL > 35000 causes panic o [1996/09/14] kern/1610 dyson mmap() of unassociated memory + mlock() c o [1996/09/16] i386/1626 MUSTEK Scanner hangs NCR SCSI controller f [1996/09/18] kern/1637 mss driver causes feedback (squeal) on so o [1996/09/19] bin/1650 telnet encryption with char-mode and asci o [1996/09/21] kern/1661 ft driver hangs uninterruptably at "bavai o [1996/09/29] kern/1689 wollman TCP extensions throttles distant connecti o [1996/09/29] kern/1692 Page fault while in kernel modem fatal tr o [1996/10/01] bin/1702 phk installing of tcl manpages fails from mak o [1996/10/03] kern/1715 le driver non-reentrant o [1996/10/04] kern/1723 gibbs kernel fault when doing scsi reprobe o [1996/10/04] kern/1724 gibbs HP colorado T4000S tape drive hangs syste o [1996/10/04] kern/1726 panic in kmem_malloc (dump available) o [1996/10/10] kern/1754 netbooted machines freeze with ifconfig a o [1996/10/11] bin/1773 ports A NULL pointer causing segmentation core o [1996/10/13] gnu/1787 markm Diffs with Index: lines are not honored f o [1996/10/15] bin/1810 fsck -p does not check pass 0 filesystems o [1996/10/15] kern/1812 dyson vnodes are left in a locked state o [1996/10/15] kern/1814 cy driver gets deadlocked sometimes o [1996/10/20] kern/1848 breakpoints may be set in shared librarie o [1996/10/21] kern/1856 read-only nfs mount: panic leaf should be a [1996/10/22] ports/1866 wosch popclient flushes remote mailbox even wit o [1996/10/24] kern/1880 kernel crash during boot when using 512 M o [1996/10/26] bin/1892 install(1) removes target file o [1996/10/29] bin/1927 User CPU time getting accounting as syste o [1996/11/07] bin/1973 jmg pppd uses /etc/ppp/options.tty after comm o [1996/11/08] gnu/1981 ypserv handles null key incorrectly o [1996/11/13] ports/2000 asami obsolete software in distfiles directory a [1996/11/13] bin/2001 vi confused about lines to display o [1996/11/13] i386/2002 sio doesn't detect com port on Compaq Con o [1996/11/14] misc/2013 'make world' fails on read-only /usr/src a [1996/11/14] kern/2014 sos Console keyboard lockup problem o [1996/11/15] bin/2016 static libtcl references symbols that are o [1996/11/15] gnu/2035 peter deque bug, local gnu changes to deque hea o [1996/11/18] kern/2053 de0 driver don't work at 100M for Compex o [1996/11/24] kern/2094 wd1: interrupt timeout: o [1996/11/26] bin/2107 problem building a system from cdrom. s [1996/12/03] kern/2142 FP mask not saved for signal handlers o [1996/12/03] kern/2144 kernel panic (page fault) running chgrp o [1996/12/08] kern/2181 2.2-ALPHA flickers/wavers part of the upp o [1996/12/10] bin/2191 syslogd stops logging after several hours o [1996/12/13] bin/2206 NIS Makefile can't manage appletalk entri o [1996/12/17] kern/2232 MSDOSFS corrupts MSDOS partitions > 500Mb o [1996/12/18] kern/2248 Mitsumi CD-ROM driver has "timeout" probl o [1996/12/20] bin/2256 brian PPP process on port will not close when a s [1996/12/22] ports/2268 ports libc from linux emulator does not use /et o [1996/12/22] kern/2270 Hayes ESP serial card locks system as of a [1996/12/25] misc/2283 ache setlocale() in libxpg4 always returns NUL o [1996/12/29] bin/2318 /usr/libexec/rlogind doesn't work after t a [1996/12/30] kern/2325 quota.user enlarged, no boot on 2.2-BETA o [1996/12/30] kern/2330 changing root device to sd0a - ncr0: abor o [1997/01/01] kern/2351 panic:timeout table full f [1997/01/06] kern/2388 joerg start unit command screws up some CDROM d o [1997/01/07] gnu/2394 tar will extract files even if -C command f [1997/01/07] kern/2401 joerg 2.2 RELENG sometimes locks up early on bo o [1997/01/08] kern/2425 amd driver does not reprobe devices. o [1997/01/08] conf/2426 At end of install, panic: Going nowhere w o [1997/01/09] bin/2430 mountd stops on loading if subnet mask is o [1997/01/09] i386/2431 panic: get_pv_entry: cannot get a pv_entr o [1997/01/12] i386/2471 Sound: Reset failed - Can't reopen device o [1997/01/13] misc/2479 sos NEC CD-ROM NOT RECOGNIZED; MATROX MISTIQU o [1997/01/13] bin/2489 gnats mangles sections o [1997/01/16] kern/2507 Renaming DOS directories with "mv" causes o [1997/01/18] kern/2521 kernel from 2.1.6 install CD doesn't acce o [1997/01/20] kern/2538 worm burning suddenly broken o [1997/01/20] bin/2541 cd (using /bin/sh) may leave you in the w o [1997/01/20] kern/2545 se < sd0(ncr0:6:0): COMMAND FAILED ==> Not a [1997/01/21] bin/2549 sos cdcontrol refuses to play audio CDs from f [1997/01/21] misc/2551 davidn limit too small for user root o [1997/01/23] kern/2569 route -iface breaks inet behaivour f [1997/01/24] kern/2570 fenner arpresolve: cant allocate llinfo o [1997/01/25] bin/2591 sh coredumps when passing an argv of a ce o [1997/01/26] bin/2597 everything stops when the new ld.so is in o [1997/01/29] kern/2613 ache syscons mistakes MONO for MONO VGA o [1997/01/29] misc/2614 make reinstall does not work o [1997/01/29] bin/2616 Installs very irratically from the same c o [1997/01/31] kern/2632 enabling psm mouse causes keyboard to not o [1997/01/31] bin/2633 fsck -p in /etc/rc fails with cannot allo o [1997/02/02] kern/2640 2.2-RELENG leaks memory (router/pppd serv s [1997/02/03] kern/2647 changing existing route to -static crashe o [1997/02/04] ports/2664 ache elm methodically writes garbage into fold o [1997/02/05] kern/2667 wollman bpfattach can hang the system f [1997/02/05] bin/2670 fetch fails with HTTP_PROXY o [1997/02/05] bin/2671 Run-away processes using all CPU time a [1997/02/06] kern/2675 lkmcioctl() is not consistent and careful o [1997/02/07] kern/2690 asami When Using ccd in a mirror mode, file cre o [1997/02/08] kern/2695 sio1 (16540 serial port) is not recognize o [1997/02/09] kern/2698 After rewind I cannot read a tape; blocks o [1997/02/12] kern/2719 added support for magneto-optical SCSI di o [1997/02/14] kern/2732 mcopy 3.0 causes kernel hang o [1997/02/14] bin/2736 No boot block if no FreeBSD partitions on o [1997/02/15] kern/2742 panic: leaf should be empty o [1997/02/15] bin/2747 davidn cannot submit at jobs from within an at j o [1997/02/16] gnu/2749 peter cvs export using remote cvs fails - CVS/T o [1997/02/17] kern/2751 asami 2GB limitation on CCD device partitions s o [1997/02/18] bin/2762 Precedence mistake in libncurses o [1997/02/19] kern/2768 ktrace(1) -i dumps corrupted trace data o [1997/02/19] bin/2769 fsck needs several runs to clean up bad/d o [1997/02/19] kern/2770 panic: vm_fault: fault on nofault entry o [1997/02/19] kern/2771 panic: bad dir f [1997/02/19] kern/2772 gibbs panic: %s:%c:%d: Target did not send an I o [1997/02/19] kern/2773 bad dir panic o [1997/02/20] misc/2784 brian userland PPP rises load to 1.00 o [1997/02/20] bin/2785 wpaul callbootd uses an unitialized variable o [1997/02/20] gnu/2786 gcc version 2.7.2.1 C compiler slows down o [1997/02/21] misc/2793 libc_r make fscanf failure o [1997/02/22] kern/2800 DDS large data writing probrem o [1997/02/25] kern/2815 Custom Kernel crashes o [1997/02/28] bin/2832 w treats corrupted utmp as fatal error o [1997/03/01] kern/2840 mlock+minherit+fork+munlock causes panics o [1997/03/03] i386/2853 sos syscons beeps even if beeping screen is n o [1997/03/03] kern/2858 dfr FreeBSD NFS client can't mount filesystem o [1997/03/04] kern/2873 the od0 devies does not handle a Maxoptix o [1997/03/07] bin/2915 the "-fstype ufs" option of "find" seems o [1997/03/07] ports/2918 ports Unable to pass 8+ command line arguments o [1997/03/08] kern/2919 vm_fault: fault on nofault entry, addr: f o [1997/03/09] bin/2925 non-priviledged user can crash FreeBSD!! o [1997/03/11] bin/2948 can't dump 640MB optical disks o [1997/03/11] ports/2956 ports New Port: xgospel-1.10d in ftp.freebsd.or o [1997/03/12] kern/2965 st0 hang/fail on reading 4mm DAT tape for o [1997/03/12] bin/2969 csh and/or builtin printf has problems wi o [1997/03/12] bin/2973 output of iostat is wrong. o [1997/03/15] kern/2991 RTF_LLINFO routes remain when interface i a [1997/03/15] ports/2994 ports xpm port does not build for the first tim o [1997/03/18] kern/3021 panic after sync during reboot o [1997/03/21] kern/3054 OPL3 sound off by one note o [1997/03/21] bin/3055 umount -f does not work o [1997/03/24] i386/3082 keyboard locks up unexpectedly o [1997/03/24] i386/3083 Toshiba XM-5702B ATAPI CDROM not detected o [1997/03/27] conf/3123 /stand/sysintstall does not perform to up s [1997/03/27] bin/3126 Install with mcd0 still broken. o [1997/03/28] i386/3130 Dell Latitude keyboard lock up o [1997/03/28] misc/3133 TIOCSETD error with Cyclades 8Yo o [1997/03/30] gnu/3149 patch-2.1: files possibly created in wron o [1997/03/31] bin/3158 seg faults and cannot update links using f [1997/04/01] kern/3162 2.2 kernel from mar 25th crashes on nfs s o [1997/04/01] bin/3170 vi freaks and dump core if user doesn't e f [1997/04/04] i386/3195 gibbs ahc panic o [1997/04/05] kern/3201 de0 not re-enabled after hub down o [1997/04/05] ports/3205 jmz Mtools-3.0 attempts to flock() a disk par f [1997/04/05] kern/3209 dyson 3.0-current panics on shutdown/reboot/hal o [1997/04/06] kern/3216 panic: pmap_zero_page: CMAP busy o [1997/04/06] kern/3219 sppp or arnet gets looped after connectio o [1997/04/09] kern/3244 ipfw flush closes connections o [1997/04/10] bin/3246 mtree -c should escape whitespace and spe o [1997/04/11] ports/3256 ache ncftp-2.4.2 in packages-2.2 was not linke o [1997/04/12] kern/3263 troubles with digiboard o [1997/04/13] kern/3278 mounting MFS uses up swap space o [1997/04/15] bin/3305 Can't do encrypted rlogin into self f [1997/04/16] bin/3307 Unable to Route to a different Class C wi o [1997/04/18] kern/3327 using gdb may cause hanging processes. f [1997/04/18] kern/3328 dyson another kernel panic o [1997/04/19] kern/3351 Scsi bus timeouts in 2.1.7.1 (adaptec 294 o [1997/04/19] bin/3355 se ncrcontrol fails when -DFAILSAFE in kerne o [1997/04/25] kern/3384 telldir-seekdir can cause livelock o [1997/04/28] bin/3406 rich Fresh Internet Install - Permissions on f o [1997/05/01] gnu/3441 C++ exceptions don't work in shared libra o [1997/05/01] misc/3460 Lots of stuff still refernces /etc/syscon o [1997/05/01] kern/3463 netstat -I packet count increase on sl0 w o [1997/05/02] kern/3468 Panic - page fault in kernel mode o [1997/05/02] gnu/3470 fail to use standart ANSI C++ string clas o [1997/05/03] bin/3478 pwd_mkdb and passwd o [1997/05/04] kern/3495 _thread_fd_table is not initialized with o [1997/05/04] i386/3502 Merge of if_ix* and if_ie* broke EE/16 su o [1997/05/06] bin/3524 rlogin doesn't read $HOSTALIASES for non- o [1997/05/07] conf/3526 Bug in config(8) mechanism o [1997/05/07] kern/3527 if_de.c doesn't recognize Kingston card p o [1997/05/08] misc/3544 Uprgade problem with schg flags o [1997/05/09] kern/3564 using MPU401 driver pagefaults kernel o [1997/05/09] kern/3569 ex0 driver doesn't work with EtherExpress o [1997/05/11] misc/3578 defining CXXFLAGS in /etc/make.conf or en o [1997/05/12] kern/3579 de driver doesn't support newer SMC 9332 o [1997/05/12] kern/3581 intermittent trap 12 in lockstatus() o [1997/05/12] kern/3582 panic: bad dir (mangled entry) in 2.2-STA o [1997/05/12] kern/3583 'syctl kern' dumps core when displaying c o [1997/05/13] conf/3591 parts in rc.local have no effects in rc.* o [1997/05/18] bin/3622 gethostbyname fails for file descriptors o [1997/05/19] kern/3633 description of interface flags in ep(4) m o [1997/05/20] ports/3640 ports xlockmore galaxy bombs out o [1997/05/20] kern/3646 kernel built with "options NETATALK" fail o [1997/05/21] ports/3649 ports xlock quits on receipt of signalxx 8 o [1997/05/21] kern/3661 System locked up while editing rc.conf, w o [1997/05/23] bin/3670 make fails in libc o [1997/05/25] kern/3685 panic: fdesc attr o [1997/05/29] gnu/3714 gdb -w -k /kernel /dev/mem != gdb --wcore o [1997/05/30] conf/3725 Cirrus Logic PCMCIA Controller Support o [1997/05/30] kern/3726 process hangs in 2.2-stable when working o [1997/05/30] kern/3727 SCSI II tape support broken o [1997/06/01] kern/3744 Inability to edit memory area for ed0 pre o [1997/06/01] kern/3745 Use of ed0 with buff addr of C8000 causes o [1997/06/01] bin/3746 daemon screen saver missing o [1997/06/01] conf/3750 phk Potential improvements to rc.firewall o [1997/06/02] i386/3760 Inlel EtherExpress pro/100B !!! o [1997/06/02] bin/3763 df hangs uninterruptably when nfs mount f o [1997/06/03] kern/3771 NFS hangs when writing to local FS re-mou o [1997/06/04] i386/3779 changing cursor to blinking block causes o [1997/06/06] bin/3799 make world failing on 2.2.1 o [1997/06/07] conf/3807 mitsumi cd-rom fx800 (8x cd-rom) is not r o [1997/06/08] gnu/3810 cvs can't handle multiple multiple-path d o [1997/06/09] docs/3817 broken indent manpage o [1997/06/09] ports/3822 asami ports-current Xaw3d doesn't compile o [1997/06/09] kern/3827 fopen/freopen fails on some binary files. o [1997/06/13] i386/3857 bios screensaver screws up screen f [1997/06/13] bin/3862 I dont seem to get a login prompt.... o [1997/06/16] misc/3883 @+netgroup entries break +NIS-user entrie o [1997/06/18] kern/3899 df while unmounting floppy crashes 2.2.2 o [1997/06/19] kern/3909 joerg A patch supporting some new worm drivers o [1997/06/19] gnu/3910 sort(1) of 2.2.1R doesn't work in special f [1997/06/22] kern/3925 SO_SNDLOWAT of 0 causes kernel to use 99% o [1997/06/28] misc/3980 access via NFS fails during mount-operati o [1997/06/29] bin/3982 /usr/include/arpa/tftp.h has bug preventi o [1997/06/29] bin/3986 rdist seg faults when target machine is d o [1997/07/01] i386/4006 panic: ahc_intr: AWAITING_MSG for an SCB o [1997/07/02] kern/4012 2.2-RELEASE/Digital UNIX NFSv3 0 length f o [1997/07/02] misc/4013 boot floppy hangs if IDE ZIP Drive presen o [1997/07/03] kern/4022 Fatal double fault using vn device o [1997/07/04] kern/4032 gibbs During recovery from scsi errors, incorre o [1997/07/04] gnu/4033 peter cvs clears default branch when adding a f o [1997/07/06] gnu/4042 gdb stackframe in static library shows no o [1997/07/06] docs/4043 man page for directory ops is misleading o [1997/07/07] ports/4050 jfitz mrtg: rateup dumps core with malloc_optio o [1997/07/08] ports/4062 obrien xskyroot o [1997/07/09] kern/4071 Accessing /dev/rst0 causes `DMA beyond en o [1997/07/12] bin/4078 sos Typed password to log in on console and i o [1997/07/17] kern/4107 ch.c does not use bounce buffers o [1997/07/17] gnu/4111 send-pr doesn't se that Category is actua o [1997/07/17] kern/4115 SunOS NFS file has wrong owner if creator o [1997/07/19] kern/4119 can't connect to Win NT 4.0 RAS using MS o [1997/07/20] ports/4129 ports New port uploaded to incoming/sane.tar.gz o [1997/07/25] bin/4167 dump fials for dumping subdirectory o [1997/07/26] bin/4171 fetch(1): poor error handling in http mod o [1997/07/26] bin/4176 restore gets confused when run over pipe o [1997/07/27] ports/4178 jdp The cvsup port cannot be built on a non X o [1997/07/27] ports/4179 fenner lmbench-1.1 dumps core after asking for m o [1997/07/28] kern/4186 nfsiod, panic, page fault in kernel mode o [1997/07/30] kern/4194 kernel pci driver for Digital 21041 Ether f [1997/07/31] bin/4202 pwd_mkdb trashes .db o [1997/08/04] i386/4226 Floating point exception for double preci o [1997/08/05] bin/4231 ipfw no more returns error when deleting o [1997/08/06] kern/4233 pca driver does not support A-law encodin o [1997/08/06] bin/4234 ncurses programs broken, won't work in re o [1997/08/06] kern/4240 kernel fails to recognise 2nd serial port o [1997/08/06] bin/4241 send-pr aborts when emacs is editor o [1997/08/07] kern/4242 Remounting devfs causes panic o [1997/08/08] conf/4252 peter sendmail doesn't use smrsh by default o [1997/08/09] bin/4254 steve make in free(): warning: chunk is already o [1997/08/09] kern/4256 ahc driver: kernel goes to strange state o [1997/08/10] kern/4260 EOF handling in st(4) is broken o [1997/08/10] kern/4265 Panic in dsinit when multiple FreeBSD sli o [1997/08/10] kern/4270 ch driver does not use bounce buffers a [1997/08/11] kern/4271 sos System crashed caused by moving mouse poi o [1997/08/11] bin/4276 Security problem with DNS resolution o [1997/08/12] kern/4284 le0 goes OACTIVE after some time o [1997/08/13] kern/4292 le0 (DE203) goes OACTIVE after some time o [1997/08/13] kern/4295 SL/IP difficulties between 2.2.1 & 2.2.2 o [1997/08/16] kern/4312 arp table gets messed up, syslog "gateway o [1997/08/17] kern/4327 NFS over TCP reconnect problem o [1997/08/19] kern/4338 New device driver o [1997/08/20] bin/4341 cc: Internal compiler error: program cpp o [1997/08/21] bin/4353 fetch -m changes modified date o [1997/08/22] bin/4357 wosch bug in adduser script causes duplicate UI o [1997/08/23] bin/4366 bad144 crashes if checking over 2gb o [1997/08/24] bin/4376 pthread_join does not return the values s o [1997/08/25] bin/4379 Make world breaks in sbin/ifconfig o [1997/08/25] docs/4381 mount -t msdos causes panic:vm_fault o [1997/08/25] kern/4382 CURRENT kernel has a "free vnode isn't" p o [1997/08/27] ports/4405 jfitz ascend-radius port is out-of-date a [1997/08/29] kern/4416 syscons: problem with font a [1997/08/29] kern/4417 syscons: mouse pointer destroys character o [1997/09/01] bin/4445 segmentation fault in vfprintf o [1997/09/02] kern/4454 X drops characters/locks up keyboard when o [1997/09/03] bin/4460 lpd hangs exiting (IE in ps table) o [1997/09/06] bin/4476 fetch puzzled while getting files when ma o [1997/09/06] bin/4477 vidcontrol fails to change videomode on s o [1997/09/07] kern/4487 Kernel panic executing a directory o [1997/09/08] bin/4497 Reverse DNS fails for some CIDR *.IN-ADDR o [1997/09/08] kern/4498 Files corrupted when written to Iomega Zi o [1997/09/08] bin/4500 mount_nfs always uses priviledged port o [1997/09/08] kern/4501 df on a stale file system panics o [1997/09/09] kern/4505 Support for Gravis UltraSound PnP card o [1997/09/10] kern/4508 nfs3 data integrity problems o [1997/09/11] gnu/4511 GCC optimization broken with -m486? o [1997/09/11] kern/4513 System lockup appears to be VM related. o [1997/09/12] bin/4520 the following (long) line kills fmt o [1997/09/13] conf/4522 Polish locale o [1997/09/14] i386/4533 Server with Cyclom-Y PCI card rebooted at o [1997/09/14] ports/4543 ports New financial | misc port: personal check o [1997/09/14] kern/4544 Linux emulator problems when MAXDSIZ is i o [1997/09/16] bin/4554 pthread_cond_wait() doesn't wait for pthr o [1997/09/16] kern/4559 ELINK_ID_PORT problem with 3C509 cards o [1997/09/18] bin/4568 simple /bin/sh script produces wrong resu o [1997/09/18] misc/4576 mfs does not mount requested size from /e o [1997/09/19] bin/4582 integer overflow in 'sa -km' o [1997/09/19] bin/4585 termcap search fails too early o [1997/09/20] kern/4588 NFS access locks up o [1997/09/21] bin/4599 mktemp is too smart, accesses the path gi o [1997/09/21] kern/4600 nfs lookups might give incorrect result f [1997/09/22] kern/4609 Heavy HTTP load causes "out of memory buf o [1997/09/25] kern/4630 buffer_map might become corrupted o [1997/09/26] conf/4634 Sendmail Problem o [1997/09/27] bin/4638 telnet tries to resolve numerical IP addr 345 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- a [1994/12/01] kern/35 mount -t union -o -b : lower layer not se o [1995/01/14] bin/115 systat iostat display doesn't scale high o [1995/01/22] kern/176 peter EIDRM not defined in errno.h o [1995/04/20] misc/355 policy on /usr/local permission in base r o [1995/05/13] bin/401 wollman Add REMOTE_* variables a [1995/05/23] i386/440 sos want vidcontrol option to apply settings a [1995/05/27] gnu/450 scrappy tar --exclude -c doesn't work o [1995/06/15] bin/517 wpaul Bad group change with 'install' o [1995/07/05] bin/591 phk SPAP request REJexted in stead of NAKed o [1995/07/09] misc/605 wpaul NIS: get*bynis routine problems f [1995/08/03] kern/652 Multiple addresses on one interface inter s [1995/08/05] gnu/655 jdp ld -r of shared objects worked in 1.1.5, o [1995/08/07] bin/658 ifconfig alias has to be separately given f [1995/08/12] kern/677 dyson X gets a bus error when calling mmap() o [1995/08/13] bin/680 joerg 2.0.5's tip using termios doesn't act the o [1995/08/18] kern/700 fenner The comments in /sys/net/if.h are confusi o [1995/09/26] kern/742 dyson syslog errors accessing Mac hard disks [p o [1995/10/03] kern/765 phk umount -f can`t umount a NFS filesystem i o [1995/11/20] kern/831 one minor complaint about the kernel visu o [1995/11/27] bin/841 stale nfs mounts cannot be umounted o [1995/11/30] bin/854 dyson swapinfo shows incorrect information for o [1995/12/17] kern/900 dyson ext2fs triggers divide by zero trap in vn a [1995/12/29] misc/922 From line handling incorrect in mail.loca a [1995/12/31] kern/924 EISA devices have disappeared from vmstat o [1996/01/21] bin/961 'more $file', incorrect CRLF compacting. o [1996/01/28] kern/975 bde getrusage returns negative deltas a [1996/01/30] bin/981 fenner clnt_broadcast() is not aware of aliases s [1996/02/03] bin/993 peter g++ complains about /usr/include/machine/ o [1996/02/07] bin/999 peter /usr/share/mk/sys.mk missing common $(RM) o [1996/02/12] bin/1021 phk pppd doesn't handle PAP-only authenticati o [1996/02/19] bin/1037 2.x telnetd handles CTRL-M differently th o [1996/02/25] i386/1042 bde Warning from sio driver reports wrong dev o [1996/02/26] misc/1043 dyson vm_bounce_alloc error on 2.1 install with o [1996/03/20] kern/1090 iostat displays incorrect sps count o [1996/03/20] bin/1093 wollman route's diagnostic is weird o [1996/04/06] kern/1119 dyson Mounted EXT2FS partition is not cleanly u a [1996/04/15] kern/1144 sig{add, del}set and sigismember fns don' a [1996/04/22] bin/1154 Configure tunN device for ip-over-ip tunn o [1996/04/23] bin/1155 systat or top display disagreeing informa o [1996/05/09] bin/1184 scrappy ls + xterm + nvi + columns != 80 + ^Z = m o [1996/05/15] bin/1206 steve /bin/sh + emacs + ^G = ruined terminal o [1996/06/11] bin/1312 automounter hangs on boot o [1996/06/12] conf/1319 muldi3 is not included into kernel's Make a [1996/06/13] bin/1320 gpalmer dump limits blocksize to 32K o [1996/06/18] i386/1331 phk changes and bug in ft driver f [1996/06/18] bin/1332 changes to amd and possible nfs lkm bug? f [1996/07/04] misc/1369 Need SC_MORE_LUS for Emulex MD23 also a [1996/07/07] bin/1375 Extraneous warning from mv(1) f [1996/07/07] misc/1376 if_tun.c does not set if_ibytes and if_ob o [1996/07/18] kern/1399 dyson invoking setuid programs over NFS case vn o [1996/07/21] ports/1416 ports cflow(1) doesn't parse GNU C __attribute_ s [1996/07/23] kern/1421 Non-bug in sosend() o [1996/07/24] misc/1428 ncurses doesn't always display ALTCHARSET o [1996/08/03] kern/1462 nfsstat doesn't work if using LKM'ed vers a [1996/08/07] ports/1470 asami need more info in the ports structure o [1996/08/17] kern/1501 vmstat reports impossible avm after start o [1996/08/17] bin/1502 vmstat 'avm' field merges with procs 'w' o [1996/08/17] kern/1508 sos syscons should protect against useless DD o [1996/08/19] kern/1514 dyson mlock fails on readonly regions o [1996/08/20] kern/1516 dyson vm_fault.c contains dead code or too many o [1996/08/21] ports/1520 erich sudo dosn't recognise certain passwords a o [1996/08/21] bin/1523 "cvs update -d -P" prunes unchecked-in di o [1996/08/24] misc/1538 enhanced /etc/security script a [1996/09/04] bin/1565 Moving a file to it's link completely rem o [1996/09/06] bin/1577 mail -f foo does not look in current dire o [1996/09/08] bin/1589 ftp fails to flush output o [1996/09/11] bin/1598 tip leaves OPOST set on controlling termi o [1996/09/12] docs/1602 ache /usr/lib/terminfo refered to in man termi o [1996/09/12] bin/1607 dfr unmount fails for a NFS fs mounted withou o [1996/09/14] gnu/1611 phk groff should use "system-wide" papersize o [1996/09/14] kern/1614 Attempt to mount an NTFS partition causes f [1996/09/18] kern/1636 mss driver extension to broaden support a [1996/09/18] bin/1642 pkg_install Makefiles could be simplified o [1996/09/19] kern/1654 In procfs, vattr doesn't contain correct o [1996/09/20] kern/1658 ktrace/kdump flaky - corrupted ktrace.out o [1996/09/23] i386/1671 s2 map in pcvt isn't ISO 8859-1 and claim o [1996/09/29] kern/1690 apm and sbxvi inappropriately probe as co o [1996/09/29] docs/1691 brian ppp server doc submission o [1996/10/02] misc/1708 monthly login accounting o [1996/10/02] kern/1711 joerg kernel logging of signaled processes shou o [1996/10/03] misc/1717 Use of ntohl causes lint to complain o [1996/10/04] bin/1721 /sbin/route incorrectly installs routes w o [1996/10/04] kern/1725 visual config redraws bits of the screen f [1996/10/08] misc/1738 Install floppy returns random geometry wi o [1996/10/11] conf/1777 sysctl called in /etc/netstart before /us s [1996/10/13] kern/1788 pst netstat gives negative numbers for tcp by o [1996/10/13] misc/1791 syslimits.h does not allow overriding def o [1996/10/13] bin/1793 steve /bin/sh return w/o exitstatus in a functi o [1996/10/14] bin/1804 pkg_create hangs if the packing list has o [1996/10/16] bin/1827 add support of Glidepoint trackpad "tap/d o [1996/10/20] bin/1849 gdb sets library breakpoints on the wrong o [1996/10/20] misc/1853 Syscons font mapping semms not to work pr o [1996/10/20] docs/1855 joerg Addition to LINT o [1996/10/22] kern/1868 system knows it has no keyboard but compl o [1996/10/23] misc/1871 incorrect '===> item' when making world o [1996/10/23] bin/1872 automounter (amd) cannot ls directories w o [1996/10/24] bin/1881 file(1) misidentifies Sun3/m68k executabl o [1996/10/26] bin/1897 Sendmail 8.8.2 requires /etc/sendmail.cw o [1996/10/27] bin/1904 /usr/bin/su is not careful enough in veri o [1996/10/29] bin/1924 if lpd is not running, lpc will say ``no o [1996/10/30] i386/1931 Mitsumi CDrom works well under 2.1.x, fai o [1996/11/01] bin/1941 wtmp and monthly rotation o [1996/11/01] bin/1943 route(8) args o [1996/11/02] bin/1945 Out of date code/comments in dd o [1996/11/04] i386/1953 sos syscons savers have no default timeout o [1996/11/04] gnu/1961 uucp logging files are in /var/spool/uucp o [1996/11/06] bin/1968 FreeBSD has no rdate(8), here's one o [1996/11/06] bin/1970 csh limtail() bug o [1996/11/09] bin/1985 pkg_delete outputs confusing message when o [1996/11/13] kern/2004 route add -link panic o [1996/11/13] bin/2005 Poor command line argument checking and b o [1996/11/14] bin/2008 kerberos tickets from login all have the o [1996/11/15] kern/2022 Switching from X display to virtual conso o [1996/11/16] bin/2036 cpio size wraparound o [1996/11/16] ports/2038 torstenb sshd dies on FreeBSD machines if run as a f [1996/11/18] ports/2051 andreas HDF library port o [1996/11/19] bin/2061 DEBUG_FLAGS in bsd.lib.mk is broken o [1996/11/19] bin/2065 wollman in tzsetup/sysinstall, allow user to type o [1996/11/19] misc/2068 Unstable keyboard mappings on the main tt o [1996/11/20] kern/2072 ZIP drive support is available for FreeBS f [1996/11/21] ports/2079 obrien New ports supporting AWE sound driver (fo o [1996/11/22] docs/2087 ifconfig.8 does not document how to remov o [1996/11/22] bin/2090 clients may bind to FreeBSD ypserv refusi o [1996/11/25] misc/2105 bsd.lib.mk has problems with STRIP and IN o [1996/11/26] bin/2106 Byte order problem in -current routed o [1996/11/26] i386/2108 sos [ATAPI] wcd driver may hang under certain o [1996/11/28] kern/2118 sos writing to virtual consoles fails to disp o [1996/11/28] bin/2119 mount lies to child about argv0, which ca o [1996/12/01] bin/2133 netstat -s overflows to negative o [1996/12/02] bin/2137 vm statistics are bad o [1996/12/02] kern/2140 FreeBSD leaves EtherExpress 16 net card i o [1996/12/03] ports/2145 pst qpopper bulletin support broken o [1996/12/03] conf/2146 brian wrong /dev for COM2 during installation v o [1996/12/06] i386/2166 psm driver locks the console o [1996/12/07] ports/2169 pst zephyr port does not completely compile f [1996/12/08] ports/2182 ports FreeBSD's and X-32's list of locales do n o [1996/12/08] bin/2184 sendmail has lots of trouble with local d o [1996/12/08] misc/2185 phk add ability to change partition type in l a [1996/12/10] ports/2190 asami need cross-reference to xpdf from X11 por o [1996/12/12] kern/2199 joerg Got a lots of "Target Busy" messages with o [1996/12/14] kern/2214 File System gets corrupted when mounting o [1996/12/14] bin/2216 Ada specs not being compiled into cc/gcc o [1996/12/16] bin/2227 FreeBSD does not recognize WD7000-ASC dri o [1996/12/17] i386/2234 fbsdboot.exe does not turn off floppy dri o [1996/12/17] i386/2239 some interrupts take too long (i.e. BT946 o [1996/12/18] misc/2242 Suggest add optional mt blocksize 512 o [1996/12/18] bin/2247 imp getopt should return -1 rather than EOF o [1996/12/20] bin/2260 brian PPP logins using PAP to Nortel/Shiva syst o [1996/12/21] ports/2264 jmz latex* ports need updating a [1996/12/21] bin/2265 guido su(1) does not call skeyaccess() o [1996/12/24] kern/2273 dufault support for POSIX.4 / POSIX.1a RT-schedul o [1996/12/25] conf/2284 Termcap ibm3163 entry has arrow keys wron o [1996/12/26] bin/2291 race condition in /etc/master.passwd lock o [1996/12/27] kern/2298 Support for DSR/DCD swapping on serial po a [1996/12/27] misc/2302 markm new crypt() including SHS and an extendab o [1996/12/28] misc/2309 Thread safe fixes to malloc, localtime, l o [1996/12/28] ports/2313 torstenb pidentd fails in 2.2-BETA o [1996/12/29] bin/2315 tail segfaults on NFS permission denied o [1996/12/29] misc/2323 FreeBSD.FAQ file in ftp.freebsd.org is lo o [1996/12/30] kern/2327 `Green' saver for pcvt o [1997/01/01] docs/2353 Changes to FAQ o [1997/01/03] bin/2366 libc does not consult /etc/services to fi o [1997/01/03] bin/2368 serial line logins "freeze" during login o [1997/01/06] bin/2382 curses.h / -lcurses incompatible with C++ o [1997/01/06] bin/2383 Inconsistent tputs(3) prototypes in curse o [1997/01/06] misc/2386 patches for new socket credential firewal o [1997/01/06] bin/2387 virtual hosting patches for inetd o [1997/01/06] kern/2390 Some CDROM drives stop audio on cdcontrol o [1997/01/07] kern/2393 filesystems not unmounted following shutd o [1997/01/07] misc/2407 dirent.h does not include sys/types.h o [1997/01/07] bin/2410 pppd(8): failing PAP doesn't force line d o [1997/01/07] kern/2412 Wine does not work o [1997/01/07] ports/2413 peter Cannot redirect "top" output o [1997/01/08] kern/2424 Pressing ALT-Fn during boot -c leave bell o [1997/01/09] kern/2429 Driver for AIMS Lab RadioTrack radio card o [1997/01/10] bin/2437 minor nits on text in 2.2-BETA install o [1997/01/10] bin/2442 davidn setusershell()/endusershell() missing o [1997/01/10] bin/2443 Fetch cannot find the correct boundary be o [1997/01/11] bin/2448 semctl() not portable -- freebsd requires o [1997/01/11] docs/2455 no description "option COMCONSOLE" MLEN o [1997/01/26] misc/2596 dd refuses to respond to SIGkill o [1997/01/26] i386/2598 ep0 in EISA mode hangs if ep0-device (ISA o [1997/01/28] bin/2603 dufault Added POSIX.4/POSIX.1b constants in unist o [1997/01/28] bin/2604 dufault Added POSIX.4/POSIX.1b shm_open()/shm_unl o [1997/01/28] ports/2607 max New port: Gopher-2.3 o [1997/01/29] misc/2617 Utility submission - upsmon - UPS monitor o [1997/01/30] kern/2621 Patch to support Cogent EM110 fast-ethern o [1997/01/30] docs/2623 ipfirewall(4) man page is way out of date o [1997/01/30] bin/2624 kdump unaware of semsys and several other o [1997/01/31] bin/2630 xargs does excessive and inconsistent arg o [1997/02/02] gnu/2637 tar dumped core with -g option. a [1997/02/02] bin/2641 wpaul login_access.c doesn't work with NIS by d o [1997/02/04] bin/2657 ypserv thinks there is no computers in ne o [1997/02/04] bin/2660 When selecting BSD to boot from system ha o [1997/02/04] bin/2665 port 22 isn't being converted to ".ssh" i o [1997/02/05] bin/2668 modification suggested for rarpd o [1997/02/05] bin/2672 Problem with telnetd s [1997/02/07] ports/2684 torstenb ircII port upgrade; 2.9_roof -> 2.9alpha1 o [1997/02/07] kern/2686 struct igmpmsg in s o [1997/02/07] misc/2687 jkh sysinstall umounts floppy after prompting o [1997/02/10] bin/2703 vipw doesn't allow you to edit master.pas o [1997/02/10] kern/2704 Occasional failure to detect wdc1 on boot o [1997/02/11] conf/2709 FBSD 2.1.6 X-Server installation setup ut o [1997/02/11] bin/2713 ftp daemon processes don't terminate, eve o [1997/02/11] kern/2715 MSDOS-FS 1024/2048 byte/sector media supp o [1997/02/11] kern/2716 od.c/sd.c non 512 byte/sector support imp o [1997/02/13] i386/2729 "make tags" in sys/kern produces barely u o [1997/02/14] bin/2734 jkh pkg_* uses relative paths to executables o [1997/02/14] bin/2735 jkh Add signature support (both MD5 and PGP) o [1997/02/14] bin/2737 yppasswd fails to change password on a su o [1997/02/15] misc/2745 fenner PR querry web form doesn't sort correctly o [1997/02/20] docs/2780 Description of Linux emulation is out of o [1997/02/20] bin/2782 err man page is slightly wrong o [1997/02/21] misc/2789 na.phone update o [1997/02/22] ports/2797 ports New Port: qmail o [1997/02/23] kern/2806 new kernel tags script o [1997/02/25] i386/2813 hard reference to /usr/src breaks make wo o [1997/02/26] conf/2819 /etc/rc does not execute 'uname' when con o [1997/02/26] conf/2822 ftp install specifying URL confusing o [1997/02/27] gnu/2827 after make world genclass is not installe o [1997/02/28] docs/2833 Repeated topics on FAQ entry hardware com o [1997/03/02] docs/2850 init(8) man page does not document secure o [1997/03/02] bin/2851 script(1) sets argv[0] of the started she o [1997/03/03] kern/2857 DE500 board exhibits capture effect o [1997/03/03] bin/2859 /usr/bin/quota seems to choke on long gro o [1997/03/03] kern/2865 dfr NFS client hangs on umount, ls, df when N o [1997/03/03] bin/2871 showmount -e returns error o [1997/03/04] misc/2882 Duplicate line in /etc/services? o [1997/03/05] kern/2886 fenner mbuf leak in multicast code o [1997/03/06] docs/2897 steve send-pr categories should be explained so o [1997/03/06] bin/2898 fenner arp -a -n buglet a [1997/03/06] ports/2902 ports Fix xmcd port for PACKAGE_BUILDING a [1997/03/06] ports/2905 ports Fixed port: xshisen-1.36 o [1997/03/08] ports/2920 ports patch for mispositioned xv windows under o [1997/03/09] i386/2924 sos syscons X keyboard gets stuck in capsmode o [1997/03/09] ports/2926 ports xmgt-2.31 port, now in pub/incoming on ft o [1997/03/10] bin/2934 sh(1) has problems with $ENV o [1997/03/10] bin/2938 Add -b, -l, and -f options to du(1) o [1997/03/11] ports/2949 ports bsd.port.mk needs something like FETCH_EN o [1997/03/11] misc/2955 pkg_add failed on xemacs via sysintall o [1997/03/13] ports/2974 ports updated Makefile and patch-ab of jp-dvi2p o [1997/03/13] bin/2977 After enabling moused and vidcontrol and o [1997/03/13] bin/2979 GCC complains about stmt. expr. when comp o [1997/03/13] i386/2984 serial port console only prints ~ 1 char o [1997/03/14] ports/2988 joerg vga font is not built o [1997/03/15] ports/2993 ports qmail-port-take2-proff.tar.gz in incoming o [1997/03/15] kern/3001 soundblaster8 card does not work correctl o [1997/03/16] misc/3009 packages-2.2/x11/fvwm-1.24r.tgz corrupt o o [1997/03/17] ports/3012 ports qmailanalog port in incoming o [1997/03/18] conf/3023 By default users have no write permission o [1997/03/18] misc/3024 make reinstall in /usr/src requires writa o [1997/03/18] bin/3025 mv to / trailed dirs prints odd error mes o [1997/03/18] bin/3028 sos add support for Glidepoint pointing devic a [1997/03/21] ports/3052 ports /usr/ports/lang/expect does not find tkCo o [1997/03/22] kern/3061 route does not accept -genmask o [1997/03/24] misc/3075 2.2-R install "features" (non critical) o [1997/03/24] ports/3081 ports sitelispdir is a directory no a path in x o [1997/03/24] ports/3090 torstenb ircii-2.9-roof does not run. o [1997/03/26] misc/3113 make libraries failed. a [1997/03/28] misc/3136 rc.firewall should be run after interface o [1997/03/29] bin/3139 qcamcontrol has a bug where I/O errors ar o [1997/03/29] misc/3140 display message is broken on boot.flp o [1997/03/30] docs/3147 /usr/share/misc/au.postcodes f [1997/03/30] misc/3148 ache adjkerntz screws up during GMT/BST change o [1997/03/31] gnu/3157 Patches to gas and gdb to support MMX ext a [1997/04/01] bin/3164 view copies the file into vi.recover o [1997/04/01] ports/3169 ports nn port broken o [1997/04/01] kern/3172 CS4232 support trouble for mss0 o [1997/04/03] bin/3190 RISCom N2 card driver problem? o [1997/04/04] bin/3194 2.2.1-RELEASE hangs when using /stand/sys o [1997/04/06] bin/3211 ctm uses mktemp()> o [1997/04/06] bin/3212 the pkg_* tools use mktemp() o [1997/04/07] bin/3221 rpc.rusersd : can't communicate with SunO o [1997/04/07] misc/3225 uucpd.c should normalize host names as lo o [1997/04/08] bin/3232 XFree86 installation Problem with non-Mic a [1997/04/08] bin/3233 wosch adduser(8) doesn't add users to the wheel o [1997/04/08] misc/3237 SCRIPTS addition to bsd.prog.mk a [1997/04/09] bin/3241 times(3) returns only stime o [1997/04/09] bin/3242 incorrect prototype for initgroups o [1997/04/09] bin/3245 variable substitution "a=${a:=}" in /bin/ o [1997/04/10] bin/3251 xsysinfo stops refreshing and wastes CPU o [1997/04/10] kern/3253 scsiconf.c: make ZIP disks use optical dr o [1997/04/13] conf/3272 $@ is deprecated I believe, so use ${.TAR o [1997/04/14] kern/3281 errors when "rm -r"-ing in a mounted ext2 o [1997/04/14] kern/3282 ext2fs causes fs-unmount at shutdown/rebo o [1997/04/14] bin/3284 symorder(1): -t option doesnīt work at al o [1997/04/14] bin/3285 date option for pom(6) (phase of the moon o [1997/04/14] bin/3286 missing error checking in mount_mfs(8) ak o [1997/04/14] kern/3287 missing symbols in /usr/src/sys/i386/i386 o [1997/04/14] bin/3289 login(1) does not check /etc/skey.access o [1997/04/15] kern/3299 /dev/console hangs f [1997/04/15] kern/3302 msdos FS bogus error o [1997/04/15] ports/3306 ports new port-package for ifmail o [1997/04/17] bin/3314 /etc/daily did not run on April 6, 1997 o [1997/04/17] kern/3317 odd TUBA_INCLUDE use in tcp_input.c o [1997/04/17] ports/3318 ports New port: jigsaw (Java-based HTTP server) o [1997/04/18] ports/3322 markm setlocale problem in lang/perl5 a [1997/04/19] ports/3335 ports new port request of korean/hanemacs o [1997/04/20] ports/3358 asami XFMail-1.1 has been released o [1997/04/20] ports/3363 max port of nana-1.00 for your collection o [1997/04/21] misc/3368 jkh sysinstall upgrade should confirm before f [1997/04/23] kern/3375 Consistent 10 min. delay at boot with REL o [1997/04/24] ports/3379 ports mprof dumps core on FreeBSD 2.2.1 o [1997/04/25] ports/3383 ports kaffe core dumps if LD_LIBRARY_PATH not s o [1997/04/25] bin/3386 kernel 'config' wrapper 'doconfig' ala Di o [1997/04/27] ports/3396 max update of the port of Mesa (now version 2 o [1997/04/27] bin/3399 mv of symbolic link can move directory in o [1997/04/27] docs/3400 MAXMEM uses maths in LINT o [1997/04/27] conf/3401 jkh sysinstall sends empty FreeBSD user regis o [1997/04/28] ports/3411 ports New port - Atari 8 bit computer emulator o [1997/04/29] bin/3416 ibcs emulation problems o [1997/04/29] bin/3418 pkg_create doesn't always create gzip'ed o [1997/05/01] ports/3455 jmz mtools-3.6.tgz could have a better mtools o [1997/05/02] kern/3475 gdb(ptrace?) cause create/modify times on o [1997/05/03] misc/3476 Please add support for .cpp suffix to sta s [1997/05/04] ports/3498 ports nn-current port is out of date o [1997/05/04] ports/3499 markm exim port out of date o [1997/05/05] i386/3504 New features (and manpage) for netboot o [1997/05/05] bin/3506 more did not show iso-8859-n characters o [1997/05/05] bin/3508 FreeBSD 2.2.1 do not view SCSI disk at sw o [1997/05/06] docs/3522 Man pages close(2) misses fcntl lock info o [1997/05/07] bin/3528 fsck fails to detect some illegal block n o [1997/05/08] kern/3546 ktrace works even if no read permission o [1997/05/08] gnu/3552 the -L option of tar does not work proper o [1997/05/09] bin/3556 Bug with -i option in /usr/bin/lpr o [1997/05/09] bin/3558 make reinstall collapses on install-info o [1997/05/09] kern/3560 Timeout counter bug in /sys/i386/isa/wd.c o [1997/05/09] kern/3571 Mounted ext2 prevents umount of filesyste o [1997/05/11] conf/3577 eBones and OBJLINK=yes fails to build o [1997/05/12] kern/3584 cleanup TCP_REASS macro in tcp_input.c o [1997/05/13] conf/3590 Difference in ttys and FAQ f [1997/05/14] ports/3597 ports jp-groff-0.99 port macro update o [1997/05/16] bin/3608 Telnet in linemode will break apart long o [1997/05/17] kern/3611 Internal CPU cache on CyrixiInstead DX2 d o [1997/05/18] gnu/3616 permissions of /usr/libexec/uucp/uuxqt no f [1997/05/19] ports/3634 andreas fvwm95-2.0.43a-i18n-port.tar.gz was put o [1997/05/19] docs/3636 No mention is made in relevant manpages a o [1997/05/20] bin/3638 /bin/w can't handle long /dev/{tty,cua}xx o [1997/05/20] bin/3639 ac doesn't know about FreeBSD's pty names o [1997/05/20] docs/3645 TCP_wrappers package doesn't mention wher o [1997/05/21] bin/3648 find(1) extension for file flags o [1997/05/21] ports/3657 ports Port of NCSA HyperNews submitted as p5-hy o [1997/05/22] i386/3663 Unable to get system printer to work o [1997/05/22] ports/3665 jmz mtools port install fails o [1997/05/22] kern/3667 patches to modularize vnode driver o [1997/05/24] conf/3673 no ddp line in /etc/protocols o [1997/05/25] kern/3678 bug in IPDIVERT code in -current o [1997/05/27] misc/3695 compiled termcap.db not in distribution o [1997/05/28] bin/3705 jkh /stand/sysinstall hangs. pkg_add also ha o [1997/05/29] conf/3713 installation floppy bug o [1997/05/30] kern/3720 Addition for supported Hardware o [1997/05/30] kern/3724 jkh sig-11 on package add in sysinstall o [1997/05/31] ports/3729 scrappy pgsql dies when initiated o [1997/05/31] kern/3731 Addition of a PCI Bridge f [1997/05/31] bin/3733 davidn getty with 'to' option causes pppd to die o [1997/05/31] ports/3737 ports The DHCPD no longer works under FreeBSD 2 o [1997/06/01] kern/3738 Byte and packet counters in ipfw overflow o [1997/06/01] kern/3739 pause key not disabled; weird stuff when o [1997/06/01] conf/3751 Improvements to /etc/rc{,.network,.pccard o [1997/06/02] ports/3759 tg xtem-5.23 (X11 TEx Menu) port submitted ( o [1997/06/02] bin/3762 dufault Bogus return values from rtprio(1) o [1997/06/02] docs/3764 systat(1) -vmstat description seems to be o [1997/06/04] conf/3775 Time Zone for Sri Lanka - LKT o [1997/06/04] bin/3778 ypbind -S domainname,server1,... does not o [1997/06/04] ports/3787 ports ghostscript-3.53 has bad PLIST o [1997/06/07] bin/3805 single process tftpd o [1997/06/07] ports/3806 ports update s3mod to 1.09 o [1997/06/08] docs/3808 The manpage telnet.1 has many bugs. o [1997/06/09] docs/3819 davidn man (5) login.conf specifies passwordtime o [1997/06/09] ports/3824 ports New port: snes97 o [1997/06/09] bin/3826 KerberosIV sometimes hangs rcp o [1997/06/09] ports/3831 ports netris port doesn't install sr o [1997/06/10] kern/3836 Cannot remove HUGE directory o [1997/06/10] bin/3837 dufault new feature for rtprio o [1997/06/10] kern/3839 X startup undoes keyboard repeat rate (pc o [1997/06/12] kern/3853 netboot/ns8390.c breaks NS datasheet o [1997/06/12] i386/3856 Improvement to autodetection logic o [1997/06/13] bin/3859 Setting the $0 variable in perl dosnt do o [1997/06/14] bin/3866 rcs2log fails with eastern timezones o [1997/06/14] ports/3870 ports Upgrade tkdesk 1.0b3 --> 1.0b4 o [1997/06/15] kern/3879 Can't export mounted ext2fs via NFS o [1997/06/16] conf/3886 install does not build sendmail host stat o [1997/06/17] ports/3888 torstenb port net/wu-ftpd: tiny bug that is wu-ftp o [1997/06/17] bin/3891 NIS-only netgroup lookups don't work o [1997/06/17] ports/3892 max new port: www/webxref (cross-reference ge o [1997/06/17] gnu/3894 manpath segfaults if it dosen't understan o [1997/06/18] kern/3901 Multicast for Intel 10/100 Ethernet Card o [1997/06/19] misc/3912 ctags(1) cannot trace some macro correctl o [1997/06/20] gnu/3918 vi dosnt wrap lines when called from send o [1997/06/22] ports/3928 ports New port: jp-pgp-2.6.3ia (language) o [1997/06/23] kern/3938 Problem about mmap() over NFS o [1997/06/23] ports/3939 ports new port: latex2html_icon_server o [1997/06/23] ports/3940 ports port of latex2html-96.1 o [1997/06/24] kern/3944 if_le doesnt receive ether multicast pack o [1997/06/24] bin/3947 /usr/src/etc/pccard_ether is too old... o [1997/06/25] kern/3948 nonworking t/tcp server side a [1997/06/25] kern/3953 kern-config: options PANIC_REBOOT_WAIT_TI o [1997/06/25] ports/3955 torstenb -kpassive_ftp=true fails on socket connec o [1997/06/26] bin/3957 Makefile dependency error in amd o [1997/06/26] ports/3958 jmz a2ps fails if used according to man o [1997/06/26] i386/3962 print disk internal cache size during pro o [1997/06/27] kern/3968 Hardware probes die on Peak SBCs. o [1997/06/28] misc/3981 brian wtmp logging of ppp activity would be nic o [1997/06/29] ports/3983 ports New port: psf toolkit o [1997/06/30] ports/3991 ports set of OffiX ports o [1997/06/30] ports/3997 ports New port: VRML browser (vrweb) a [1997/07/01] bin/4004 moused(8) + international language text = o [1997/07/02] ports/4014 ports package/port installation obeys roots uma o [1997/07/02] ports/4017 ports Someone has to upgrade the plor port! o [1997/07/03] bin/4019 mount_mfs lacks an error message, and exi o [1997/07/03] kern/4020 itojun vxget() in /sys/dev/vx/if_vx.c needs rewo o [1997/07/03] ports/4023 ports One can't play the cardgame Ass on FreeBS o [1997/07/03] i386/4024 sos Patch to add dead key support to syscons o [1997/07/03] ports/4025 ports New port - jp-ebw3 o [1997/07/04] ports/4027 ports New port: rot13-1.3 o [1997/07/05] kern/4037 boot.flp panics after kernel load if >2 s o [1997/07/05] ports/4038 ports Initial port of the alpha-rel. WindowMake o [1997/07/06] kern/4039 2940UW and DCAS 32160 -- hungs if 40 MB/s o [1997/07/07] kern/4051 pppd connect 'chat ...' broken o [1997/07/07] kern/4052 VJ compression drops packets with IP+TCP o [1997/07/07] ports/4055 ports Port for XMpeg3 v1.0 o [1997/07/07] ports/4056 obrien Port for netpipes 3.2 o [1997/07/08] ports/4061 obrien new port: xklock o [1997/07/08] misc/4063 2.2.2R Installation fails if Jaz drive sp o [1997/07/09] ports/4067 ports wrong formats of files in offix.tar o [1997/07/13] ports/4083 ache netscape wrapper doesn't hand off args co o [1997/07/13] kern/4086 Floppy Disk Driver Problem o [1997/07/14] bin/4087 nameservice terminates after ndc restart o [1997/07/16] ports/4103 ports Should I or should I not ? o [1997/07/16] ports/4104 ports Minor fix to hobbes-icons-xpm3 o [1997/07/17] ports/4109 ports New port: xcopilot o [1997/07/17] kern/4112 PPSCLOCK kernel diffs o [1997/07/17] kern/4113 Processes shouldn't get SIGIO when the tt o [1997/07/18] bin/4116 davidn Kerberized login as .root fails to o [1997/07/18] ports/4118 ports New Port: bind 8.1.1 o [1997/07/19] bin/4120 Partition sysid prevents extended DOS par o [1997/07/19] ports/4124 ache Apache 1.2.1 port does not install docume o [1997/07/20] ports/4127 ache netscape-3.01: get rid of bogus error mes o [1997/07/20] ports/4133 ports new port: mpich.tar.gz o [1997/07/21] misc/4138 /etc/rc and sudo : chg to rm -rf /var/run o [1997/07/21] ports/4140 ports New port: xgolgo (x11) o [1997/07/22] ports/4142 ports Hugs port to FreeBSD 2.2.1 o [1997/07/22] ports/4149 ports gcl port isn't of latest version o [1997/07/23] bin/4152 pstat -T o [1997/07/23] kern/4153 New tcp initial send sequence number code o [1997/07/23] bin/4154 wish /bin/sleep handled fractions of a se o [1997/07/24] bin/4157 netstat atalk output should print symboli o [1997/07/24] bin/4163 ftp core dumps after hitting control-C f [1997/07/25] bin/4165 fetch gone to interminable query cycle af o [1997/07/26] bin/4172 link goes down for too long -- transfer f o [1997/07/26] ports/4174 ports file mode of jnethack o [1997/07/27] bin/4182 netstat should always print the interface o [1997/07/27] bin/4183 How about upgrading bc to 1.04? o [1997/07/28] kern/4184 minor nits in sys/netatalk o [1997/07/28] bin/4187 The w command should have a larger tty fi o [1997/07/30] ports/4192 ports New port: Amulet o [1997/07/31] conf/4201 Installing only X-User does not install c o [1997/07/31] ports/4203 ports Updated port file for the perl package p5 o [1997/07/31] bin/4204 ac printed wrong report about tty users o [1997/08/01] misc/4208 sos New syscons font o [1997/08/02] bin/4216 dlsym returns null o [1997/08/03] ports/4219 ports TkRef submitted to Ports o [1997/08/03] kern/4221 Kernel mode pppd doesen't update wtmp on o [1997/08/03] docs/4223 dump(8) man page error o [1997/08/03] ports/4224 ports New Port: qpage (v3.2) o [1997/08/04] ports/4227 ports cops perl script produces errors o [1997/08/04] conf/4229 Ethernet interface unreachable on bootup o [1997/08/06] ports/4232 scrappy Boot-time start of postgressql postmaster o [1997/08/06] misc/4235 asami /usr/share/mk/bsd.ports.mk and GNU config o [1997/08/06] bin/4238 chpass only occasionally works in conjunc o [1997/08/06] ports/4239 ports New Port: xtattr o [1997/08/07] kern/4243 file locking doesn't work for pipe o [1997/08/07] bin/4247 modification to /etc/security for FreeBSD o [1997/08/08] ports/4248 ports Port submission of Chimera 2.0a2 X-WWW Br o [1997/08/08] misc/4249 wpaul ypchsh doesn't care about changing a user a [1997/08/09] kern/4255 SMP kernel freezes on machines with >2 CP a [1997/08/09] kern/4257 itojun scsi RESERVATION CONFLICT support needed o [1997/08/10] ports/4263 ports new ports: jp-vfxdvik-18f (dvi viewer for o [1997/08/10] ports/4264 ports mftp get a Segmentation fault o [1997/08/11] ports/4277 ports New port: asclock o [1997/08/12] ports/4281 ports Compress pcl graphics files - this is an o [1997/08/12] misc/4285 SDL RISCom/N2 (ISA) o [1997/08/12] ports/4287 jfitz mail/p5-Mail-Folder is broke a [1997/08/13] gnu/4290 ache man wrong viewed koi8-r manpages and neqn o [1997/08/13] ports/4296 ports New Port emulators/stonx o [1997/08/13] kern/4297 dufault SIGEV_NONE and SIGEV_SIGNAL go in signal. o [1997/08/13] bin/4298 joerg Is there any support for using the scsi C o [1997/08/13] i386/4300 msmith The initial timeout on open("/dev/lpt0".. o [1997/08/14] bin/4303 dumpon accepts any device, including none o [1997/08/14] ports/4304 ports Recommendation re. Ports Collection f [1997/08/15] bin/4308 FreeBSD uses an out of date version of vi o [1997/08/15] ports/4311 ports new port of asmail-0.50 o [1997/08/17] misc/4316 pthread_cleanup_{push|pop} nonexistent o [1997/08/17] ports/4319 ports New port: ASFiles-1.0 o [1997/08/17] docs/4320 function prototype in pthread_detach man o [1997/08/17] bin/4323 Initial routing tables incomplete o [1997/08/18] kern/4329 read(2) from /dev/bktr0 hangs o [1997/08/18] ports/4330 ports new ports for rxvt with big5 support o [1997/08/18] ports/4331 ports new port of asprint o [1997/08/20] ports/4343 ports New ports submission - GUI E-Mail util o [1997/08/22] ports/4356 erich sudo shouldn't block signals in tgetpass( s [1997/08/22] ports/4360 ports new port of Amaya-1.0b o [1997/08/23] ports/4362 ports submit new port chinese/rxvt o [1997/08/23] conf/4363 kernel build depend on make obj o [1997/08/24] bin/4369 dump can calculate wrong estimate times w o [1997/08/24] ports/4371 ports tkcvs+tkdiff o [1997/08/25] ports/4377 ports bkpupsd [device] o [1997/08/25] ports/4384 ports New port display-1.0 o [1997/08/25] gnu/4385 un- and unclearly documented options in t o [1997/08/26] ports/4387 ports New port: icewm o [1997/08/26] ports/4391 ports New port: VPCE o [1997/08/26] misc/4395 if exists(secure) in /usr/src/Makefile is o [1997/08/27] ports/4402 ports Port submission: math::MatrixReal o [1997/08/28] bin/4407 sendmail 8.8.7 can't write sendmail.pid o [1997/08/28] ports/4412 ports New port: YaTeX (in print and japanese) o [1997/08/29] kern/4413 No way to unmount a floppy that goes bad o [1997/08/29] misc/4414 be.iso.kbd errors in mapping o [1997/08/29] bin/4415 df(1) always pretends success o [1997/08/29] bin/4419 man can display the same man page twice o [1997/08/29] bin/4420 find -exedir doesn't chdir for first entr o [1997/08/30] docs/4439 davidn man pages wrong regarding login.conf o [1997/08/30] kern/4441 3com Etherlink III card not working while o [1997/08/31] conf/4444 Can't seem to configure for a DEC VRT17-H o [1997/09/01] ports/4446 ports New port: Atlast-1.0 o [1997/09/02] bin/4452 wpaul /etc/ethers and NIS: Bad comment parser o [1997/09/03] bin/4459 bde No prototype for moncontrol(3) and monsta o [1997/09/04] kern/4463 When using ipfw, all I get is the followi o [1997/09/04] ports/4465 jmz cd-write port doesn't work o [1997/09/04] misc/4468 dlopen is not available from static execu o [1997/09/04] misc/4470 libc_r deviates from the pthread standard o [1997/09/04] docs/4472 manpage for /usr/bin/printf is not comple o [1997/09/07] ports/4481 ports yet another Mac hfs utility o [1997/09/07] misc/4482 jdp A bug in dynamic loader design o [1997/09/07] bin/4483 w, who, and the like are broken o [1997/09/07] bin/4484 peter sendmail is barfing o [1997/09/07] kern/4485 boot fials if root fs blocksize is not 8k o [1997/09/08] ports/4496 ports new port of latex2html-97.1.tar.gz o [1997/09/08] ports/4499 ports Update of slurp port o [1997/09/08] bin/4502 Wrong variable type in tftp.h include fil o [1997/09/11] ports/4510 ports New port: lftp-0.12.2 o [1997/09/12] ports/4521 ports 'Joe' editor does not show control-chars o [1997/09/13] kern/4528 processes hang if the mount_portal proces o [1997/09/13] ports/4529 ports New port: kaskade-3.1.1 o [1997/09/13] ports/4530 ports New port: Xinvest o [1997/09/14] ports/4534 ports replace gimp with gimp-devel o [1997/09/14] i386/4538 byteswapped ATAPI id strings o [1997/09/14] bin/4541 Data needed for slovene localization o [1997/09/14] docs/4542 Slovene WWW and FTP mirrors of FreeBSD o [1997/09/14] bin/4545 f77 will only call `cc', no com-line opti o [1997/09/14] ports/4546 ports HDF-lib port revised o [1997/09/15] i386/4547 asc.c and pcaudio.c should use selrecord o [1997/09/15] ports/4552 ports New port: cccc-2.1.1 o [1997/09/16] bin/4553 man fails to open manpage if ./man exists o [1997/09/16] docs/4555 Typo in utf2(4) man page o [1997/09/16] misc/4556 make can't build executable from single F o [1997/09/16] ports/4557 ports New ports: xjig 2.4 o [1997/09/16] misc/4560 XFree86 3.3.1 fails to install properly i o [1997/09/17] bin/4562 Compiler traps and exits then recompiling o [1997/09/17] i386/4563 mount IDE atapi cd-rom reports input/outp o [1997/09/17] ports/4565 ports News port: ircII-current (ircII-2.9a8/col o [1997/09/18] ports/4567 ports wide-dhcp stores runtime data in /etc o [1997/09/18] ports/4570 ports New ports ted3.6a o [1997/09/18] ports/4571 ports New ports cn-ted-3.6a o [1997/09/18] conf/4572 /etc/rc.network loads ipfirewall lkm rega o [1997/09/18] ports/4578 ports New port of a checkbook//accounting packa o [1997/09/18] docs/4579 Typo in usr.bin/netstat/netstat.1 o [1997/09/18] ports/4580 ports new port of tycoon, x11 desktop stuff o [1997/09/19] ports/4583 ports More changes to games/angband o [1997/09/20] kern/4589 de driver error message during boot o [1997/09/20] ports/4590 ports New port: xaniroc-1.02 (category x11) o [1997/09/20] ports/4591 ports Port submission: xtide o [1997/09/21] ports/4595 ports Lynx tarball missing from ftp.freebsd.org o [1997/09/21] ports/4596 ports nas port fails build on 2.2-STABLE o [1997/09/21] kern/4597 Patch to pass NPX status word in signal c o [1997/09/21] kern/4601 Contrib: userconfig patch to edit SCSI co o [1997/09/22] conf/4603 configure ddr between FreeBSD host and Ci o [1997/09/22] ports/4604 max New port ja-japaneseAFM-1.0(japanese/japa o [1997/09/22] ports/4605 max New port ja-vftool-1.2(japanese/vftool). o [1997/09/22] ports/4606 ports New port: Hugs 1.4 (hugs-1.4.tar.gz in /p o [1997/09/22] bin/4607 fmt dumps core on ^M (in 2.2.2 again) o [1997/09/22] ports/4608 ports The packing list for the mutt port is inc o [1997/09/23] ports/4611 ports Upgade of weblint v1.017 to 1.020 o [1997/09/23] ports/4613 ports New port: wdiff (display word differences o [1997/09/23] docs/4617 man page for mount_null has a reference t o [1997/09/24] ports/4621 ports New port: xtris [category games] o [1997/09/24] ports/4623 ports Updated port: xmame-0.27.1 (category emul o [1997/09/25] ports/4624 ports New port of Wily, a clone of the Plan 9 e o [1997/09/25] bin/4629 calendar doesn't print all dates sometime o [1997/09/25] ports/4631 ports New port: ncurses-1.9.9g o [1997/09/26] misc/4636 sysinstall upgrade overwrites /etc networ o [1997/09/27] ports/4640 ports Enabled I18n code of transfig-3.2 with no o [1997/09/28] ports/4643 ports new port - japanese-english dictionary o [1997/09/28] ports/4644 ports This is a new port xfig -international ba o [1997/09/28] ports/4645 ports Enabled command line options such as TOP_ o [1997/09/28] misc/4646 Can't fixit with an NFS-mounted CD. o [1997/09/28] kern/4650 Cirrus Logic pcic chips need audio bit & o [1997/09/29] bin/4652 fclose on NULL pointer causes rdist to Se 622 problems total. From owner-freebsd-bugs Mon Sep 29 10:10:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA23343 for bugs-outgoing; Mon, 29 Sep 1997 10:10:06 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA23336; Mon, 29 Sep 1997 10:10:02 -0700 (PDT) Resent-Date: Mon, 29 Sep 1997 10:10:02 -0700 (PDT) Resent-Message-Id: <199709291710.KAA23336@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, sean_cull@hotmail.com Received: (from nobody@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA22876; Mon, 29 Sep 1997 10:02:44 -0700 (PDT) Message-Id: <199709291702.KAA22876@hub.freebsd.org> Date: Mon, 29 Sep 1997 10:02:44 -0700 (PDT) From: sean_cull@hotmail.com To: freebsd-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: www-1.0 Subject: kern/4653: In v2.2.2, install fails with "cannot create /kernel" Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4653 >Category: kern >Synopsis: In v2.2.2, install fails with "cannot create /kernel" >Confidential: no >Severity: critical >Priority: low >Responsible: freebsd-bugs >State: open >Class: support >Submitter-Id: current-users >Arrival-Date: Mon Sep 29 10:10:01 PDT 1997 >Last-Modified: >Originator: Sean Cull >Organization: Career Development Institute >Release: v2.2.2 >Environment: Pentium 133, 32 megs ram, Gigabyte motherboard, 2.1 gig Western Digital hard disk >Description: I've never done this before, so please bear with me. I recently got v2.2.2 of FreeBSD. When I try to install it from CD or Dos partition, no matter which installation method I use, when I start the installation procedure, I get "cannot create /kernel" and then the install halts, and it returns back to the install screen, saying that installation was completed, but with some errors. But, after rebooting, it is clear that nothing has been installed. Any help on this would be greatly appreciated. Perhaps it could be a bad CD??? >How-To-Repeat: Novice install, from either CD or Dos partition. >Fix: No idea. >Audit-Trail: >Unformatted: From owner-freebsd-bugs Mon Sep 29 11:03:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA26460 for bugs-outgoing; Mon, 29 Sep 1997 11:03:06 -0700 (PDT) Received: from dub-img-2.compuserve.com (dub-img-2.compuserve.com [149.174.206.132]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA26455 for ; Mon, 29 Sep 1997 11:03:02 -0700 (PDT) Received: (from root@localhost) by dub-img-2.compuserve.com (8.8.6/8.8.6/2.5) id OAA22152 for freebsd-bugs@freebsd.org; Mon, 29 Sep 1997 14:02:30 -0400 (EDT) Date: Mon, 29 Sep 1997 14:01:44 -0400 From: Malcolm Boff Subject: Problem with subroutine 'mktemp' To: freebsd-bugs Message-ID: <199709291402_MC2-222B-DF8C@compuserve.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id LAA26456 Sender: owner-freebsd-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk The function 'mktemp' fails with a SIGBUS error. Test function :- #include #include int main(int argc, char **argv) { char *rc; rc = mktemp("/tmp/abcXXXXXX"); fprintf(stderr,"rc=%s\n",rc); exit(1); } If this has been fixed please let me know where to find the source. As I am not registered to this forum please reply directly to my mail address 'Malcolm_boff@compuserve.com' Malcolm G. Boff From owner-freebsd-bugs Mon Sep 29 11:42:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA29464 for bugs-outgoing; Mon, 29 Sep 1997 11:42:21 -0700 (PDT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA29455 for ; Mon, 29 Sep 1997 11:42:08 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.8.5/8.8.5) id OAA12625; Mon, 29 Sep 1997 14:42:04 -0400 (EDT) Date: Mon, 29 Sep 1997 14:42:04 -0400 (EDT) From: Garrett Wollman Message-Id: <199709291842.OAA12625@khavrinen.lcs.mit.edu> To: Malcolm Boff Cc: freebsd-bugs Subject: Problem with subroutine 'mktemp' In-Reply-To: <199709291402_MC2-222B-DF8C@compuserve.com> References: <199709291402_MC2-222B-DF8C@compuserve.com> Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk < said: > rc = mktemp("/tmp/abcXXXXXX"); Programmer error. Literal strings are constants. mktemp() modifies its arguments. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick From owner-freebsd-bugs Mon Sep 29 12:07:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA00746 for bugs-outgoing; Mon, 29 Sep 1997 12:07:49 -0700 (PDT) Received: from isbalham.ist.co.uk (isbalham.ist.co.uk [192.31.26.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA00740; Mon, 29 Sep 1997 12:07:30 -0700 (PDT) Received: from gid.co.uk (uucp@localhost) by isbalham.ist.co.uk (8.8.4/8.8.4) with UUCP id TAA04312; Mon, 29 Sep 1997 19:56:16 +0100 (BST) Received: from [194.32.164.2] by seagoon.gid.co.uk; Mon, 29 Sep 1997 20:04:41 +0100 X-Sender: rb@194.32.164.1 Message-Id: In-Reply-To: <199709290905.CAA00880@implode.root.com> References: Your message of "Mon, 29 Sep 1997 16:05:18 +0800." <199709290805.QAA10988@spinner.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 29 Sep 1997 19:57:56 +0100 To: dg@root.com, Peter Wemm From: Bob Bishop Subject: Re: kern/4630: buffer_map might become corrupted Cc: Poul-Henning Kamp , Tor Egge , freebsd-bugs@FreeBSD.ORG, dyson@FreeBSD.ORG Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi At 10:05 am +0100 29/9/97, David Greenman wrote: >>BTW2; I wish there was an easy way of producing a stack trace automatically >>on a panic or fatal trap, or as a diagnostic tool. Having a machine panic >>and reboot is near for unattended machines. Having a stack trace in the >>console log would be fantastic. :-) > > John and I were talking about this exact thing just last night. :-) I >think the best approach would be to create a 'cda' crash dump analyzer >that generates a report on reboot (stores the report in a file) that includes >a traceback, register info, dumps of important data structures and lists, etc. >[etc] Isn't that just a (k)gdb script in a wrapper, run after savecore has done its thing? -- Bob Bishop (0118) 977 4017 international code +44 118 rb@gid.co.uk fax (0118) 989 4254 between 0800 and 1800 UK From owner-freebsd-bugs Mon Sep 29 12:12:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA01129 for bugs-outgoing; Mon, 29 Sep 1997 12:12:30 -0700 (PDT) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA01121 for ; Mon, 29 Sep 1997 12:12:25 -0700 (PDT) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id MAA06285; Mon, 29 Sep 1997 12:14:58 -0700 (PDT) Message-Id: <199709291914.MAA06285@implode.root.com> To: Bob Bishop cc: freebsd-bugs@FreeBSD.ORG Subject: Re: kern/4630: buffer_map might become corrupted In-reply-to: Your message of "Mon, 29 Sep 1997 19:57:56 BST." From: David Greenman Reply-To: dg@root.com Date: Mon, 29 Sep 1997 12:14:58 -0700 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Isn't that just a (k)gdb script in a wrapper, run after savecore has done >its thing? kgdb scripting is painfully slow, difficult to write, and not very flexible. What I'd like to see is a cda that is built along with the kernel so it's data structures are correct and it stays in sync with the kernel sources. I'd also like the utility to be able to read the crash dump saved in swap without having to copy it first to a file (since few people have the space for large crash dump images). -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-bugs Mon Sep 29 12:22:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA01918 for bugs-outgoing; Mon, 29 Sep 1997 12:22:25 -0700 (PDT) Received: from isbalham.ist.co.uk (isbalham.ist.co.uk [192.31.26.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA01901; Mon, 29 Sep 1997 12:22:06 -0700 (PDT) Received: from gid.co.uk (uucp@localhost) by isbalham.ist.co.uk (8.8.4/8.8.4) with UUCP id UAA04369; Mon, 29 Sep 1997 20:11:11 +0100 (BST) Received: from [194.32.164.2] by seagoon.gid.co.uk; Mon, 29 Sep 1997 20:06:48 +0100 X-Sender: rb@194.32.164.1 Message-Id: In-Reply-To: <11222.875526272@time.cdrom.com> References: Your message of "Mon, 29 Sep 1997 16:05:18 +0800." <199709290805.QAA10988@spinner.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 29 Sep 1997 20:00:03 +0100 To: "Jordan K. Hubbard" , Peter Wemm From: Bob Bishop Subject: Re: kern/4630: buffer_map might become corrupted Cc: Poul-Henning Kamp , Tor Egge , freebsd-bugs@FreeBSD.ORG, dyson@FreeBSD.ORG Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, At 10:44 am +0100 29/9/97, Jordan K. Hubbard wrote: >> BTW2; I wish there was an easy way of producing a stack trace automatically >> on a panic or fatal trap, or as a diagnostic tool. Having a machine panic > >Me too - I could use this to very good effect in usermode, >e.g. sysinstall. ;) ISTR a Dr Dobbs article several years back where some guy was doing precisely that (stack backtrace etc off assorted signals). I'll have a dig in the attic if anyone's interested. -- Bob Bishop (0118) 977 4017 international code +44 118 rb@gid.co.uk fax (0118) 989 4254 between 0800 and 1800 UK From owner-freebsd-bugs Mon Sep 29 13:19:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA05956 for bugs-outgoing; Mon, 29 Sep 1997 13:19:17 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA05937 for ; Mon, 29 Sep 1997 13:19:10 -0700 (PDT) Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id WAA01393; Mon, 29 Sep 1997 22:17:41 +0200 (CEST) To: dg@root.com cc: Bob Bishop , freebsd-bugs@FreeBSD.ORG Subject: Re: kern/4630: buffer_map might become corrupted In-reply-to: Your message of "Mon, 29 Sep 1997 12:14:58 PDT." <199709291914.MAA06285@implode.root.com> Date: Mon, 29 Sep 1997 22:17:41 +0200 Message-ID: <1391.875564261@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In message <199709291914.MAA06285@implode.root.com>, David Greenman writes: >>Isn't that just a (k)gdb script in a wrapper, run after savecore has done >>its thing? > > kgdb scripting is painfully slow, difficult to write, and not very >flexible. What I'd like to see is a cda that is built along with the kernel >so it's data structures are correct and it stays in sync with the kernel >sources. I'd also like the utility to be able to read the crash dump saved >in swap without having to copy it first to a file (since few people have >the space for large crash dump images). maybe make a "dump-light" thing ? Instead of dumping all the stuff, it merely prints a traceback + various other info and stores that as the crashdump ? -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-bugs Mon Sep 29 14:00:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA09404 for bugs-outgoing; Mon, 29 Sep 1997 14:00:05 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA09395; Mon, 29 Sep 1997 14:00:01 -0700 (PDT) Resent-Date: Mon, 29 Sep 1997 14:00:01 -0700 (PDT) Resent-Message-Id: <199709292100.OAA09395@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, muir@ping.idiom.com Received: from ping.idiom.com (idiom-frVT1-gw.sf.tlg.net [140.174.37.22] (may be forged)) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA08967 for ; Mon, 29 Sep 1997 13:54:03 -0700 (PDT) Received: (from root@localhost) by ping.idiom.com (8.8.5/8.8.5) id NAA03470; Mon, 29 Sep 1997 13:53:13 -0700 (PDT) Message-Id: <199709292053.NAA03470@ping.idiom.com> Date: Mon, 29 Sep 1997 13:53:13 -0700 (PDT) From: David Sharnoff Reply-To: muir@ping.idiom.com To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: conf/4654: Need to do post-ifconfig commands Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4654 >Category: conf >Synopsis: Need to do post-ifconfig commands >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Class: change-request >Submitter-Id: current-users >Arrival-Date: Mon Sep 29 14:00:00 PDT 1997 >Last-Modified: >Originator: David Sharnoff >Organization: Idiom >Release: FreeBSD 2.2.2-RELEASE i386 >Environment: FreeBSD 2.2.2 with an ETinc Frame card. >Description: To configure things for the ETinc card, I need to do commands both before and after ifconfig. >How-To-Repeat: >Fix: Add the following to /etc/rc.network at the end of the ifconfig loop: if [ -e /etc/start_if.${ifn}.post ]; then . /etc/start_if.${ifn}.post ${ifn} fi >Audit-Trail: >Unformatted: From owner-freebsd-bugs Mon Sep 29 14:03:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA09649 for bugs-outgoing; Mon, 29 Sep 1997 14:03:08 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA09644; Mon, 29 Sep 1997 14:03:02 -0700 (PDT) From: Joerg Wunsch Received: (from joerg@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id NAA07761; Mon, 29 Sep 1997 13:57:38 -0700 (PDT) Date: Mon, 29 Sep 1997 13:57:38 -0700 (PDT) Message-Id: <199709292057.NAA07761@freefall.freebsd.org> To: roberte@MEP.Ruhr-Uni-Bochum.de, joerg@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: bin/4607 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: fmt dumps core on ^M (in 2.2.2 again) State-Changed-From-To: open-closed State-Changed-By: joerg State-Changed-When: Mon Sep 29 22:54:21 MEST 1997 State-Changed-Why: Sorry, we can't fix 2.2.2 anymore. ;) The fix from bin/2968 has been applied after 2.2.2 shipped, but it's in HEAD as well as RELENG_2_2 now. From owner-freebsd-bugs Mon Sep 29 14:21:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA10781 for bugs-outgoing; Mon, 29 Sep 1997 14:21:22 -0700 (PDT) Received: from isbalham.ist.co.uk (isbalham.ist.co.uk [192.31.26.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA10773 for ; Mon, 29 Sep 1997 14:21:16 -0700 (PDT) Received: from gid.co.uk (uucp@localhost) by isbalham.ist.co.uk (8.8.4/8.8.4) with UUCP id VAA04696; Mon, 29 Sep 1997 21:56:20 +0100 (BST) Received: from [194.32.164.2] by seagoon.gid.co.uk; Mon, 29 Sep 1997 21:53:10 +0100 X-Sender: rb@194.32.164.1 Message-Id: In-Reply-To: <199709291914.MAA06285@implode.root.com> References: Your message of "Mon, 29 Sep 1997 19:57:56 BST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 29 Sep 1997 21:46:25 +0100 To: dg@root.com From: Bob Bishop Subject: Re: kern/4630: buffer_map might become corrupted Cc: freebsd-bugs@FreeBSD.ORG Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 8:14 pm +0100 29/9/97, David Greenman wrote: > kgdb scripting is painfully slow, difficult to write, and not very >flexible. What I'd like to see is a cda that is built along with the kernel >so it's data structures are correct and it stays in sync with the kernel >sources. Mmm. Call me cynical, but if that isn't real hard to do, why has ps had such filthy interfacing all these years? -- Bob Bishop (0118) 977 4017 international code +44 118 rb@gid.co.uk fax (0118) 989 4254 between 0800 and 1800 UK From owner-freebsd-bugs Mon Sep 29 14:50:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA12871 for bugs-outgoing; Mon, 29 Sep 1997 14:50:57 -0700 (PDT) Received: from sumatra.americantv.com (sumatra.americantv.com [207.170.17.37]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA12864 for ; Mon, 29 Sep 1997 14:50:54 -0700 (PDT) Received: from right.PCS (right.PCS [148.105.10.31]) by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id QAA25419; Mon, 29 Sep 1997 16:50:48 -0500 (CDT) Received: (from jlemon@localhost) by right.PCS (8.6.13/8.6.4) id QAA23899; Mon, 29 Sep 1997 16:50:16 -0500 Message-ID: <19970929165015.14793@right.PCS> Date: Mon, 29 Sep 1997 16:50:15 -0500 From: Jonathan Lemon To: Gareth McCaughan Cc: freebsd-bugs@FreeBSD.ORG Subject: Re: bin/4520 and fmt References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.61.1 In-Reply-To: ; from Gareth McCaughan on Sep 09, 1997 at 03:38:57PM +0100 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sep 09, 1997 at 03:38:57PM +0100, Gareth McCaughan wrote: > A couple of other fmt things: > > - It also appears that my patch for bin/2968 has been applied to fix > bin/4607 (fine) and that bin/4607 hasn't been closed (not fine). Well, being the last person to touch fmt, I'll answer this one: bin/4607 was opened Sep 22, after I closed bin/2968 on Aug 20th. It appears to be a straight dup of 2968, so I'm not sure why it was re- submitted; I applied the fix to both -current and -stable. I guess it should be closed, I've been swamped the last few weeks and haven't done much except delete my mail. :-( > I have a drop-in replacement for it, written by me, which the > FreeBSD project can have on any reasonable terms. It contains no > fixed-size buffers, no calls to |abort| and no ghastly ad-hockery. > It's also significantly faster (not that that matters). > > Official FreeBSD People: Are you interested in this? I don't use fmt, so I'm the wrong person to ask. :-) -- Jonathan From owner-freebsd-bugs Mon Sep 29 17:20:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA20206 for bugs-outgoing; Mon, 29 Sep 1997 17:20:03 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA20183; Mon, 29 Sep 1997 17:20:01 -0700 (PDT) Date: Mon, 29 Sep 1997 17:20:01 -0700 (PDT) Message-Id: <199709300020.RAA20183@hub.freebsd.org> To: freebsd-bugs Cc: From: Studded Subject: Re: bin/4299: named is vulnerable to DNS spoofing Reply-To: Studded Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The following reply was made to PR bin/4299; it has been noted by GNATS. From: Studded To: freebsd-gnats-submit@freebsd.org, tedm@toybox.placo.com Cc: Subject: Re: bin/4299: named is vulnerable to DNS spoofing Date: Mon, 29 Sep 1997 17:10:02 -0700 This PR can probably be closed since BIND 4.9.6 has been migrated to -current and -stable. Doug PS, feel free to let me know if I should not be submitting suggestions this way. From owner-freebsd-bugs Mon Sep 29 20:51:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA29233 for bugs-outgoing; Mon, 29 Sep 1997 20:51:43 -0700 (PDT) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA29227 for ; Mon, 29 Sep 1997 20:51:39 -0700 (PDT) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id UAA09399; Mon, 29 Sep 1997 20:51:52 -0700 (PDT) Message-Id: <199709300351.UAA09399@implode.root.com> To: Poul-Henning Kamp cc: freebsd-bugs@FreeBSD.ORG Subject: Re: kern/4630: buffer_map might become corrupted In-reply-to: Your message of "Mon, 29 Sep 1997 22:17:41 +0200." <1391.875564261@critter.freebsd.dk> From: David Greenman Reply-To: dg@root.com Date: Mon, 29 Sep 1997 20:51:52 -0700 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >In message <199709291914.MAA06285@implode.root.com>, David Greenman writes: >>>Isn't that just a (k)gdb script in a wrapper, run after savecore has done >>>its thing? >> >> kgdb scripting is painfully slow, difficult to write, and not very >>flexible. What I'd like to see is a cda that is built along with the kernel >>so it's data structures are correct and it stays in sync with the kernel >>sources. I'd also like the utility to be able to read the crash dump saved >>in swap without having to copy it first to a file (since few people have >>the space for large crash dump images). > >maybe make a "dump-light" thing ? >Instead of dumping all the stuff, it merely prints a traceback + various >other info and stores that as the crashdump ? That's what I meant if it wasn't clear - yes, you'd only save the summary. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-bugs Mon Sep 29 21:30:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA01081 for bugs-outgoing; Mon, 29 Sep 1997 21:30:07 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA01074; Mon, 29 Sep 1997 21:30:02 -0700 (PDT) Resent-Date: Mon, 29 Sep 1997 21:30:02 -0700 (PDT) Resent-Message-Id: <199709300430.VAA01074@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, marukun@mx2.nisiq.net Received: (from nobody@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA00605; Mon, 29 Sep 1997 21:21:17 -0700 (PDT) Message-Id: <199709300421.VAA00605@hub.freebsd.org> Date: Mon, 29 Sep 1997 21:21:17 -0700 (PDT) From: marukun@mx2.nisiq.net To: freebsd-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: www-1.0 Subject: kern/4657: faulting to probe DSI modem in LoadSoftModem() routine at sio.c Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4657 >Category: kern >Synopsis: faulting to probe DSI modem in LoadSoftModem() routine at sio.c >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Sep 29 21:30:01 PDT 1997 >Last-Modified: >Originator: Kenji Saito >Organization: Iwate Medical University >Release: 2.2.2-Release >Environment: >Description: LoadSoftModem() routine at sio.c does not trap general serial I/Os. It fauls to probe eather DSI Modem or others. >How-To-Repeat: to serial port that is not DSI Modem execute ioctl(fd, TCIODSISOFTMODEM, p); >Fix: I made patch for this failure. Please refer http://www1.nisiq.net/~marukun/smup/ Thank you. >Audit-Trail: >Unformatted: From owner-freebsd-bugs Tue Sep 30 07:39:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA28708 for bugs-outgoing; Tue, 30 Sep 1997 07:39:13 -0700 (PDT) Received: from hil-img-3.compuserve.com (hil-img-3.compuserve.com [149.174.177.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA28702 for ; Tue, 30 Sep 1997 07:39:11 -0700 (PDT) Received: (from root@localhost) by hil-img-3.compuserve.com (8.8.6/8.8.6/2.5) id KAA13077 for freebsd-bugs@freebsd.org; Tue, 30 Sep 1997 10:38:36 -0400 (EDT) Date: Tue, 30 Sep 1997 10:38:27 -0400 From: Malcolm Boff Subject: Re: mktemp To: freebsd-bugs Message-ID: <199709301038_MC2-2250-7828@compuserve.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id HAA28703 Sender: owner-freebsd-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Many thanks to all who commented on my faux pas ... I should say that I am coding/debugging an AIX system from home on FreeBSD and I had to change calls to 'tempnam' to calls to 'mktemp' since the FreeBSD spec is quite different from the AIX spec (which claims to be BSD conformant) but that is no excuse for the error of my ways. Thank you all for being so polite (not one unpalateble reply). Malcolm G. Boff From owner-freebsd-bugs Tue Sep 30 07:40:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA28830 for bugs-outgoing; Tue, 30 Sep 1997 07:40:05 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA28824; Tue, 30 Sep 1997 07:40:03 -0700 (PDT) Resent-Date: Tue, 30 Sep 1997 07:40:03 -0700 (PDT) Resent-Message-Id: <199709301440.HAA28824@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, hubert@physics.uottawa.ca Received: (from nobody@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA28296; Tue, 30 Sep 1997 07:32:51 -0700 (PDT) Message-Id: <199709301432.HAA28296@hub.freebsd.org> Date: Tue, 30 Sep 1997 07:32:51 -0700 (PDT) From: hubert@physics.uottawa.ca To: freebsd-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: www-1.0 Subject: conf/4659: sysinstall changes the rc.conf file ? Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4659 >Category: conf >Synopsis: sysinstall changes the rc.conf file ? >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Sep 30 07:40:00 PDT 1997 >Last-Modified: >Originator: Sylvain Hubert >Organization: student >Release: 2.2.2 >Environment: FreeBSD tadevirus 2.2.2-RELEASE FreeBSD 2.2.2-RELEASE #0: Tue May 20 10:45:24 GMT 1997 jkh@time.cdrom.com:/usr/src/sys/compile/GENERIC i386 >Description: when I was in Xwindow environment, I ran /stand/sysinstall. I changed the monitor setting (vertical and horizontal freq.). When I saved the changes, it also changes the file rc.conf. From what I can see, It repeat the comments. If you change the monitor setting a few times, the reboot process won't be able to read the file rc.conf anymore?? >How-To-Repeat: >Fix: >Audit-Trail: >Unformatted: From owner-freebsd-bugs Tue Sep 30 09:00:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA03508 for bugs-outgoing; Tue, 30 Sep 1997 09:00:05 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA03499; Tue, 30 Sep 1997 09:00:01 -0700 (PDT) Resent-Date: Tue, 30 Sep 1997 09:00:01 -0700 (PDT) Resent-Message-Id: <199709301600.JAA03499@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, Andre Albsmeier Received: from david-relay.siemens.de (david-relay.siemens.de [139.23.36.13]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA03377 for ; Tue, 30 Sep 1997 08:58:08 -0700 (PDT) Received: from salomon.mchp.siemens.de (salomon.siemens.de [139.23.33.13]) by david-relay.siemens.de (8.8.7/8.8.7) with ESMTP id RAA27094 for ; Tue, 30 Sep 1997 17:55:07 +0200 (MET DST) Received: from curry.mchp.siemens.de (daemon@curry.mchp.siemens.de [146.180.31.23]) by salomon.mchp.siemens.de (8.8.7/8.8.5) with ESMTP id RAA16557 for ; Tue, 30 Sep 1997 17:58:03 +0200 (MDT) Received: (from daemon@localhost) by curry.mchp.siemens.de (8.8.7/8.8.7) id RAA02366 for ; Tue, 30 Sep 1997 17:58:03 +0200 (MET DST) Message-Id: <199709301557.RAA03366@curry.mchp.siemens.de> Date: Tue, 30 Sep 1997 17:57:58 +0200 (CEST) From: Andre Albsmeier To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: kern/4660: bug in wd.c when using devfs Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4660 >Category: kern >Synopsis: bug in wd.c when using devfs >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Sep 30 09:00:00 PDT 1997 >Last-Modified: >Originator: Andre Albsmeier >Organization: >Release: FreeBSD 2.2-STABLE i386 >Environment: I suspect all systems, but at least 2.2-STABLE >Description: When using devfs on 2.2-STABLE with 3 IDE drives, I saw that wd2 doesn't appear in /devs. Instead, when booting, the kernel prints a message that wd0 (yes, wd0) is already present. IMHO this is due to a bug in wd.c: When calling the devfs routines, the variable unit is passed instead of lunit. As far as I am correct, unit refers to the physical unit on the controller wdc which is 0 for wd2. And lunit refers to the logical unit which is 2 for wd2. So the kernel thinks, wd0 should be registered once more and complains. I have attached my changes to wd.c which makes it work. Maybe, this applies to 2.1 and current, too. And maybe, I am also completely wrong :-) *** wd.c.ORI Sun Sep 21 14:38:19 1997 --- wd.c Sun Sep 21 14:50:16 1997 *************** *** 478,492 **** wdtimeout(du); #ifdef DEVFS ! mynor = dkmakeminor(unit, WHOLE_DISK_SLICE, RAW_PART); du->dk_bdev = devfs_add_devswf(&wd_bdevsw, mynor, DV_BLK, UID_ROOT, GID_OPERATOR, 0640, ! "wd%d", unit); du->dk_cdev = devfs_add_devswf(&wd_cdevsw, mynor, DV_CHR, UID_ROOT, GID_OPERATOR, 0640, ! "rwd%d", unit); #endif if (dk_ndrive < DK_NDRIVE) { --- 478,492 ---- wdtimeout(du); #ifdef DEVFS ! mynor = dkmakeminor(lunit, WHOLE_DISK_SLICE, RAW_PART); du->dk_bdev = devfs_add_devswf(&wd_bdevsw, mynor, DV_BLK, UID_ROOT, GID_OPERATOR, 0640, ! "wd%d", lunit); du->dk_cdev = devfs_add_devswf(&wd_cdevsw, mynor, DV_CHR, UID_ROOT, GID_OPERATOR, 0640, ! "rwd%d", lunit); #endif if (dk_ndrive < DK_NDRIVE) { >How-To-Repeat: Make a machine with at least 3 IDE drives and enable devfs. >Fix: see above >Audit-Trail: >Unformatted: From owner-freebsd-bugs Tue Sep 30 09:50:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA06555 for bugs-outgoing; Tue, 30 Sep 1997 09:50:06 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA06543; Tue, 30 Sep 1997 09:50:02 -0700 (PDT) Resent-Date: Tue, 30 Sep 1997 09:50:02 -0700 (PDT) Resent-Message-Id: <199709301650.JAA06543@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, blank@sliphost37.uni-trier.de Received: from sliphost37.uni-trier.de (root@sliphost37.uni-trier.de [136.199.240.37]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA05849 for ; Tue, 30 Sep 1997 09:40:24 -0700 (PDT) Received: (from blank@localhost) by sliphost37.uni-trier.de (8.8.7/8.8.7) id SAA05444; Tue, 30 Sep 1997 18:39:13 +0200 (CEST) Message-Id: <199709301639.SAA05444@sliphost37.uni-trier.de> Date: Tue, 30 Sep 1997 18:39:13 +0200 (CEST) From: Sascha Blank Reply-To: blank@sliphost37.uni-trier.de To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: bin/4661: date(1) in 2.2-STABLE does not allow to set times with ".ss" Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4661 >Category: bin >Synopsis: date(1) in 2.2-STABLE does not allow to set times with ".ss" >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Sep 30 09:50:01 PDT 1997 >Last-Modified: >Originator: Sascha Blank >Organization: >Release: FreeBSD 2.2-STABLE i386 >Environment: A very recent 2.2-STABLE system. blank in /usr/src/bin/date (331): ident date.c date.c: $Id: date.c,v 1.7.2.3 1997/09/14 13:07:05 jkh Exp $ >Description: date(1) does not allow to set the time and/or date when the time string the user has given contains the ".ss" seconds field. Whenever this is done the string is rejected as being in the wrong format. >How-To-Repeat: "date 1000" or "date 9709301000" work. But "date 1000.00" or "date 9709301000.20" don't work and produce this message: date: illegal time format usage: date [-nu] [-d dst] [-r seconds] [-t west] [+format] [-v [+|-]val[ymwdHM]] ... [-f fmt date | [[[[yy]mm]dd]HH]MM[.ss]] even though the strings are correct according to the template. >Fix: This small diff fixes the problem. The switch-statement starting in line 216 in date.c always expects a time string where the ".ss" field has been removed. Unfortunately this is not the case when a string like "1000.30" is passed to date(1). *** date.c.ctm Tue Sep 30 18:06:14 1997 --- date.c Tue Sep 30 18:37:38 1997 *************** *** 213,219 **** } else lt->tm_sec = 0; ! switch (strlen(p)) { case 10: /* yy */ lt->tm_year = ATOI2(p); if (lt->tm_year < 69) /* hack for 2000 ;-} */ --- 213,220 ---- } else lt->tm_sec = 0; ! /* if p has a ".ss" field then let's pretend it's not there */ ! switch (strlen(p) - ((dot != NULL) ? 3 : 0)) { case 10: /* yy */ lt->tm_year = ATOI2(p); if (lt->tm_year < 69) /* hack for 2000 ;-} */ -- Sascha Blank - mailto:blank@fox.uni-trier.de Student and System Administrator at the University of Trier, Germany Finger my account to receive my Public PGP key I don't speak for my employers, they don't pay me enough for that. >Audit-Trail: >Unformatted: From owner-freebsd-bugs Tue Sep 30 12:48:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA17012 for bugs-outgoing; Tue, 30 Sep 1997 12:48:15 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA16947; Tue, 30 Sep 1997 12:47:59 -0700 (PDT) From: "Jordan K. Hubbard" Received: (from jkh@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id MAA29128; Tue, 30 Sep 1997 12:42:28 -0700 (PDT) Date: Tue, 30 Sep 1997 12:42:28 -0700 (PDT) Message-Id: <199709301942.MAA29128@freefall.freebsd.org> To: hubert@physics.uottawa.ca, jkh@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: conf/4659 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: sysinstall changes the rc.conf file ? State-Changed-From-To: open-closed State-Changed-By: jkh State-Changed-When: Tue Sep 30 12:42:01 PDT 1997 State-Changed-Why: Known bug, documented in: ftp://ftp.freebsd.org/pub/FreeBSD/2.2.2-RELEASE/ERRATA.TXT From owner-freebsd-bugs Tue Sep 30 12:50:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA17257 for bugs-outgoing; Tue, 30 Sep 1997 12:50:14 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA17226; Tue, 30 Sep 1997 12:50:02 -0700 (PDT) From: Joerg Wunsch Received: (from joerg@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id MAA29283; Tue, 30 Sep 1997 12:44:31 -0700 (PDT) Date: Tue, 30 Sep 1997 12:44:31 -0700 (PDT) Message-Id: <199709301944.MAA29283@freefall.freebsd.org> To: mi@aldan.ziplink.net, joerg@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: bin/4520 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: the following (long) line kills fmt State-Changed-From-To: open-closed State-Changed-By: joerg State-Changed-When: Tue Sep 30 21:44:04 MEST 1997 State-Changed-Why: Fixed in rev 1.11 of fmt.c. From owner-freebsd-bugs Tue Sep 30 12:52:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA17414 for bugs-outgoing; Tue, 30 Sep 1997 12:52:05 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA17345; Tue, 30 Sep 1997 12:51:48 -0700 (PDT) From: Joerg Wunsch Received: (from joerg@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id MAA29404; Tue, 30 Sep 1997 12:46:17 -0700 (PDT) Date: Tue, 30 Sep 1997 12:46:17 -0700 (PDT) Message-Id: <199709301946.MAA29404@freefall.freebsd.org> To: zigg@iserv.net, joerg@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: bin/4299 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: named is vulnerable to DNS spoofing State-Changed-From-To: open-closed State-Changed-By: joerg State-Changed-When: Tue Sep 30 21:45:01 MEST 1997 State-Changed-Why: From: Studded This PR can probably be closed since BIND 4.9.6 has been migrated to -current and -stable. From owner-freebsd-bugs Tue Sep 30 13:00:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA18042 for bugs-outgoing; Tue, 30 Sep 1997 13:00:05 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA18000; Tue, 30 Sep 1997 13:00:02 -0700 (PDT) Resent-Date: Tue, 30 Sep 1997 13:00:02 -0700 (PDT) Resent-Message-Id: <199709302000.NAA18000@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, hsu@mail.clinet.fi Received: from hauki.clinet.fi (root@hauki.clinet.fi [194.100.0.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA17121 for ; Tue, 30 Sep 1997 12:49:13 -0700 (PDT) Received: from katiska.clinet.fi (root@katiska.clinet.fi [194.100.0.4]) by hauki.clinet.fi (8.8.6/8.8.6) with ESMTP id VAA16976 for ; Tue, 30 Sep 1997 21:48:27 +0200 (EET) Received: (root@localhost) by katiska.clinet.fi (8.8.7/8.6.4) id WAA24861; Tue, 30 Sep 1997 22:48:27 +0300 (EEST) Message-Id: <199709301948.WAA24861@katiska.clinet.fi> Date: Tue, 30 Sep 1997 22:48:27 +0300 (EEST) From: Heikki Suonsivu Reply-To: hsu@mail.clinet.fi To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: kern/4663: checkalias panic Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4663 >Category: kern >Synopsis: checkalias panic >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Sep 30 13:00:01 PDT 1997 >Last-Modified: >Originator: Heikki Suonsivu >Organization: Clinet, Espoo, Finland >Release: FreeBSD 2.2-STABLE i386 >Environment: 2.2-STABLE >Description: We are getting very frequent, usually nfs-related panics ffrom checkalias in vfs_subr. Often these repeat and several machines go in a row, which look a bit like it could be initiated from user level (>3000 users can access the machines, so it might be that someone found a kill-freebsd-o-matic). I think this happens much less frequently in closed servers. checkalias seem to refer lots of things without checking them for being NULL. We are also seeing nfs directories locking up and various instability with nfs, which I pr'd some time ago. fault virtual addr: 0x87654371 fault code: supervisor read, page not present instruction pointer: 0x8:0xf0131dff stack pointer: 0x10:0xcfbffd7c frrame pointer: 0x10:0xcfbffd8c code segment base 0x0 limit 0xfffff type 0x1b DPL 0 press 1 def 32 gran 1 cpu eflags interrupt enabled, resume IOPL = 0 current prcess 112 (nfsiod) interrupt mask bio panic page fault (copied from handwriting, there may be some bit errors) f01310c0 F vfs_subr.o f01310c0 t ___gnu_compiled_c f01310c0 t _sysctl___kern_maxvnodes f01310c0 t gcc2_compiled. f01310e8 t ___set_sysctl__kern_sym_sysctl___kern_maxvnodes f01310ec T _vntblinit f0131130 T _vfs_lock f0131184 T _vfs_unlock f01311c0 T _vfs_busy f0131228 T _vfs_unbusy f01312f4 T _vfs_unmountroot f0131408 T _vfs_unmountall f01314b4 T _getvfs f01314ec T _getnewfsid f0131574 T _vattr_null f0131624 T _getnewvnode f013178c T _insmntque f01317f8 T _vwakeup f0131878 T _vinvalbuf f0131ab0 T _bgetvp f0131b4c T _brelvp f0131bdc T _pbgetvp f0131c20 T _pbrelvp f0131c5c T _reassignbuf f0131d60 T _bdevvp f0131dcc T _checkalias f0131ef8 T _vget f0131fdc T _vref f0132024 T _vput f0132078 T _vrele f0132178 T _vflush f013229c T _vclean f01323fc T _vgoneall f01324a8 T _vgone f013265c T _vfinddev f01326ac T _vcount f01327c0 T _vprint >How-To-Repeat: Lots of users and nfs seem to be a good one. >Fix: >Audit-Trail: >Unformatted: From owner-freebsd-bugs Tue Sep 30 13:13:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA18876 for bugs-outgoing; Tue, 30 Sep 1997 13:13:22 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA18866; Tue, 30 Sep 1997 13:13:16 -0700 (PDT) From: Joerg Wunsch Received: (from joerg@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id NAA29631; Tue, 30 Sep 1997 13:07:45 -0700 (PDT) Date: Tue, 30 Sep 1997 13:07:45 -0700 (PDT) Message-Id: <199709302007.NAA29631@freefall.freebsd.org> To: blank@sliphost37.uni-trier.de, joerg@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: bin/4661 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: date(1) in 2.2-STABLE does not allow to set times with ".ss" State-Changed-From-To: open-closed State-Changed-By: joerg State-Changed-When: Tue Sep 30 22:07:09 MEST 1997 State-Changed-Why: Suggested fix applied in rev 1.18 (and also merged into RELENG_2_2). thanks! From owner-freebsd-bugs Tue Sep 30 18:36:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA07449 for bugs-outgoing; Tue, 30 Sep 1997 18:36:59 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA07403; Tue, 30 Sep 1997 18:36:49 -0700 (PDT) From: "Jordan K. Hubbard" Received: (from jkh@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id SAA01801; Tue, 30 Sep 1997 18:31:15 -0700 (PDT) Date: Tue, 30 Sep 1997 18:31:15 -0700 (PDT) Message-Id: <199710010131.SAA01801@freefall.freebsd.org> To: jack@diamond.xtalwind.net, jkh@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: misc/4636 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: sysinstall upgrade overwrites /etc network files before backing them up State-Changed-From-To: open-closed State-Changed-By: jkh State-Changed-When: Tue Sep 30 18:31:06 PDT 1997 State-Changed-Why: Fix applied, thanks! From owner-freebsd-bugs Tue Sep 30 19:10:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA09190 for bugs-outgoing; Tue, 30 Sep 1997 19:10:05 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA09181; Tue, 30 Sep 1997 19:10:02 -0700 (PDT) Resent-Date: Tue, 30 Sep 1997 19:10:02 -0700 (PDT) Resent-Message-Id: <199710010210.TAA09181@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, schauer@bigfoot.com Received: (from nobody@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA08630; Tue, 30 Sep 1997 19:00:23 -0700 (PDT) Message-Id: <199710010200.TAA08630@hub.freebsd.org> Date: Tue, 30 Sep 1997 19:00:23 -0700 (PDT) From: schauer@bigfoot.com To: freebsd-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: www-1.0 Subject: kern/4665: Machine reboots self often. Second problem is machine won't shutdown properly Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4665 >Category: kern >Synopsis: Machine reboots self often. Second problem is machine won't shutdown properly >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Sep 30 19:10:01 PDT 1997 >Last-Modified: >Originator: John Schauer >Organization: >Release: 2.2.2-RELEASE >Environment: FreeBSD thunder.ufp 2.2.2-RELEASE FreeBSD 2.2.2-RELEASE #0: Mon Sep 29 23:18:42 CDT 1997 schauer@thunder.ufp:/usr/src/sys/compile/THUNDER i386 >Description: First problem: Machine will reboot itself without warning. No messages appear in /var/log/messages. Happens more than once a day. Exact same hardware ran for previous year (problem free) under Netware 3.12. Second problem: If any ext2fs disks are mounted, /sbin/reboot fails to umount all disks and gives up leaving all disks dirty the next boot. If I "umount -t ext2fs -a" then "reboot" the shutdown sequence works properly. Also, this machine has exactly 48megs of memory in it. The boot disk did freeze and the software solution in the errata didn't work. I had to physically remove the excess memeory for the install. After the install completed I replaced the memeory. Could it be that the 48meg problem is not just limited to the install? Other info: AMD K5 CPU @ 75mhz, 48meg ram, 2 1gig IDE drives (where root partition, /usr are in ufs format). 2 SCSI drives (2gig and 150meg) formated ext2fs (Had to use a Linux boot floppy for this. FreeBSD failed to partition the drives for even native ufs). SCSI controller AHA1520, NIC: pci ne2000 compatible, video 8bit mono adapter. Main use: Samba suite. >How-To-Repeat: >Fix: >Audit-Trail: >Unformatted: From owner-freebsd-bugs Wed Oct 1 00:10:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA24065 for bugs-outgoing; Wed, 1 Oct 1997 00:10:04 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA24057; Wed, 1 Oct 1997 00:10:01 -0700 (PDT) Resent-Date: Wed, 1 Oct 1997 00:10:01 -0700 (PDT) Resent-Message-Id: <199710010710.AAA24057@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, muir@idiom.com Received: from news.idiom.com (news.idiom.com [140.174.82.35]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA23778 for ; Wed, 1 Oct 1997 00:03:00 -0700 (PDT) Received: (from muir@localhost) by news.idiom.com (8.8.7/8.8.5) id AAA08206; Wed, 1 Oct 1997 00:02:59 -0700 (PDT) Message-Id: <199710010702.AAA08206@news.idiom.com> Date: Wed, 1 Oct 1997 00:02:59 -0700 (PDT) From: muir@idiom.com Reply-To: muir@idiom.com To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: kern/4666: umount -f doesn't seem to work Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4666 >Category: kern >Synopsis: umount -f doesn't seem to work >Confidential: no >Severity: serious >Priority: low >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Oct 1 00:10:01 PDT 1997 >Last-Modified: >Originator: David Muir Sharnoff >Organization: Idiom >Release: FreeBSD 2.2-STABLE i386 >Environment: 2.2-STABLE system, mounting disks from a 2.2-STABLE system with the following options... tmp:/ /net/tmp nfs ro,intr,bg,tcp,nfsv2,resvport,nosuid 0 0 tmp:/usr /net/tmp/usr nfs ro,intr,bg,tcp,nfsv2,resvport,nosuid 0 0 >Description: # umount -f -h tmp nfs server tmp:/: not responding # umount -f /net/tmp nfs server tmp:/: not responding # umount -f /net/tmp/usr nfs server tmp:/: not responding # df nfs server tmp:/: not responding I should mention that the machine formerly known as 'tmp' is currently in the mail. >How-To-Repeat: Mount a filesystem as above. Turn of the NFS server and mail it somewhere. Try to unmount the disks without cheating. >Fix: >Audit-Trail: >Unformatted: From owner-freebsd-bugs Wed Oct 1 01:50:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA29454 for bugs-outgoing; Wed, 1 Oct 1997 01:50:06 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA29445; Wed, 1 Oct 1997 01:50:01 -0700 (PDT) Resent-Date: Wed, 1 Oct 1997 01:50:01 -0700 (PDT) Resent-Message-Id: <199710010850.BAA29445@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, mcpaul@earthlink.net Received: (from nobody@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA28979; Wed, 1 Oct 1997 01:41:32 -0700 (PDT) Message-Id: <199710010841.BAA28979@hub.freebsd.org> Date: Wed, 1 Oct 1997 01:41:32 -0700 (PDT) From: mcpaul@earthlink.net To: freebsd-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: www-1.0 Subject: bin/4668: I cannot mail to the IMDB, which you support. Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4668 >Category: bin >Synopsis: I cannot mail to the IMDB, which you support. >Confidential: no >Severity: serious >Priority: low >Responsible: freebsd-bugs >State: open >Class: support >Submitter-Id: current-users >Arrival-Date: Wed Oct 1 01:50:00 PDT 1997 >Last-Modified: >Originator: Paul McKinney >Organization: >Release: ?? >Environment: >Description: One of their relay servers seems to be down, and all of my mail to them comes back unsent. I am hoping that as a software supporter of the IMDB, you may be able to contact them about the problem. What happens is my mail server times out when it tries to connect to their mail server. >How-To-Repeat: Send an e-mail to any address of the IMDB. I tried add@imdb.com. >Fix: >Audit-Trail: >Unformatted: From owner-freebsd-bugs Wed Oct 1 03:16:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA04299 for bugs-outgoing; Wed, 1 Oct 1997 03:16:05 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA04232; Wed, 1 Oct 1997 03:15:56 -0700 (PDT) From: "Jordan K. Hubbard" Received: (from jkh@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id DAA04971; Wed, 1 Oct 1997 03:10:20 -0700 (PDT) Date: Wed, 1 Oct 1997 03:10:20 -0700 (PDT) Message-Id: <199710011010.DAA04971@freefall.freebsd.org> To: mcpaul@earthlink.net, jkh@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: bin/4668 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: I cannot mail to the IMDB, which you support. State-Changed-From-To: open-closed State-Changed-By: jkh State-Changed-When: Wed Oct 1 03:10:00 PDT 1997 State-Changed-Why: Excuse me? We have absolutely nothing to do with the organization in question. From owner-freebsd-bugs Wed Oct 1 04:19:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA06946 for bugs-outgoing; Wed, 1 Oct 1997 04:19:36 -0700 (PDT) Received: from gatekeeper.tsc.tdk.com (root@gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA06938; Wed, 1 Oct 1997 04:19:29 -0700 (PDT) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.4/8.8.4) with ESMTP id EAA27657; Wed, 1 Oct 1997 04:19:05 -0700 (PDT) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id EAA08918; Wed, 1 Oct 1997 04:19:04 -0700 (PDT) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id EAA14305; Wed, 1 Oct 1997 04:19:03 -0700 (PDT) From: Don Lewis Message-Id: <199710011119.EAA14305@salsa.gv.tsc.tdk.com> Date: Wed, 1 Oct 1997 04:19:03 -0700 In-Reply-To: Richard Jones "Re: FreeBSD TCP stack and RST processing [subj changed]" (Oct 1, 7:48pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Richard Jones , dg@root.com Subject: Re: FreeBSD TCP stack and RST processing [subj changed] Cc: hackers@FreeBSD.ORG, bugs@FreeBSD.ORG Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Oct 1, 7:48pm, Richard Jones wrote: } Subject: Re: FreeBSD TCP stack and RST processing [subj changed] } } Ok the other system tested was 2-2 Stable. implode.root.com exhibits the } same behaviour as does 204.216.27.21 (the real freefall as pointed out by } you in a later mail). The main reason I didn't provide version info } was that I thought it was an easy enough situation to replicate if it was } indeed replicatable. Unfortunately I know of no systems that are running } CURRENT to test upon. I think this bug exists in all versions including -current ... Fortunately, I have my copy of TCP/IP Illustrated Volume 2 here in the office :-) The initial faked SYN will put is in the SYN_RECEIVED state. This is the code from tcp_input() in -current that is supposed handle this situation, and it appears to be the same in 2.1 and 2.2: /* * If the RST bit is set examine the state: * SYN_RECEIVED STATE: * If passive open, return to LISTEN state. * If active open, inform user that connection was refused. * ESTABLISHED, FIN_WAIT_1, FIN_WAIT2, CLOSE_WAIT STATES: * Inform user that connection was reset, and close tcb. * CLOSING, LAST_ACK, TIME_WAIT STATES * Close the tcb. */ if (tiflags&TH_RST) switch (tp->t_state) { case TCPS_SYN_RECEIVED: so->so_error = ECONNREFUSED; goto close; This code appears to be correct, and agrees with what's in the book. However ... there is some code *earlier* in tcp_input() that looks like it botches this situation: /* * If the state is SYN_RECEIVED: * do just the ack and RST checks from SYN_SENT state. * If the state is SYN_SENT: * if seg contains an ACK, but not for our SYN, drop the input. * if seg contains a RST, then drop the connection. * if seg does not contain SYN, then drop it. * Otherwise this is an acceptable SYN segment * initialize tp->rcv_nxt and tp->irs * if seg contains ack then advance tp->snd_una * if SYN has been acked change to ESTABLISHED else SYN_RCVD state * arrange for segment to be acked (eventually) * continue processing rest of data/controls, beginning with URG */ case TCPS_SYN_RECEIVED: case TCPS_SYN_SENT: if ((taop = tcp_gettaocache(inp)) == NULL) { taop = &tao_noncached; bzero(taop, sizeof(*taop)); } if ((tiflags & TH_ACK) && (SEQ_LEQ(ti->ti_ack, tp->iss) || SEQ_GT(ti->ti_ack, tp->snd_max))) { /* * If we have a cached CCsent for the remote host, * hence we haven't just crashed and restarted, * do not send a RST. This may be a retransmission * from the other side after our earlier ACK was lost. * Our new SYN, when it arrives, will serve as the * needed ACK. */ if (taop->tao_ccsent != 0) goto drop; else goto dropwithreset; } if (tiflags & TH_RST) { if (tiflags & TH_ACK) tp = tcp_drop(tp, ECONNREFUSED); goto drop; } if (tp->t_state == TCPS_SYN_RECEIVED) break; It looks like we just drop the packet containing the RST! The example code in the book does not execute this code in the SYN_RECEIVED state. I don't know the history of this code, so I don't know why it was changed. copied to freebsd-bugs --- Truck From owner-freebsd-bugs Wed Oct 1 04:30:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA07466 for bugs-outgoing; Wed, 1 Oct 1997 04:30:07 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA07457; Wed, 1 Oct 1997 04:30:03 -0700 (PDT) Resent-Date: Wed, 1 Oct 1997 04:30:03 -0700 (PDT) Resent-Message-Id: <199710011130.EAA07457@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, obrien@NUXI.COM Received: from kongur.cs.ucdavis.edu (kongur.cs.ucdavis.edu [128.120.56.192]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA07137 for ; Wed, 1 Oct 1997 04:22:25 -0700 (PDT) Received: from dragon.nuxi.com (d60-072.leach.ucdavis.edu [169.237.60.72]) by kongur.cs.ucdavis.edu (8.8.5/8.8.5) with ESMTP id EAA21764 for ; Wed, 1 Oct 1997 04:21:12 -0700 (PDT) Received: (from obrien@localhost) by dragon.nuxi.com (8.8.7/8.7.3) id LAA14939; Wed, 1 Oct 1997 11:21:12 GMT Message-Id: <19971001042111.56343@dragon.nuxi.com> Date: Wed, 1 Oct 1997 04:21:11 -0700 From: "David O'Brien" Reply-To: obrien@NUXI.COM To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: bin/4670: /usr/bin/fetch fails to ftp a file ncftp can Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4670 >Category: bin >Synopsis: /usr/bin/fetch fails to ftp a file ncftp can >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Oct 1 04:30:01 PDT 1997 >Last-Modified: >Originator: David O'Brien >Organization: The FreeBSD Project >Release: FreeBSD 2.2-STABLE i386 >Environment: 2.2-STABLE built sept-03 >Description: fetch ftp://ftp.fu-berlin.de/pub/unix/mail/mutt/mutt-pgp/mutt-0.84e-0.84.dif fails, where as ncftp ftp://ftp.fu-berlin.de/pub/unix/mail/mutt/mutt-pgp/mutt-0.84e-0.84.dif works bash$ fetch -v ftp://ftp.fu-berlin.de/pub/unix/mail/mutt/mutt-pgp/mutt-0.84e Sending: USER anonymous FTP.FU-Berlin.DE ready, please login as user "ftp". Anonymous login ok, send your e-mail address as password. Sending: PASS obrien@dragon.nuxi.com Welcome at Freie Universitaet Berlin, Germany. Anonymous login ok, for special commands see the README. Sending: TYPE I Type set to I. Sending SIZE pub/unix/mail/mutt/mutt-pgp/mutt-0.84e-0.84.diff.gz pub/unix/mail/mutt/mutt-pgp/mutt-0.84e-0.84.diff.gz: not a plain file. Sending MDTM pub/unix/mail/mutt/mutt-pgp/mutt-0.84e-0.84.diff.gz pub/unix/mail/mutt/mutt-pgp/mutt-0.84e-0.84.diff.gz: No such file or directo fetch: pub/unix/mail/mutt/mutt-pgp/mutt-0.84e-0.84.diff.gz: cannot get remot Sending: PORT 169,237,60,72,4,246 PORT command successful. Sending: RETR pub/unix/mail/mutt/mutt-pgp/mutt-0.84e-0.84.diff.gz pub/unix/mail/mutt/mutt-pgp/mutt-0.84e-0.84.diff.gz: No such file OR directo fetch: ftp://ftp.fu-berlin.de/pub/unix/mail/mutt/mutt-pgp/mutt-0.84e-0.84.di fetch: File unavailable (e.g., file not found, no access) Sending: QUIT Goodbye. bash$ bash$ bash$ ncftp ftp://ftp.fu-berlin.de/pub/unix/mail/mutt/mutt-pgp/mutt-0.84e-0. FTP.FU-Berlin.DE ready, please login as user "ftp". Receiving file: mutt-0.84e-0.84.diff.gz mutt-0.84e-0.84.diff.gz: 13751 bytes received in 11.27 seconds, 1.19 K/s. exit >How-To-Repeat: fetch ftp://ftp.fu-berlin.de/pub/unix/mail/mutt/mutt-pgp/mutt-0.84e-0.84.dif ncftp ftp://ftp.fu-berlin.de/pub/unix/mail/mutt/mutt-pgp/mutt-0.84e-0.84.dif >Fix: ??? >Audit-Trail: >Unformatted: From owner-freebsd-bugs Wed Oct 1 04:49:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA08200 for bugs-outgoing; Wed, 1 Oct 1997 04:49:14 -0700 (PDT) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA08192; Wed, 1 Oct 1997 04:49:05 -0700 (PDT) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id EAA08698; Wed, 1 Oct 1997 04:51:35 -0700 (PDT) Message-Id: <199710011151.EAA08698@implode.root.com> To: Don Lewis cc: Richard Jones , pst@freebsd.org, hackers@freebsd.org, bugs@freebsd.org Subject: Re: FreeBSD TCP stack and RST processing [subj changed] In-reply-to: Your message of "Wed, 01 Oct 1997 04:19:03 PDT." <199710011119.EAA14305@salsa.gv.tsc.tdk.com> From: David Greenman Reply-To: dg@root.com Date: Wed, 01 Oct 1997 04:51:35 -0700 Sender: owner-freebsd-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >This code appears to be correct, and agrees with what's in the book. > >However ... there is some code *earlier* in tcp_input() that looks like it >botches this situation: ... >It looks like we just drop the packet containing the RST! The example code >in the book does not execute this code in the SYN_RECEIVED state. I don't >know the history of this code, so I don't know why it was changed. > >copied to freebsd-bugs This appears to have been broken in rev 1.52: ---------------------------- revision 1.52 date: 1996/10/07 04:32:39; author: pst; state: Exp; lines: +23 -13 Increase robustness of FreeBSD against high-rate connection attempt denial of service attacks. Reviewed by: bde,wollman,olah Inspired by: vjs@sgi.com ---------------------------- ... *************** *** 753,758 **** --- 758,765 ---- } /* + * If the state is SYN_RECEIVED: + * do just the ack and RST checks from SYN_SENT state. * If the state is SYN_SENT: * if seg contains an ACK, but not for our SYN, drop the input. * if seg contains a RST, then drop the connection. *************** *** 764,769 **** --- 771,777 ---- * arrange for segment to be acked (eventually) * continue processing rest of data/controls, beginning with URG */ + case TCPS_SYN_RECEIVED: case TCPS_SYN_SENT: if ((taop = tcp_gettaocache(inp)) == NULL) { taop = &tao_noncached; *************** *** 791,796 **** --- 799,806 ---- tp = tcp_drop(tp, ECONNREFUSED); goto drop; } + if (tp->t_state == TCPS_SYN_RECEIVED) + break; if ((tiflags & TH_SYN) == 0) goto drop; tp->snd_wnd = ti->ti_win; /* initial send window */ -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-bugs Wed Oct 1 04:59:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA08753 for bugs-outgoing; Wed, 1 Oct 1997 04:59:55 -0700 (PDT) Received: from gatekeeper.tsc.tdk.com (root@gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA08729; Wed, 1 Oct 1997 04:59:15 -0700 (PDT) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.4/8.8.4) with ESMTP id EAA27860; Wed, 1 Oct 1997 04:58:57 -0700 (PDT) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id EAA09539; Wed, 1 Oct 1997 04:58:56 -0700 (PDT) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id EAA14360; Wed, 1 Oct 1997 04:58:55 -0700 (PDT) From: Don Lewis Message-Id: <199710011158.EAA14360@salsa.gv.tsc.tdk.com> Date: Wed, 1 Oct 1997 04:58:55 -0700 In-Reply-To: David Greenman "Re: FreeBSD TCP stack and RST processing [subj changed]" (Oct 1, 4:51am) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: dg@root.com, Don Lewis Subject: Re: FreeBSD TCP stack and RST processing [subj changed] Cc: Richard Jones , pst@freebsd.org, hackers@freebsd.org, bugs@freebsd.org Sender: owner-freebsd-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Oct 1, 4:51am, David Greenman wrote: } Subject: Re: FreeBSD TCP stack and RST processing [subj changed] } ---------------------------- } revision 1.52 } date: 1996/10/07 04:32:39; author: pst; state: Exp; lines: +23 -13 } Increase robustness of FreeBSD against high-rate connection attempt } denial of service attacks. It sure looks to me like it does the opposite :-( I'd either back this patch out entirely, or only do the ack check. A third possibility would be to always call tcp_drop() if TH_RST is set in the TCPS_SYN_RECEIVED state, no matter if TH_ACK is set or not. I looked at {Open,Net}BSD and neither of them picked up this change. --- Truck From owner-freebsd-bugs Wed Oct 1 08:30:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA19973 for bugs-outgoing; Wed, 1 Oct 1997 08:30:04 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA19953; Wed, 1 Oct 1997 08:30:02 -0700 (PDT) Date: Wed, 1 Oct 1997 08:30:02 -0700 (PDT) Message-Id: <199710011530.IAA19953@hub.freebsd.org> To: freebsd-bugs Cc: From: j@uriah.heep.sax.de (J Wunsch) Subject: Re: kern/4666: umount -f doesn't seem to work Reply-To: j@uriah.heep.sax.de (J Wunsch) Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The following reply was made to PR kern/4666; it has been noted by GNATS. From: j@uriah.heep.sax.de (J Wunsch) To: muir@idiom.com Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: kern/4666: umount -f doesn't seem to work Date: Wed, 1 Oct 1997 17:10:51 +0200 As muir@idiom.com wrote: > tmp:/ /net/tmp nfs ro,intr,bg,tcp,nfsv2,resvport,nosuid 0 0 > tmp:/usr /net/tmp/usr nfs ro,intr,bg,tcp,nfsv2,resvport,nosuid 0 0 > > >Description: > > # umount -f -h tmp > nfs server tmp:/: not responding This is what one would expect how umount -f is working, but not what is described for umount -f: forcibly unmounting is currently only defined as ``don't care about resources that are locally still in use, but revoke them''. Anyway, i think this is already in Doug Rabson's queue of ``nice to have'' things. If i'm not totally mistaken, there might already be another open PR for it. Did you check before filing? -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-bugs Wed Oct 1 09:20:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA22865 for bugs-outgoing; Wed, 1 Oct 1997 09:20:08 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA22849; Wed, 1 Oct 1997 09:20:02 -0700 (PDT) Resent-Date: Wed, 1 Oct 1997 09:20:02 -0700 (PDT) Resent-Message-Id: <199710011620.JAA22849@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, hsu@mail.clinet.fi Received: from hauki.clinet.fi (hauki.clinet.fi [194.100.0.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA22675 for ; Wed, 1 Oct 1997 09:17:37 -0700 (PDT) Received: from katiska.clinet.fi (root@katiska.clinet.fi [194.100.0.4]) by hauki.clinet.fi (8.8.6/8.8.6) with ESMTP id SAA10705 for ; Wed, 1 Oct 1997 18:14:19 +0200 (EET) Received: (root@localhost) by katiska.clinet.fi (8.8.7/8.6.4) id TAA21605; Wed, 1 Oct 1997 19:14:19 +0300 (EEST) Message-Id: <199710011614.TAA21605@katiska.clinet.fi> Date: Wed, 1 Oct 1997 19:14:19 +0300 (EEST) From: Heikki Suonsivu Reply-To: hsu@mail.clinet.fi To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: kern/4673: Two panics, now crash dumps, always in reassignbuf Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4673 >Category: kern >Synopsis: Two panics, now crash dumps, always in reassignbuf >Confidential: no >Severity: critical >Priority: high >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Oct 1 09:20:01 PDT 1997 >Last-Modified: >Originator: Heikki Suonsivu >Organization: Clinet, Espoo, Finland >Release: FreeBSD 2.2-STABLE i386 >Environment: Two user machines, pentiums, mostly nfs disks, local boot disk. >Description: Repeating panics in reassignbuf: hsu#katiska.clinet.fi Wed 120: gdb -k kernel.12 vmcore.12 GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.16 (i386-unknown-freebsd), Copyright 1996 Free Software Foundation, Inc... IdlePTD 278000 current pcb at 2196dc panic: page fault #0 boot (howto=260) at ../../kern/kern_shutdown.c:266 266 dumppcb.pcb_cr3 = rcr3(); (kgdb) bt #0 boot (howto=260) at ../../kern/kern_shutdown.c:266 #1 0xf01128f2 in panic (fmt=0xf01d322f "page fault") at ../../kern/kern_shutdown.c:390 #2 0xf01d3d96 in trap_fatal (frame=0xefbffa58) at ../../i386/i386/trap.c:742 #3 0xf01d3884 in trap_pfault (frame=0xefbffa58, usermode=0) at ../../i386/i386/trap.c:653 #4 0xf01d355f in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = -1073739712, tf_esi = -215228544, tf_ebp = -272631132, tf_isp = -272631168, tf_ebx = -184626164, tf_edx = 0, tf_ecx = -1073739712, tf_eax = -184350504, tf_trapno = 12, tf_err = 2, tf_eip = -267182654, tf_cs = 8, tf_eflags = 66182, tf_esp = -184626164, tf_ss = -184638924}) at ../../i386/i386/trap.c:311 #5 0xf0131dc2 in reassignbuf (bp=0xf4fed40c, newvp=0xf32bdf80) at ../../kern/vfs_subr.c:657 #6 0xf01301a4 in cluster_wbuild (vp=0xf32bdf80, size=8192, start_lbn=361, len=8) at ../../kern/vfs_cluster.c:690 #7 0xf012d249 in vfs_bio_awrite (bp=0xf4fed40c) at ../../kern/vfs_bio.c:833 #8 0xf012d4d0 in getnewbuf (slpflag=0, slptimeo=0, size=8192, maxsize=8192) at ../../kern/vfs_bio.c:924 #9 0xf012da05 in getblk (vp=0xf3048e80, blkno=262208, size=8192, slpflag=0, slptimeo=0) at ../../kern/vfs_bio.c:1197 #10 0xf012c55d in bread (vp=0xf3048e80, blkno=262208, size=8192, cred=0x0, bpp=0xefbffbc4) at ../../kern/vfs_bio.c:228 #11 0xf01b1d5f in ffs_update (ap=0xefbffbf0) at ../../ufs/ffs/ffs_inode.c:137 #12 0xf01b53c0 in ffs_fsync (ap=0xefbffc34) at vnode_if.h:1031 #13 0xf01b4020 in ffs_sync (mp=0xf301dc00, waitfor=2, cred=0xf301c400, p=0xf025a778) at vnode_if.h:407 #14 0xf013354b in sync (p=0xf025a778, uap=0x0, retval=0x0) at ../../kern/vfs_syscalls.c:357 #15 0xf01124fd in boot (howto=256) at ../../kern/kern_shutdown.c:199 #16 0xf01128f2 in panic (fmt=0xf01d322f "page fault") at ../../kern/kern_shutdown.c:390 #17 0xf01d3d96 in trap_fatal (frame=0xefbffd40) at ../../i386/i386/trap.c:742 #18 0xf01d3884 in trap_pfault (frame=0xefbffd40, usermode=0) at ../../i386/i386/trap.c:653 #19 0xf01d355f in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = -1073739712, tf_esi = -215228544, tf_ebp = -272630388, tf_isp = -272630424, tf_ebx = -184637384, tf_edx = 0, tf_ecx = 8192, tf_eax = -184626164, tf_trapno = 12, tf_err = 2, tf_eip = -267182654, tf_cs = 8, tf_eflags = 66182, tf_esp = 2916352, tf_ss = 0}) at ../../i386/i386/trap.c:311 #20 0xf0131dc2 in reassignbuf (bp=0xf4fea838, newvp=0xf32bdf80) at ../../kern/vfs_subr.c:657 #21 0xf016573f in nfs_doio (bp=0xf4fea838, cr=0xf3142c00, p=0x0) at ../../nfs/nfs_bio.c:1101 #22 0xf018494b in nfssvc_iod (p=0xf30c0a00) at ../../nfs/nfs_syscalls.c:811 #23 0xf018361a in nfssvc (p=0xf30c0a00, uap=0xefbfff94, retval=0xefbfff84) at ../../nfs/nfs_syscalls.c:209 #24 0xf01d402f in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = -272638336, tf_esi = 0, tf_ebp = -272638384, tf_isp = -272629788, tf_ebx = 1, tf_edx = 1, tf_ecx = 1, tf_eax = 155, tf_trapno = 12, tf_err = 7, tf_eip = 9077, tf_cs = 31, tf_eflags = 582, tf_esp = -272638408, tf_ss = 39}) at ../../i386/i386/trap.c:890 #25 0x2375 in ?? () #26 0x107f in ?? () (kgdb) frame 16 #16 0xf01128f2 in panic (fmt=0xf01d322f "page fault") at ../../kern/kern_shutdown.c:390 390 boot(bootopt); (kgdb) bt #0 boot (howto=260) at ../../kern/kern_shutdown.c:266 #1 0xf01128f2 in panic (fmt=0xf01d322f "page fault") at ../../kern/kern_shutdown.c:390 #2 0xf01d3d96 in trap_fatal (frame=0xefbffa58) at ../../i386/i386/trap.c:742 #3 0xf01d3884 in trap_pfault (frame=0xefbffa58, usermode=0) at ../../i386/i386/trap.c:653 #4 0xf01d355f in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = -1073739712, tf_esi = -215228544, tf_ebp = -272631132, tf_isp = -272631168, tf_ebx = -184626164, tf_edx = 0, tf_ecx = -1073739712, tf_eax = -184350504, tf_trapno = 12, tf_err = 2, tf_eip = -267182654, tf_cs = 8, tf_eflags = 66182, tf_esp = -184626164, tf_ss = -184638924}) at ../../i386/i386/trap.c:311 #5 0xf0131dc2 in reassignbuf (bp=0xf4fed40c, newvp=0xf32bdf80) at ../../kern/vfs_subr.c:657 #6 0xf01301a4 in cluster_wbuild (vp=0xf32bdf80, size=8192, start_lbn=361, len=8) at ../../kern/vfs_cluster.c:690 #7 0xf012d249 in vfs_bio_awrite (bp=0xf4fed40c) at ../../kern/vfs_bio.c:833 #8 0xf012d4d0 in getnewbuf (slpflag=0, slptimeo=0, size=8192, maxsize=8192) at ../../kern/vfs_bio.c:924 #9 0xf012da05 in getblk (vp=0xf3048e80, blkno=262208, size=8192, slpflag=0, slptimeo=0) at ../../kern/vfs_bio.c:1197 #10 0xf012c55d in bread (vp=0xf3048e80, blkno=262208, size=8192, cred=0x0, bpp=0xefbffbc4) at ../../kern/vfs_bio.c:228 #11 0xf01b1d5f in ffs_update (ap=0xefbffbf0) at ../../ufs/ffs/ffs_inode.c:137 #12 0xf01b53c0 in ffs_fsync (ap=0xefbffc34) at vnode_if.h:1031 #13 0xf01b4020 in ffs_sync (mp=0xf301dc00, waitfor=2, cred=0xf301c400, p=0xf025a778) at vnode_if.h:407 #14 0xf013354b in sync (p=0xf025a778, uap=0x0, retval=0x0) at ../../kern/vfs_syscalls.c:357 #15 0xf01124fd in boot (howto=256) at ../../kern/kern_shutdown.c:199 #16 0xf01128f2 in panic (fmt=0xf01d322f "page fault") at ../../kern/kern_shutdown.c:390 #17 0xf01d3d96 in trap_fatal (frame=0xefbffd40) at ../../i386/i386/trap.c:742 #18 0xf01d3884 in trap_pfault (frame=0xefbffd40, usermode=0) at ../../i386/i386/trap.c:653 #19 0xf01d355f in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = -1073739712, tf_esi = -215228544, tf_ebp = -272630388, tf_isp = -272630424, tf_ebx = -184637384, tf_edx = 0, tf_ecx = 8192, tf_eax = -184626164, tf_trapno = 12, tf_err = 2, tf_eip = -267182654, tf_cs = 8, tf_eflags = 66182, tf_esp = 2916352, tf_ss = 0}) at ../../i386/i386/trap.c:311 #20 0xf0131dc2 in reassignbuf (bp=0xf4fea838, newvp=0xf32bdf80) at ../../kern/vfs_subr.c:657 #21 0xf016573f in nfs_doio (bp=0xf4fea838, cr=0xf3142c00, p=0x0) at ../../nfs/nfs_bio.c:1101 #22 0xf018494b in nfssvc_iod (p=0xf30c0a00) at ../../nfs/nfs_syscalls.c:811 #23 0xf018361a in nfssvc (p=0xf30c0a00, uap=0xefbfff94, retval=0xefbfff84) at ../../nfs/nfs_syscalls.c:209 #24 0xf01d402f in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = -272638336, tf_esi = 0, tf_ebp = -272638384, tf_isp = -272629788, tf_ebx = 1, tf_edx = 1, tf_ecx = 1, tf_eax = 155, tf_trapno = 12, tf_err = 7, tf_eip = 9077, tf_cs = 31, tf_eflags = 582, tf_esp = -272638408, tf_ss = 39}) at ../../i386/i386/trap.c:890 #25 0x2375 in ?? () #26 0x107f in ?? () (kgdb) up #17 0xf01d3d96 in trap_fatal (frame=0xefbffd40) at ../../i386/i386/trap.c:742 742 panic(trap_msg[type]); (kgdb) up #18 0xf01d3884 in trap_pfault (frame=0xefbffd40, usermode=0) at ../../i386/i386/trap.c:653 653 trap_fatal(frame); (kgdb) up #19 0xf01d355f in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = -1073739712, tf_esi = -215228544, tf_ebp = -272630388, tf_isp = -272630424, tf_ebx = -184637384, tf_edx = 0, tf_ecx = 8192, tf_eax = -184626164, tf_trapno = 12, tf_err = 2, tf_eip = -267182654, tf_cs = 8, tf_eflags = 66182, tf_esp = 2916352, tf_ss = 0}) at ../../i386/i386/trap.c:311 311 (void) trap_pfault(&frame, FALSE); (kgdb) up #20 0xf0131dc2 in reassignbuf (bp=0xf4fea838, newvp=0xf32bdf80) at ../../kern/vfs_subr.c:657 657 bufremvn(bp); (kgdb) list 652 s = splbio(); 653 /* 654 * Delete from old vnode list, if on one. 655 */ 656 if (bp->b_vnbufs.le_next != NOLIST) 657 bufremvn(bp); 658 /* 659 * If dirty, put on list of dirty buffers; otherwise insert onto list 660 * of clean buffers. 661 */ (kgdb) print bp $1 = (struct buf *) 0xf4fea838 (kgdb) print *bp $2 = {b_hash = {le_next = 0x0, le_prev = 0x0}, b_vnbufs = { le_next = 0xf4fed40c, le_prev = 0x0}, b_freelist = {tqe_next = 0x0, tqe_prev = 0xf3069be8}, b_act = {tqe_next = 0x0, tqe_prev = 0x0}, b_proc = 0x0, b_flags = 1610744022, b_qindex = 0, b_usecount = 0 '\000', b_error = 0, b_bufsize = 8192, b_bcount = 8192, b_resid = 0, b_dev = 4294967295, b_un = { b_addr = 0xf6797000 "ðh\024#\201\2341ŽzÃ\001ķ3Ûč\036\216âŋ&ÕüûâJ·Į\027\021%QS[Ó8\006U2f\rą%ÄØJiMĄ^\n\230\221\017/Ð\005ĸrģãc^\203Ö2\e\013ýbũ\227\217Dy\aGBz9+/\226WQŧgÐqYd\214g\t\020md#ī9í,\236áähĩ\027æ\027ïŲ1zģwÄ\001\2360Ė\027!\tgē[âJļJ\037?ŊFžUÅ8ßÔ\214\036ïDfĪöfĒÞ°\027å'\0301Óņž\n\202qB-æņë\2061RĸĮ\023\235Þ\201ŧ\207ĶUĘ\201ģ.Éi]Hú8\213æC#xęķ2ŦŅ"...}, b_kvabase = 0xf6797000 "ðh\024#\201\2341ŽzÃ\001ķ3Ûč\036\216âŋ&ÕüûâJ·Į\027\021%QS[Ó8\006U2f\rą%ÄØJiMĄ^\n\230\221\017/Ð\005ĸrģãc^\203Ö2\e\013ýbũ\227\217Dy\aGBz9+/\226WQŧgÐqYd\214g\t\020md#ī9í,\236áähĩ\027æ\027ïŲ1zģwÄ\001\2360Ė\027!\tgē[âJļJ\037?ŊFžUÅ8ßÔ\214\036ïDfĪöfĒÞ°\027å'\0301Óņž\n\202qB-æņë\2061RĸĮ\023\235Þ\201ŧ\207ĶUĘ\201ģ.Éi]Hú8\213æC#xęķ2ŦŅ"..., b_kvasize = 8192, b_saveaddr = 0x0, b_lblkno = 356, b_blkno = 5696, b_iodone = 0xf012fc34 , b_iodone_chain = 0x0, b_vp = 0xf32bdf80, b_dirtyoff = 0, b_dirtyend = 8192, b_rcred = 0x0, b_wcred = 0xf3142c00, b_validoff = 0, b_validend = 0, b_pblkno = 0, b_savekva = 0x0, b_driver1 = 0x0, b_driver2 = 0x0, b_spc = 0x0, b_cluster = {cluster_head = {tqh_first = 0xf5000f70, tqh_last = 0xf5001000}, cluster_entry = {tqe_next = 0xf5000f70, tqe_prev = 0xf5001000}}, b_pages = {0xf03f34dc, 0xf03f3510, 0x0 }, b_npages = 2} (kgdb) bt #0 boot (howto=260) at ../../kern/kern_shutdown.c:266 #1 0xf01128f2 in panic (fmt=0xf01d322f "page fault") at ../../kern/kern_shutdown.c:390 #2 0xf01d3d96 in trap_fatal (frame=0xefbffa58) at ../../i386/i386/trap.c:742 #3 0xf01d3884 in trap_pfault (frame=0xefbffa58, usermode=0) at ../../i386/i386/trap.c:653 #4 0xf01d355f in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = -1073739712, tf_esi = -215228544, tf_ebp = -272631132, tf_isp = -272631168, tf_ebx = -184626164, tf_edx = 0, tf_ecx = -1073739712, tf_eax = -184350504, tf_trapno = 12, tf_err = 2, tf_eip = -267182654, tf_cs = 8, tf_eflags = 66182, tf_esp = -184626164, tf_ss = -184638924}) at ../../i386/i386/trap.c:311 #5 0xf0131dc2 in reassignbuf (bp=0xf4fed40c, newvp=0xf32bdf80) at ../../kern/vfs_subr.c:657 #6 0xf01301a4 in cluster_wbuild (vp=0xf32bdf80, size=8192, start_lbn=361, len=8) at ../../kern/vfs_cluster.c:690 #7 0xf012d249 in vfs_bio_awrite (bp=0xf4fed40c) at ../../kern/vfs_bio.c:833 #8 0xf012d4d0 in getnewbuf (slpflag=0, slptimeo=0, size=8192, maxsize=8192) at ../../kern/vfs_bio.c:924 #9 0xf012da05 in getblk (vp=0xf3048e80, blkno=262208, size=8192, slpflag=0, slptimeo=0) at ../../kern/vfs_bio.c:1197 #10 0xf012c55d in bread (vp=0xf3048e80, blkno=262208, size=8192, cred=0x0, bpp=0xefbffbc4) at ../../kern/vfs_bio.c:228 #11 0xf01b1d5f in ffs_update (ap=0xefbffbf0) at ../../ufs/ffs/ffs_inode.c:137 #12 0xf01b53c0 in ffs_fsync (ap=0xefbffc34) at vnode_if.h:1031 #13 0xf01b4020 in ffs_sync (mp=0xf301dc00, waitfor=2, cred=0xf301c400, p=0xf025a778) at vnode_if.h:407 #14 0xf013354b in sync (p=0xf025a778, uap=0x0, retval=0x0) at ../../kern/vfs_syscalls.c:357 #15 0xf01124fd in boot (howto=256) at ../../kern/kern_shutdown.c:199 #16 0xf01128f2 in panic (fmt=0xf01d322f "page fault") at ../../kern/kern_shutdown.c:390 #17 0xf01d3d96 in trap_fatal (frame=0xefbffd40) at ../../i386/i386/trap.c:742 #18 0xf01d3884 in trap_pfault (frame=0xefbffd40, usermode=0) at ../../i386/i386/trap.c:653 #19 0xf01d355f in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = -1073739712, tf_esi = -215228544, tf_ebp = -272630388, tf_isp = -272630424, tf_ebx = -184637384, tf_edx = 0, tf_ecx = 8192, tf_eax = -184626164, tf_trapno = 12, tf_err = 2, tf_eip = -267182654, tf_cs = 8, tf_eflags = 66182, tf_esp = 2916352, tf_ss = 0}) at ../../i386/i386/trap.c:311 #20 0xf0131dc2 in reassignbuf (bp=0xf4fea838, newvp=0xf32bdf80) at ../../kern/vfs_subr.c:657 #21 0xf016573f in nfs_doio (bp=0xf4fea838, cr=0xf3142c00, p=0x0) at ../../nfs/nfs_bio.c:1101 #22 0xf018494b in nfssvc_iod (p=0xf30c0a00) at ../../nfs/nfs_syscalls.c:811 #23 0xf018361a in nfssvc (p=0xf30c0a00, uap=0xefbfff94, retval=0xefbfff84) at ../../nfs/nfs_syscalls.c:209 #24 0xf01d402f in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = -272638336, tf_esi = 0, tf_ebp = -272638384, tf_isp = -272629788, tf_ebx = 1, tf_edx = 1, tf_ecx = 1, tf_eax = 155, tf_trapno = 12, tf_err = 7, tf_eip = 9077, tf_cs = 31, tf_eflags = 582, tf_esp = -272638408, tf_ss = 39}) at ../../i386/i386/trap.c:890 #25 0x2375 in ?? () #26 0x107f in ?? () (kgdb) up #21 0xf016573f in nfs_doio (bp=0xf4fea838, cr=0xf3142c00, p=0x0) at ../../nfs/nfs_bio.c:1101 1101 reassignbuf(bp, vp); (kgdb) list 1096 * Since for the B_ASYNC case, nfs_bwrite() has reassigned the 1097 * buffer to the clean list, we have to reassign it back to the 1098 * dirty one. Ugh. 1099 */ 1100 if (bp->b_flags & B_ASYNC) 1101 reassignbuf(bp, vp); 1102 else 1103 bp->b_flags |= B_EINTR; 1104 } else { 1105 if (error) { (kgdb) up #22 0xf018494b in nfssvc_iod (p=0xf30c0a00) at ../../nfs/nfs_syscalls.c:811 811 (void) nfs_doio(bp, bp->b_wcred, (struct proc *)0); (kgdb) list 806 wakeup(&nmp->nm_bufq); 807 } 808 if (bp->b_flags & B_READ) 809 (void) nfs_doio(bp, bp->b_rcred, (struct proc *)0); 810 else 811 (void) nfs_doio(bp, bp->b_wcred, (struct proc *)0); 812 813 /* 814 * If there are more than one iod on this mount, then defect 815 * so that the iods can be shared out fairly between the mounts (kgdb) print bp $3 = (struct buf *) 0xf4fea838 (kgdb) print *bp $4 = {b_hash = {le_next = 0x0, le_prev = 0x0}, b_vnbufs = { le_next = 0xf4fed40c, le_prev = 0x0}, b_freelist = {tqe_next = 0x0, tqe_prev = 0xf3069be8}, b_act = {tqe_next = 0x0, tqe_prev = 0x0}, b_proc = 0x0, b_flags = 1610744022, b_qindex = 0, b_usecount = 0 '\000', b_error = 0, b_bufsize = 8192, b_bcount = 8192, b_resid = 0, b_dev = 4294967295, b_un = { b_addr = 0xf6797000 "ðh\024#\201\2341ŽzÃ\001ķ3Ûč\036\216âŋ&ÕüûâJ·Į\027\021%QS[Ó8\006U2f\rą%ÄØJiMĄ^\n\230\221\017/Ð\005ĸrģãc^\203Ö2\e\013ýbũ\227\217Dy\aGBz9+/\226WQŧgÐqYd\214g\t\020md#ī9í,\236áähĩ\027æ\027ïŲ1zģwÄ\001\2360Ė\027!\tgē[âJļJ\037?ŊFžUÅ8ßÔ\214\036ïDfĪöfĒÞ°\027å'\0301Óņž\n\202qB-æņë\2061RĸĮ\023\235Þ\201ŧ\207ĶUĘ\201ģ.Éi]Hú8\213æC#xęķ2ŦŅ"...}, b_kvabase = 0xf6797000 "ðh\024#\201\2341ŽzÃ\001ķ3Ûč\036\216âŋ&ÕüûâJ·Į\027\021%QS[Ó8\006U2f\rą%ÄØJiMĄ^\n\230\221\017/Ð\005ĸrģãc^\203Ö2\e\013ýbũ\227\217Dy\aGBz9+/\226WQŧgÐqYd\214g\t\020md#ī9í,\236áähĩ\027æ\027ïŲ1zģwÄ\001\2360Ė\027!\tgē[âJļJ\037?ŊFžUÅ8ßÔ\214\036ïDfĪöfĒÞ°\027å'\0301Óņž\n\202qB-æņë\2061RĸĮ\023\235Þ\201ŧ\207ĶUĘ\201ģ.Éi]Hú8\213æC#xęķ2ŦŅ"..., b_kvasize = 8192, b_saveaddr = 0x0, b_lblkno = 356, b_blkno = 5696, b_iodone = 0xf012fc34 , b_iodone_chain = 0x0, b_vp = 0xf32bdf80, b_dirtyoff = 0, b_dirtyend = 8192, b_rcred = 0x0, b_wcred = 0xf3142c00, b_validoff = 0, b_validend = 0, b_pblkno = 0, b_savekva = 0x0, b_driver1 = 0x0, b_driver2 = 0x0, b_spc = 0x0, b_cluster = {cluster_head = {tqh_first = 0xf5000f70, tqh_last = 0xf5001000}, cluster_entry = {tqe_next = 0xf5000f70, tqe_prev = 0xf5001000}}, b_pages = {0xf03f34dc, 0xf03f3510, 0x0 }, b_npages = 2} (kgdb) print nmp $5 = (struct nfsmount *) 0xf3069a00 (kgdb) print *nmp $6 = {nm_flag = 68452864, nm_mountp = 0xf3069c00, nm_numgrps = 16, nm_fh = "&\004\000\000\001\000\000\000\f\000\000\000\002\000\000\000Uõę2", '\000' , nm_fhsize = 28, nm_so = 0xf3068900, nm_sotype = 2, nm_soproto = 0, nm_soflags = 3, nm_nam = 0xf1bd2a80, nm_timeo = 100, nm_retry = 10, nm_srtt = {15, 24, 36, 48}, nm_sdrtt = {4, 6, 5, 9}, nm_sent = 256, nm_cwnd = 1150, nm_timeouts = 0, nm_deadthresh = 9, nm_rsize = 8192, nm_wsize = 8192, nm_readdirsize = 8192, nm_readahead = 1, nm_leaseterm = 30, nm_timerhead = {cqh_first = 0xf3069ab0, cqh_last = 0xf3069ab0}, nm_inprog = 0x0, nm_authuid = 0, nm_authtype = 0, nm_authlen = 0, nm_authstr = 0x0, nm_verfstr = 0x0, nm_verflen = 0, nm_verf = "40\205\210\000\004\234Ė", nm_key = "\000", nm_numuids = 0, nm_uidlruhead = {tqh_first = 0x0, tqh_last = 0xf3069ae4}, nm_uidhashtbl = {{ lh_first = 0x0} }, nm_bufq = {tqh_first = 0x0, tqh_last = 0xf3069be8}, nm_bufqlen = 0, nm_bufqwant = 0, nm_bufqiods = 3} (kgdb) kernels and dumps available on request. >How-To-Repeat: Someone/something seems to repeat it very often, 6 times this evening. >Fix: >Audit-Trail: >Unformatted: From owner-freebsd-bugs Wed Oct 1 10:50:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA27168 for bugs-outgoing; Wed, 1 Oct 1997 10:50:06 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA27156; Wed, 1 Oct 1997 10:50:02 -0700 (PDT) Date: Wed, 1 Oct 1997 10:50:02 -0700 (PDT) Message-Id: <199710011750.KAA27156@hub.freebsd.org> To: freebsd-bugs Cc: From: John-Mark Gurney Subject: Re: bin/4670: /usr/bin/fetch fails to ftp a file ncftp can Reply-To: John-Mark Gurney Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The following reply was made to PR bin/4670; it has been noted by GNATS. From: John-Mark Gurney To: obrien@NUXI.COM Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: bin/4670: /usr/bin/fetch fails to ftp a file ncftp can Date: Wed, 1 Oct 1997 10:46:51 -0700 David O'Brien scribbled this message on Oct 1: > Sending SIZE pub/unix/mail/mutt/mutt-pgp/mutt-0.84e-0.84.diff.gz > pub/unix/mail/mutt/mutt-pgp/mutt-0.84e-0.84.diff.gz: not a plain file. > Sending MDTM pub/unix/mail/mutt/mutt-pgp/mutt-0.84e-0.84.diff.gz > pub/unix/mail/mutt/mutt-pgp/mutt-0.84e-0.84.diff.gz: No such file or directo > fetch: pub/unix/mail/mutt/mutt-pgp/mutt-0.84e-0.84.diff.gz: cannot get remot > Sending: PORT 169,237,60,72,4,246 > PORT command successful. > Sending: RETR pub/unix/mail/mutt/mutt-pgp/mutt-0.84e-0.84.diff.gz > pub/unix/mail/mutt/mutt-pgp/mutt-0.84e-0.84.diff.gz: No such file OR directo > fetch: ftp://ftp.fu-berlin.de/pub/unix/mail/mutt/mutt-pgp/mutt-0.84e-0.84.di > fetch: File unavailable (e.g., file not found, no access) > Sending: QUIT > Goodbye. > bash$ > bash$ > bash$ ncftp ftp://ftp.fu-berlin.de/pub/unix/mail/mutt/mutt-pgp/mutt-0.84e-0. > FTP.FU-Berlin.DE ready, please login as user "ftp". > Receiving file: mutt-0.84e-0.84.diff.gz > mutt-0.84e-0.84.diff.gz: 13751 bytes received in 11.27 seconds, 1.19 K/s. > exit well.. basicly the output tells you all you need.. when you login, the file pub/unix/mail/.../mutt isn't avail.. it turns out that the ftp server decides to dump you in the /pub directory instead of the root directory... so you end up duplicating the pub... now the question is, should we simply add a / to the front of the path in fetch? it would fix it... I don't have my RFC database close at hand but does it tell you whwer you are suppose to get dumped when you login? -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-bugs Wed Oct 1 11:28:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA29117 for bugs-outgoing; Wed, 1 Oct 1997 11:28:55 -0700 (PDT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA29110 for ; Wed, 1 Oct 1997 11:28:53 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.8.5/8.8.5) id OAA19756; Wed, 1 Oct 1997 14:28:46 -0400 (EDT) Date: Wed, 1 Oct 1997 14:28:46 -0400 (EDT) From: Garrett Wollman Message-Id: <199710011828.OAA19756@khavrinen.lcs.mit.edu> To: John-Mark Gurney Cc: freebsd-bugs@hub.freebsd.org Subject: Re: bin/4670: /usr/bin/fetch fails to ftp a file ncftp can In-Reply-To: <199710011750.KAA27156@hub.freebsd.org> References: <199710011750.KAA27156@hub.freebsd.org> Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk < said: > now the question is, should we simply add a / to the front of the path > in fetch? No. FTP URLs are SUPPOSED to be relative to wherever FTP puts incoming users. If you want to add a literal `/' to the URL, add `%2f' at the beginning. (Many URL parsers interpret this incorrectly... the third slash in an absolute URL is ONLY a separator, and does not comprise part of the `path' component.) -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick From owner-freebsd-bugs Wed Oct 1 11:54:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA00829 for bugs-outgoing; Wed, 1 Oct 1997 11:54:40 -0700 (PDT) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA00822 for ; Wed, 1 Oct 1997 11:54:35 -0700 (PDT) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id LAA12877; Wed, 1 Oct 1997 11:54:28 -0700 (PDT) Message-ID: <19971001115428.03021@hydrogen.nike.efn.org> Date: Wed, 1 Oct 1997 11:54:28 -0700 From: John-Mark Gurney To: Garrett Wollman Cc: freebsd-bugs@hub.freebsd.org Subject: Re: bin/4670: /usr/bin/fetch fails to ftp a file ncftp can References: <199710011750.KAA27156@hub.freebsd.org> <199710011828.OAA19756@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199710011828.OAA19756@khavrinen.lcs.mit.edu>; from Garrett Wollman on Wed, Oct 01, 1997 at 02:28:46PM -0400 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Garrett Wollman scribbled this message on Oct 1: > < said: > > > now the question is, should we simply add a / to the front of the path > > in fetch? > > No. FTP URLs are SUPPOSED to be relative to wherever FTP puts > incoming users. If you want to add a literal `/' to the URL, add > `%2f' at the beginning. (Many URL parsers interpret this > incorrectly... the third slash in an absolute URL is ONLY a separator, > and does not comprise part of the `path' component.) yep... if you add a %2f, fetch will complete successfully.... so would adding a fourth slash to be relative be in spec? or are all repeate slashes suppose to be condensed? because fetch will work if you do: fetch ftp://ftp.fu-berlin.de//pub/... thanks for the clarification on the url's... -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-bugs Wed Oct 1 12:50:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA03610 for bugs-outgoing; Wed, 1 Oct 1997 12:50:05 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA03603; Wed, 1 Oct 1997 12:50:01 -0700 (PDT) Date: Wed, 1 Oct 1997 12:50:01 -0700 (PDT) Message-Id: <199710011950.MAA03603@hub.freebsd.org> To: freebsd-bugs Cc: From: Bill Fenner Subject: Re: bin/4670: /usr/bin/fetch fails to ftp a file ncftp can Reply-To: Bill Fenner Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The following reply was made to PR bin/4670; it has been noted by GNATS. From: Bill Fenner To: Garrett Wollman Cc: freebsd-gnats-submit@freebsd.org Subject: Re: bin/4670: /usr/bin/fetch fails to ftp a file ncftp can Date: Wed, 1 Oct 1997 12:41:51 PDT However, if fetch followed the RFC1738 definition of ftp: URL's, then it would be able to fetch this particular URL. Sending: USER anonymous FTP.FU-Berlin.DE ready, please login as user "ftp". Anonymous login ok, send your e-mail address as password. Sending: PASS fenner@ampere.freebsd.org Welcome at Freie Universitaet Berlin, Germany. Anonymous login ok, for special commands see the README. Sending: TYPE I Type set to I. Sending: CWD pub CWD command successful. Sending: CWD unix CWD command successful. Sending: CWD mail CWD command successful. Sending: CWD mutt CWD command successful. Sending: CWD mutt-pgp This is the Mutt version with PGP support. I always try to upload the latest version here. This is either the illegally exported version from ftp://ftp.teuto.de/pub/user/lmb or my adaption of the PGP parts to a newer Mutt version. This is an inofficial Mutt version. leitner@math.fu-berlin.de CWD command successful. Sending SIZE mutt-0.84e-0.84.diff.gz 13751 Sending MDTM mutt-0.84e-0.84.diff.gz 19970917125011 Sending: PORT 204,216,27,20,4,19 PORT command successful. Sending: RETR mutt-0.84e-0.84.diff.gz Opening BINARY mode data connection for mutt-0.84e-0.84.diff.gz (13751 bytes). Receiving mutt-0.84e-0.84.diff.gz (13751 bytes)Sending: QUIT Transfer complete. The following diff causes fetch to interpret FTP URL's as RFC1738 defines. Bill Index: ftp.c =================================================================== RCS file: /home/ncvs/src/usr.bin/fetch/ftp.c,v retrieving revision 1.7 diff -u -r1.7 ftp.c --- ftp.c 1997/05/31 14:45:41 1.7 +++ ftp.c 1997/10/01 19:33:41 @@ -293,6 +293,7 @@ off_t seekloc, wehave; time_t modtime; size_t readresult, writeresult; + char *p, *q, *path; ftp = ftpLogin(ftps->ftp_hostname, (char *)(ftps->ftp_user ? ftps->ftp_user : "anonymous"), @@ -306,8 +307,19 @@ } ftpBinary(ftp); ftpPassive(ftp, fs->fs_passive_mode); - size = ftpGetSize(ftp, ftps->ftp_remote_file); - modtime = ftpGetModtime(ftp, ftps->ftp_remote_file); + p = path = safe_strdup(ftps->ftp_remote_file); + while ((q = strchr(p, '/')) != 0) { + *q++ = '\0'; + if ((status = ftpChdir(ftp, p)) != 0) { + warnx("%s: %s: %s", ftps->ftp_hostname, + p, ftpErrString(status)); + free(path); + return EX_IOERR; + } + p = q; + } + size = ftpGetSize(ftp, p); + modtime = ftpGetModtime(ftp, p); if (modtime <= 0) { /* xxx */ warnx("%s: cannot get remote modification time", ftps->ftp_remote_file); @@ -334,6 +346,7 @@ if (fs->fs_mirror && stab.st_size == size && modtime <= stab.st_mtime) { fclose(ftp); + free(path); return 0; } if (fs->fs_restart) { @@ -342,7 +355,8 @@ } } - remote = ftpGet(ftp, ftps->ftp_remote_file, &seekloc); + remote = ftpGet(ftp, p, &seekloc); + free(path); if (remote == 0) { if (ftpErrno(ftp)) { warnx("ftp://%s/%s: FTP error:", From owner-freebsd-bugs Wed Oct 1 13:10:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA04721 for bugs-outgoing; Wed, 1 Oct 1997 13:10:04 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA04704; Wed, 1 Oct 1997 13:10:01 -0700 (PDT) Date: Wed, 1 Oct 1997 13:10:01 -0700 (PDT) Message-Id: <199710012010.NAA04704@hub.freebsd.org> To: freebsd-bugs Cc: From: Bill Fenner Subject: Re: bin/4670: /usr/bin/fetch fails to ftp a file ncftp can Reply-To: Bill Fenner Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The following reply was made to PR bin/4670; it has been noted by GNATS. From: Bill Fenner To: freebsd-gnats-submit@freebsd.org Cc: Subject: Re: bin/4670: /usr/bin/fetch fails to ftp a file ncftp can Date: Wed, 1 Oct 1997 13:07:36 PDT Oops; that patch doesn't handle encoded slashes right. Looks like ftp_parse() has to break up the elements of the path and call percent_decode() on each element individually, and save the list in ftps for ftp_retrieve() to use. Bill From owner-freebsd-bugs Wed Oct 1 15:31:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA13512 for bugs-outgoing; Wed, 1 Oct 1997 15:31:12 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA13478; Wed, 1 Oct 1997 15:31:03 -0700 (PDT) Received: from base.juniper.net (base.juniper.net [208.197.169.208]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id PAA12785; Wed, 1 Oct 1997 15:30:28 -0700 (PDT) Received: from base.juniper.net (localhost.juniper.net [127.0.0.1]) by base.juniper.net (8.8.7/8.7.3) with ESMTP id PAA03697; Wed, 1 Oct 1997 15:30:15 -0700 (PDT) Message-Id: <199710012230.PAA03697@base.juniper.net> To: dg@root.com cc: Don Lewis , Richard Jones , hackers@freebsd.org, bugs@freebsd.org Subject: Re: FreeBSD TCP stack and RST processing [subj changed] In-reply-to: Your message of "Wed, 01 Oct 1997 04:51:35 PDT." <199710011151.EAA08698@implode.root.com> Date: Wed, 01 Oct 1997 15:30:15 -0700 From: Paul Traina Sender: owner-freebsd-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk It's been so long since I touched this that I won't offer an opinion. The original idea was ripped from Stevens by vjs and then from me, if memory serves me. From: David Greenman Subject: Re: FreeBSD TCP stack and RST processing [subj changed] >This code appears to be correct, and agrees with what's in the book. > >However ... there is some code *earlier* in tcp_input() that looks like it >botches this situation: ... >It looks like we just drop the packet containing the RST! The example code >in the book does not execute this code in the SYN_RECEIVED state. I don't >know the history of this code, so I don't know why it was changed. > >copied to freebsd-bugs This appears to have been broken in rev 1.52: ---------------------------- revision 1.52 date: 1996/10/07 04:32:39; author: pst; state: Exp; lines: +23 -13 Increase robustness of FreeBSD against high-rate connection attempt denial of service attacks. Reviewed by: bde,wollman,olah Inspired by: vjs@sgi.com ---------------------------- ... *************** *** 753,758 **** --- 758,765 ---- } /* + * If the state is SYN_RECEIVED: + * do just the ack and RST checks from SYN_SENT state. * If the state is SYN_SENT: * if seg contains an ACK, but not for our SYN, drop the input. * if seg contains a RST, then drop the connection. *************** *** 764,769 **** --- 771,777 ---- * arrange for segment to be acked (eventually) * continue processing rest of data/controls, beginning with URG */ + case TCPS_SYN_RECEIVED: case TCPS_SYN_SENT: if ((taop = tcp_gettaocache(inp)) == NULL) { taop = &tao_noncached; *************** *** 791,796 **** --- 799,806 ---- tp = tcp_drop(tp, ECONNREFUSED); goto drop; } + if (tp->t_state == TCPS_SYN_RECEIVED) + break; if ((tiflags & TH_SYN) == 0) goto drop; tp->snd_wnd = ti->ti_win; /* initial send window */ -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-bugs Wed Oct 1 16:55:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA17346 for bugs-outgoing; Wed, 1 Oct 1997 16:55:13 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA17339; Wed, 1 Oct 1997 16:55:11 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id QAA18570; Wed, 1 Oct 1997 16:54:42 -0700 (PDT) To: Paul Traina cc: dg@root.com, Don Lewis , Richard Jones , hackers@FreeBSD.ORG, bugs@FreeBSD.ORG Subject: Re: FreeBSD TCP stack and RST processing [subj changed] In-reply-to: Your message of "Wed, 01 Oct 1997 15:30:15 PDT." <199710012230.PAA03697@base.juniper.net> Date: Wed, 01 Oct 1997 16:54:42 -0700 Message-ID: <18567.875750082@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > It's been so long since I touched this that I won't offer an opinion. > The original idea was ripped from Stevens by vjs and then from me, if > memory serves me. Well, since it certainly seems to cause deviation from expected behavior and none of the other *BSDs have picked it up, shall we simply rip it out? Jordan From owner-freebsd-bugs Wed Oct 1 17:55:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA20146 for bugs-outgoing; Wed, 1 Oct 1997 17:55:12 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA20125; Wed, 1 Oct 1997 17:55:08 -0700 (PDT) Received: from base.juniper.net (base.juniper.net [208.197.169.208]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id RAA15433; Wed, 1 Oct 1997 17:54:37 -0700 (PDT) Received: from base.juniper.net (localhost.juniper.net [127.0.0.1]) by base.juniper.net (8.8.7/8.7.3) with ESMTP id RAA04241; Wed, 1 Oct 1997 17:54:24 -0700 (PDT) Message-Id: <199710020054.RAA04241@base.juniper.net> To: "Jordan K. Hubbard" cc: dg@root.com, Don Lewis , Richard Jones , hackers@FreeBSD.ORG, bugs@FreeBSD.ORG Subject: Re: FreeBSD TCP stack and RST processing [subj changed] In-reply-to: Your message of "Wed, 01 Oct 1997 16:54:42 PDT." <18567.875750082@time.cdrom.com> Date: Wed, 01 Oct 1997 17:54:24 -0700 From: Paul Traina Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I put it in there for a reason, Steven's III showed a case where you could pummel the box with a barage of, I believe, syn ack's and basicly melt things. Sorry my memory is so foggy on the issue now. I'll go back and try to remember. From: "Jordan K. Hubbard" Subject: Re: FreeBSD TCP stack and RST processing [subj changed] > It's been so long since I touched this that I won't offer an opinion. > The original idea was ripped from Stevens by vjs and then from me, if > memory serves me. Well, since it certainly seems to cause deviation from expected behavior and none of the other *BSDs have picked it up, shall we simply rip it out? Jordan From owner-freebsd-bugs Wed Oct 1 18:07:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA20659 for bugs-outgoing; Wed, 1 Oct 1997 18:07:06 -0700 (PDT) Received: from a42.deep-thought.org (A42.deep-thought.org [203.4.184.227]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA20635; Wed, 1 Oct 1997 18:06:45 -0700 (PDT) Received: from a42.deep-thought.org ([127.0.0.1]) by a42.deep-thought.org with esmtp id m0xGZlz-0024w4C (Debian Smail-3.2 1996-Jul-4 #2); Thu, 2 Oct 1997 11:09:47 +1000 (EST) Message-Id: X-Mailer: exmh version 1.6.9 8/22/96 To: Paul Traina cc: "Jordan K. Hubbard" , dg@root.com, Don Lewis , hackers@FreeBSD.ORG, bugs@FreeBSD.ORG Subject: Re: FreeBSD TCP stack and RST processing [subj changed] In-reply-to: Your message of "Wed, 01 Oct 1997 17:54:24 MST." <199710020054.RAA04241@base.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 02 Oct 1997 11:09:47 +1000 From: Richard Jones Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Paul Traina wrote: > I put it in there for a reason, Steven's III showed a case where you could > pummel the box with a barage of, I believe, syn ack's and basicly melt things. > Sorry my memory is so foggy on the issue now. I'll go back and try to > remember. Hmm..but if you barrage the system with SYN ACK's when the system is in a listen state, you shouldn't jump into SYN_RECEIVED should you? The code which does the if (TH_RST) stuff is prolly ok...its the addition of the case SYN_RECEIVED up the top that does the trick. Its ok to look for an ACK when in SYN_SENT on RST's coz thats what is expected, and if you get other than expected and drop then its no big deal unless you can force a remote freebsd system to send out (pure) SYN's to non-connected ports, unlikely. I only have the snippets posted to the list available, but based on them I'd say remove the case SYN_RECEIVED that was added. You might get away with getting rid of the ACK flag check without losing anything, but any side effects should be thought through. Anyways I'm running late for appointment which is why this may sound a little incoherent, gotta run. Richard Jones. From owner-freebsd-bugs Wed Oct 1 18:16:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA21182 for bugs-outgoing; Wed, 1 Oct 1997 18:16:39 -0700 (PDT) Received: from usr04.primenet.com (tlambert@usr04.primenet.com [206.165.6.204]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA21177; Wed, 1 Oct 1997 18:16:26 -0700 (PDT) Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id SAA01906; Wed, 1 Oct 1997 18:15:57 -0700 (MST) From: Terry Lambert Message-Id: <199710020115.SAA01906@usr04.primenet.com> Subject: Re: FreeBSD TCP stack and RST processing [subj changed] To: dg@root.com Date: Thu, 2 Oct 1997 01:15:57 +0000 (GMT) Cc: Don.Lewis@tsc.tdk.com, richard@a42.deep-thought.org, pst@FreeBSD.ORG, hackers@FreeBSD.ORG, bugs@FreeBSD.ORG In-Reply-To: <199710011151.EAA08698@implode.root.com> from "David Greenman" at Oct 1, 97 04:51:35 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > This appears to have been broken in rev 1.52: [ ... diff ... ] Forget my other posting -- I see the problem now. I still think it requires a trojan connect to trigger it: the attacking system has to get you to connect to it. For normal traffic, sendmail is the only push-model interface, where the sever connects, I think. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-bugs Wed Oct 1 18:20:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA21441 for bugs-outgoing; Wed, 1 Oct 1997 18:20:19 -0700 (PDT) Received: from usr04.primenet.com (tlambert@usr04.primenet.com [206.165.6.204]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA21435; Wed, 1 Oct 1997 18:20:14 -0700 (PDT) Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id SAA02029; Wed, 1 Oct 1997 18:19:37 -0700 (MST) From: Terry Lambert Message-Id: <199710020119.SAA02029@usr04.primenet.com> Subject: Re: FreeBSD TCP stack and RST processing [subj changed] To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Thu, 2 Oct 1997 01:19:37 +0000 (GMT) Cc: pst@juniper.net, dg@root.com, Don.Lewis@tsc.tdk.com, richard@a42.deep-thought.org, hackers@FreeBSD.ORG, bugs@FreeBSD.ORG In-Reply-To: <18567.875750082@time.cdrom.com> from "Jordan K. Hubbard" at Oct 1, 97 04:54:42 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > It's been so long since I touched this that I won't offer an opinion. > > The original idea was ripped from Stevens by vjs and then from me, if > > memory serves me. > > Well, since it certainly seems to cause deviation from expected > behavior and none of the other *BSDs have picked it up, shall we > simply rip it out? I think the "ignore H_ACK for the compare" suggestion is best. If we ripped out everything that the other BSD's didn't agree was BSD, then you'd lose things like, oh, the new VM code. And so on. Not a strong justifiable argument, IMO. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-bugs Wed Oct 1 18:38:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA22218 for bugs-outgoing; Wed, 1 Oct 1997 18:38:18 -0700 (PDT) Received: from gatekeeper.tsc.tdk.com (root@gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA22212; Wed, 1 Oct 1997 18:38:15 -0700 (PDT) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.4/8.8.4) with ESMTP id SAA08144; Wed, 1 Oct 1997 18:37:39 -0700 (PDT) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id SAA24062; Wed, 1 Oct 1997 18:37:37 -0700 (PDT) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id SAA16461; Wed, 1 Oct 1997 18:37:36 -0700 (PDT) From: Don Lewis Message-Id: <199710020137.SAA16461@salsa.gv.tsc.tdk.com> Date: Wed, 1 Oct 1997 18:37:36 -0700 In-Reply-To: Richard Jones "Re: FreeBSD TCP stack and RST processing [subj changed]" (Oct 2, 11:09am) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Richard Jones , Paul Traina Subject: Re: FreeBSD TCP stack and RST processing [subj changed] Cc: "Jordan K. Hubbard" , dg@root.com, Don Lewis , hackers@FreeBSD.ORG, bugs@FreeBSD.ORG Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Oct 2, 11:09am, Richard Jones wrote: } Subject: Re: FreeBSD TCP stack and RST processing [subj changed] } Paul Traina wrote: } > I put it in there for a reason, Steven's III showed a case where you could } > pummel the box with a barage of, I believe, syn ack's and basicly melt things. } > Sorry my memory is so foggy on the issue now. I'll go back and try to } > remember. Steven's III? I don't have that one, since I figured that I already knew how NNTP worked. } Hmm..but if you barrage the system with SYN ACK's when the system is in a } listen state, you shouldn't jump into SYN_RECEIVED should you? Nope. This case is handled earlier: case TCPS_LISTEN: { struct mbuf *am; register struct sockaddr_in *sin; if (tiflags & TH_RST) goto drop; if (tiflags & TH_ACK) goto dropwithreset; if ((tiflags & TH_SYN) == 0) goto drop; } The code } which does the if (TH_RST) stuff is prolly ok...its the addition of the } case SYN_RECEIVED up the top that does the trick. As in goobers it up. } Its ok to look for } an ACK when in SYN_SENT on RST's coz thats what is expected, and if you } get other than expected and drop then its no big deal unless you can force } a remote freebsd system to send out (pure) SYN's to non-connected } ports, unlikely. I only have the snippets posted to the list available, but } based on them I'd say remove the case SYN_RECEIVED that was added. That's what I did in my local source tree. } You might } get away with getting rid of the ACK flag check without losing anything, but } any side effects should be thought through. Yeah, the case of what to do if you receive an ACK in the SYN_RECEIVED case bothers me as well. --- Truck From owner-freebsd-bugs Wed Oct 1 19:11:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA23973 for bugs-outgoing; Wed, 1 Oct 1997 19:11:07 -0700 (PDT) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id TAA23964; Wed, 1 Oct 1997 19:11:02 -0700 (PDT) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <52020(2)>; Wed, 1 Oct 1997 19:10:21 PDT Received: by crevenia.parc.xerox.com id <177486>; Wed, 1 Oct 1997 19:10:14 -0700 From: Bill Fenner To: jkh@time.cdrom.com, tlambert@primenet.com Subject: Re: FreeBSD TCP stack and RST processing [subj changed] Cc: Don.Lewis@tsc.tdk.com, bugs@freebsd.org, dg@root.com, hackers@freebsd.org, pst@juniper.net, richard@a42.deep-thought.org Message-Id: <97Oct1.191014pdt.177486@crevenia.parc.xerox.com> Date: Wed, 1 Oct 1997 19:10:10 PDT Sender: owner-freebsd-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >I think the "ignore H_ACK for the compare" suggestion is best. No. Validating the ACK is a required part of RST processing in SYN_SENT state (but not in SYN_RECEIVED). Bill From owner-freebsd-bugs Wed Oct 1 19:27:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA24957 for bugs-outgoing; Wed, 1 Oct 1997 19:27:17 -0700 (PDT) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA24951 for ; Wed, 1 Oct 1997 19:27:13 -0700 (PDT) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id TAA16000; Wed, 1 Oct 1997 19:29:45 -0700 (PDT) Message-Id: <199710020229.TAA16000@implode.root.com> To: Don Lewis cc: bugs@FreeBSD.ORG Subject: Re: FreeBSD TCP stack and RST processing [subj changed] In-reply-to: Your message of "Wed, 01 Oct 1997 18:37:36 PDT." <199710020137.SAA16461@salsa.gv.tsc.tdk.com> From: David Greenman Reply-To: dg@root.com Date: Wed, 01 Oct 1997 19:29:45 -0700 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >} Its ok to look for >} an ACK when in SYN_SENT on RST's coz thats what is expected, and if you >} get other than expected and drop then its no big deal unless you can force >} a remote freebsd system to send out (pure) SYN's to non-connected >} ports, unlikely. I only have the snippets posted to the list available, but >} based on them I'd say remove the case SYN_RECEIVED that was added. > >That's what I did in my local source tree. ...and that's the way -current is as of a few minutes ago. I'll merge the fix into 2.2-stable in a day or two. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-bugs Wed Oct 1 22:37:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA04626 for bugs-outgoing; Wed, 1 Oct 1997 22:37:20 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA04621; Wed, 1 Oct 1997 22:37:18 -0700 (PDT) Received: from time.cdrom.com (localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id WAA04596; Wed, 1 Oct 1997 22:36:20 -0700 (PDT) To: Terry Lambert cc: pst@juniper.net, dg@root.com, Don.Lewis@tsc.tdk.com, richard@a42.deep-thought.org, hackers@FreeBSD.ORG, bugs@FreeBSD.ORG Subject: Re: FreeBSD TCP stack and RST processing [subj changed] In-reply-to: Your message of "Thu, 02 Oct 1997 01:19:37 -0000." <199710020119.SAA02029@usr04.primenet.com> Date: Wed, 01 Oct 1997 22:36:19 -0700 Message-ID: <4592.875770579@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Well, since it certainly seems to cause deviation from expected > > behavior and none of the other *BSDs have picked it up, shall we > > simply rip it out? > > I think the "ignore H_ACK for the compare" suggestion is best. If we > ripped out everything that the other BSD's didn't agree was BSD, then > you'd lose things like, oh, the new VM code. And so on. Not a strong > justifiable argument, IMO. No, but it's also not my argument. I merely cited it as a data point, any comparison between the VM system and a relatively syn-flood fix being definite apples-and-oranges material anyway. The other *BSDs generally do track one another's DoS and general security fixes unless there's a clear reason to avoid something. The VM system is not in this category, it's merely too hard to track in a multi-architecture environment (not for want of trying on the part of various folks in NetBSD, at least). Jordan From owner-freebsd-bugs Thu Oct 2 01:26:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA12492 for bugs-outgoing; Thu, 2 Oct 1997 01:26:02 -0700 (PDT) Received: from usr08.primenet.com (tlambert@usr08.primenet.com [206.165.6.208]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA12468; Thu, 2 Oct 1997 01:25:58 -0700 (PDT) Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id BAA24472; Thu, 2 Oct 1997 01:25:51 -0700 (MST) From: Terry Lambert Message-Id: <199710020825.BAA24472@usr08.primenet.com> Subject: Re: FreeBSD TCP stack and RST processing [subj changed] To: fenner@parc.xerox.com (Bill Fenner) Date: Thu, 2 Oct 1997 08:25:50 +0000 (GMT) Cc: jkh@time.cdrom.com, tlambert@primenet.com, Don.Lewis@tsc.tdk.com, bugs@freebsd.org, dg@root.com, hackers@freebsd.org, pst@juniper.net, richard@a42.deep-thought.org In-Reply-To: <97Oct1.191014pdt.177486@crevenia.parc.xerox.com> from "Bill Fenner" at Oct 1, 97 07:10:10 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >I think the "ignore H_ACK for the compare" suggestion is best. > > No. Validating the ACK is a required part of RST processing in SYN_SENT > state (but not in SYN_RECEIVED). The fallthrough case does this. We are talking about the conditions under which a fallthreough can occur. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-bugs Thu Oct 2 06:20:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA25052 for bugs-outgoing; Thu, 2 Oct 1997 06:20:05 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA25007; Thu, 2 Oct 1997 06:20:01 -0700 (PDT) Resent-Date: Thu, 2 Oct 1997 06:20:01 -0700 (PDT) Resent-Message-Id: <199710021320.GAA25007@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, gfoster@gfoster.com Received: from gfoster.intr.net (gfoster.intr.net [207.32.93.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA24623 for ; Thu, 2 Oct 1997 06:12:34 -0700 (PDT) Received: (from gfoster@localhost) by gfoster.intr.net (8.8.7/8.8.6) id JAA01609; Thu, 2 Oct 1997 09:12:33 -0400 (EDT) Message-Id: <199710021312.JAA01609@gfoster.intr.net> Date: Thu, 2 Oct 1997 09:12:33 -0400 (EDT) From: Glen Foster Reply-To: gfoster@gfoster.com To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: misc/4679: xtend(8) doesn't handle the "dump" command correctly Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4679 >Category: misc >Synopsis: xtend(8) doesn't handle the "dump" command correctly >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Class: change-request >Submitter-Id: current-users >Arrival-Date: Thu Oct 2 06:20:00 PDT 1997 >Last-Modified: >Originator: Glen Foster >Organization: self >Release: FreeBSD 2.2-STABLE i386 >Environment: affects only sites running the tw0 optional device driver and xtend(8)/xten(1) software. >Description: The xtend man page describes a command "dump" to the xtend daemon. As shipped, xtend tries to write the dump file to an inappropriate location, one where it has no write permission and is not logically tied to the program. >How-To-Repeat: Compile a kernel with the tw0 device, set xtend_enable="YES" in /etc/rc.conf. Run "xten -" and issue the command "dump" to the xtend daemon. Rather than writing a status.out file in /var/spool/xten/, the command will generate an error. >Fix: Apply the patch: *** /usr/src/libexec/xtend/user.c.orig Thu Oct 2 08:54:35 1997 --- /usr/src/libexec/xtend/user.c Thu Oct 2 08:55:05 1997 *************** *** 73,78 **** --- 73,79 ---- } } else if(!strcmp("dump\n", cmd)) { strcpy(dumppath, X10DIR); + strcat(dumppath, "/"); strcat(dumppath, X10DUMPNAME); if((dumpf = fopen(dumppath, "w")) != NULL) { for(h = 0; h < 16; h++) { >Audit-Trail: >Unformatted: From owner-freebsd-bugs Thu Oct 2 09:35:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA06856 for bugs-outgoing; Thu, 2 Oct 1997 09:35:45 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA06847; Thu, 2 Oct 1997 09:35:29 -0700 (PDT) From: Joerg Wunsch Received: (from joerg@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id JAA09209; Thu, 2 Oct 1997 09:29:43 -0700 (PDT) Date: Thu, 2 Oct 1997 09:29:43 -0700 (PDT) Message-Id: <199710021629.JAA09209@freefall.freebsd.org> To: switzel@uni-goettingen.de, joerg@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: bin/4445 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: segmentation fault in vfprintf State-Changed-From-To: open-closed State-Changed-By: joerg State-Changed-When: Thu Oct 2 18:29:09 MEST 1997 State-Changed-Why: Cancelled by originator's requeust. From owner-freebsd-bugs Thu Oct 2 09:54:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA08128 for bugs-outgoing; Thu, 2 Oct 1997 09:54:06 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA08107; Thu, 2 Oct 1997 09:53:57 -0700 (PDT) Received: from base.juniper.net (base.juniper.net [208.197.169.208]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id JAA24951; Thu, 2 Oct 1997 09:53:26 -0700 (PDT) Received: from base.juniper.net (localhost.juniper.net [127.0.0.1]) by base.juniper.net (8.8.7/8.7.3) with ESMTP id JAA05848; Thu, 2 Oct 1997 09:53:13 -0700 (PDT) Message-Id: <199710021653.JAA05848@base.juniper.net> To: Don Lewis cc: Richard Jones , "Jordan K. Hubbard" , dg@root.com, hackers@FreeBSD.ORG, bugs@FreeBSD.ORG Subject: Re: FreeBSD TCP stack and RST processing [subj changed] In-reply-to: Your message of "Wed, 01 Oct 1997 18:37:36 PDT." <199710020137.SAA16461@salsa.gv.tsc.tdk.com> Date: Thu, 02 Oct 1997 09:53:13 -0700 From: Paul Traina Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk From: Don Lewis Subject: Re: FreeBSD TCP stack and RST processing [subj changed] On Oct 2, 11:09am, Richard Jones wrote: } Subject: Re: FreeBSD TCP stack and RST processing [subj changed] } Paul Traina wrote: } > I put it in there for a reason, Steven's III showed a case where you coul >>d } > pummel the box with a barage of, I believe, syn ack's and basicly melt th >>ings. } > Sorry my memory is so foggy on the issue now. I'll go back and try to } > remember. Steven's III? I don't have that one, since I figured that I already knew how NNTP worked. No, it's actually the most interesting, because it goes into a lot of performance. } Hmm..but if you barrage the system with SYN ACK's when the system is in a } listen state, you shouldn't jump into SYN_RECEIVED should you? Nope. This case is handled earlier: case TCPS_LISTEN: { struct mbuf *am; register struct sockaddr_in *sin; if (tiflags & TH_RST) goto drop; if (tiflags & TH_ACK) goto dropwithreset; if ((tiflags & TH_SYN) == 0) goto drop; Yep, and the bug is that the two got spammed together after I gutted one. From owner-freebsd-bugs Thu Oct 2 15:54:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA29164 for bugs-outgoing; Thu, 2 Oct 1997 15:54:11 -0700 (PDT) Received: from cyrus.watson.org (robert@AMALTHEA.RES.CMU.EDU [128.2.91.57]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA29155 for ; Thu, 2 Oct 1997 15:54:02 -0700 (PDT) Received: from localhost (robert@localhost) by cyrus.watson.org (8.8.5/8.8.5) with SMTP id SAA03575 for ; Thu, 2 Oct 1997 18:55:10 -0400 (EDT) Date: Thu, 2 Oct 1997 18:55:10 -0400 (EDT) From: Robert Watson Reply-To: Robert Watson To: bugs@freebsd.org Subject: Possible weakness in LPD protocol (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Was wondering if this was a concern for us? Robert N Watson Junior, Logic+Computation, Carnegie Mellon University http://www.cmu.edu/ Network Administrator, SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org rwatson@safeport.com http://www.watson.org/~robert/ ---------- Forwarded message ---------- Date: Thu, 2 Oct 1997 16:58:23 -0400 From: Bennett Samowich Reply-To: a42n8k9@unspecified-domain, *NO-SPAM**.redrose.net@unspecified-domain To: BUGTRAQ@NETSPACE.ORG Subject: Possible weakness in LPD protocol Greetings, This may be old news, but here it is anyway... While working of a port of "lpr/lpd" to Windows95 I noticed some weaknesses in the implementation of the LPR protocol. Mostly it appears to affect BSD based UNIX's. I found it using the source for BSD4.4, and tested it on "Linux Slackware 2.2.0". I have also tested it on AIX 4.1.5 and it seems to be OK. Unfortunately, (or Fortunately depending on how you look at it), I only have access to these two operating systems. Explaining this assumes that you are familiar with [RFC-1179 Line Pinter Daemon Protocol]. If you are not familiar or have not read it, it may be obtained via FTP from ftp://nic.ddn.mil/rfc/rfc1179.txt The possibilities are as follows: 1.) Obtaining hard (or possibly soft) copies of any file on the system. 2.) Deleting any file on the system. 3.) Creating a file on the system. 4.) Mail bombing. There are a few requirements that need to be met in order to perform these actions. 1.) Must be 'root' on the source machine. NOTE: Under Windows95 the user already has 'root' status. This means that anyone on a Win95 box can bind network sockets to the reserved ports. 2.) Must have or obtain permission to print to the target machine. Usually machines on the same network will have permission to print to each other, but that may not always be the case. 3.) Must have or obtain access to the target printer. Otherwise how will you get your printout? HOW IT WORKS... When lpd sends a file to a remote machine it creates a control file used to instruct the remote machine on how to process the incoming print job. These commands are outlined in [RFC-1179]. It is the implementation of the control commands that provide the weakness. 1.) Obtaining hard (or possibly soft) copies of any file on the system. The control command 'f' causes a file to be printed as text. The syntax is: f filename [LF] Therefore, by inserting the line: "f/etc/shadow" into the control file you will cause the Shadow password file to be printed. (Hard copy) If the print queue points to a network printer then it would be possible to capture the packets. (Soft copy) 2.) Delete any file on the system. The control command 'U' instructs the remote machine to "unlink" the file upon completion of the job. The syntax is: U filename [LF] Therefore, by inserting the line: "U/vmlinuz" into the control file you will cause the Linux kernel to be removed from the file system. 3.) Create a file on the remote system. This is a little trickier, in that BSD4.4 takes the filename that you specify and appends its view of the calling machine's hostname to it. However, BSD4.4 starts at the sixth character. The syntax is 2 size [SP] filename [LF]. Where '2' is the octet 2 not the character, size is the size of the file in bytes, filename is ... (DUH). - From RECVJOB.C case '\2': /* read cf file */ size = 0; while (*cp >= '0' && *cp <= '9') size = size * 10 + (*cp++ - '0'); if (*cp++ != ' ') break; /* * host name has been authenticated, we use our * view of the host name since we may be passed * something different than what gethostbyaddr() * returns */ HERE -----------> strcpy(cp + 6, from); strcpy(tfname, cp); tfname[0] = 't'; if (!chksize(size)) { (void) write(1, "\2", 1); continue; } if (!readfile(tfname, size)) { rcleanup(0); continue; } if (link(tfname, cp) < 0) frecverr("%s: %m", tfname); (void) unlink(tfname); tfname[0] = '\0'; nfiles++; continue; The result is this: /rc becomes /rc /etc/passwd becomes /etc/passwd.www.yourhost.com This is accomplished by using the printer command of '2' (receive control file) Therefore by sending the printer command '2/rc' and then sending our file, we have created a file in the root directory called 'rc'. By sending '2/home/yourfriend/somefile' and the your file you will have sent somefile to yourfriend ... and even put it in their home directory. Of course it will have the name somefile.www.yourhost.com, but he got it none the less. 4.) Mail bombing. The control command 'M' instructs lpd to mail the user when the job is finished. The syntax is: M username [LF] Therefore by adding the line: "Mjoeuser@www.somewhere.com" you will cause joeuser to receive mail notification about the print job. By adding several thousand of these lines, well you get the idea. SOLUTIONS ??? These holes are due to the implementation of the lpr protocol and the fact that lpd runs as root. I am sure that there may be many solutions to this, but At first glance I think that by checking for a '/' in the filenames would cause the program to react when someone tries to print files from outside of the queue directory. As far as the mail bomb, maybe by checking the destination host with lpd's view of the caller, but that wouldn't allow for someone to print from one account and get the mail at another. IE the boss getting notices when the report is finished. Let me know if I have miss-stated something. Bennett From owner-freebsd-bugs Thu Oct 2 15:56:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA29245 for bugs-outgoing; Thu, 2 Oct 1997 15:56:03 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA29200; Thu, 2 Oct 1997 15:55:22 -0700 (PDT) From: Masafumi NAKANE Received: (from max@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id PAA09997; Thu, 2 Oct 1997 15:49:34 -0700 (PDT) Date: Thu, 2 Oct 1997 15:49:34 -0700 (PDT) Message-Id: <199710022249.PAA09997@freefall.freebsd.org> To: max@FreeBSD.ORG, gnats-admin@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: pending/4671 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: ftpd panics kernel on (ppp only?) links Responsible-Changed-From-To: gnats-admin->freebsd-bugs Responsible-Changed-By: max Responsible-Changed-When: Thu Oct 2 15:48:47 PDT 1997 Responsible-Changed-Why: Misfiled PR. From owner-freebsd-bugs Thu Oct 2 15:58:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA29325 for bugs-outgoing; Thu, 2 Oct 1997 15:58:04 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA29285; Thu, 2 Oct 1997 15:57:03 -0700 (PDT) From: Masafumi NAKANE Received: (from max@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id PAA10079; Thu, 2 Oct 1997 15:51:15 -0700 (PDT) Date: Thu, 2 Oct 1997 15:51:15 -0700 (PDT) Message-Id: <199710022251.PAA10079@freefall.freebsd.org> To: max@FreeBSD.ORG, gnats-admin@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: pending/4680 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: lkm version of vn.c Responsible-Changed-From-To: gnats-admin->freebsd-bugs Responsible-Changed-By: max Responsible-Changed-When: Thu Oct 2 15:50:31 PDT 1997 Responsible-Changed-Why: Misfiled PR. From owner-freebsd-bugs Thu Oct 2 19:20:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA09662 for bugs-outgoing; Thu, 2 Oct 1997 19:20:04 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA09652; Thu, 2 Oct 1997 19:20:02 -0700 (PDT) Resent-Date: Thu, 2 Oct 1997 19:20:02 -0700 (PDT) Resent-Message-Id: <199710030220.TAA09652@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, seki@sysrap.cs.fujitsu.co.jp Received: from fgwmail.fujitsu.co.jp (fgwmail.fujitsu.co.jp [164.71.1.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA09570 for ; Thu, 2 Oct 1997 19:18:08 -0700 (PDT) Received: from fdmmail.fujitsu.co.jp by fgwmail.fujitsu.co.jp (8.8.7+2.7Wbeta6/3.6Wbeta6-MX970929-Fujitsu Mail Gateway) id LAA14977; Fri, 3 Oct 1997 11:17:30 +0900 (JST) Received: from nile.sysrap.cs.fujitsu.co.jp by fdmmail.fujitsu.co.jp (8.8.5+2.7Wbeta5/3.5Wpl3-971001-Fujitsu Domain Mail Master) id LAA11487; Fri, 3 Oct 1997 11:16:58 +0900 (JST) Received: (from seki@localhost) by nile.sysrap.cs.fujitsu.co.jp (8.8.5/8.7.3) id LAA13556; Fri, 3 Oct 1997 11:16:58 +0900 (JST) Message-Id: <199710030216.LAA13556@nile.sysrap.cs.fujitsu.co.jp> Date: Fri, 3 Oct 1997 11:16:58 +0900 (JST) From: Masahiro Sekiguchi Reply-To: seki@sysrap.cs.fujitsu.co.jp To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: docs/4681: Typo in man page example Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4681 >Category: docs >Synopsis: The man page (1) example has a typo. >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Thu Oct 2 19:20:01 PDT 1997 >Last-Modified: >Originator: Masahiro Sekiguchi >Organization: Fujitsu Limited >Release: FreeBSD 2.2.2-RELEASE i386 >Environment: FreeBSD 2.2.2R >Description: The man page (1) example (/usr/share/examples/mdoc/example.1) has a typo in it. It says: DIAGNOSTICS Exist status is 0 on success, and 1 if the command fails but the first term must be "Exit status." >How-To-Repeat: groff -mandoc -Tascii /usr/share/examples/mdoc/examples.1 >Fix: Apply the following patch. (Or, just remove an "s" with an editor...) --- example.1.orig Fri Oct 3 11:03:00 1997 +++ example.1 Fri Oct 3 11:04:04 1997 @@ -120,7 +120,7 @@ .St -ansiC , it should be noted here. .Sh DIAGNOSTICS -Exist status is 0 on success, and 1 if the command +Exit status is 0 on success, and 1 if the command fails for one of the following reasons .Bl -diag .It example error message >Audit-Trail: >Unformatted: From owner-freebsd-bugs Thu Oct 2 20:40:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA13306 for bugs-outgoing; Thu, 2 Oct 1997 20:40:46 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA13281; Thu, 2 Oct 1997 20:40:27 -0700 (PDT) From: "Jordan K. Hubbard" Received: (from jkh@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id UAA12117; Thu, 2 Oct 1997 20:34:37 -0700 (PDT) Date: Thu, 2 Oct 1997 20:34:37 -0700 (PDT) Message-Id: <199710030334.UAA12117@freefall.freebsd.org> To: seki@sysrap.cs.fujitsu.co.jp, jkh@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: docs/4681 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: The man page (1) example has a typo. State-Changed-From-To: open-closed State-Changed-By: jkh State-Changed-When: Thu Oct 2 20:34:25 PDT 1997 State-Changed-Why: Fixed, thanks! From owner-freebsd-bugs Thu Oct 2 21:40:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA16130 for bugs-outgoing; Thu, 2 Oct 1997 21:40:08 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA16109; Thu, 2 Oct 1997 21:40:02 -0700 (PDT) Resent-Date: Thu, 2 Oct 1997 21:40:02 -0700 (PDT) Resent-Message-Id: <199710030440.VAA16109@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, Craig Leres Received: from ell.ee.lbl.gov (ell.ee.lbl.gov [131.243.1.20]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA15662 for ; Thu, 2 Oct 1997 21:32:51 -0700 (PDT) Received: by ell.ee.lbl.gov (8.8.7/8.8.5) id VAA27803; Thu, 2 Oct 1997 21:32:50 -0700 (PDT) Message-Id: <199710030432.VAA27803@ell.ee.lbl.gov> Date: Thu, 02 Oct 97 21:32:50 PDT From: Craig Leres To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: misc/4682: magic file entries for tcpdump save files Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4682 >Category: misc >Synopsis: magic file entries for tcpdump save files >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Class: change-request >Submitter-Id: current-users >Arrival-Date: Thu Oct 2 21:40:01 PDT 1997 >Last-Modified: >Originator: Craig Leres >Organization: Lawrence Berkeley National Laboratory >Release: FreeBSD 2.2.2-RELEASE i386 >Environment: >Description: Here are some entries for /usr/share/misc/magic that identify the two kinds of tcpdump save files. >How-To-Repeat: >Fix: # # libpcap/tcpdump packet capture savefiles # 0 lelong 0xa1b2c3d4 tcpdump save file >Audit-Trail: >Unformatted: >4 leshort x (v%d >6 leshort x \b.%d, little-endian) 0 belong 0xa1b2c3d4 tcpdump save file >4 beshort x (v%d >6 beshort x \b.%d, big-endian) From owner-freebsd-bugs Thu Oct 2 23:40:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA23560 for bugs-outgoing; Thu, 2 Oct 1997 23:40:06 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA23539; Thu, 2 Oct 1997 23:40:02 -0700 (PDT) Date: Thu, 2 Oct 1997 23:40:02 -0700 (PDT) Message-Id: <199710030640.XAA23539@hub.freebsd.org> To: freebsd-bugs Cc: From: David Muir Sharnoff Subject: Re: kern/4666: umount -f doesn't seem to work Reply-To: David Muir Sharnoff Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The following reply was made to PR kern/4666; it has been noted by GNATS. From: David Muir Sharnoff To: j@uriah.heep.sax.de (J Wunsch) Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: kern/4666: umount -f doesn't seem to work Date: Thu, 2 Oct 1997 23:34:37 -0700 (PDT) * As muir@idiom.com wrote: * * > tmp:/ /net/tmp nfs ro,intr,bg,tcp,nfsv2,resvport,nosuid 0 0 * > tmp:/usr /net/tmp/usr nfs ro,intr,bg,tcp,nfsv2,resvport,nosuid 0 0 * > * > >Description: * > * > # umount -f -h tmp * > nfs server tmp:/: not responding * * This is what one would expect how umount -f is working, but not what * is described for umount -f: forcibly unmounting is currently only * defined as ``don't care about resources that are locally still in use, * but revoke them''. * * Anyway, i think this is already in Doug Rabson's queue of ``nice to * have'' things. If i'm not totally mistaken, there might already be * another open PR for it. Did you check before filing? No. It seemed like a bug to me. -Dave From owner-freebsd-bugs Fri Oct 3 02:02:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA01895 for bugs-outgoing; Fri, 3 Oct 1997 02:02:21 -0700 (PDT) Received: from relay.ucb.crimea.ua (relay.ucb.crimea.ua [194.93.177.113]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA01878; Fri, 3 Oct 1997 02:01:43 -0700 (PDT) Received: (from ru@localhost) by relay.ucb.crimea.ua (8.8.7/8.8.7) id MAA28795; Fri, 3 Oct 1997 12:00:50 +0300 (EEST) From: Ruslan Ermilov Message-Id: <199710030900.MAA28795@relay.ucb.crimea.ua> Subject: slip driver To: jkh@freebsd.org, ache@freebsd.org Date: Fri, 3 Oct 1997 12:00:50 +0300 (EEST) Cc: freebsd-bugs@freebsd.org X-My-Interests: Unix,Oracle,Networking X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi! I'm interesting is there a slip driver bug (in STATIC UNIT FEATURE) will be resolved in 2.2.5? thanks, -- Ruslan A. Ermilov System Administrator ru@ucb.crimea.ua United Commercial Bank +380-652-247647 Simferopol, Crimea 2426679 ICQ Network, UIN From owner-freebsd-bugs Fri Oct 3 03:18:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA05373 for bugs-outgoing; Fri, 3 Oct 1997 03:18:55 -0700 (PDT) Received: from lsd.relcom.eu.net (lsd.relcom.eu.net [193.124.23.23]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA05368; Fri, 3 Oct 1997 03:18:44 -0700 (PDT) Received: (from ache@localhost) by lsd.relcom.eu.net (8.8.7/8.8.7) id OAA12537; Fri, 3 Oct 1997 14:16:09 +0400 (MSD) Date: Fri, 3 Oct 1997 14:16:08 +0400 (MSD) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= X-Sender: ache@lsd.relcom.eu.net To: Ruslan Ermilov cc: jkh@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: slip driver In-Reply-To: <199710030900.MAA28795@relay.ucb.crimea.ua> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 3 Oct 1997, Ruslan Ermilov wrote: > I'm interesting is there a slip driver bug (in > STATIC UNIT FEATURE) will be resolved in 2.2.5? Please specify which bug do you mean exactly. -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/ From owner-freebsd-bugs Fri Oct 3 11:12:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA02409 for bugs-outgoing; Fri, 3 Oct 1997 11:12:10 -0700 (PDT) Received: from elvis.vnet.net (elvis.vnet.net [166.82.1.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA02341; Fri, 3 Oct 1997 11:11:38 -0700 (PDT) Received: from ponds.dignus.com (ponds.vnet.net [166.82.177.48]) by elvis.vnet.net (8.8.5/8.8.4) with ESMTP id OAA19557; Fri, 3 Oct 1997 14:11:21 -0400 (EDT) Received: from lakes.dignus.com (lakes [10.0.0.3]) by ponds.dignus.com (8.8.5/8.8.5) with ESMTP id OAA11377; Fri, 3 Oct 1997 14:26:24 -0400 (EDT) Received: (from rivers@localhost) by lakes.dignus.com (8.8.5/8.6.9) id OAA16814; Fri, 3 Oct 1997 14:17:17 -0400 (EDT) Date: Fri, 3 Oct 1997 14:17:17 -0400 (EDT) From: Thomas David Rivers Message-Id: <199710031817.OAA16814@lakes.dignus.com> To: jkh@time.cdrom.com, phk@critter.freebsd.dk Subject: Electric Fence info (was Re: Bug in malloc/free (was: Memory leak in getservbyXXX?)) Cc: freebsd-bugs@FreeBSD.ORG, gram@cdsec.com, hackers@FreeBSD.ORG Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > This would indicate a bug of the class where memory is written to after > > being free()'ed, a kind of bug which phkmalloc makes no attempt to catch. > > Man, I sure wish there was a copy of purify available for FreeBSD. > It's great at catching stuff like this! :( > > Maybe you could hack free() to do an mprotect(addr, len, PROT_NONE) on > free'd pages, unprotecting them again as necessary when the malloc > routines themselves need to frob that memory. Or, since we're just > testing, do it from an internally registered SIGBUS handler which > figures out the right thing to do. :-) > > BTW, how *do* you get the faulting memory location from a SIGBUS > handler? I was just playing around with this a bit and noted that it > wasn't immediately obvious how you'd get that info from the signal > handler. > > Jordan Ok - there seems to be enough interest... Here's the man page for electric fence (which does the mprotect() trick Jordan mentions): I can make the source available to anyone who wants it. - Dave Rivers - efence(3) efence(3) NAME efence - Electric Fence Malloc Debugger SYNOPSIS #include void * malloc (size_t size); void free (void *ptr); void * realloc (void *ptr, size_t size); void * calloc (size_t nelem, size_t elsize); void * memalign (size_t alignment, size_t size); void * valloc (size_t size); extern int EF_ALIGNMENT; extern int EF_PROTECT_BELOW; extern int EF_PROTECT_FREE; DESCRIPTION Electric Fence helps you detect two common programming bugs: software that overruns the boundaries of a malloc() memory allocation, and software that touches a memory allocation that has been released by free(). Unlike other malloc() debuggers, Electric Fence will detect read accesses as well as writes, and it will pinpoint the exact instruction that causes an error. It has been in use at Pixar since 1987, and at many other sites for years. Electric Fence uses the virtual memory hardware of your computer to place an inaccessible memory page immediately after (or before, at the user's option) each memory allo- cation. When software reads or writes this inaccessible page, the hardware issues a segmentation fault, stopping the program at the offending instruction. It is then triv- ial to find the erroneous statement using your favorite debugger. In a similar manner, memory that has been released by free() is made inaccessible, and any code that touches it will get a segmentation fault. Simply linking your application with libefence.a will allow you to detect most, but not all, malloc buffer over- runs and accesses of free memory. If you want to be rea- sonably sure that you've found all bugs of this type, you'll have to read and understand the rest of this man page. USAGE Link your program with the library libefence.a . Make 27-April-1993 1 efence(3) efence(3) sure you are not linking with -lmalloc, -lmallocdebug, or with other malloc-debugger or malloc-enhancer libraries. You can only use one at a time. If your system adminis- trator has installed Electric Fence for public use, you'll be able to use the -lefence argument to the linker, other- wise you'll have to put the path-name for libefence.a in the linker's command line. Some systems will require spe- cial arguments to the linker to assure that you are using the Electric Fence malloc() and not the one from your C library. On AIX systems, you may have to use the flags -bnso -bnodelcsect -bI:/lib/syscalls.exp On Sun systems running SunOS 4.X, you'll probably have to use -Bstatic. Run your program using a debugger. It's easier to work this way than to create a core file and post-mortem debug it. Electric Fence can create huge core files, and some operating systems will thus take minutes simply to dump core! Some operating systems will not create usable core files from programs that are linked with Electric Fence. If your program has one of the errors detected by Electric Fence, it will get a segmentation fault (SIGSEGV) at the offending instruction. Use the debugger to locate the erroneous statement, and repair it. GLOBAL AND ENVIRONMENT VARIABLES Electric Fence has four configuration switches that can be enabled via the shell environment, or by setting the value of global integer variables using a debugger. These switches change what bugs Electric Fence will detect, so it's important that you know how to use them. EF_ALIGNMENT This is an integer that specifies the alignment for any memory allocations that will be returned by malloc(), calloc(), and realloc(). The value is specified in bytes, thus a value of 4 will cause memory to be aligned to 32-bit boundaries unless your system doesn't have a 8-bit characters. EF_ALIGNMENT is set to sizeof(int) by default, since that is generally the word-size of your CPU. If your program requires that allocations be aligned to 64-bit boundaries and you have a 32-bit int you'll have to set this value to 8. This is the case when compiling with the -mips2 flag on MIPS- based systems such as those from SGI. The memory allocation that is returned by Electric Fence mal- loc() is aligned using the value in EF_ALIGNMENT, and its size the multiple of that value that is greater than or equal to the requested size. For this reason, you will sometimes want to set EF_ALIGNMENT to 0 (no alignment), so that you can detect overruns of less than your CPU's word size. Be sure to read the section WORD-ALIGNMENT AND 27-April-1993 2 efence(3) efence(3) OVERRUN DETECTION in this manual page before you try this. To change this value, set EF_ALIGNMENT in the shell environment to an integer value, or assign to the global integer variable EF_ALIGNMENT using a debugger. EF_PROTECT_BELOW Electric Fence usually places an inaccessible page immediately after each memory allocation, so that software that runs past the end of the allocation will be detected. Setting EF_PROTECT_BELOW to 1 causes Electric Fence to place the inaccessible page before the allocation in the address space, so that under-runs will be detected instead of over- runs. When EF_PROTECT_BELOW is set, the EF_ALIGN- MENT parameter is ignored. All allocations will be aligned to virtual-memory-page boundaries, and their size will be the exact size that was requested. To change this value, set EF_PRO- TECT_BELOW in the shell environment to an integer value, or assign to the global integer variable EF_PROTECT_BELOW using a debugger. EF_PROTECT_FREE Electric Fence usually returns free memory to a pool from which it may be re-allocated. If you sus- pect that a program may be touching free memory, set EF_PROTECT_FREE to 1. This will cause Electric Fence to never re-allocate memory once it has been freed, so that any access to free memory will be detected. Some programs will use tremendous amounts of memory when this parameter is set. To change this value, set EF_PROTECT_FREE in the shell envi- ronment to an integer value, or assign to the global integer variable EF_PROTECT_FREE using a debugger. EF_ALLOW_MALLOC_0 By default, Electric Fence traps calls to malloc() with a size of zero, because they are often the result of a software bug. If EF_ALLOW_MALLOC_0 is non-zero, the software will not trap calls to mal- loc() with a size of zero. To change this value, set EF_ALLOC_MALLOC_0 in the shell environment to an integer value, or assign to the global integer variable EF_ALLOC_MALLOC_0 using a debugger. WORD-ALIGNMENT AND OVERRUN DETECTION There is a conflict between the alignment restrictions that malloc() operates under and the debugging strategy used by Electric Fence. When detecting overruns, Electric Fence malloc() allocates two or more virtual memory pages for each allocation. The last page is made inaccessible in such a way that any read, write, or execute access will 27-April-1993 3 efence(3) efence(3) cause a segmentation fault. Then, Electric Fence malloc() will return an address such that the first byte after the end of the allocation is on the inaccessible page. Thus, any overrun of the allocation will cause a segmentation fault. It follows that the address returned by malloc() is the address of the inaccessible page minus the size of the memory allocation. Unfortunately, malloc() is required to return word-aligned allocations, since many CPUs can only access a word when its address is aligned. The conflict happens when software makes a memory allocation using a size that is not a multiple of the word size, and expects to do word accesses to that allocation. The location of the inaccessible page is fixed by hardware at a word- aligned address. If Electric Fence malloc() is to return an aligned address, it must increase the size of the allo- cation to a multiple of the word size. In addition, the functions memalign() and valloc() must honor explicit specifications on the alignment of the memory allocation, and this, as well can only be implemented by increasing the size of the allocation. Thus, there will be situa- tions in which the end of a memory allocation contains some padding space, and accesses of that padding space will not be detected, even if they are overruns. Electric Fence provides the variable EF_ALIGNMENT so that the user can control the default alignment used by mal- loc(), calloc(), and realloc(). To debug overruns as small as a single byte, you can set EF_ALIGNMENT to zero. This will result in Electric Fence malloc() returning unaligned addresses for allocations with sizes that are not a multiple of the word size. This is not a problem in most cases, because compilers must pad the size of objects so that alignment restrictions are honored when storing those objects in arrays. The problem surfaces when soft- ware allocates odd-sized buffers for objects that must be word-aligned. One case of this is software that allocates a buffer to contain a structure and a string, and the string has an odd size (this example was in a popular TIFF library). If word references are made to un-aligned buffers, you will see a bus error (SIGBUS) instead of a segmentation fault. The only way to fix this is to re- write the offending code to make byte references or not make odd-sized allocations, or to set EF_ALIGNMENT to the word size. Another example of software incompatible with EF_ALIGNMENT < word-size is the strcmp() function and other string functions on SunOS (and probably Solaris), which make word-sized accesses to character strings, and may attempt to access up to three bytes beyond the end of a string. These result in a segmentation fault (SIGSEGV). The only way around this is to use versions of the string functions 27-April-1993 4 efence(3) efence(3) that perform byte references instead of word references. INSTRUCTIONS FOR DEBUGGING YOUR PROGRAM 1. Link with libefence.a as explained above. 2. Run your program in a debugger and fix any overruns or accesses to free memory. 3. Quit the debugger. 4. Set EF_PROTECT_BELOW = 1 in the shell environment. 5. Repeat step 2, this time repairing underruns if they occur. 6. Quit the debugger. 7. Read the restrictions in the section on WORD-ALIGN- MENT AND OVERRUN DETECTION. See if you can set EF_ALIGNMENT to 0 and repeat step 2. Sometimes this will be too much work, or there will be problems with library routines for which you don't have the source, that will prevent you from doing this. MEMORY USAGE AND EXECUTION SPEED Since Electric Fence uses at least two virtual memory pages for each of its allocations, it's a terrible memory hog. I've sometimes found it necessary to add a swap file using swapon(8) so that the system would have enough vir- tual memory to debug my program. Also, the way we manipu- late memory results in various cache and translation buffer entries being flushed with each call to malloc or free. The end result is that your program will be much slower and use more resources while you are debugging it with Electric Fence. Don't leave libefence.a linked into production software! Use it only for debugging. PORTING Electric Fence is written for ANSI C. You should be able to port it with simple changes to the Makefile and to page.c, which contains the memory management primitives . Many POSIX platforms will require only a re-compile. The operating system facilities required to port Electric Fence are: A way to allocate memory pages A way to make selected pages inaccessible. A way to make the pages accessible again. A way to detect when a program touches an inacces- sible page. A way to print messages. 27-April-1993 5 efence(3) efence(3) Please e-mail me a copy of any changes you have to make, so that I can merge them into the distribution. AUTHOR Bruce Perens WARNINGS I have tried to do as good a job as I can on this soft- ware, but I doubt that it is even theoretically possible to make it bug-free. This software has no warranty. It will not detect some bugs that you might expect it to detect, and will indicate that some non-bugs are bugs. Bruce Perens and/or Pixar will not be liable to any claims resulting from the use of this software or the ideas within it. The entire responsibility for its use must be assumed by the user. If you use it and it results in loss of life and/or property, tough. If it leads you on a wild goose chase and you waste two weeks debugging something, too bad. If you can't deal with the above, please don't use the software! I've written this in an attempt to help other people, not to get myself sued or prosecuted. LICENSE Copyright 1987,1988,1989,1990,1991,1992,1993 Bruce Perens. All Rights Reserved except for those granted in this notice. Permission is granted for you to use this software to debug other programs. You may re-distribute it the origi- nal form in which I released it to you. If you make modi- fications to it, please send them to me for distribution - you may not re-distribute modified versions. You may not sell this software. You may not sell support for this software. If you use ideas from this software in your own product, please pay me for them. CONTACTING THE AUTHOR Bruce Perens c/o Pixar 1001 West Cutting Blvd., Suite 200 Richmond, CA 94804 Telephone: 510-215-3502 Fax: 510-236-0388 Internet: Bruce@Pixar.com FILES /dev/zero: Source of memory pages (via mmap(2)). SEE ALSO malloc(3), mmap(2), mprotect(2), swapon(8) DIAGNOSTICS Segmentation Fault: Examine the offending statement for violation of the boundaries of a memory allocation. 27-April-1993 6 efence(3) efence(3) Bus Error: See the section on WORD-ALIGNMENT AND OVERRUN DETECTION. in this manual page. BUGS My explanation of the alignment issue could be improved. Some Sun systems running SunOS 4.1 are reported to signal an access to a protected page with SIGBUS rather than SIGSEGV, I suspect this is an undocumented feature of a particular Sun hardware version, not just the operating system. On these systems, eftest will fail with a bus error until you modify the Makefile to define PAGE_PROTEC- TION_VIOLATED_SIGNAL as SIGBUS. There are, without doubt, other bugs and porting issues. Please contact me via e-mail if you have any bug reports, ideas, etc. WHAT'S BETTER PURIFY, from Purify Systems, does a much better job than Electric Fence, and does much more. It's available at this writing on SPARC systems only, soon on HP. I'm not affili- ated with Purify, I just think it's a wonderful product and you should check it out. 27-April-1993 7 From owner-freebsd-bugs Fri Oct 3 15:10:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA15990 for bugs-outgoing; Fri, 3 Oct 1997 15:10:05 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA15978; Fri, 3 Oct 1997 15:10:01 -0700 (PDT) Resent-Date: Fri, 3 Oct 1997 15:10:01 -0700 (PDT) Resent-Message-Id: <199710032210.PAA15978@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, zach@gaffaneys.com Received: from murkwood.gaffaneys.com (dialup7.gaffaneys.com [208.155.161.57]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA15767 for ; Fri, 3 Oct 1997 15:05:08 -0700 (PDT) Received: (from zach@localhost) by murkwood.gaffaneys.com (8.8.7/8.8.6) id RAA00469; Fri, 3 Oct 1997 17:04:39 -0500 (CDT) Message-Id: <199710032204.RAA00469@murkwood.gaffaneys.com> Date: Fri, 3 Oct 1997 17:04:39 -0500 (CDT) From: Zach Heilig Reply-To: zach@gaffaneys.com To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: kern/4684: crash on very heavy disk activity. Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4684 >Category: kern >Synopsis: crash on very heavy disk activity. >Confidential: no >Severity: critical >Priority: high >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Oct 3 15:10:01 PDT 1997 >Last-Modified: >Originator: Zach Heilig >Organization: none >Release: FreeBSD 2.2-STABLE i386 >Environment: 2.2 stable as of Sept 18. Copyright (c) 1992-1997 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 2.2-STABLE #0: Thu Sep 18 09:44:26 CDT 1997 zach@murkwood.gaffaneys.com:/usr/src/sys/compile/ZACH CPU: Pentium (166.59-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x543 Stepping=3 Features=0x8001bf real memory = 67108864 (65536K bytes) avail memory = 62824448 (61352K bytes) Probing for devices on PCI bus 0: chip0 rev 35 on pci0:0 chip1 rev 37 on pci0:7:0 pci0:7:1: VIA Technologies, device=0x0571, class=storage (ide) [no driver assigned] vga0 rev 0 int a irq 10 on pci0:9 ncr0 rev 1 int a irq 11 on pci0:10 ncr0 waiting for scsi devices to settle (ncr0:0:0): "MICROP 4743NS S162" type 0 fixed SCSI 2 sd0(ncr0:0:0): Direct-Access sd0(ncr0:0:0): 20.0 MB/s (50 ns, offset 15) sd0(ncr0:0:0): M_DISCONNECT received, but datapointer not saved: data=701b4 save=e40016b0 goal=e40016d4. 4100MB (8398656 512 byte sectors) sd0(ncr0:0:0): with 6506 cyls, 7 heads, and an average 184 sectors/track (ncr0:1:0): "QUANTUM FIREBALL_TM2110S 300X" type 0 fixed SCSI 2 sd1(ncr0:1:0): Direct-Access sd1(ncr0:1:0): 20.0 MB/s (50 ns, offset 15) 2014MB (4124736 512 byte sectors) sd1(ncr0:1:0): with 6810 cyls, 4 heads, and an average 151 sectors/track (ncr0:2:0): "iomega jaz 1GB J.83" type 0 removable SCSI 2 sd2(ncr0:2:0): Direct-Access sd2(ncr0:2:0): 10.0 MB/s (100 ns, offset 15) sd2(ncr0:2:0): ILLEGAL REQUEST asc:24,0 Invalid field in CDB sd2 could not mode sense (4). Using ficticious geometry 1021MB (2091050 512 byte sectors) sd2(ncr0:2:0): with 1021 cyls, 64 heads, and an average 32 sectors/track (ncr0:4:0): "SANYO CRD-254S 1.02" type 5 removable SCSI 2 cd0(ncr0:4:0): CD-ROM cd0(ncr0:4:0): asynchronous. can't get the size Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 flags 0x6 on motherboard sc0: VGA color <16 virtual consoles, flags=0x6> sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface pca0 on motherboard pca0: PC speaker audio driver fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 72065B fd0: 1.44MB 3.5in npx0 on motherboard npx0: INT 16 interface joy0 at 0x201 on isa joy0: joystick sb0 at 0x220 irq 5 drq 1 on isa sb0: sbxvi0 at 0x0 drq 5 on isa sbxvi0: sbmidi0 at 0x330 on isa opl0 at 0x388 on isa opl0: WARNING: / was not properly dismounted. sd2(ncr0:2:0): UNIT ATTENTION asc:28,0 sd2(ncr0:2:0): Not ready to ready transition, medium may have changed sd2(ncr0:2:0): ILLEGAL REQUEST asc:24,0 Invalid field in CDB sd2 could not mode sense (4). Using ficticious geometry >Description: Here are the last few console messages before the reboot: sd2(ncr0:2:0): extraneous data discarded. sd2(ncr0:2:0): COMMAND FAILED (9 0) @f078bc00. sd2(ncr0:2:0): extraneous data discarded. sd2(ncr0:2:0); COMMAND FAILED (9 0) @f06b4000. sd2(ncr0:2:0): extraneous data discarded. sd2(ncr0:2:0); COMMAND FAILED (9 0) @f06b4000. sd2(ncr0:2:0): extraneous data discarded. sd2(ncr0:2:0); COMMAND FAILED (9 0) @f06b4000. /src: bad dir ino 145920 at offset 0: mangled entry panic: bad dir syncing disks... 22 22 21 18 14 9 2 2 2 2 2 2 2 2 2 2 2 2 2 2 giving up dumping to dev 30401, offset 131072 dump 64 63 ... 1 succeeded This was during both an rm -rf of a large tree on sd2s1e and a cvs checkout from the cvs repository I keep on that slice. I have more information, if you need to know more. I did keep the core dump around (and logged the fsck for /dev/sd2s1e). >How-To-Repeat: >Fix: >Audit-Trail: >Unformatted: From owner-freebsd-bugs Fri Oct 3 23:30:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA00491 for bugs-outgoing; Fri, 3 Oct 1997 23:30:06 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA00484; Fri, 3 Oct 1997 23:30:04 -0700 (PDT) Resent-Date: Fri, 3 Oct 1997 23:30:04 -0700 (PDT) Resent-Message-Id: <199710040630.XAA00484@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, uhclem.bsd Received: from nemesis.lonestar.org ([204.178.74.200]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id TAA27940 for ; Fri, 3 Oct 1997 19:34:28 -0700 (PDT) Received: by nemesis.lonestar.org (Smail3.1.27.1 #22) id m0xHJmX-000txrC; Fri, 3 Oct 97 21:17 CDT Message-Id: Date: Fri, 3 Oct 97 21:17 CDT From: uhclem.bsd@nemesis.lonestar.org Reply-To: uhclem.bsd To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: kern/4685: Some SCSI retry messages formatted differently - FDIV072 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4685 >Category: kern >Synopsis: Some SCSI retry messages formatted differently - FDIV072 >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Oct 3 23:30:01 PDT 1997 >Last-Modified: >Originator: Frank Durda IV >Organization: None >Release: FreeBSD 2.2.5-971003-BETA >Environment: Pentium 133 system, 128Meg, PCI 2940 or 2940U SCSI, as follows: All entries Oct 3 (and "/kernel" has been stripped for readability) 17:05:11 cabal1: FreeBSD 2.2.5-971003-BETA #0: Fri 16:51:38 CDT 1997 17:05:11 cabal1: uhclem.bsd@handsoff:/usr/src/sys.new/sys/compile/CABAL1 17:05:11 cabal1: CPU: Pentium (132.96-MHz 586-class CPU) 17:05:11 cabal1: Origin = "GenuineIntel" Id = 0x52c Stepping=12 17:05:11 cabal1: Features=0x1bf 17:05:11 cabal1: real memory = 134217728 (131072K bytes) 17:05:11 cabal1: avail memory = 129269760 (126240K bytes) 17:05:11 cabal1: ahc0: aic7880 Single Channel, SCSI Id=7, 16 SCBs 17:05:11 cabal1: (ahc0:0:0): "QUANTUM FIREBALL ST4.3S 0F0C" type 0 fixed SCSI 2 17:05:11 cabal1: sd0(ahc0:0:0): Direct-Access 4136MB (8471232 512 byte sectors) 17:05:11 cabal1: (ahc0:3:0): "SEAGATE ST19171N 0017" type 0 fixed SCSI 2 17:05:11 cabal1: sd1(ahc0:3:0): Direct-Access 8683MB (17783112 512 byte sectors) >Description: For most read (or alleged) errors, the SCSI driver returns a two-line message like this: 18:42:19 cabal1: sd1(ahc0:3:0): RECOVERED ERROR info:0x468f80 asc:17,1 Recovered data with retries field replaceable unit: ea sks:80,1 18:42:19 cabal1: , retries:4 The problem here is that sometimes the second message ", retries:4" gets separated from the first line by one or more lines in the log, particularly on a system receiving syslog info from several terminal servers or other application. This second bit of the SCSI error message should be part of the first message, or the second line should repeat the device information as in "sd1(ahc0:3:0): retries:4". Also, there is at least one similar error message in the SCSI driver that is split across three lines: 19:44:33 cabal1: sd1(ahc0:3:0): RECOVERED ERROR info:0x4b8a77 asc:18,1 19:44:33 cabal1: sd1(ahc0:3:0): Recovered data with error correction & retries applied field replaceable unit: ea sks:80,1 19:44:33 cabal1: , retries:4 I actually think this second layout where the description is on the second line is easier to read, but even in this case the trailing ", retries:4" info needs to be put on the end of one of the other lines. The leading space on the second (and third) lines of the messages should be cleaned up while working in the neighborhood too. >How-To-Repeat: Get the SCSI driver to report some disk errors, or something it thinks are disk errors. >Fix: >Audit-Trail: >Unformatted: From owner-freebsd-bugs Fri Oct 3 23:40:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA01400 for bugs-outgoing; Fri, 3 Oct 1997 23:40:07 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA01382; Fri, 3 Oct 1997 23:40:02 -0700 (PDT) Resent-Date: Fri, 3 Oct 1997 23:40:02 -0700 (PDT) Resent-Message-Id: <199710040640.XAA01382@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, uhclem.bsd Received: from nemesis.lonestar.org ([204.178.74.200]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id UAA00242 for ; Fri, 3 Oct 1997 20:34:24 -0700 (PDT) Received: by nemesis.lonestar.org (Smail3.1.27.1 #22) id m0xHKND-000twaC; Fri, 3 Oct 97 21:55 CDT Message-Id: Date: Fri, 3 Oct 97 21:55 CDT From: uhclem.bsd@nemesis.lonestar.org Reply-To: uhclem.bsd To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: kern/4686: SCSI driver gradually remaps entire drive/false read errors? - FDIV073 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4686 >Category: kern >Synopsis: SCSI driver gradually remaps entire drive/false read errors? - FDIV073 >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Oct 3 23:40:00 PDT 1997 >Last-Modified: >Originator: Frank Durda IV >Organization: None >Release: FreeBSD 2.1-STABLE i386 >Environment: All entries Oct 3 ("/kernel" removed from lines for readability) 17:05:11 cabal1: FreeBSD 2.2.5-971003-BETA #0: Fri 16:51:38 CDT 1997 17:05:11 cabal1: uhclem@handsoff:/usr/src/sys.new/sys/compile/CABAL1 17:05:11 cabal1: CPU: Pentium (132.96-MHz 586-class CPU) 17:05:11 cabal1: Origin = "GenuineIntel" Id = 0x52c Stepping=12 17:05:11 cabal1: Features=0x1bf 17:05:11 cabal1: real memory = 134217728 (131072K bytes) 17:05:11 cabal1: avail memory = 129269760 (126240K bytes) 17:05:11 cabal1: ahc0: aic7880 Single Channel, SCSI Id=7, 16 SCBs 17:05:11 cabal1: (ahc0:0:0): "QUANTUM FIREBALL ST4.3S 0F0C" type 0 fixed SCSI 2 17:05:11 cabal1: sd0(ahc0:0:0): Direct-Access 4136MB (8471232 512 byte sectors) 17:05:11 cabal1: (ahc0:3:0): "SEAGATE ST19171N 0017" type 0 fixed SCSI 2 17:05:11 cabal1: sd1(ahc0:3:0): Direct-Access 8683MB (17783112 512 byte sectors) >Description: On four different (but identical) systems as shown above with different makes of drives, we have been running into a situation where the SCSI driver will get into a mode where it will apparently start remapping bad sectors because of real or imagined media problems. Once in a while, the driver seems to get in a state where it starts substituting one block after another as fast as it can, while at other times, it will go anywhere from two minutes to two hours after the first remapping "event" before it does another and each disk problem from that point on until reboot results in an apparent media reassignment, until there are no spare blocks left. Using a logic analyzer and monitoring the SCSI bus, we found that a SCSI bus RESET (actually two) is performed immediately prior to each message being displayed. This is done even though multiple drives were active, which seems dangerous. Later, when the system is shut down and the Adaptec media scan is run, it finds no errors, OR the errors it does find are not anywhere the block numbers supposedly reassigned. We modified a kernel from a month ago (after the last big batch of changes to the AIC drivers) to simply panic rather than reassign a block, so that we could perform a media scan using the Adaptec diags at that moment. Again, the diags found no flaws, or found some far away from the block number reported in the driver error message. It may be possible that an errant SCSI bus RESET is resulting in other parts of the driver thinking the media is flawed. Another curiosity is that the errors are almost always reported on drives 1 thru 3 in a four drive configuration (usually the highest drive number), or drive 1 in a two drive configuration, regardless of which physical media is placed on that drive select and cable position. This makes us tend to disbelieve the device being blamed even more. Because of the application, 99.5% of disk I/O is to drives other than 0. The media is Quantum 4.3GB Fireballs with high velocity fans blowing directly on their circuit boards (we found that they start mis-handling SCSI commands otherwise), or 9GB Seagate Baracudas. We have cycled through 16 different brand new Quantums during this process and two Seagates. We have used four different 2940 or 2940U SCSI adapters, different cables, power supplies, motherboards (all Intel), and memory. Each type of drive and every drive select has had the opportunity to be the last drive on the cable and be terminated. We have even used discrete termination blocks just to eliminate that. A 250MHz scope and a logic analyzer were used to check for ringing or glitches on the SCSI bus. Note that several of the Quantums became unusable during use in this application, so much so that the Adaptec BIOS could not mark blocks bad (you get the Media-Check red screen) and the BIOS could not perform a low-level format (the command would not even start). These are now collecting dust in the corner. We finally tried using a 1542CP SCSI controller with some of the same drives that had been reporting recoverable read errors on the 2940. The errors stopped during the period when the 1542CP was in use, suggesting that not all of these errors are real, but are actually some sort of problem with the 2940 driver/sequencer. Unfortunately, the 1542 ISA controller is too slow for the application and we really need to use the 2940 PCI speed. Note that running in or out of Ultra mode made no difference to the error rate. We even tried setting all drives to Async mode on the 2940. We still got errors. Note that a disk-exercising application running on a DECstation (using NetBSD) (random writes 10X the system cache size followed by reads and compares) with the same drives doesn't encounter any media problems either. >How-To-Repeat: The application used to kill these drives on the 2940 was Diablo, with drive 0 being the / and /usr partitions and three stripped (ccd driver) 4.3GB Quantum drives or one 9GB Seagate for the /news partition. Failures would begin in as little as two minutes once articles started coming in: 17:05:11 cabal1: FreeBSD 2.2.5-971003-BETA #0: Fri Oct 3 16:51:38 CDT 1997 17:37:40 cabal1 login: ROOT LOGIN (root) ON ttyv0 (Diablo application started here) 18:42:19 cabal1: sd1(ahc0:3:0): RECOVERED ERROR info:0x468f80 asc:17,1 Recovered data with retries field replaceable unit: ea sks:80,1 18:42:19 cabal1: , retries:4 18:48:36 cabal1: sd1(ahc0:3:0): RECOVERED ERROR info:0x8d7c80 asc:17,1 Recovered data with retries field replaceable unit: ea sks:80,1 18:48:36 cabal1: , retries:4 19:36:25 cabal1: sd1(ahc0:3:0): RECOVERED ERROR info:0x8febcc asc:17,1 Recovered data with retries field replaceable unit: d2 sks:80,1 19:36:25 cabal1: , retries:4 19:44:33 cabal1: sd1(ahc0:3:0): RECOVERED ERROR info:0x4b8a77 asc:18,1 19:44:33 cabal1: sd1(ahc0:3:0): Recovered data with error correction & retries applied field replaceable unit: ea sks:80,1 19:44:33 cabal1: , retries:4 20:42:36 cabal1: sd1(ahc0:3:0): RECOVERED ERROR info:0x70ab40 asc:10,0 Id CRC or ECC error field replaceable unit: f1 sks:80,1 20:42:36 cabal1: , retries:4 20:56:03 cabal1: sd1(ahc0:3:0): RECOVERED ERROR info:0x52cc84 asc:17,1 Recovered data with retries field replaceable unit: ea sks:80,1 20:56:03 cabal1: , retries:4 It's 21:15 now. Based on previous tests, drive 1 will accumulate enough of these messages to be reported unusable in roughly 24 hours, at least until I reboot and/or low-level format it. Clearly this problem isn't easy to run into or there would be a lot more people reporting it. I gave this PR a lower priority because of this, even though for this application, this is a killer problem. >Fix: Not known. >Audit-Trail: >Unformatted: From owner-freebsd-bugs Sat Oct 4 00:07:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA02589 for bugs-outgoing; Sat, 4 Oct 1997 00:07:28 -0700 (PDT) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA02569; Sat, 4 Oct 1997 00:07:19 -0700 (PDT) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.8.4/8.8.4) with ESMTP id GAA14906; Sat, 4 Oct 1997 06:31:48 +0200 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.8.6/brasil-1.2) with UUCP id GAA09876; Sat, 4 Oct 1997 06:31:25 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.7/keltia-2.10/nospam) id DAA17652; Sat, 4 Oct 1997 03:58:59 +0200 (CEST) Message-ID: <19971004035858.34857@keltia.freenix.fr> Date: Sat, 4 Oct 1997 03:58:58 +0200 From: Ollivier Robert To: freebsd-bugs@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Electric Fence info (was Re: Bug in malloc/free (was: Memory leak in getservbyXXX?)) References: <199710031817.OAA16814@lakes.dignus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: <199710031817.OAA16814@lakes.dignus.com>; from Thomas David Rivers on Fri, Oct 03, 1997 at 02:17:17PM -0400 X-Operating-System: FreeBSD 3.0-CURRENT Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Thomas David Rivers: > Ok - there seems to be enough interest... Here's the man page > for electric fence (which does the mprotect() trick Jordan mentions): The main problem of EFence is the amount of swap it takes... I tried to run Mutt through it a few months ago and ran out of swap _before_ displaying anything. -- Ollivier ROBERT -=- FreeBSD: There are no limits -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #35: Sun Sep 21 19:28:07 CEST 1997 From owner-freebsd-bugs Sat Oct 4 01:10:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA05528 for bugs-outgoing; Sat, 4 Oct 1997 01:10:04 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA05510; Sat, 4 Oct 1997 01:10:02 -0700 (PDT) Resent-Date: Sat, 4 Oct 1997 01:10:02 -0700 (PDT) Resent-Message-Id: <199710040810.BAA05510@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, muir@ping.idiom.com Received: from ping.idiom.com (idiom-frVT1-gw.sf.tlg.net [140.174.37.22] (may be forged)) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA05026 for ; Sat, 4 Oct 1997 01:00:30 -0700 (PDT) Received: (from muir@localhost) by ping.idiom.com (8.8.5/8.8.5) id BAA12414; Sat, 4 Oct 1997 01:00:25 -0700 (PDT) Message-Id: <199710040800.BAA12414@ping.idiom.com> Date: Sat, 4 Oct 1997 01:00:25 -0700 (PDT) From: David Sharnoff Reply-To: muir@ping.idiom.com To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: kern/4687: ipfw accept ignored. Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4687 >Category: kern >Synopsis: ipfw accept ignored >Confidential: no >Severity: serious >Priority: low >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Oct 4 01:10:01 PDT 1997 >Last-Modified: >Originator: David Sharnoff >Organization: Idiom Consutling >Release: FreeBSD 2.2.2-RELEASE i386 >Environment: A router with lots of rules. I'll send 'em to anyone who is interested. The router is running FreeBSD 2.2.2 RELEASE >Description: I have a rule that passes a packet. I can tell that it passes the packet because the counter goes up by one whenever a packet goes by. I have another rule that rejects packets. Both rules are firing on the same packet. % ipfw -a list | grep 111 13000 24 2016 allow udp from 209.66.121.0/27 to 140.174.82.0/26 111 in via ethb17 13000 0 0 allow udp from 140.174.82.32/27 to 140.174.82.32/27 111 in via ep0 13000 0 0 allow tcp from 140.174.82.0/27 to 140.174.82.0/26 111 in via fxp0 13000 0 0 allow udp from 140.174.82.0/27 to 140.174.82.0/27 111 in via fxp0 13000 24 2016 deny log udp from any to 140.174.82.0/26 111 13500 0 0 allow tcp from 140.174.82.32/27 to 140.174.82.0/26 111 in via ep0 13500 0 0 deny log tcp from any to 140.174.82.0/26 111 I've renumbered the rules in many ways. It behaves the same if both rules (with the 24 2016 count) have the same number or different numbers. >How-To-Repeat: Duplicate the above rules. Send packets. >Fix: >Audit-Trail: >Unformatted: From owner-freebsd-bugs Sat Oct 4 01:36:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA06614 for bugs-outgoing; Sat, 4 Oct 1997 01:36:29 -0700 (PDT) Received: from mail.webspan.net (root@mail.webspan.net [206.154.70.7]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA06609 for ; Sat, 4 Oct 1997 01:36:27 -0700 (PDT) Received: from orion.webspan.net (orion.webspan.net [206.154.70.5]) by mail.webspan.net (WEBSPAN/970608) with ESMTP id CAA11440; Sat, 4 Oct 1997 02:47:27 -0400 (EDT) Received: from orion.webspan.net (localhost [127.0.0.1]) by orion.webspan.net (WEBSPAN/970608) with ESMTP id CAA20896; Sat, 4 Oct 1997 02:47:26 -0400 (EDT) To: dg@root.com cc: Bob Bishop , freebsd-bugs@FreeBSD.ORG From: "Gary Palmer" Subject: Re: kern/4630: buffer_map might become corrupted In-reply-to: Your message of "Mon, 29 Sep 1997 12:14:58 PDT." <199709291914.MAA06285@implode.root.com> Date: Sat, 04 Oct 1997 02:47:26 -0400 Message-ID: <20894.875947646@orion.webspan.net> Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk David Greenman wrote in message ID <199709291914.MAA06285@implode.root.com>: > >Isn't that just a (k)gdb script in a wrapper, run after savecore has done > >its thing? > > kgdb scripting is painfully slow, difficult to write, and not very > flexible. What I'd like to see is a cda that is built along with the kernel > so it's data structures are correct and it stays in sync with the kernel > sources. I'd also like the utility to be able to read the crash dump saved > in swap without having to copy it first to a file (since few people have > the space for large crash dump images). How about the wish-list item of saving only relevant parts of RAM to disk, rather than a complete image? I'm sure wcarchive doesn't have a .5gig swap partition it could dump to if it panics, and a lot of machines these days also don't have a single swap parition that is big enough to hold a full dump... Gary -- Gary Palmer FreeBSD Core Team Member FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info From owner-freebsd-bugs Sat Oct 4 04:40:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA13675 for bugs-outgoing; Sat, 4 Oct 1997 04:40:07 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA13667; Sat, 4 Oct 1997 04:40:02 -0700 (PDT) Date: Sat, 4 Oct 1997 04:40:02 -0700 (PDT) Message-Id: <199710041140.EAA13667@hub.freebsd.org> To: freebsd-bugs Cc: From: "Daniel O'Callaghan" Subject: Re: kern/4687: ipfw accept ignored. Reply-To: "Daniel O'Callaghan" Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The following reply was made to PR kern/4687; it has been noted by GNATS. From: "Daniel O'Callaghan" To: David Sharnoff Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: kern/4687: ipfw accept ignored. Date: Sat, 4 Oct 1997 21:38:13 +1000 (EST) On Sat, 4 Oct 1997, David Sharnoff wrote: > I have a rule that passes a packet. I can tell that it > passes the packet because the counter goes up by one > whenever a packet goes by. > > I have another rule that rejects packets. > > Both rules are firing on the same packet. > > % ipfw -a list | grep 111 > 13000 24 2016 allow udp from 209.66.121.0/27 to 140.174.82.0/26 111 in via ethb17 > 13000 24 2016 deny log udp from any to 140.174.82.0/26 111 If you look at the second rule carefully, you'll see that you have not defined a direction on it. What is happening is that the packet is accepted *in* using the first rule, and denied from leaving (as this is a router) by the second rule. Fix: Add *in* keyword to deny rule (you don't need to specify an interface). Danny /* Daniel O'Callaghan */ /* HiLink Internet danny@hilink.com.au */ /* FreeBSD - works hard, plays hard... danny@freebsd.org */ From owner-freebsd-bugs Sat Oct 4 08:20:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA19616 for bugs-outgoing; Sat, 4 Oct 1997 08:20:04 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA19602; Sat, 4 Oct 1997 08:20:02 -0700 (PDT) Resent-Date: Sat, 4 Oct 1997 08:20:02 -0700 (PDT) Resent-Message-Id: <199710041520.IAA19602@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, kuku@FreeBSD.ORG Received: from Campino.Informatik.RWTH-Aachen.DE (campino.Informatik.RWTH-Aachen.DE [137.226.116.240]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA19342 for ; Sat, 4 Oct 1997 08:12:41 -0700 (PDT) Received: from gil.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.30.2]) by Campino.Informatik.RWTH-Aachen.DE (8.8.7/RBI-Z13) with ESMTP id RAA02230 for ; Sat, 4 Oct 1997 17:10:08 +0200 (MET DST) Received: (from kuku@localhost) by gil.physik.rwth-aachen.de (8.8.5/8.6.9) id RAA11790; Sat, 4 Oct 1997 17:18:21 +0200 (MEST) Message-Id: <199710041518.RAA11790@gil.physik.rwth-aachen.de> Date: Sat, 4 Oct 1997 17:18:21 +0200 (MEST) From: kuku@FreeBSD.ORG Reply-To: kuku@FreeBSD.ORG To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: bin/4688: sys/utsname.h SYS_NMLN 32 too small Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4688 >Category: bin >Synopsis: sys/utsname.h SYS_NMLN 32 too small >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-bugs >State: open >Class: change-request >Submitter-Id: current-users >Arrival-Date: Sat Oct 4 08:20:01 PDT 1997 >Last-Modified: >Originator: Christoph Kukulies >Organization: I.Physikalisches Institut RWTH Aachen >Release: FreeBSD 3.0-CURRENT i386 >Environment: FreeBSD-3.0-current >Description: bootpd gave error: "Can not get my IP address" Built in debugging code revealed that hostname isdn-kukulies.dialup.rwth-aachen.de was longer than 32 chars. >How-To-Repeat: name your host to something longer than 32 chars and enable bootpd in /etc/inetd.conf. kill -HUP inetd. >Fix: affects libc and probably kernel. I don't know if increasing the value of SYS_NMLN to 64 would cure the problem for all possible hostnames in the future but it would decrease the likelyhood that it happens to someone who runs bootpd and has a long hostname. >Audit-Trail: >Unformatted: From owner-freebsd-bugs Sat Oct 4 09:20:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA21873 for bugs-outgoing; Sat, 4 Oct 1997 09:20:40 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA21757; Sat, 4 Oct 1997 09:18:23 -0700 (PDT) From: "Justin T. Gibbs" Received: (from gibbs@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id JAA05568; Sat, 4 Oct 1997 09:18:17 -0700 (PDT) Date: Sat, 4 Oct 1997 09:18:17 -0700 (PDT) Message-Id: <199710041618.JAA05568@freefall.freebsd.org> To: uhclem.bsd@FreeBSD.ORG, gibbs@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG, gibbs@FreeBSD.ORG Subject: Re: kern/4686 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: SCSI driver gradually remaps entire drive/false read errors? - FDIV073 State-Changed-From-To: open-closed State-Changed-By: gibbs State-Changed-When: Sat Oct 4 08:38:51 PDT 1997 State-Changed-Why: Neither the aic7xxx driver nor the generic SCSI layer ever manually remap sectors on a drive. I'd be interested in knowing what code in the aic7xxx driver you modified to remove block reassignment, as that feature doesn't exist. As to the aic7xxx/SCSI layer incorrectly reporting media errors, this just isn't possible. The aic7xxx driver simply returns the sense information that the drive provides, and in this case, it is telling us that it believes it's media is bad. So, if the aic7xxx driver isn't remapping your sectors, who is? The drive will remap sectors automatically if the AWRE (Auto Write Reallocation Enbld) and/or ARRE (Auto Read Reallocation Enbld) bits are set in mode page 0xC, on the drive. I think that Quantum drives ship with these on by default. Why don't these "bad blocks" show up during a "media verify" operation? During a verify, media is accessed via logical block number. When a sector is remapped, you will get the new, remapped, block during the verify, not the original block. If you want to see what blocks were remapped, look at the "Grown Defect List". The SCSI-2 spec tells you how to do this if you don't have a utility that will do it for you. As to your point about bus resets being dangerous if multiple targets are active, this really isn't the case. Bus resets are used to recover devices that don't seem to be responding and the driver/generic SCSI layer can deal with the consequences of a bus reset if the code believes it is necessary. My guess is that the bus reset was performed because some other transaction to the drive was delayed while it attempted internal retries to retreive the bad block. The driver should have attempted to abort the transaction before it threw the bus reset, but that recovery action must have failed. One thing I do know about the FireBall ST is that the currently shipping firmware can become unstable under certain, rapid, seek patterns. I doubt that a 1542 is capable of generating the load required to see this problem. We use these drives in the Pluto Digital Space Recorder and had to work with Quantum for several weeks until they believed that the bug was indeed their fault and tracked the problem down to their servo code. In our case, the drives simply stopped functioning. I don't think anyone here checked the grown defect list to see if the drives were remapping sectors. Unfortunately Pluto is not autorized to release the firmware we've been given, but it was my understanding that this fix would be made available in the next release of the ST firmware. You might try contacting Quantum Tech support to see if you can obatain new firmware in advance. Responsible-Changed-From-To: freebsd-bugs->gibbs Responsible-Changed-By: gibbs Responsible-Changed-When: Sat Oct 4 08:38:51 PDT 1997 Responsible-Changed-Why: My driver. From owner-freebsd-bugs Sat Oct 4 10:00:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA23717 for bugs-outgoing; Sat, 4 Oct 1997 10:00:04 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA23696; Sat, 4 Oct 1997 10:00:01 -0700 (PDT) Date: Sat, 4 Oct 1997 10:00:01 -0700 (PDT) Message-Id: <199710041700.KAA23696@hub.freebsd.org> To: freebsd-bugs Cc: From: David Muir Sharnoff Subject: Re: kern/4687: ipfw accept ignored. Reply-To: David Muir Sharnoff Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The following reply was made to PR kern/4687; it has been noted by GNATS. From: David Muir Sharnoff To: "Daniel O'Callaghan" Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: kern/4687: ipfw accept ignored. Date: Sat, 4 Oct 1997 09:56:43 -0700 (PDT) * > % ipfw -a list | grep 111 * > 13000 24 2016 allow udp from 209.66.121.0/27 to 140.174.82.0/26 111 in via ethb17 * > 13000 24 2016 deny log udp from any to 140.174.82.0/26 111 * * If you look at the second rule carefully, you'll see that you have not * defined a direction on it. What is happening is that the packet is * accepted *in* using the first rule, and denied from leaving (as this is * a router) by the second rule. * * Fix: Add *in* keyword to deny rule (you don't need to specify an interface). Ah, I see! I didn't realize the packet got tested twice. It makes sense in retrospect. Thank you for the clue. -Dave From owner-freebsd-bugs Sat Oct 4 10:20:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA25241 for bugs-outgoing; Sat, 4 Oct 1997 10:20:04 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA25234; Sat, 4 Oct 1997 10:20:01 -0700 (PDT) Resent-Date: Sat, 4 Oct 1997 10:20:01 -0700 (PDT) Resent-Message-Id: <199710041720.KAA25234@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, john@vapornet.com Received: from helium.vapornet.com (root@helium.vapornet.com [208.202.126.112]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA25188 for ; Sat, 4 Oct 1997 10:19:55 -0700 (PDT) Received: from argon.vapornet.com (vapornet.xnet.com [205.243.141.107]) by helium.vapornet.com (8.8.7/VaporServer-v3.0+SpamNot) with ESMTP id MAA10250 for ; Sat, 4 Oct 1997 12:20:17 -0500 (CDT) Received: by argon.vapornet.com (8.8.7/VaporClient-1.1) id MAA04283; Sat, 4 Oct 1997 12:19:41 -0500 (CDT) Message-Id: <199710041719.MAA04283@argon.vapornet.com> Date: Sat, 4 Oct 1997 12:19:41 -0500 (CDT) From: john@vapornet.com Reply-To: john@vapornet.com To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: conf/4689: pick nits in rc.conf Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4689 >Category: conf >Synopsis: rc.conf passes "NO" as a command line flag for mountd >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Oct 4 10:20:00 PDT 1997 >Last-Modified: >Originator: John Preisler >Organization: VaporNet Inc. >Release: FreeBSD 2.2-STABLE i386 >Environment: nfs server chosen in rc.conf. # $Id: rc.conf,v 1.1.2.22 1997/09/30 20:12:33 jkh Exp $ # $Id: rc.network,v 1.1.2.11 1997/09/18 22:47:12 danny Exp $ >Description: rc.conf has as default mountd_flags="NO" which should be changed to either "" or "/etc/exports" because mountd expects an exports file named "NO". Since there is no exports file named NO, it doenst register the service on the network and clients cant mount. >How-To-Repeat: as long as mountd_flags="NO" and nfs_server_enable="YES" the server will fail rpc reg. >Fix: change default config for mountd_flags from "NO" to "" or "/etc/exports" >Audit-Trail: >Unformatted: From owner-freebsd-bugs Sat Oct 4 12:28:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA02546 for bugs-outgoing; Sat, 4 Oct 1997 12:28:07 -0700 (PDT) Received: from smtp.interlog.com (root@smtp.interlog.com [198.53.145.6]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA02541 for ; Sat, 4 Oct 1997 12:28:04 -0700 (PDT) Received: from shell1.interlog.com (saruman@shell1.interlog.com [207.34.202.8]) by smtp.interlog.com (8.8.3/8.7.6) with ESMTP id PAA24211 for ; Sat, 4 Oct 1997 15:27:58 -0400 (EDT) Received: (from saruman@localhost) by shell1.interlog.com (8.8.5/8.8.5) id PAA01110; Sat, 4 Oct 1997 15:27:50 -0400 (EDT) Date: Sat, 4 Oct 1997 15:27:50 -0400 (EDT) From: Nick Popoff To: bugs@FreeBSD.org Subject: Support Request Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-bugs@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hi there. This most likely isn't a bug, but I'm assuming this is the correct address for support issues, rather than 'questions@FreeBSD.org'. I'm having a problem with the install boot floppy on my machine and I was hoping you'd seen something like this before. I'm using FreeBSD 2.1.6 from CD-ROM. My system is a Pentium 120 currently running Win95 on a C drive, with a D drive waiting for FreeBSD. I used the makeflp.bat to create the boot disk. I reboot my machine with the floppy inside. It comes to the Boot: prompt, then continues to boot after a moment. A few seconds later, as it is showing the load in progress (something about reading text) it begins to spam this on the screen and doesn't stop (I let it go for 20 minutes): Error D:0x0 C:14 H:0 S:2 I assumed it was a problem with the floppy I made, so I've tried another, but the same problem occured in the same way. Any ideas? I'd really appreciate help. Also, since I'm sure you're very busy, I'd appreciate any references to mailing lists or appropriate news groups that I might also be able to get help in. Looking forward to using your great OS, Nick From owner-freebsd-bugs Sat Oct 4 13:16:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA04611 for bugs-outgoing; Sat, 4 Oct 1997 13:16:07 -0700 (PDT) Received: from inga.augusta.de (root@inga.augusta.de [193.175.23.65]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id NAA04584 for ; Sat, 4 Oct 1997 13:15:59 -0700 (PDT) Received: from rabbit by inga.augusta.de with uucp (Smail3.1.29.1 #1) id m0xHaan-004d1eC; Sat, 4 Oct 97 22:14 MET DST Received: from augusta.de(really [127.0.0.1]) by rabbit.augusta.de via sendmail with esmtp id for ; Sat, 4 Oct 1997 22:09:45 +0200 (CEST) (Smail-3.2 1996-Jul-4 #1 built DST-May-22) Message-Id: X-Mailer: exmh version 2.0zeta 7/24/97 From: Andreas Kohout X-url: http://www.augusta.de/~shanee/ X-pgp-keyid: 35AEFAE9 X-pgp-fingerprint: 77 2B 33 F6 83 0A EE F8 FD 7D C8 B1 80 3A ED CA X-Mail-Attention: It is forbidden by law to send unwanted mail to this account! To: julian@tfs.com Subject: Regal cd-changer with 5 lunīs Cc: bugs@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Sat, 04 Oct 1997 22:09:44 +0200 Sender: owner-freebsd-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello Julian, itīs not really a bug, but FYI I post it in bugs@freebsd.org, too ... I tried to install my new REGAL CDC-4X 3.00 fife time CD changer, but the kernel canīt recognize all the LUNīs ... scbus0 target 5 lun 0: type 5 removable SCSI 2 So I consult the manīs, LINT and share/doc and found in the handbook the solution: root@rabbit (/sys/scsi)# diff -c scsiconf.c.orig scsiconf.c *** scsiconf.c.orig Sat Oct 4 14:33:26 1997 --- scsiconf.c Sat Oct 4 14:39:31 1997 *************** *** 401,406 **** --- 401,414 ---- T_READONLY, T_READONLY, T_REMOV, "NAKAMICH", "MJ-4*" ,"*", "cd", SC_MORE_LUS }, + /* + * My REGAL CDC-4X 3.00 + * -Shanee + */ + { + T_READONLY, T_READONLY, T_REMOV, "REGAL", "CDC-4*" ,"*", + "cd", SC_MORE_LUS + }, #endif /* !UKTEST */ #endif /* NCD */ #if NWORM > 0 Now it works ... Because Iīm not very happy to patch my living src-tree, I wish that someone commit this patch, pleas ... -- Greetings, Andy --------------------------------------------------------------------------- running FreeBSD-current From owner-freebsd-bugs Sat Oct 4 14:04:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA06623 for bugs-outgoing; Sat, 4 Oct 1997 14:04:28 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA06605; Sat, 4 Oct 1997 14:04:13 -0700 (PDT) From: "Jordan K. Hubbard" Received: (from jkh@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id OAA06701; Sat, 4 Oct 1997 14:04:05 -0700 (PDT) Date: Sat, 4 Oct 1997 14:04:05 -0700 (PDT) Message-Id: <199710042104.OAA06701@freefall.freebsd.org> To: john@vapornet.com, jkh@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: conf/4689 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: rc.conf passes "NO" as a command line flag for mountd State-Changed-From-To: open-closed State-Changed-By: jkh State-Changed-When: Sat Oct 4 14:03:47 PDT 1997 State-Changed-Why: An excellent point - fixed, thanks! From owner-freebsd-bugs Sat Oct 4 15:05:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA09465 for bugs-outgoing; Sat, 4 Oct 1997 15:05:47 -0700 (PDT) Received: from nemesis.lonestar.org ([204.178.74.200]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id PAA09451; Sat, 4 Oct 1997 15:05:39 -0700 (PDT) Received: by nemesis.lonestar.org (Smail3.1.27.1 #22) id m0xHcIt-000twhC; Sat, 4 Oct 97 17:04 CDT Message-Id: Date: Sat, 4 Oct 97 17:04 CDT To: uhclem.bsd@FreeBSD.ORG, gibbs@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG From: uhclem@nemesis.lonestar.org (Frank Durda IV) Sent: Sat Oct 4 1997, 17:04:03 CDT Subject: Re: kern/4686 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk [0]Neither the aic7xxx driver nor the generic SCSI layer ever [0]manually remap sectors on a drive. I'd be interested in knowing [0]what code in the aic7xxx driver you modified to remove block [0]reassignment, as that feature doesn't exist. Ah, serves me right for believing someone else without examining their hack in detail. All they did is cause the kernel to panic when the message about "reassigning" was displayed, probably assuming that further on down in the code, the reassignment was being explicitly done by our driver. (The PR was filed on the driver exactly as it stands in 2.2.5-BETA, with no modifications of any kind.) I must say that the current error message the driver emits certainly implies that reassignment is being performed by *somebody*. Since not all drives do this automatically, I assumed the driver was always doing the work, using the explicit reassign commands that are available. My apologies. Perhaps the kernel error message should be changed to *suggest* that a block reassignment should be done. Almost as proof of what you claim, I got two errors in a row this morning on the Baracuda back-to-back in the same block. If reassignment was being performed, this would imply that the reassigned spare was also bad. With no reassignment being performed, it just hit the same bad block again. [0]As to the aic7xxx/SCSI layer incorrectly reporting media errors, [0]this just isn't possible. The aic7xxx driver simply returns the [0]sense information that the drive provides, and in this case, it [0]is telling us that it believes it's media is bad. Ok, is there an offset difference caused by the partitioning or slicing of the drive? Some of the errors would make sense if that was the case. [0]So, if the aic7xxx driver isn't remapping your sectors, who is? No one, I understand you clearly. Must beat on person who gave me bad info. [0]Why don't these "bad blocks" show up during a "media verify" operation? Ah, but if the Baracudas have it off by default, this would not be explained. It would also not explain a few cases where the Quantums did find blocks exactly at the same block number reported by the driver and the BIOS scan program, assuming the Quauntums are doing reassignment by default. I think something may still be odd here, although it is possible the Adaptec scan program is lying or using an offset (seems unlikely). [0]As to your point about bus resets being dangerous if multiple targets are [0]active, this really isn't the case. Bus resets are used to recover devices [0]that don't seem to be responding and the driver/generic SCSI layer can deal [0]with the consequences of a bus reset if the code believes it is necessary. I am quite familiar with this point (I wrote one of the first, if not the first SCSI driver for a multitasking platform (68000 XENIX) back in 1984 for the old Bernoulli drives. However, I'm also aware that SCSI devices doing write operations are allowed to abort uncleanly in response to the RST signal. This has been in there since the original 1984 SCSI specification drafts. It was put in there to allow tape devices to be aborted during write operations that were repeatedly failing, ie running through half the length of a 9-track tape drive writing permanent gaps over and over as it looked for a good read-back of data just written, which I have seen happen. The same "blow off what you are doing" exists in disk devices. You can end up with incompletely written blocks. The Iomegas used to do it, leaving sectors half written with CRC/ECC data from the previous occupant. I know for a fact that the old CDC SCSI hard disk drives did this too. Granted that SCSI-II provides "soft reset", but the old style (now called "hard reset" in SCSI-II section 6.2.2 if I recall correctly) allows for the blowing-away of operations in progress. Then there is the additional problem of some vendors just not implementing the "soft reset" correctly and they toss their unwritten write cache. Very nasty. Subsequently, the use of the big-hammer (RST signal) really should not be used if any of the drives are performing write operations if at all possible. It should be the last resort. Even if you try to avoid using it during write operations you initiated, there remains problems because drives that are performing automatic error correction, block reassignment and delayed cached writes are performing hidden write operations which can also be aborted "at a bad time" by a bus RESET. [0]One thing I do know about the FireBall ST is that the currently [0]shipping firmware can become unstable under certain, rapid, seek [0]patterns. I doubt that a 1542 is capable of generating the load [0]required to see this problem. Makes sense, but we also see the problems on the Seagate 9GB Baracuda drives too. All the errors in the PR were from one of the Baracudas under load. It is unlikely Seagate and Quantum share much firmware in common. The question of why things eventually go into a loop displaying messages for blocks all over the disk faster than you can read them remains. Unfortunately, the system always dies when this happens and leave me no logs to send. Only the intermittent message failure (as included in the PR) leaves me with any logged evidence. [0]You might try contacting Quantum Tech support to see if you can [0]obatain new firmware in advance. Indeed, we will try beating higher in the Quantum food chain on Monday. Everybody we spoke with to date claimed there were no problems with the drive firmware, there is no newer firmware, your OS is the problem, why aren't you running Windows '95, etc. Sigh. If possible, please send me (via EMAIL) your firms name and the name of any technical contact you had with Quantum, just so I can point them to a part of the company that has heard of problems with the ST drives. Thanks for the reply. Frank Durda IV - only these addresses work:|"The Knights who say "LETNi" | demand... A SEGMENT REGISTER!!!" or |"A what?" These Anti-spam addresses expire Nov. 15th |"LETNi! LETNi! LETNi!" - 1983 From owner-freebsd-bugs Sat Oct 4 16:40:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA13540 for bugs-outgoing; Sat, 4 Oct 1997 16:40:03 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA13462; Sat, 4 Oct 1997 16:39:46 -0700 (PDT) From: "Daniel O'Callaghan" Received: (from danny@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id QAA10550; Sat, 4 Oct 1997 16:39:38 -0700 (PDT) Date: Sat, 4 Oct 1997 16:39:38 -0700 (PDT) Message-Id: <199710042339.QAA10550@freefall.freebsd.org> To: muir@ping.idiom.com, danny@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: kern/4687 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: ipfw accept ignored State-Changed-From-To: open-closed State-Changed-By: danny State-Changed-When: Sat Oct 4 16:37:17 PDT 1997 State-Changed-Why: Closed because there is no problem with ipfw - the packet is tested inbound by the first rule and outbound by the second (no direction specified) rule. From owner-freebsd-bugs Sat Oct 4 18:40:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA18380 for bugs-outgoing; Sat, 4 Oct 1997 18:40:52 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA18370; Sat, 4 Oct 1997 18:40:33 -0700 (PDT) From: Brian Somers Received: (from brian@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id SAA10957; Sat, 4 Oct 1997 18:40:24 -0700 (PDT) Date: Sat, 4 Oct 1997 18:40:24 -0700 (PDT) Message-Id: <199710050140.SAA10957@freefall.freebsd.org> To: yugi@inter.net.il, brian@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG, brian@FreeBSD.ORG Subject: Re: kern/4119 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: can't connect to Win NT 4.0 RAS using MS CHAP and CBCP State-Changed-From-To: open-feedback State-Changed-By: brian State-Changed-When: Sat Oct 4 18:36:39 PDT 1997 State-Changed-Why: Can we re-test this. Peter recently brought ppp up to 2.3.1. Responsible-Changed-From-To: freebsd-bugs->brian Responsible-Changed-By: brian Responsible-Changed-When: Sat Oct 4 18:36:39 PDT 1997 Responsible-Changed-Why: This should be no problem to fix - we've got it working in ppp :-) From owner-freebsd-bugs Sat Oct 4 18:46:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA18625 for bugs-outgoing; Sat, 4 Oct 1997 18:46:43 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA18616; Sat, 4 Oct 1997 18:46:38 -0700 (PDT) From: Brian Somers Received: (from brian@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id SAA11276; Sat, 4 Oct 1997 18:46:29 -0700 (PDT) Date: Sat, 4 Oct 1997 18:46:29 -0700 (PDT) Message-Id: <199710050146.SAA11276@freefall.freebsd.org> To: brian@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG, brian@FreeBSD.ORG Subject: Re: kern/4052 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: VJ compression drops packets with IP+TCP header length > MLEN Responsible-Changed-From-To: freebsd-bugs->brian Responsible-Changed-By: brian Responsible-Changed-When: Sat Oct 4 18:45:31 PDT 1997 Responsible-Changed-Why: I guess I'll have this - nobody else seems to want it.