From owner-freebsd-hackers Sun Oct 19 00:18:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA26384 for hackers-outgoing; Sun, 19 Oct 1997 00:18:06 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (ppp20.portal.net.au [202.12.71.120]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA26348 for ; Sun, 19 Oct 1997 00:15:54 -0700 (PDT) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (localhost [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id QAA01175; Sun, 19 Oct 1997 16:42:10 +0930 (CST) Message-Id: <199710190712.QAA01175@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: "David E. Cross" cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD authentication... In-reply-to: Your message of "Sat, 18 Oct 1997 10:29:58 -0400." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 19 Oct 1997 16:42:08 +0930 From: Mike Smith Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Is anyone working on supporting Kerberos V5 now that it is out, instead of > the kerb-4 eBones packge? This is in -current. > Is there any interest (should there be) to mooving to Pluggabl > Authentication Modules. (Since they are implimented as shared libraries, > that you link in as needed, would we need to rewrite ld.so a bit to ensure > that people couldn't set their LD_LIBRARY_PATH, and then run su to get > full root acces, sans password?) Modules are loaded explicitly, so this is not an issue. See my homepage (http://www.smith.net.au/~mike) for a port of a slightly older version of the Linux-PAM distribution to FreeBSD. There are a number of problems which need to be addressed before PAM can be taken seriously, but these really just require developer time. mike From owner-freebsd-hackers Sun Oct 19 00:54:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA27290 for hackers-outgoing; Sun, 19 Oct 1997 00:54:36 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (ppp20.portal.net.au [202.12.71.120]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA27282 for ; Sun, 19 Oct 1997 00:54:14 -0700 (PDT) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (localhost [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id RAA01382; Sun, 19 Oct 1997 17:16:24 +0930 (CST) Message-Id: <199710190746.RAA01382@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Peter Dufault cc: mdean@best.com (mdean), freebsd-hackers@FreeBSD.ORG Subject: Re: Opinions wanted. In-reply-to: Your message of "Sat, 18 Oct 1997 19:13:30 -0400." <199710182313.TAA23016@hda.hda.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 19 Oct 1997 17:16:20 +0930 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > If an 8255 (digital I/O) 8-bit port is opened via open() call by the user > > as O_RDWR then it becomes an output, It makes little sense to model the 8255 like this. It would be much more sensible to allow open/close and require an ioctl to provide register access. > The system design must arrange to pull the signals high at start > up (if you can, yes I'm mostly software) so that it doesn't turn > on devices. This is impossible with the 8255, as it resets its outputs low whenever the mode byte is changed. It is a most disgusting device indeed. mike From owner-freebsd-hackers Sun Oct 19 01:55:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA28615 for hackers-outgoing; Sun, 19 Oct 1997 01:55:33 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA28609 for ; Sun, 19 Oct 1997 01:55:28 -0700 (PDT) (envelope-from jamil@trojanhorse.ml.org) Received: from localhost (jamil@localhost) by trojanhorse.ml.org (8.8.7/8.8.5) with SMTP id BAA00524; Sun, 19 Oct 1997 01:28:22 -0700 (PDT) Date: Sun, 19 Oct 1997 01:28:22 -0700 (PDT) From: "Jamil J. Weatherbee" To: Mike Smith cc: Peter Dufault , freebsd-hackers@FreeBSD.ORG Subject: Re: Opinions wanted. In-Reply-To: <199710190746.RAA01382@word.smith.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > If an 8255 (digital I/O) 8-bit port is opened via open() call by the user > > > as O_RDWR then it becomes an output, > > It makes little sense to model the 8255 like this. It would be much > more sensible to allow open/close and require an ioctl to provide > register access. I would have to disagree with this, here's how I have it configure itself. O_RDWR or O_WRONLY makes it an output O_RDONLY makes it an input To have to ioctl() it for a basic operation like determining if it is an input or output is just extra work when the open flags describe operation precisely anyway. I have completed my work and debugged it (it took much longer than expected). I would now like to request to have some kernel type person look at it and tell me if I have major league screwed up anything (it works fine in all my tests). From owner-freebsd-hackers Sun Oct 19 02:22:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA29331 for hackers-outgoing; Sun, 19 Oct 1997 02:22:50 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id CAA29317 for ; Sun, 19 Oct 1997 02:22:43 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id LAA20575; Sun, 19 Oct 1997 11:22:41 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id LAA17267; Sun, 19 Oct 1997 11:14:43 +0200 (MET DST) Message-ID: <19971019111443.MO62406@uriah.heep.sax.de> Date: Sun, 19 Oct 1997 11:14:43 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG Cc: tad@csh.rit.edu (Tad Hunt) Subject: Re: libc_r and print... References: <199710190058.UAA26658@jake.csh.rit.edu> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199710190058.UAA26658@jake.csh.rit.edu>; from Tad Hunt on Oct 18, 1997 20:58:39 -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Tad Hunt wrote: > I'm having a problem with the following simple test case > on FreeBSD-2.2-RELEASE when linking with libc_r > % gcc -static foo.c -lc_r > % ./a.out > [ hang in print ] > > When I compile with -static, I am unable to stop a.out from running unless > I signal it with SIGKILL. Works fine in -current. You could analyze the ps output to see what it is waiting for. -- 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-hackers Sun Oct 19 05:24:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA04658 for hackers-outgoing; Sun, 19 Oct 1997 05:24:38 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: (from jmb@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA04645; Sun, 19 Oct 1997 05:24:27 -0700 (PDT) (envelope-from jmb) From: "Jonathan M. Bresler" Message-Id: <199710191224.FAA04645@hub.freebsd.org> Subject: Re: pulling email addresses from freebsd lists To: joerg_wunsch@uriah.heep.sax.de Date: Sun, 19 Oct 1997 05:24:27 -0700 (PDT) Cc: hackers@FreeBSD.ORG In-Reply-To: <19971018143950.GR04030@uriah.heep.sax.de> from "J Wunsch" at Oct 18, 97 02:39:50 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk J Wunsch wrote: > > As Hellmuth Michaelis wrote: > > > I'd vote to disable majordomos feature to send out the complete list of > > memebers, its useless for the normal user anyway. > > This feature has been disabled long ago. the "who" feature was disabled long ago. there is also a "which" feature...a subscriber sends mail with the command "which"...it returns a list of mailing lists that the subscriber is subscribed to. unfortunately, it does not check the subscriber address against the "which" request. so a "which @" returns all the addresses in the mailing lists. "which" has been diabled. jmb From owner-freebsd-hackers Sun Oct 19 06:50:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA07214 for hackers-outgoing; Sun, 19 Oct 1997 06:50:43 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id GAA07209 for ; Sun, 19 Oct 1997 06:50:37 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id PAA23248 for freebsd-hackers@FreeBSD.ORG; Sun, 19 Oct 1997 15:50:35 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id PAA00447; Sun, 19 Oct 1997 15:36:40 +0200 (MET DST) Message-ID: <19971019153639.DJ26052@uriah.heep.sax.de> Date: Sun, 19 Oct 1997 15:36:39 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG Subject: Re: fd.c and Compaq AERO References: X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Alexander Hausner on Sep 11, 1997 14:02:38 +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Alexander Hausner wrote: > There is a problem concerning detection of the pcmcia-floppy > on compaq aero notebooks. I found some entries in the freebsd-questions > archive: Well, this is a heads-up for those who don't read the commit messages (and serves also reference purposes in the list archives): The proposed hack looked too disgusting to me. Instead, i've just committed the code and documentation for a `flags 0x1' to the fdc config line (so it can also be specified from within UserConfig). Setting this flag will pretend a floppy drive 0 of type 1.44 MB, regardless of what the CMOS says. This is supposedly a good enough bandaid for those plagued by the Compaq Aero. -- 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-hackers Sun Oct 19 07:16:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA07997 for hackers-outgoing; Sun, 19 Oct 1997 07:16:09 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (ppp20.portal.net.au [202.12.71.120]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA07991 for ; Sun, 19 Oct 1997 07:16:03 -0700 (PDT) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (localhost [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id XAA00268; Sun, 19 Oct 1997 23:41:20 +0930 (CST) Message-Id: <199710191411.XAA00268@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: "Jamil J. Weatherbee" cc: Mike Smith , Peter Dufault , freebsd-hackers@FreeBSD.ORG Subject: Re: Opinions wanted. In-reply-to: Your message of "Sun, 19 Oct 1997 01:28:22 MST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 19 Oct 1997 23:41:18 +0930 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >>>> If an 8255 (digital I/O) 8-bit port is opened via open() call by the user >>>> as O_RDWR then it becomes an output, >> >> It makes little sense to model the 8255 like this. It would be much >> more sensible to allow open/close and require an ioctl to provide >> register access. > > I would have to disagree with this, here's how I have it configure itself. > > O_RDWR or O_WRONLY makes it an output > O_RDONLY makes it an input I'll reiterate the point, and clarify. It makes little sense to model the 8255 like this, as it is prohibitively restrictive. Each of ports A and B are split in half, and each half can be configured for input or output. You don't make allowance for this mode of operation. You also don't provide for use of the bit-port operations on port C. It makes little sense to model the port like this. If it's worth anything, I have been down this road a number of times with different I/O parts (8255, Z8536, AM29???) and every time the optimal solution has been either a driver which addresses the operational mode of the hardware on the other side of the device, or straight user-mode I/O. > I have completed my work and debugged it (it took much > longer than expected). I would now like to request to have some kernel > type person look at it and tell me if I have major league screwed up > anything (it works fine in all my tests). If it's only going to be used for your application, the fact that it works for you is probably enough. If you're aiming for mainstream integration, you've got a lot more ground to cover. 8) mike From owner-freebsd-hackers Sun Oct 19 07:48:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA09099 for hackers-outgoing; Sun, 19 Oct 1997 07:48:17 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from intercore.com (num1sun.intercore.com [199.181.243.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA09087 for ; Sun, 19 Oct 1997 07:48:11 -0700 (PDT) (envelope-from robin@intercore.com) Received: (robin@localhost) by intercore.com (8.7.1/8.6.4) id KAA24537; Sun, 19 Oct 1997 10:45:11 -0400 (EDT) Message-ID: <19971019104510.16409@num1sun.intercore.com> Date: Sun, 19 Oct 1997 10:45:10 -0400 From: Robin Cutshaw To: "Jordan K. Hubbard" Cc: hackers@FreeBSD.ORG Subject: Re: 48 hours left in 2.2.5 BETA cycle! References: <27616.877235537@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.79 In-Reply-To: <27616.877235537@time.cdrom.com>; from Jordan K. Hubbard on Sat, Oct 18, 1997 at 09:32:17PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, Oct 18, 1997 at 09:32:17PM -0700, Jordan K. Hubbard wrote: > And, as things would have it, Peter has just committed a last minute > syncronization patch with Matt Thomas's latest to the de driver, > meaning that *anyone* with a DC21xxx based card should very definitely > install 2.2.5-971018-BETA from ftp.freebsd.org or one of its mirrors > as soon as possible and let us know if it *doesn't* work. If it does > work, great, you've nothing to worry about for 2.2.5. If it doesn't, > we need to know about it instantly! ;) > Still no joy. The de driver does not correctly detect 100 Mb/s mode and link2 doesn't change anything. robin -- ---- Robin Cutshaw internet: robin@interlabs.com robin@intercore.com Internet Labs, Inc. BellNet: 404-817-9787 robin@XFree86.Org "Time is just one damn thing after another" -- PBS/Nova ---- -- From owner-freebsd-hackers Sun Oct 19 08:26:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA13435 for hackers-outgoing; Sun, 19 Oct 1997 08:26:48 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from intercore.com (num1sun.intercore.com [199.181.243.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA13429 for ; Sun, 19 Oct 1997 08:26:45 -0700 (PDT) (envelope-from robin@intercore.com) Received: (robin@localhost) by intercore.com (8.7.1/8.6.4) id LAA24578; Sun, 19 Oct 1997 11:23:54 -0400 (EDT) Message-ID: <19971019112353.26513@num1sun.intercore.com> Date: Sun, 19 Oct 1997 11:23:53 -0400 From: Robin Cutshaw To: hackers@freebsd.org Subject: fsck problem with 2.2.5-971015-BETA Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.79 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk System: P5-200, 64MB ram, 3 3GB IDE drives, 2 2GB scsi, 4 9GB scsi. "fsck -p" in /etc/rc fails when it gets to the 1st 9GB drive with "cannot alloc 2088961 bytes for statemap". I'm using the dpt_1.2.4 patches to get to the scsi drives. robin -- ---- Robin Cutshaw internet: robin@interlabs.com robin@intercore.com Internet Labs, Inc. BellNet: 404-817-9787 robin@XFree86.Org "Time is just one damn thing after another" -- PBS/Nova ---- -- From owner-freebsd-hackers Sun Oct 19 09:53:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA18492 for hackers-outgoing; Sun, 19 Oct 1997 09:53:59 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id JAA18487 for ; Sun, 19 Oct 1997 09:53:48 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id SAA24824; Sun, 19 Oct 1997 18:51:08 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id SAA00990; Sun, 19 Oct 1997 18:35:51 +0200 (MET DST) Message-ID: <19971019183550.SV35032@uriah.heep.sax.de> Date: Sun, 19 Oct 1997 18:35:50 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Cc: robin@intercore.com (Robin Cutshaw) Subject: Re: fsck problem with 2.2.5-971015-BETA References: <19971019112353.26513@num1sun.intercore.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <19971019112353.26513@num1sun.intercore.com>; from Robin Cutshaw on Oct 19, 1997 11:23:53 -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Robin Cutshaw wrote: > "fsck -p" in /etc/rc fails when it gets to the 1st 9GB drive > with "cannot alloc 2088961 bytes for statemap". ISTR a comment that you need to increase the VM resource limits to fsck large filesystems. -- 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-hackers Sun Oct 19 10:09:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA19042 for hackers-outgoing; Sun, 19 Oct 1997 10:09:17 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from iq.org (proff@profane.iq.org [203.4.184.222]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id KAA19032 for ; Sun, 19 Oct 1997 10:09:07 -0700 (PDT) (envelope-from proff@iq.org) Received: (qmail 1110 invoked by uid 110); 19 Oct 1997 17:08:38 -0000 Date: 19 Oct 1997 17:08:38 -0000 Message-ID: <19971019170838.1109.qmail@iq.org> From: Julian Assange To: freebsd-hackers@freebsd.org Subject: nasty problem with vnode and other disk drivers? Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Surely this can't be correct behavior: # cp /usr/share/dict/words words # head words A a aa aal aalii aam Aani aardvark aardwolf Aaron # vnconfig /dev/vn0 words # dd if=/dev/rvn0 bs=8 count=10 A a aa aA a aa aA a aa aA a aa aA a aa aA a aa aA a aa aA a aa aA a aa aA a aa a10+0 records in 10+0 records out 80 bytes transferred in 0.002210 secs (36199 bytes/sec) # dd if=/dev/vn0 bs=8 count=10 A a aa aal aalii aam Aani aardvark aardwolf Aaron Aaronic Aaronical Aaronite Aar10+0 records in 10+0 records out physio() is passed a uio argument, with an offset into the device. It then builds a struct buf, and calculates b_blkno like so: bp->b_blkno = btodb(uio->uio_offset); (btodb just divides by 512) vn_strategy() is called via physio() with a struct buf * argument (only). vn_strategy() then tries to "rebuild" uio->uio_offset from bp->b_blkno with: auio.uio_offset = dbtob (bp->b_blkno); But the earlier btodb() has of course sliced off the bottem 9 bits in the division - meaning the same data is fetched over and over again, within each 512 byte block. The reason the block device (/dev/vn0) works where the character device fails is that the block device is always accessed in multiples of 2048, regardless of how short the userland read() -- Prof. Julian Assange |If you want to build a ship, don't drum up people |together to collect wood and don't assign them tasks proff@iq.org |and work, but rather teach them to long for the endless proff@gnu.ai.mit.edu |immensity of the sea. -- Antoine de Saint Exupery From owner-freebsd-hackers Sun Oct 19 11:51:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA25215 for hackers-outgoing; Sun, 19 Oct 1997 11:51:02 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id LAA25206 for ; Sun, 19 Oct 1997 11:50:55 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id UAA26468; Sun, 19 Oct 1997 20:50:53 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id UAA01482; Sun, 19 Oct 1997 20:40:19 +0200 (MET DST) Message-ID: <19971019204018.PF25731@uriah.heep.sax.de> Date: Sun, 19 Oct 1997 20:40:18 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG Cc: proff@iq.org (Julian Assange) Subject: Re: nasty problem with vnode and other disk drivers? References: <19971019170838.1109.qmail@iq.org> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <19971019170838.1109.qmail@iq.org>; from Julian Assange on Oct 19, 1997 17:08:38 -0000 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Julian Assange wrote: > physio() is passed a uio argument, with an offset into the device. > It then builds a struct buf, and calculates b_blkno like so: > > bp->b_blkno = btodb(uio->uio_offset); > > (btodb just divides by 512) (and so on) All this nasty shiftomania is subject to be killed some day, for b_blkno should be replaced by a b_offset field (of type off_t). I think a number of (not so unimportant to the project effort :) people already agreed that this is the way to go, so it's only a matter of time, until someone can spend the energy required to make this change, and debug everything. Hopefully, this should still be before 3.0 hits the surface. -- 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-hackers Sun Oct 19 11:54:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA25592 for hackers-outgoing; Sun, 19 Oct 1997 11:54:49 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA25577 for ; Sun, 19 Oct 1997 11:54:42 -0700 (PDT) (envelope-from jamil@trojanhorse.ml.org) Received: from localhost (jamil@localhost) by trojanhorse.ml.org (8.8.7/8.8.5) with SMTP id LAA00646; Sun, 19 Oct 1997 11:54:24 -0700 (PDT) Date: Sun, 19 Oct 1997 11:54:23 -0700 (PDT) From: "Jamil J. Weatherbee" Reply-To: "Jamil J. Weatherbee" To: Mike Smith cc: Peter Dufault , freebsd-hackers@FreeBSD.ORG Subject: Re: Opinions wanted. In-Reply-To: <199710191411.XAA00268@word.smith.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk This particular hardware has 2 8255's (and only the C port can be split), it also only operates in mode 0. And since the point of spliting the c port is so you can have your bits half and half it is not necessary here since there are two 8255's. The board also has change of state interrupts (on all lines) which is why I did this in the first place. Unless you have a better way to pass interrupts through to a user process (I'll immediately throw away all my work and use that). I think criticism is good here but please take a look at the spec sheet first: http://www.indcompsrc.com/products/data/html/dio48s_at-p.html > I'll reiterate the point, and clarify. It makes little sense to model > the 8255 like this, as it is prohibitively restrictive. > > Each of ports A and B are split in half, and each half can be > configured for input or output. You don't make allowance for this mode > of operation. Also it is only port C that can be split not port A and B > You also don't provide for use of the bit-port operations on port C. Set/Reset operations are not supported by this board, that bit is used for tristate enable/disable > If it's only going to be used for your application, the fact that it > works for you is probably enough. If you're aiming for mainstream > integration, you've got a lot more ground to cover. 8) I've been trying my best to make it as general as possible. If you have tangible ideas in terms of functionality after you see the code and spec sheet I'd be happy to add them. From owner-freebsd-hackers Sun Oct 19 12:34:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA27734 for hackers-outgoing; Sun, 19 Oct 1997 12:34:39 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from cleopatra.ultra.net (cleopatra.ultra.net [199.232.56.35]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA27727 for ; Sun, 19 Oct 1997 12:34:33 -0700 (PDT) (envelope-from moncrg@ma.ultranet.com) Received: from moncrg (d8.dial-17.mbo.ma.ultra.net [146.115.100.168]) by cleopatra.ultra.net (8.8.5/ult1.05) with SMTP id PAA11843; Sun, 19 Oct 1997 15:34:19 -0400 (EDT) From: "Gregory D Moncreaff" To: "Hackers FreeBSD" , "Terry Lambert" Subject: Re: [Q] Is recvmsg for ancillary (control) data part of protocol or generic sockets? Date: Sun, 19 Oct 1997 14:32:34 -0400 Message-ID: <01bcdcbd$5e351cc0$a8647392@moncrg> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0103_01BCDC9B.D7237CC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0103_01BCDC9B.D7237CC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit -----Original Message----- From: Terry Lambert To: Gregory D Moncreaff Cc: hackers@FreeBSD.ORG Date: Friday, October 17, 1997 4:00 PM Subject: Re: [Q] Is recvmsg for ancillary (control) data part of protocol or generic sockets? >> was looking at design and implementation 4.4 and >> there was a PRU_RECV, PRU_RECVOOB but no >> PRU_RECVCTL. >> >> just wondering how the control data gets from the >> protocol to the user.... > >man recvmsg. > >The control and data parts are retrieved simultaneously. > > > Terry Lambert > terry@lambert.org >--- >Any opinions in this posting are my own and not those of my present >or previous employers. > I eventually found the code in kern/uipc_socket.c:soreceive() There seems to be a problem with connection oriented protocols getting disconnect data since soreceive checks PR_CONNREQUIRED and aborts before checking to see if control data is present. Is this by accident or design? PR_CONNREQUIRED is only supposed to gate send according to sys/protosw.h... if (m == 0 || (( ..... ..... if ((so->so_state & (SS_ISCONNECTED|SS_ISCONNECTING)) == 0 && (so->so_proto->pr_flags & PR_CONNREQUIRED)) { error = ENOTCONN; goto release; ..... while (m && m->m_type == MT_CONTROL && error == 0) { if (flags & MSG_PEEK) { if (controlp) *controlp = m_copy(m, 0, m->m_len); m = m->m_next; ..... release: sbunlock(&so->so_rcv); splx(s); return (error); ===================================================================== Gregory D. Moncreaff Phone 1-508-490-2048 Raytheon Electronic Systems Fax 1-508-490-2086 Gregory_D_Moncreaff@res.raytheon.com Home moncrg@ma.ultranet.com --------------------------------------------------------------------- ------=_NextPart_000_0103_01BCDC9B.D7237CC0 Content-Type: text/x-vcard; name="Gregory Donald Moncreaff.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Gregory Donald Moncreaff.vcf" BEGIN:VCARD N:Moncreaff;Gregory;Donald FN:Gregory Donald Moncreaff EMAIL;PREF;INTERNET:moncrg@ma.ultranet.com END:VCARD ------=_NextPart_000_0103_01BCDC9B.D7237CC0-- From owner-freebsd-hackers Sun Oct 19 12:40:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA28186 for hackers-outgoing; Sun, 19 Oct 1997 12:40:35 -0700 (PDT) (envelope-from owner-freebsd-hackers) 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 MAA28177 for ; Sun, 19 Oct 1997 12:40:30 -0700 (PDT) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.7/8.8.5) id OAA04475; Sun, 19 Oct 1997 14:39:00 -0500 (EST) From: "John S. Dyson" Message-Id: <199710191939.OAA04475@dyson.iquest.net> Subject: Re: nasty problem with vnode and other disk drivers? In-Reply-To: <19971019170838.1109.qmail@iq.org> from Julian Assange at "Oct 19, 97 05:08:38 pm" To: proff@iq.org (Julian Assange) Date: Sun, 19 Oct 1997 14:39:00 -0500 (EST) Cc: freebsd-hackers@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-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Julian Assange said: > > > Surely this can't be correct behavior: > > # cp /usr/share/dict/words words > # head words > A > a > aa > aal > aalii > aam > Aani > aardvark > aardwolf > Aaron > # vnconfig /dev/vn0 words > # dd if=/dev/rvn0 bs=8 count=10 > A > a > aa > aA > a > aa > aA > a > aa > It isn't expected behavior, but raw, block devices currently need I/O on 512 byte boundarys for integrals of 512 byte lengths. John From owner-freebsd-hackers Sun Oct 19 15:43:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA06428 for hackers-outgoing; Sun, 19 Oct 1997 15:43:13 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from citrine.cyberstation.net (citrine.cyberstation.net [205.167.0.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA06420 for ; Sun, 19 Oct 1997 15:42:58 -0700 (PDT) (envelope-from hannibal@cyberstation.net) Received: from localhost (hannibal@localhost) by citrine.cyberstation.net (8.8.7/8.8.7) with SMTP id RAA23371 for ; Sun, 19 Oct 1997 17:42:46 -0500 (CDT) Date: Sun, 19 Oct 1997 17:42:46 -0500 (CDT) From: Dan Walters To: hackers@freebsd.org Subject: ATAPI CD-RW documentation... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I just ordered a EIDE CD-RW (all the 4x models I could find were EIDE, and if hard drives are any indication I bet most CD-RWs will probably be EIDE soon) and of course would like to use it under FreeBSD. I don't even see anything looking like support for it under Linux, which really surprised me. I'd be interested in at least attempting to implement some support for it. Can someone tell me where I could get my hands on some sort of programmer's guide or manual for these? Would the specifics for a CD-RW actually be covered in the ATAPI specs from WD? ====================================================================== Dan Walters hannibal@cyberstation.net ====================================================================== From owner-freebsd-hackers Sun Oct 19 15:48:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA06694 for hackers-outgoing; Sun, 19 Oct 1997 15:48:42 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from eps.ufsc.br (eps.ufsc.br [150.162.1.50]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA06687 for ; Sun, 19 Oct 1997 15:48:33 -0700 (PDT) (envelope-from george@eps.ufsc.br) Received: from localhost (d51.ad.eps.ufsc.br [150.162.46.51]) by eps.ufsc.br (8.8.6/8.7.3) with SMTP id VAA29503 for ; Sun, 19 Oct 1997 21:46:04 -0200 (EDT) Date: Sun, 19 Oct 1997 20:47:46 -0200 (EDT) From: George Tavares X-Sender: george@localhost To: freebsd-hackers@FreeBSD.ORG Subject: PThread Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I was using pthread (libc_r) packages I like to know if this package is the same from MIT (MIT pthread). When I running a pthread application, I press ^C and it doesn't kill my application (running same program im Solaris it works). The signals aren't passed to application? Another think, how I know what function are MT-SAFE. I don't see nothing about this in the man's. Why it is not compiled in make world? Many bugs? ----------------------------------------------------------------------- | George Tavares Ciencias da Computacao - UFSC | | Fone:(048)331-7020 E-mail: george@eps.ufsc.br | | http://www.eps.ufsc.br/~george PGP key disponivel por http | ----------------------------------------------------------------------- From owner-freebsd-hackers Sun Oct 19 16:09:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA07672 for hackers-outgoing; Sun, 19 Oct 1997 16:09:25 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from citrine.cyberstation.net (hannibal@citrine.cyberstation.net [205.167.0.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA07667 for ; Sun, 19 Oct 1997 16:09:19 -0700 (PDT) (envelope-from hannibal@cyberstation.net) Received: from localhost (hannibal@localhost) by citrine.cyberstation.net (8.8.7/8.8.7) with SMTP id SAA25842 for ; Sun, 19 Oct 1997 18:09:07 -0500 (CDT) Date: Sun, 19 Oct 1997 18:09:07 -0500 (CDT) From: Dan Walters To: hackers@freebsd.org Subject: Re: ATAPI CD-RW documentation... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Never mind, it's amazing how you always find things right after you give up and ask. :) For anyone wondering, the motherload of specs can be found by ftp at fission.dt.wdc.com, including the working draft of the ATAPI Removable Rewritable Specification, SFF-8070. Wish their web pages would mention the site. :) So, has anyone already began work on this, or should I go ahead and give it a shot when my drive gets in? ====================================================================== Dan Walters hannibal@cyberstation.net ====================================================================== From owner-freebsd-hackers Sun Oct 19 16:40:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA09175 for hackers-outgoing; Sun, 19 Oct 1997 16:40:33 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA09170 for ; Sun, 19 Oct 1997 16:40:30 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.8.7/8.8.5) with ESMTP id QAA01433; Sun, 19 Oct 1997 16:40:01 -0700 (PDT) Message-Id: <199710192340.QAA01433@rah.star-gate.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: George Tavares cc: freebsd-hackers@FreeBSD.ORG Subject: Re: PThread In-reply-to: Your message of "Sun, 19 Oct 1997 20:47:46 -0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 19 Oct 1997 16:40:01 -0700 From: Amancio Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The default on FreeBSD 3.0-current is to build libc_r. libc_r is not that the same a Provenzo's pthread package a couple of years ago when I was interested on threads for FreeBSD provenzo's pthread package was buggier than libc_r. control-c is trap by thread package and a little ago there where patches submitted to the list to fix this condition. Amancio > > I was using pthread (libc_r) packages I like to know if this > package is the same from MIT (MIT pthread). > When I running a pthread application, I press ^C and it doesn't > kill my application (running same program im Solaris it works). The > signals aren't passed to application? > Another think, how I know what function are MT-SAFE. I don't see > nothing about this in the man's. > Why it is not compiled in make world? Many bugs? > > > ----------------------------------------------------------------------- > | George Tavares Ciencias da Computacao - UFSC | > | Fone:(048)331-7020 E-mail: george@eps.ufsc.br | > | http://www.eps.ufsc.br/~george PGP key disponivel por http | > ----------------------------------------------------------------------- > > From owner-freebsd-hackers Sun Oct 19 16:43:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA09336 for hackers-outgoing; Sun, 19 Oct 1997 16:43:45 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from fly.HiWAAY.net (root@fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA09331 for ; Sun, 19 Oct 1997 16:43:43 -0700 (PDT) (envelope-from dkelly@nospam.hiwaay.net) Received: from nospam.hiwaay.net (tnt2-182.HiWAAY.net [208.147.148.182]) by fly.HiWAAY.net (8.8.7/8.8.6) with ESMTP id SAA30366; Sun, 19 Oct 1997 18:43:36 -0500 (CDT) Received: from nospam.hiwaay.net (localhost [127.0.0.1]) by nospam.hiwaay.net (8.8.7/8.8.4) with ESMTP id SAA11486; Sun, 19 Oct 1997 18:43:34 -0500 (CDT) Message-Id: <199710192343.SAA11486@nospam.hiwaay.net> X-Mailer: exmh version 2.0zeta 7/24/97 To: Dan Walters cc: hackers@FreeBSD.ORG From: dkelly@hiwaay.net Subject: Re: ATAPI CD-RW documentation... In-reply-to: Message from Dan Walters of "Sun, 19 Oct 1997 17:42:46 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 19 Oct 1997 18:43:32 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I just ordered a EIDE CD-RW (all the 4x models I could find were EIDE, and > if hard drives are any indication I bet most CD-RWs will probably be EIDE > soon) Really? EIDE? I've never seen a CR-R (not re-writable) EIDE but wouldn't venture to claim they don't exist. If you want to find good SCSI stuff, look in the Macintosh magazines. SCSI CD-RW's are fairly easy to find there, EIDE models are not. Prices for SCSI in the Mac magazines are usually way under Computer Shopper prices. SCSI CD-RW's are fairly easy to find there, EIDE models are not. -- David Kelly N4HHE, dkelly@hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. From owner-freebsd-hackers Sun Oct 19 16:55:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA10005 for hackers-outgoing; Sun, 19 Oct 1997 16:55:25 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA10000 for ; Sun, 19 Oct 1997 16:55:22 -0700 (PDT) (envelope-from jamil@trojanhorse.ml.org) Received: from localhost (jamil@localhost) by trojanhorse.ml.org (8.8.7/8.8.5) with SMTP id QAA02799; Sun, 19 Oct 1997 16:55:15 -0700 (PDT) Date: Sun, 19 Oct 1997 16:55:15 -0700 (PDT) From: "Jamil J. Weatherbee" Reply-To: "Jamil J. Weatherbee" To: freebsd-hackers@freebsd.org cc: jkh@time.cdrom.com Subject: Device Driver Submission Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I wish to submit my device driver. Its name is "dio". I have written a man page for it and have debugged it extensively. It drives a digital i/o board that supports only mode 0 on the intel 8255 PPI. It supports change of state interrupts on all inputs (this is a feature not found in other boards). This type of hardware is commonly used to drive solid state relays, for instance I have some backplanes and relays that will allow you to do high current AC or DC switching. The change of state interrupts might be used anywhere you are waiting for some event to occur (such as an an alarm system or an industrial machine that must do limit detection.) The driver is about 500 lines, I have tested it to make sure that its devfs hooks work correctly (DEVFS btw is pretty cool) and is well documented. I'd like to know how this is usually done, especially since this does not support some kind of critical system that would adversely effect stability. In other words it is very special-purpose. for specs see: http://www.indcompsrc.com/products/data/html/dio48s_at-p.html I've been considering buying some of this hardware to do home automation. For instance if you want to control some 0-60volt 3AMP dc signals a backplane with 24 Solid State Relays runs about $400. The board itself costs $260. I've used them on many different projects. From owner-freebsd-hackers Sun Oct 19 17:13:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA11203 for hackers-outgoing; Sun, 19 Oct 1997 17:13:53 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from gaia.coppe.ufrj.br ([146.164.5.200]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA11198 for ; Sun, 19 Oct 1997 17:13:41 -0700 (PDT) (envelope-from jonny@coppe.ufrj.br) Received: (from jonny@localhost) by gaia.coppe.ufrj.br (8.8.7/8.8.7) id WAA14748; Sun, 19 Oct 1997 22:13:27 -0200 (EDT) (envelope-from jonny) From: Joao Carlos Mendes Luis Message-Id: <199710200013.WAA14748@gaia.coppe.ufrj.br> Subject: Re: PThread In-Reply-To: from George Tavares at "Oct 19, 97 08:47:46 pm" To: george@eps.ufsc.br (George Tavares) Date: Sun, 19 Oct 1997 22:13:27 -0200 (EDT) Cc: freebsd-hackers@FreeBSD.ORG 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-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk #define quoting(George Tavares) // I was using pthread (libc_r) packages I like to know if this // package is the same from MIT (MIT pthread). // When I running a pthread application, I press ^C and it doesn't // kill my application (running same program im Solaris it works). The // signals aren't passed to application? // Another think, how I know what function are MT-SAFE. I don't see // nothing about this in the man's. // Why it is not compiled in make world? Many bugs? One professor here at UFRJ had a program with pthreads that worked with Solaris and froze with FreeBSD. Even ^C did not break the running code. Only SIGKILL could stop it. I took a look at the program at it was simply a problem with not initialized pointers. Compile your code with -Wall and see if it helps. I think libc_r is not default because most applications do not need it and would waste CPU for nothing. Jonny PS: I really wonder how Solaris can run wrong code and do not complain at all... :) -- Joao Carlos Mendes Luis jonny@gta.ufrj.br +55 21 290-4698 jonny@coppe.ufrj.br Universidade Federal do Rio de Janeiro UFRJ/COPPE/CISI PGP fingerprint: 29 C0 50 B9 B6 3E 58 F2 83 5F E3 26 BF 0F EA 67 From owner-freebsd-hackers Sun Oct 19 17:16:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA11397 for hackers-outgoing; Sun, 19 Oct 1997 17:16:11 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from pahtoh.cwu.edu (root@pahtoh.cwu.edu [198.104.65.27]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA11246; Sun, 19 Oct 1997 17:14:55 -0700 (PDT) (envelope-from skynyrd@opus.cts.cwu.edu) Received: from opus.cts.cwu.edu (skynyrd@opus.cts.cwu.edu [198.104.92.71]) by pahtoh.cwu.edu (8.8.7/8.8.7) with ESMTP id RAA18645; Sun, 19 Oct 1997 17:14:53 -0700 (PDT) Received: from localhost (skynyrd@localhost) by opus.cts.cwu.edu (8.8.7/8.8.7) with SMTP id RAA09457; Sun, 19 Oct 1997 17:14:52 -0700 (PDT) Date: Sun, 19 Oct 1997 17:14:52 -0700 (PDT) From: Chris Timmons Reply-To: Chris Timmons To: Robin Cutshaw cc: "Jordan K. Hubbard" , Peter Wemm , hackers@FreeBSD.ORG Subject: New de driver in 2.2.5-BETA In-Reply-To: <19971019104510.16409@num1sun.intercore.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk link2 won't ever help you again - see de(4). I am running DEC DE500-XA cards. I built the world and the kernel a couple of hours ago, and adding "media 100baseTX" achieves the desired result (ie in place of link2 in the ifconfig for that interface.) One de driver difference between -current and 2.2.5-beta is that -current's ifconfig always shows you the media options, while 2.2.5-beta does so only if you say 'ifconfig -m', the documented behavior for both -stable and -current. I'm not sure if it is a feature or bug, but if your interface is ifconfig'ed when there is no carrier present (eg. first machine up on a crossover cable), ifconfig will tell you that there is no carrier even after link is established: 2.2.5-beta> ifconfig de0 de0: flags=8843 mtu 1500 inet 192.168.1.9 netmask 0xfffffff8 broadcast 192.168.1.15 ether 00:00:f8:01:10:ad media: 100baseTX status: no carrier current> ifconfig de0 de0: flags=8843 mtu 1500 inet 192.168.1.10 netmask 0xfffffff8 broadcast 192.168.1.15 ether 00:00:f8:01:12:e8 media: 100baseTX status: no carrier supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP Other than that the updated driver appears to work fine on the DE500, -current and 2.2.5-beta -Chris On Sun, 19 Oct 1997, Robin Cutshaw wrote: > On Sat, Oct 18, 1997 at 09:32:17PM -0700, Jordan K. Hubbard wrote: > > And, as things would have it, Peter has just committed a last minute > > syncronization patch with Matt Thomas's latest to the de driver, > > meaning that *anyone* with a DC21xxx based card should very definitely > > install 2.2.5-971018-BETA from ftp.freebsd.org or one of its mirrors > > as soon as possible and let us know if it *doesn't* work. If it does > > work, great, you've nothing to worry about for 2.2.5. If it doesn't, > > we need to know about it instantly! ;) > > > > Still no joy. The de driver does not correctly detect 100 Mb/s mode > and link2 doesn't change anything. > > robin > -- > ---- > Robin Cutshaw internet: robin@interlabs.com robin@intercore.com > Internet Labs, Inc. BellNet: 404-817-9787 robin@XFree86.Org > > "Time is just one damn thing after another" -- PBS/Nova > ---- > -- > From owner-freebsd-hackers Sun Oct 19 18:09:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA14564 for hackers-outgoing; Sun, 19 Oct 1997 18:09:55 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from iq.org (proff@profane.iq.org [203.4.184.222]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id SAA14528 for ; Sun, 19 Oct 1997 18:09:26 -0700 (PDT) (envelope-from proff@iq.org) From: proff@iq.org Received: (qmail 4636 invoked by uid 110); 20 Oct 1997 01:09:10 -0000 Message-ID: <19971020010910.4635.qmail@iq.org> Subject: Re: nasty problem with vnode and other disk drivers? In-Reply-To: <199710191939.OAA04475@dyson.iquest.net> from "John S. Dyson" at "Oct 19, 97 02:39:00 pm" To: toor@dyson.iquest.net (John S. Dyson) Date: Mon, 20 Oct 1997 11:09:09 +1000 (EST) Cc: proff@iq.org, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > From toor@dyson.iquest.net Sun Oct 19 19:40:17 1997 > Delivered-To: proff@iq.org > From: "John S. Dyson" > Message-Id: <199710191939.OAA04475@dyson.iquest.net> > Subject: Re: nasty problem with vnode and other disk drivers? > In-Reply-To: <19971019170838.1109.qmail@iq.org> from Julian Assange at "Oct 19, 97 05:08:38 pm" > To: proff@iq.org (Julian Assange) > Date: Sun, 19 Oct 1997 14:39:00 -0500 (EST) > Cc: freebsd-hackers@FreeBSD.ORG > X-Mailer: ELM [version 2.4ME+ PL31 (25)] > Julian Assange said: > > > > > > Surely this can't be correct behavior: > > > > # cp /usr/share/dict/words words > > # head words > > A > > a > > aa > > aal > > aalii > > aam > > Aani > > aardvark > > aardwolf > > Aaron > > # vnconfig /dev/vn0 words > > # dd if=/dev/rvn0 bs=8 count=10 > > A > > a > > aa > > aA > > a > > aa > > aA > > a > > aa > > > It isn't expected behavior, but raw, block devices currently need I/O on > 512 byte boundarys for integrals of 512 byte lengths. > > John > > > /dev/rvn0 is a character device. /dev/vn0 is the block device. From owner-freebsd-hackers Sun Oct 19 18:23:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA15244 for hackers-outgoing; Sun, 19 Oct 1997 18:23:09 -0700 (PDT) (envelope-from owner-freebsd-hackers) 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 SAA15236 for ; Sun, 19 Oct 1997 18:23:01 -0700 (PDT) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.7/8.8.5) id UAA05647; Sun, 19 Oct 1997 20:21:26 -0500 (EST) From: "John S. Dyson" Message-Id: <199710200121.UAA05647@dyson.iquest.net> Subject: Re: nasty problem with vnode and other disk drivers? In-Reply-To: <19971020010910.4635.qmail@iq.org> from "proff@iq.org" at "Oct 20, 97 11:09:09 am" To: proff@iq.org Date: Sun, 19 Oct 1997 20:21:26 -0500 (EST) Cc: freebsd-hackers@FreeBSD.ORG Reply-To: dyson@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-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk proff@iq.org said: > > > > > It isn't expected behavior, but raw, block devices currently need I/O on > > 512 byte boundarys for integrals of 512 byte lengths. > > > > John > > > > > > > > /dev/rvn0 is a character device. /dev/vn0 is the block device. > I understand, as I said (raw, block device) is a type of character device. So is a tty. Try seeking on a tty -- it won't skip characters, but it is possible to implement. Such (raw, block device) types usually support aligned transfers only (even on some SVR4 derivatives.) If you want to do unaligned transfers, it is best to do some buffering. There might be something coming along in the future, but not now. -- John dyson@freebsd.org jdyson@nc.com From owner-freebsd-hackers Sun Oct 19 18:33:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA15816 for hackers-outgoing; Sun, 19 Oct 1997 18:33:06 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from intercore.com (num1sun.intercore.com [199.181.243.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA15810 for ; Sun, 19 Oct 1997 18:33:00 -0700 (PDT) (envelope-from robin@intercore.com) Received: (robin@localhost) by intercore.com (8.7.1/8.6.4) id VAA25193; Sun, 19 Oct 1997 21:29:59 -0400 (EDT) Message-ID: <19971019212958.33788@num1sun.intercore.com> Date: Sun, 19 Oct 1997 21:29:58 -0400 From: Robin Cutshaw To: Joerg Wunsch Cc: hackers@FreeBSD.ORG Subject: Re: fsck problem with 2.2.5-971015-BETA References: <19971019112353.26513@num1sun.intercore.com> <19971019183550.SV35032@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.79 In-Reply-To: <19971019183550.SV35032@uriah.heep.sax.de>; from J Wunsch on Sun, Oct 19, 1997 at 06:35:50PM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, Oct 19, 1997 at 06:35:50PM +0200, J Wunsch wrote: > As Robin Cutshaw wrote: > > > "fsck -p" in /etc/rc fails when it gets to the 1st 9GB drive > > with "cannot alloc 2088961 bytes for statemap". > > ISTR a comment that you need to increase the VM resource limits to > fsck large filesystems. > Why does the fsck work correctly once the system is up in multi-user mode? robin -- ---- Robin Cutshaw internet: robin@interlabs.com robin@intercore.com Internet Labs, Inc. BellNet: 404-817-9787 robin@XFree86.Org "Time is just one damn thing after another" -- PBS/Nova ---- -- From owner-freebsd-hackers Sun Oct 19 18:40:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA16255 for hackers-outgoing; Sun, 19 Oct 1997 18:40:55 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA16249 for ; Sun, 19 Oct 1997 18:40:47 -0700 (PDT) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (localhost.gsoft.com.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id LAA00451; Mon, 20 Oct 1997 11:07:31 +0930 (CST) Message-Id: <199710200137.LAA00451@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Dan Walters cc: hackers@freebsd.org Subject: Re: ATAPI CD-RW documentation... In-reply-to: Your message of "Sun, 19 Oct 1997 17:42:46 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 20 Oct 1997 11:07:30 +0930 From: Mike Smith Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I just ordered a EIDE CD-RW (all the 4x models I could find were EIDE, and > if hard drives are any indication I bet most CD-RWs will probably be EIDE > soon) and of course would like to use it under FreeBSD. I don't even see > anything looking like support for it under Linux, which really surprised > me. I'd be interested in at least attempting to implement some support > for it. Can someone tell me where I could get my hands on some sort of > programmer's guide or manual for these? Would the specifics for a CD-RW > actually be covered in the ATAPI specs from WD? What you have basically bought is a SCSI device with an IDE connector. If you're serious about hacking on ATAPI support for FreeBSD, you will want to grab the relevant specifications documents (I've got most of them at ftp://ftp.smith.net.au/doc/ATAPI,CAM) and Justin Gibbs' CAM work (from ftp://ftp.freebsd.org/pub/FreeBSD/incoming/cam-*). Kenneth Merry and I were discussing this the last week or so; I can send you various excerpts and some useful diagrams that came out of that if you're interested. mike From owner-freebsd-hackers Sun Oct 19 18:46:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA16654 for hackers-outgoing; Sun, 19 Oct 1997 18:46:30 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from mother.sneaker.net.au (akm@mother.sneaker.net.au [203.30.3.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA16641 for ; Sun, 19 Oct 1997 18:46:23 -0700 (PDT) (envelope-from akm@mother.sneaker.net.au) Received: (from akm@localhost) by mother.sneaker.net.au (8.8.5/8.8.5) id LAA06957; Mon, 20 Oct 1997 11:54:28 GMT From: Andrew Kenneth Milton Message-Id: <199710201154.LAA06957@mother.sneaker.net.au> Subject: Re: PThread To: jonny@coppe.ufrj.br (Joao Carlos Mendes Luis) Date: Mon, 20 Oct 1997 11:54:28 +0000 () Cc: george@eps.ufsc.br, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199710200013.WAA14748@gaia.coppe.ufrj.br> from "Joao Carlos Mendes Luis" at Oct 19, 97 10:13:27 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk +-----[ Joao Carlos Mendes Luis ]------------------------------ | | PS: I really wonder how Solaris can run wrong code and do not | complain at all... :) I'll drift off topic here and just say, that HPUX lets you dereference NULL pointers as many times as you want, without skipping a beat. They always return NULL though, not random data, so I suppose it's an alternative form of robustness. -- ,-_|\ SneakerNet | Andrew Milton | GSM: +61(41)6 022 411 / \ P.O. Box 154 | akm@sneaker.net.au | Fax: +61(2) 9746 8233 \_,-._/ N Strathfield +--+----------------------+---+ Ph: +61(2) 9746 8233 v NSW 2137 | Low cost Internet Solutions | From owner-freebsd-hackers Sun Oct 19 18:53:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA17127 for hackers-outgoing; Sun, 19 Oct 1997 18:53:35 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from intercore.com (num1sun.intercore.com [199.181.243.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA16700; Sun, 19 Oct 1997 18:47:09 -0700 (PDT) (envelope-from robin@intercore.com) Received: (robin@localhost) by intercore.com (8.7.1/8.6.4) id VAA25218; Sun, 19 Oct 1997 21:42:59 -0400 (EDT) Message-ID: <19971019214258.62172@num1sun.intercore.com> Date: Sun, 19 Oct 1997 21:42:58 -0400 From: Robin Cutshaw To: Chris Timmons Cc: Robin Cutshaw , "Jordan K. Hubbard" , Peter Wemm , hackers@FreeBSD.ORG Subject: Re: New de driver in 2.2.5-BETA References: <19971019104510.16409@num1sun.intercore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.79 In-Reply-To: ; from Chris Timmons on Sun, Oct 19, 1997 at 05:14:52PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, Oct 19, 1997 at 05:14:52PM -0700, Chris Timmons wrote: > > I am running DEC DE500-XA cards. I built the world and the kernel a > couple of hours ago, and adding "media 100baseTX" achieves the desired > result (ie in place of link2 in the ifconfig for that interface.) > Correct you are. With "media 100baseTX" it works (even with the 971015 kernel). Looks like autosense is not working. robin From owner-freebsd-hackers Sun Oct 19 18:58:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA17434 for hackers-outgoing; Sun, 19 Oct 1997 18:58:55 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from dcarmich.pr.mcs.net (dcarmich.pr.mcs.net [204.95.63.202]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA17421 for ; Sun, 19 Oct 1997 18:58:45 -0700 (PDT) (envelope-from dcarmich@dcarmich.pr.mcs.net) Received: (from dcarmich@localhost) by dcarmich.pr.mcs.net (8.8.5/8.8.5) id VAA00264; Sun, 19 Oct 1997 21:02:20 -0500 (CDT) Message-ID: <19971019210220.51925@dcarmich.pr.mcs.net> Date: Sun, 19 Oct 1997 21:02:20 -0500 From: Douglas Carmichael To: freebsd-hackers@freebsd.org Subject: Any X.25 support for FreeBSD? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74e Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Is there any support coming for X.25 in FreeBSD, e.g. Eicon cards? (I'd love to hook up a BBS machine to Sprintnet/Tymnet) From owner-freebsd-hackers Sun Oct 19 19:42:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA19750 for hackers-outgoing; Sun, 19 Oct 1997 19:42:54 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA19741 for ; Sun, 19 Oct 1997 19:42:47 -0700 (PDT) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (localhost.gsoft.com.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id MAA00729; Mon, 20 Oct 1997 12:09:23 +0930 (CST) Message-Id: <199710200239.MAA00729@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Andrew Kenneth Milton cc: hackers@FreeBSD.ORG Subject: Re: PThread In-reply-to: Your message of "Mon, 20 Oct 1997 11:54:28 GMT." <199710201154.LAA06957@mother.sneaker.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 20 Oct 1997 12:09:23 +0930 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > +-----[ Joao Carlos Mendes Luis ]------------------------------ > | > | PS: I really wonder how Solaris can run wrong code and do not > | complain at all... :) > > I'll drift off topic here and just say, that HPUX lets you dereference > NULL pointers as many times as you want, without skipping a beat. They > always return NULL though, not random data, so I suppose it's an > alternative form of robustness. This is called "mapping page zero", and it is a concession to all those stupid programmers out there that don't have the brains Zoroaster gave a rock. mike (Apologies to any Zoroastrians out there that feel that rocks weren't so hard done by as I am implying.) From owner-freebsd-hackers Sun Oct 19 19:58:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA20542 for hackers-outgoing; Sun, 19 Oct 1997 19:58:58 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from postoffice.onu.edu (postoffice.onu.edu [140.228.10.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA20529 for ; Sun, 19 Oct 1997 19:58:47 -0700 (PDT) (envelope-from n-ludban@onu.edu) Received: from austin.onu.edu (austin.onu.edu [140.228.10.1]) by postoffice.onu.edu (8.8.5/8.8.5) with SMTP id WAA18391 for ; Sun, 19 Oct 1997 22:58:30 -0400 (EDT) Date: Sun, 19 Oct 1997 22:58:34 -0400 (EDT) From: Neil Ludban To: freebsd-hackers@freebsd.org Subject: NCR 53c875j support? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello, I've ruled out everything I could think of on this problem, and what's left points to a question about the ncr driver for -hackers. I'm trying to get FreeBSD 2.2.2-RELEASE to recognize a Diamond FirePort40 SCSI adapter, which uses the NCR 53c875j chip. A borrowed Asus PCI-SC875 is recognized correctly on the same system (53c875 chip, no j). I looked through the ncr code and found the identification numbers for different chip numbers, but didn't see anything about the 875j or even different revisions of other chips. Can anyone tell me if this should already work (I got a bad card, or a messed up BIOS), or explain where to start to add support? According to Symbios' web site, the j suffix means it "supports JTAG boundary scan for onboard testing." I assume that if the current driver were to recognize it, it would act like a plain 875, which would be good enough for me. I've double checked all the BIOS settings, moved cards around, and removed everything except the PCI video card (Graphics Blaster, CL5462 chip). The motherboard is a HOT-433, with 486 PCI/ISA BIOS from AMI (copyright 1993), and UMC 8881/8886 chipset. The only thing I have not done is install Win95 to verify that the card works with its own drivers. A possibly related problem is that having both SCSI cards installed at once, or the Asus with a PCI NIC (ed2, RealTek 8029) causes the boot to hang after the imasks line. The next thing should have been the BIOS disk geometries. FWIW, the geometry of the SCSI disk is correct for either controller. Thanks for any help-- --Neil Here'e the BIOS message from the FirePort40: Diamond Multimedia Systems, Inc. SDMS (TM) V 4.0 PCI SCSI BIOS Copyright 1995, 1996 Symbios Logic. FirePort40 SCSI Host Adapter DIAMOND-4.03.08c And here's the pci section from dmesg after a boot -v with the 875j: 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.2-RELEASE #0: Thu Oct 2 20:49:53 EDT 1997 nludban@austin2.onu.edu:/usr/src/sys/compile/TIGGER Calibrating clock(s) ... i8254 clock: 1193365 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency CPU: AMD Am5x86 Write-Back (486-class CPU) Origin = "AuthenticAMD" Id = 0x4f4 Stepping=4 Features=0x1 real memory = 33554432 (32768K bytes) avail memory = 30351360 (29640K bytes) pcibus_setup(1): mode 1 addr port (0x0cf8) is 0x80009040 pcibus_setup(1a): mode1res=0x80000000 (0x80000000) pcibus_check: device 0 1 2 3 4 5 6 7 8 9 10 11 12 is there (id=008f1000) Probing for devices on PCI bus 0: configuration mode 1 allows 32 devices. pci0:12: NCR/Symbios, device=0x008f, class=storage (scsi) int a irq 11 [no driver assigned] map(10): io(fc00) map(14): mem32(ffbebf00) map(18): mem32(ffbea000) vga0 rev 1 on pci0:13 mapreg[10] type=0 addr=ffbec000 size=4000. mapreg[14] type=0 addr=fc000000 size=2000000. chip0 rev 4 on pci0:16 chip1 rev 14 on pci0:18:0 pci0:18:1: UMC, device=0x673a, class=storage (ide) [no driver assigned] map(10): io(ffe0) map(14): io(fff0) map(18): io(ffa8) map(1c): io(ffa4) map(20): io(ff90) pci0: uses 33570816 bytes of memory from fc000000 upto ffbeffff. Probing for devices on the ISA bus: From owner-freebsd-hackers Sun Oct 19 20:05:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA20908 for hackers-outgoing; Sun, 19 Oct 1997 20:05:18 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from shell.futuresouth.com (shell.futuresouth.com [207.141.254.20]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA20901 for ; Sun, 19 Oct 1997 20:05:11 -0700 (PDT) (envelope-from fullermd@futuresouth.com) Received: from shell.futuresouth.com (mail.futuresouth.com [207.141.254.21]) by shell.futuresouth.com (8.8.5/8.8.5) with SMTP id WAA25924; Sun, 19 Oct 1997 22:04:50 -0500 (CDT) Date: Sun, 19 Oct 1997 22:04:50 -0500 (CDT) From: "Matthew D. Fuller" To: Robin Cutshaw cc: Joerg Wunsch , hackers@FreeBSD.ORG Subject: Re: fsck problem with 2.2.5-971015-BETA In-Reply-To: <19971019212958.33788@num1sun.intercore.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 19 Oct 1997, Robin Cutshaw wrote: > On Sun, Oct 19, 1997 at 06:35:50PM +0200, J Wunsch wrote: > > As Robin Cutshaw wrote: > > > > > "fsck -p" in /etc/rc fails when it gets to the 1st 9GB drive > > > with "cannot alloc 2088961 bytes for statemap". > > > > ISTR a comment that you need to increase the VM resource limits to > > fsck large filesystems. > > > > Why does the fsck work correctly once the system is up in multi-user > mode? Because in multi-user, it has access to swap. If your turn swapon in single-user, I'll bet the fsck will work. > > robin > -- > ---- > Robin Cutshaw internet: robin@interlabs.com robin@intercore.com > Internet Labs, Inc. BellNet: 404-817-9787 robin@XFree86.Org > > "Time is just one damn thing after another" -- PBS/Nova > ---- > -- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* | FreeBSD; the way computers were meant to be | * "The only reason I'm burning my candle at both ends, is * | that I haven't figured out how to light the middle yet."| * fullermd@futuresouth.com :-} MAtthew Fuller * | http://keystone.westminster.edu/~fullermd | *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* From owner-freebsd-hackers Sun Oct 19 21:24:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA25134 for hackers-outgoing; Sun, 19 Oct 1997 21:24:18 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from dfw-ix16.ix.netcom.com (dfw-ix16.ix.netcom.com [206.214.98.16]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA25124 for ; Sun, 19 Oct 1997 21:24:13 -0700 (PDT) (envelope-from wghhicks@ix.netcom.com) Received: (from smap@localhost) by dfw-ix16.ix.netcom.com (8.8.4/8.8.4) id XAA09662; Sun, 19 Oct 1997 23:23:08 -0500 (CDT) Received: from atl-ga16-13.ix.netcom.com(204.32.174.141) by dfw-ix16.ix.netcom.com via smap (V1.3) id rma009632; Sun Oct 19 23:22:32 1997 Message-ID: <344ADB89.46FC5A59@ix.netcom.com> Date: Mon, 20 Oct 1997 00:18:17 -0400 From: Jerry Hicks Reply-To: wghhicks@ix.netcom.com Organization: TerraEarth X-Mailer: Mozilla 4.03b8 [en] (X11; I; FreeBSD 2.2-STABLE i386) MIME-Version: 1.0 To: Douglas Carmichael CC: freebsd-hackers@FreeBSD.ORG Subject: Re: Any X.25 support for FreeBSD? References: <19971019210220.51925@dcarmich.pr.mcs.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Douglas Carmichael wrote: > > Is there any support coming for X.25 in FreeBSD, e.g. Eicon cards? > (I'd love to hook up a BBS machine to Sprintnet/Tymnet) Eicon makes a developer sign a rather ugly NDA last time I tried. It's a shame, their boards are my fave... Jerry Hicks jerry_hicks@bigfoot.com From owner-freebsd-hackers Sun Oct 19 21:26:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA25300 for hackers-outgoing; Sun, 19 Oct 1997 21:26:08 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from mail.san.rr.com (mail-atm.san.rr.com [204.210.0.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA25272 for ; Sun, 19 Oct 1997 21:25:59 -0700 (PDT) (envelope-from Studded@dal.net) Received: from dt5h1n61.san.rr.com (dt5h1n61.san.rr.com [204.210.31.97]) by mail.san.rr.com (8.8.7/8.8.7) with SMTP id VAA06271 for ; Sun, 19 Oct 1997 21:25:05 -0700 (PDT) Message-Id: <199710200425.VAA06271@mail.san.rr.com> From: "Studded" To: "freebsd-hackers@freebsd.org" Date: Sun, 19 Oct 97 21:24:57 -0700 Reply-To: "Studded" Priority: Normal X-Mailer: PMMail 1.95a For OS/2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Fwd: misc/4766: Changes to rc* scripts for ipfw Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Pardon my forwarding this to yet another list, but it's been 5 days now, the deadline is close at hand, and I've yet to hear any kind of comment on this. Even "Doug, go away." would be fine at this point. :) If the concept of making the default rule "open" is too much of a challenge, I would really like to suggest that some kind of warning is included in rc.conf, since I think the fact that "open" is not the same as "OPEN" will cause more than one person to stumble. I have temporarily subscribed to -hackers since that seems to be the list that is next most likely to get a response. I would prefer that discussion about this take place on -stable though, since that is where it started. I know y'all are busy and it's close to release time, but the actual changes I'm proposing are quite small (except for the default policy change, which is easily reversed) and I really believe they will add to the usability of the system. Thanks for your time, Doug ==================BEGIN FORWARDED MESSAGE================== >Date: Tue, 14 Oct 1997 20:59:14 -0700 (PDT) >From: studded@dal.net >Number: 4766 >Category: misc >Synopsis: Simple changes to make ipfw safer and easier to use >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-bugs >State: open >Class: change-request >Submitter-Id: current-users >Arrival-Date: Tue Oct 14 21:00:01 PDT 1997 >Last-Modified: >Originator: Studded >Organization: DALnet IRC network >Release: FreeBSD 2.2.5-971012-BETA i386 >Environment: All FreeBSD 2.2x systems. (Note that I'm unsure about the category.) >Description: The ipfw functionality is a valuable part of FreeBSD, however compiling it into the kernel or enabling the option in rc.conf (which currently loads the kernel module from rc.network) can lead to a system accidentally being closed off from the internet. This is especially dangerous when administering a system remotely. >How-To-Repeat: Load ipfw. >Fix: The following patch (in both unified and context format because I can never remember what y'all like :) make a few small changes to rc.conf to make things more clear, add some safety features to rc.network and rc.firewall so that the default firewall type is open, and makes sure that rc.firewall is loaded if there is ipfw functionality in the kernel. It also makes a small change to the rc.firewall script so that the rules in the script look like the rules you see when doing 'ipfw list.' Finally it makes rc.firewall and rc.network friendlier to a mistake in case for "YES" vs. "yes," etc. I realize that making the default rule "open" is a controversial thing, however it would be trivial for someone who *wanted* a closed system to make the firewall type "CLOSED." On the other hand, someone compiling the ipfw option into the kernel or enabling it in rc.conf without doing their "homework" will find themself with anything from a mysterious situation to a catastrophic error for someone administering a system remotely. Even if the powers that be do not accept my proposal for changing the default rule, I'd like serious consideration for the expanded and clarified warning messages, and the change from "pass all" to "allow ip" in rc.firewall. There is currently a discussion on this topic happening on freebsd-stable. Hope this helps, Doug Context format: diff -cr ../etc-1014/rc.conf ./rc.conf *** ../etc-1014/rc.conf Sun Oct 12 13:33:28 1997 --- ./rc.conf Tue Oct 14 18:19:56 1997 *************** *** 4,10 **** # This is rc.conf - a file full of useful variables that you can set # to change the default startup behavior of your system. # ! # All arguments must be in double or single quotes. # # $Id: rc.conf,v 1.1.2.26 1997/10/12 20:33:28 imp Exp $ --- 4,12 ---- # This is rc.conf - a file full of useful variables that you can set # to change the default startup behavior of your system. # ! # All arguments must be in double or single quotes, and are case sensitive. ! # Therefore you should use CAPITAL LETTERS for the YES/NO options. ! # "NO" is not the same as "no". # # $Id: rc.conf,v 1.1.2.26 1997/10/12 20:33:28 imp Exp $ *************** *** 28,35 **** hostname="myname.my.domain" # Set this! nisdomainname="NO" # Set to NIS domain if using NIS (or NO). firewall_enable="NO" # Set to YES to enable firewall functionality - firewall_type="UNKNOWN" # Firewall type (see /etc/rc.firewall) firewall_quiet="NO" # Set to YES to suppress rule display tcp_extensions="YES" # Allow RFC1323 & RFC1544 extensions (or NO). network_interfaces="lo0" # List of network interfaces (lo0 is loopback). ifconfig_lo0="inet 127.0.0.1" # default loopback device configuration. --- 30,38 ---- hostname="myname.my.domain" # Set this! nisdomainname="NO" # Set to NIS domain if using NIS (or NO). firewall_enable="NO" # Set to YES to enable firewall functionality firewall_quiet="NO" # Set to YES to suppress rule display + firewall_type="OPEN" # Firewall type (see /etc/rc.firewall) + # "OPEN" allows all traffic to pass by default. Other options are available. tcp_extensions="YES" # Allow RFC1323 & RFC1544 extensions (or NO). network_interfaces="lo0" # List of network interfaces (lo0 is loopback). ifconfig_lo0="inet 127.0.0.1" # default loopback device configuration. diff -cr ../etc-1014/rc.firewall ./rc.firewall *** ../etc-1014/rc.firewall Thu Sep 18 15:47:10 1997 --- ./rc.firewall Tue Oct 14 19:50:42 1997 *************** *** 4,13 **** ############ # Define the firewall type in /etc/rc.conf. Valid values are: ! # open - will allow anyone in ! # client - will try to protect just this machine ! # simple - will try to protect a whole network ! # closed - totally disables IP services except via lo0 interface # UNKNOWN - disables the loading of firewall rules. # filename - will load the rules in the given filename (full path required) # --- 4,13 ---- ############ # Define the firewall type in /etc/rc.conf. Valid values are: ! # OPEN - will allow anyone in ! # CLIENT - will try to protect just this machine ! # SIMPLE - will try to protect a whole network ! # CLOSED - totally disables IP services except via lo0 interface # UNKNOWN - disables the loading of firewall rules. # filename - will load the rules in the given filename (full path required) # *************** *** 39,49 **** if [ "x$1" != "x" ]; then firewall_type=$1 fi ############ # Set quiet mode if requested ! if [ "x$firewall_quiet" = "xYES" ]; then fwcmd="/sbin/ipfw -q" else fwcmd="/sbin/ipfw" --- 39,51 ---- if [ "x$1" != "x" ]; then firewall_type=$1 + else + firewall_type=OPEN fi ############ # Set quiet mode if requested ! if [ "x$firewall_quiet" = "xYES" -o "x$firewall_quiet" = "xyes" ]; then fwcmd="/sbin/ipfw -q" else fwcmd="/sbin/ipfw" *************** *** 53,77 **** # Flush out the list before we begin. $fwcmd -f flush ############ # If you just configured ipfw in the kernel as a tool to solve network # problems or you just want to disallow some particular kinds of traffic # they you will want to change the default policy to open. You can also ! # do this as your only action by setting the firewall_type to ``open''. ! # $fwcmd add 65000 pass all from any to any ############ # Only in rare cases do you want to change this rule ! $fwcmd add 1000 pass all from 127.0.0.1 to 127.0.0.1 # Prototype setups. ! if [ "${firewall_type}" = "open" ]; then ! $fwcmd add 65000 pass all from any to any ! elif [ "${firewall_type}" = "client" ]; then ############ # This is a prototype setup that will protect your system somewhat against --- 55,85 ---- # Flush out the list before we begin. $fwcmd -f flush + # In the examples below, the words "allow" and "ip" are equivalent to + # "pass" and "all" as used in this file previously, and accurately reflect + # how ipfw will list the rules when you use ipfw list. See man ipfw(8) + # for more details. + ############ # If you just configured ipfw in the kernel as a tool to solve network # problems or you just want to disallow some particular kinds of traffic # they you will want to change the default policy to open. You can also ! # do this as your only action by setting the firewall_type to "OPEN" in ! # /etc/rc.conf. ! # $fwcmd add 65000 allow ip from any to any ############ # Only in rare cases do you want to change this rule ! $fwcmd add 100 allow ip from 127.0.0.1 to 127.0.0.1 # Prototype setups. ! if [ "${firewall_type}" = "OPEN" -o "${firewall_type}" = "open" ]; then ! $fwcmd add 65000 allow ip from any to any ! elif [ "${firewall_type}" = "CLIENT" -o "${firewall_type}" = "client" ]; then ############ # This is a prototype setup that will protect your system somewhat against *************** *** 84,115 **** ip="192.168.4.17" # Allow any traffic to or from my own net. ! $fwcmd add pass all from ${ip} to ${net}:${mask} ! $fwcmd add pass all from ${net}:${mask} to ${ip} # Allow TCP through if setup succeeded ! $fwcmd add pass tcp from any to any established # Allow setup of incoming email ! $fwcmd add pass tcp from any to ${ip} 25 setup # Allow setup of outgoing TCP connections only ! $fwcmd add pass tcp from ${ip} to any setup # Disallow setup of all other TCP connections $fwcmd add deny tcp from any to any setup # Allow DNS queries out in the world ! $fwcmd add pass udp from any 53 to ${ip} ! $fwcmd add pass udp from ${ip} to any 53 # Allow NTP queries out in the world ! $fwcmd add pass udp from any 123 to ${ip} ! $fwcmd add pass udp from ${ip} to any 123 # Everything else is denied as default. ! elif [ "${firewall_type}" = "simple" ]; then ############ # This is a prototype setup for a simple firewall. Configure this machine --- 92,125 ---- ip="192.168.4.17" # Allow any traffic to or from my own net. ! $fwcmd add allow ip from ${ip} to ${net}:${mask} ! $fwcmd add allow ip from ${net}:${mask} to ${ip} # Allow TCP through if setup succeeded ! $fwcmd add allow tcp from any to any established # Allow setup of incoming email ! $fwcmd add allow tcp from any to ${ip} 25 setup # Allow setup of outgoing TCP connections only ! $fwcmd add allow tcp from ${ip} to any setup # Disallow setup of all other TCP connections $fwcmd add deny tcp from any to any setup # Allow DNS queries out in the world ! # (BIND 8.1.1 and later do not use port 53 by ! # default, but it can be configured to do so.) ! $fwcmd add allow udp from any 53 to ${ip} ! $fwcmd add allow udp from ${ip} to any 53 # Allow NTP queries out in the world ! $fwcmd add allow udp from any 123 to ${ip} ! $fwcmd add allow udp from ${ip} to any 123 # Everything else is denied as default. ! elif [ "${firewall_type}" = "SIMPLE" -o "${firewall_type}" = "simple" ]; then ############ # This is a prototype setup for a simple firewall. Configure this machine *************** *** 130,171 **** iip="192.168.3.17" # Stop spoofing ! $fwcmd add deny all from ${inet}:${imask} to any in via ${oif} ! $fwcmd add deny all from ${onet}:${omask} to any in via ${iif} # Stop RFC1918 nets on the outside interface ! $fwcmd add deny all from 192.168.0.0:255.255.0.0 to any via ${oif} ! $fwcmd add deny all from 172.16.0.0:255.240.0.0 to any via ${oif} ! $fwcmd add deny all from 10.0.0.0:255.0.0.0 to any via ${oif} # Allow TCP through if setup succeeded ! $fwcmd add pass tcp from any to any established # Allow setup of incoming email ! $fwcmd add pass tcp from any to ${oip} 25 setup # Allow access to our DNS ! $fwcmd add pass tcp from any to ${oip} 53 setup # Allow access to our WWW ! $fwcmd add pass tcp from any to ${oip} 80 setup # Reject&Log all setup of incoming connections from the outside $fwcmd add deny log tcp from any to any in via ${oif} setup # Allow setup of any other TCP connection ! $fwcmd add pass tcp from any to any setup # Allow DNS queries out in the world ! $fwcmd add pass udp from any 53 to ${oip} ! $fwcmd add pass udp from ${oip} to any 53 # Allow NTP queries out in the world ! $fwcmd add pass udp from any 123 to ${oip} ! $fwcmd add pass udp from ${oip} to any 123 # Everything else is denied as default. ! elif [ "${firewall_type}" != "NONE" -a -r "${firewall_type}" ]; then $fwcmd ${firewall_type} fi --- 140,185 ---- iip="192.168.3.17" # Stop spoofing ! $fwcmd add deny ip from ${inet}:${imask} to any in via ${oif} ! $fwcmd add deny ip from ${onet}:${omask} to any in via ${iif} # Stop RFC1918 nets on the outside interface ! $fwcmd add deny ip from 192.168.0.0:255.255.0.0 to any via ${oif} ! $fwcmd add deny ip from 172.16.0.0:255.240.0.0 to any via ${oif} ! $fwcmd add deny ip from 10.0.0.0:255.0.0.0 to any via ${oif} # Allow TCP through if setup succeeded ! $fwcmd add allow tcp from any to any established # Allow setup of incoming email ! $fwcmd add allow tcp from any to ${oip} 25 setup # Allow access to our DNS ! # (BIND 8.1.1 and later do not use port 53 by ! # default, but it can be configured to do so.) ! $fwcmd add allow tcp from any to ${oip} 53 setup # Allow access to our WWW ! $fwcmd add allow tcp from any to ${oip} 80 setup # Reject&Log all setup of incoming connections from the outside $fwcmd add deny log tcp from any to any in via ${oif} setup # Allow setup of any other TCP connection ! $fwcmd add allow tcp from any to any setup # Allow DNS queries out in the world ! # (BIND 8.1.1 and later do not use port 53 by ! # default, but it can be configured to do so.) ! $fwcmd add allow udp from any 53 to ${oip} ! $fwcmd add allow udp from ${oip} to any 53 # Allow NTP queries out in the world ! $fwcmd add allow udp from any 123 to ${oip} ! $fwcmd add allow udp from ${oip} to any 123 # Everything else is denied as default. ! elif [ "${firewall_type}" != "UNKNOWN -a -r "${firewall_type}" ]; then $fwcmd ${firewall_type} fi diff -cr ../etc-1014/rc.network ./rc.network *** ../etc-1014/rc.network Thu Sep 18 15:47:12 1997 --- ./rc.network Tue Oct 14 20:28:16 1997 *************** *** 55,88 **** ifconfig ${ifn} done ! # Initialize IP filtering using ipfw ! echo "" /sbin/ipfw -q flush > /dev/null 2>&1 ! if [ $? = 1 ] ; then firewall_in_kernel=0 else firewall_in_kernel=1 fi ! if [ $firewall_in_kernel = 0 -a "x$firewall_enable" = "xYES" ] ; then ! modload /lkm/ipfw_mod.o ! if [ $? = 0 ]; then ! firewall_in_kernel=1 # module loaded successfully ! echo "Kernel firewall module loaded." ! else ! echo "Warning: firewall kernel module failed to load." fi fi ! # Load the filters if required if [ $firewall_in_kernel = 1 ]; then ! if [ -n "$firewall_enable" -a -f /etc/rc.firewall -a \ ! "x$firewall_enable" = "xYES" ] ; then ! . /etc/rc.firewall ! echo "Firewall rules loaded." else ! echo "Warning: kernel has firewall functionality, but firewall rules are not enabled." ! echo " All ip services are disabled." fi fi --- 55,95 ---- ifconfig ${ifn} done ! echo "Initializing IP filtering using ipfw." ! /sbin/ipfw -q flush > /dev/null 2>&1 ! if [ $? != 0 ]; then firewall_in_kernel=0 else firewall_in_kernel=1 fi ! if [ "x$firewall_enable" = "xYES" -o "x$firewall_enable" = "xyes" ]; then ! ! if [ $firewall_in_kernel = 0 ]; then ! /sbin/modload /lkm/ipfw_mod.o ! ! if [ $? = 0 ]; then ! firewall_in_kernel=1 ! echo "Kernel firewall module loaded successfully." ! else ! echo "Warning: Firewall is enabled in /etc/rc.conf, but it is not compiled" ! echo "Warning: into the kernel, and the kernel module failed to load." ! fi fi fi ! # Load the filters if ipfw is in the kernel or loaded above. ! if [ $firewall_in_kernel = 1 ]; then ! if [ -r /etc/rc.firewall ]; then ! . /etc/rc.firewall ! echo "Firewall rules loaded from /etc/rc.firewall." else ! echo "Warning: Firewall functionality is enabled, but firewall rules were" ! echo "Warning: not loaded from /etc/rc.firewall." ! echo "" ! echo "Warning: *** All IP services are disabled. ***" fi fi Unified format: diff -ur ../etc-1014/rc.conf ./rc.conf --- ../etc-1014/rc.conf Sun Oct 12 13:33:28 1997 +++ ./rc.conf Tue Oct 14 18:19:56 1997 @@ -4,7 +4,9 @@ # This is rc.conf - a file full of useful variables that you can set # to change the default startup behavior of your system. # -# All arguments must be in double or single quotes. +# All arguments must be in double or single quotes, and are case sensitive. +# Therefore you should use CAPITAL LETTERS for the YES/NO options. +# "NO" is not the same as "no". # # $Id: rc.conf,v 1.1.2.26 1997/10/12 20:33:28 imp Exp $ @@ -28,8 +30,9 @@ hostname="myname.my.domain" # Set this! nisdomainname="NO" # Set to NIS domain if using NIS (or NO). firewall_enable="NO" # Set to YES to enable firewall functionality -firewall_type="UNKNOWN" # Firewall type (see /etc/rc.firewall) firewall_quiet="NO" # Set to YES to suppress rule display +firewall_type="OPEN" # Firewall type (see /etc/rc.firewall) +# "OPEN" allows all traffic to pass by default. Other options are available. tcp_extensions="YES" # Allow RFC1323 & RFC1544 extensions (or NO). network_interfaces="lo0" # List of network interfaces (lo0 is loopback). ifconfig_lo0="inet 127.0.0.1" # default loopback device configuration. diff -ur ../etc-1014/rc.firewall ./rc.firewall --- ../etc-1014/rc.firewall Thu Sep 18 15:47:10 1997 +++ ./rc.firewall Tue Oct 14 19:50:42 1997 @@ -4,10 +4,10 @@ ############ # Define the firewall type in /etc/rc.conf. Valid values are: -# open - will allow anyone in -# client - will try to protect just this machine -# simple - will try to protect a whole network -# closed - totally disables IP services except via lo0 interface +# OPEN - will allow anyone in +# CLIENT - will try to protect just this machine +# SIMPLE - will try to protect a whole network +# CLOSED - totally disables IP services except via lo0 interface # UNKNOWN - disables the loading of firewall rules. # filename - will load the rules in the given filename (full path required) # @@ -39,11 +39,13 @@ if [ "x$1" != "x" ]; then firewall_type=$1 +else + firewall_type=OPEN fi ############ # Set quiet mode if requested -if [ "x$firewall_quiet" = "xYES" ]; then +if [ "x$firewall_quiet" = "xYES" -o "x$firewall_quiet" = "xyes" ]; then fwcmd="/sbin/ipfw -q" else fwcmd="/sbin/ipfw" @@ -53,25 +55,31 @@ # Flush out the list before we begin. $fwcmd -f flush +# In the examples below, the words "allow" and "ip" are equivalent to +# "pass" and "all" as used in this file previously, and accurately reflect +# how ipfw will list the rules when you use ipfw list. See man ipfw(8) +# for more details. + ############ # If you just configured ipfw in the kernel as a tool to solve network # problems or you just want to disallow some particular kinds of traffic # they you will want to change the default policy to open. You can also -# do this as your only action by setting the firewall_type to ``open''. +# do this as your only action by setting the firewall_type to "OPEN" in +# /etc/rc.conf. -# $fwcmd add 65000 pass all from any to any +# $fwcmd add 65000 allow ip from any to any ############ # Only in rare cases do you want to change this rule -$fwcmd add 1000 pass all from 127.0.0.1 to 127.0.0.1 +$fwcmd add 100 allow ip from 127.0.0.1 to 127.0.0.1 # Prototype setups. -if [ "${firewall_type}" = "open" ]; then +if [ "${firewall_type}" = "OPEN" -o "${firewall_type}" = "open" ]; then - $fwcmd add 65000 pass all from any to any + $fwcmd add 65000 allow ip from any to any -elif [ "${firewall_type}" = "client" ]; then +elif [ "${firewall_type}" = "CLIENT" -o "${firewall_type}" = "client" ]; then ############ # This is a prototype setup that will protect your system somewhat against @@ -84,32 +92,34 @@ ip="192.168.4.17" # Allow any traffic to or from my own net. - $fwcmd add pass all from ${ip} to ${net}:${mask} - $fwcmd add pass all from ${net}:${mask} to ${ip} + $fwcmd add allow ip from ${ip} to ${net}:${mask} + $fwcmd add allow ip from ${net}:${mask} to ${ip} # Allow TCP through if setup succeeded - $fwcmd add pass tcp from any to any established + $fwcmd add allow tcp from any to any established # Allow setup of incoming email - $fwcmd add pass tcp from any to ${ip} 25 setup + $fwcmd add allow tcp from any to ${ip} 25 setup # Allow setup of outgoing TCP connections only - $fwcmd add pass tcp from ${ip} to any setup + $fwcmd add allow tcp from ${ip} to any setup # Disallow setup of all other TCP connections $fwcmd add deny tcp from any to any setup # Allow DNS queries out in the world - $fwcmd add pass udp from any 53 to ${ip} - $fwcmd add pass udp from ${ip} to any 53 + # (BIND 8.1.1 and later do not use port 53 by + # default, but it can be configured to do so.) + $fwcmd add allow udp from any 53 to ${ip} + $fwcmd add allow udp from ${ip} to any 53 # Allow NTP queries out in the world - $fwcmd add pass udp from any 123 to ${ip} - $fwcmd add pass udp from ${ip} to any 123 + $fwcmd add allow udp from any 123 to ${ip} + $fwcmd add allow udp from ${ip} to any 123 # Everything else is denied as default. -elif [ "${firewall_type}" = "simple" ]; then +elif [ "${firewall_type}" = "SIMPLE" -o "${firewall_type}" = "simple" ]; then ############ # This is a prototype setup for a simple firewall. Configure this machine @@ -130,42 +140,46 @@ iip="192.168.3.17" # Stop spoofing - $fwcmd add deny all from ${inet}:${imask} to any in via ${oif} - $fwcmd add deny all from ${onet}:${omask} to any in via ${iif} + $fwcmd add deny ip from ${inet}:${imask} to any in via ${oif} + $fwcmd add deny ip from ${onet}:${omask} to any in via ${iif} # Stop RFC1918 nets on the outside interface - $fwcmd add deny all from 192.168.0.0:255.255.0.0 to any via ${oif} - $fwcmd add deny all from 172.16.0.0:255.240.0.0 to any via ${oif} - $fwcmd add deny all from 10.0.0.0:255.0.0.0 to any via ${oif} + $fwcmd add deny ip from 192.168.0.0:255.255.0.0 to any via ${oif} + $fwcmd add deny ip from 172.16.0.0:255.240.0.0 to any via ${oif} + $fwcmd add deny ip from 10.0.0.0:255.0.0.0 to any via ${oif} # Allow TCP through if setup succeeded - $fwcmd add pass tcp from any to any established + $fwcmd add allow tcp from any to any established # Allow setup of incoming email - $fwcmd add pass tcp from any to ${oip} 25 setup + $fwcmd add allow tcp from any to ${oip} 25 setup # Allow access to our DNS - $fwcmd add pass tcp from any to ${oip} 53 setup + # (BIND 8.1.1 and later do not use port 53 by + # default, but it can be configured to do so.) + $fwcmd add allow tcp from any to ${oip} 53 setup # Allow access to our WWW - $fwcmd add pass tcp from any to ${oip} 80 setup + $fwcmd add allow tcp from any to ${oip} 80 setup # Reject&Log all setup of incoming connections from the outside $fwcmd add deny log tcp from any to any in via ${oif} setup # Allow setup of any other TCP connection - $fwcmd add pass tcp from any to any setup + $fwcmd add allow tcp from any to any setup # Allow DNS queries out in the world - $fwcmd add pass udp from any 53 to ${oip} - $fwcmd add pass udp from ${oip} to any 53 + # (BIND 8.1.1 and later do not use port 53 by + # default, but it can be configured to do so.) + $fwcmd add allow udp from any 53 to ${oip} + $fwcmd add allow udp from ${oip} to any 53 # Allow NTP queries out in the world - $fwcmd add pass udp from any 123 to ${oip} - $fwcmd add pass udp from ${oip} to any 123 + $fwcmd add allow udp from any 123 to ${oip} + $fwcmd add allow udp from ${oip} to any 123 # Everything else is denied as default. -elif [ "${firewall_type}" != "NONE" -a -r "${firewall_type}" ]; then +elif [ "${firewall_type}" != "UNKNOWN -a -r "${firewall_type}" ]; then $fwcmd ${firewall_type} fi diff -ur ../etc-1014/rc.network ./rc.network --- ../etc-1014/rc.network Thu Sep 18 15:47:12 1997 +++ ./rc.network Tue Oct 14 20:28:16 1997 @@ -55,34 +55,41 @@ ifconfig ${ifn} done - # Initialize IP filtering using ipfw - echo "" + echo "Initializing IP filtering using ipfw." + /sbin/ipfw -q flush > /dev/null 2>&1 - if [ $? = 1 ] ; then + if [ $? != 0 ]; then firewall_in_kernel=0 else firewall_in_kernel=1 fi - if [ $firewall_in_kernel = 0 -a "x$firewall_enable" = "xYES" ] ; then - modload /lkm/ipfw_mod.o - if [ $? = 0 ]; then - firewall_in_kernel=1 # module loaded successfully - echo "Kernel firewall module loaded." - else - echo "Warning: firewall kernel module failed to load." + if [ "x$firewall_enable" = "xYES" -o "x$firewall_enable" = "xyes" ]; then + + if [ $firewall_in_kernel = 0 ]; then + /sbin/modload /lkm/ipfw_mod.o + + if [ $? = 0 ]; then + firewall_in_kernel=1 + echo "Kernel firewall module loaded successfully." + else +echo "Warning: Firewall is enabled in /etc/rc.conf, but it is not compiled" +echo "Warning: into the kernel, and the kernel module failed to load." + fi fi fi - # Load the filters if required + # Load the filters if ipfw is in the kernel or loaded above. + if [ $firewall_in_kernel = 1 ]; then - if [ -n "$firewall_enable" -a -f /etc/rc.firewall -a \ - "x$firewall_enable" = "xYES" ] ; then - . /etc/rc.firewall - echo "Firewall rules loaded." + if [ -r /etc/rc.firewall ]; then + . /etc/rc.firewall + echo "Firewall rules loaded from /etc/rc.firewall." else - echo "Warning: kernel has firewall functionality, but firewall rules are not enabled." - echo " All ip services are disabled." +echo "Warning: Firewall functionality is enabled, but firewall rules were" +echo "Warning: not loaded from /etc/rc.firewall." +echo "" +echo "Warning: *** All IP services are disabled. ***" fi fi >Audit-Trail: >Unformatted: ===================END FORWARDED MESSAGE=================== *** Proud operator, designer and maintainer of the world's largest *** Internet Relay Chat server. 4,168 clients and still growing. :-) *** Try spider.dal.net on ports 6662-4 (Powered by FreeBSD) From owner-freebsd-hackers Sun Oct 19 22:20:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA28313 for hackers-outgoing; Sun, 19 Oct 1997 22:20:16 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from gate.mgt.msk.ru (mgtrep.24h.dialup.ru [194.87.18.139]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA28295; Sun, 19 Oct 1997 22:20:11 -0700 (PDT) (envelope-from tarkhil@mgt.msk.ru) Received: from asteroid.mgt.msk.ru (asteroid.mgt.msk.ru [192.168.133.145]) by gate.mgt.msk.ru (8.8.6/8.8.6) with ESMTP id JAA15967; Mon, 20 Oct 1997 09:20:05 +0400 (MSD) Received: from asteroid.mgt.msk.ru (localhost.mgt.msk.ru [127.0.0.1]) by asteroid.mgt.msk.ru (8.8.7/8.8.6) with ESMTP id JAA24209; Mon, 20 Oct 1997 09:19:22 +0400 (MSD) Message-Id: <199710200519.JAA24209@asteroid.mgt.msk.ru> To: hackers@freebsd.org, hardware@freebsd.org Reply-To: tarkhil@mgt.msk.ru Subject: on Worm detection Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 20 Oct 1997 09:19:21 +0400 From: "Alexander B. Povolotsky" Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello! Since my 2.2-STABLE fails to detect Pinnacle Micro 4X4 CD-R as worm, and 2.2.2 or 2.2.1 did it, and I don't want to fetch it and install again, can't one wise man describe me process of worm detection, so I'll try to make it working? Alex. From owner-freebsd-hackers Sun Oct 19 23:26:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA01703 for hackers-outgoing; Sun, 19 Oct 1997 23:26:49 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from sos.freebsd.dk (sos.freebsd.dk [195.8.129.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA01697 for ; Sun, 19 Oct 1997 23:26:45 -0700 (PDT) (envelope-from sos@sos.freebsd.dk) Received: (from sos@localhost) by sos.freebsd.dk (8.8.7/8.7.3) id IAA19215; Mon, 20 Oct 1997 08:26:30 +0200 (MEST) Message-Id: <199710200626.IAA19215@sos.freebsd.dk> Subject: Re: ATAPI CD-RW documentation... In-Reply-To: from Dan Walters at "Oct 19, 97 06:09:07 pm" To: hannibal@cyberstation.net (Dan Walters) Date: Mon, 20 Oct 1997 08:26:30 +0200 (MEST) Cc: hackers@FreeBSD.ORG From: Sųren Schmidt Reply-to: sos@FreeBSD.dk X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In reply to Dan Walters who wrote: > Never mind, it's amazing how you always find things right after you give > up and ask. :) For anyone wondering, the motherload of specs can be > found by ftp at fission.dt.wdc.com, including the working draft of the > ATAPI Removable Rewritable Specification, SFF-8070. Wish their web pages > would mention the site. :) > > So, has anyone already began work on this, or should I go ahead and give > it a shot when my drive gets in? No, there is nobody working at it so far, or at least not that I'm aware of. If you look carefully in the atapi.? files in sys/i386/isa you will see that there is hooks for atapi disk & tapes, but its only stubs the real driver are not written yet. You should hang of the CD-RW in the same fashion I guess, giving us a wcdrw.c driver.... We should probably coordinate things a little, as I'm currently adding changer support into the CDROM driver parts of our (E)IDE subsystem... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Sųren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-hackers Sun Oct 19 23:46:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA02703 for hackers-outgoing; Sun, 19 Oct 1997 23:46:47 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from safeconcept.utimaco.co.at (mail-gw.utimaco.co.at [195.96.28.162]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA02694 for ; Sun, 19 Oct 1997 23:46:26 -0700 (PDT) (envelope-from Michael.Schuster@utimaco.co.at) Received: (from uucp@localhost) by safeconcept.utimaco.co.at (8.8.5/8.8.5) id IAA13517 for ; Mon, 20 Oct 1997 08:35:15 +0200 (CEST) Received: from wshpux.utimaco.co.at(10.0.0.18) by safeconcept via smap (V2.0) id xma013515; Mon, 20 Oct 97 08:35:13 +0200 Message-ID: <344AFDD1.52D4AF96@utimaco.co.at> Date: Mon, 20 Oct 1997 08:44:33 +0200 From: Michael Schuster Organization: Utimaco Safe Concept GmbH., Linz, Austria X-Mailer: Mozilla 4.02b7 [en] (X11; I; HP-UX B.10.01 9000/715) MIME-Version: 1.0 To: "hackers@FreeBSD.ORG" Subject: Re: outb() / inb() Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 0000-Administrator wrote: > outb (0x250, *c++); /* doesn't work whereas */ > outb (0x250, *c); c++; /* works */ > > I would guess (but cannot verify) that > > > *c++ = inb (0x250); /* probably works since the increment expression is > * not part of the macro */ > > can somebody verify this for me I am pretty sure about the inb (even > though I can't test it easily), as for the outb since outb just is a macro > that puts in an inline function outbv() why does it not work? right: (copied by hand from /usr/include/machine/coufuncs.h): >#define outb(port,data) \ > <....> \ > ? outbc(port,data):outbv(port,data)) which means that if you write outb (0x250, *c++); then the expression "*c++" gets evaluated twice, and only every other byte is output to port 0x250. Your solution is correct. Michael -- Michael Schuster Utimaco Safe Concept GmbH. | Tel: +43 732 655755 41 Europaplatz 6 | Fax: +43 732 655755 5 A-4020 Linz Austria | email: Michael.Schuster@utimaco.co.at From owner-freebsd-hackers Sun Oct 19 23:57:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA03402 for hackers-outgoing; Sun, 19 Oct 1997 23:57:37 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from ren.dtir.qld.gov.au (firewall-user@ns.dtir.qld.gov.au [203.108.138.66]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA03395 for ; Sun, 19 Oct 1997 23:57:33 -0700 (PDT) (envelope-from syssgm@dtir.qld.gov.au) Received: by ren.dtir.qld.gov.au; id RAA21451; Mon, 20 Oct 1997 17:07:55 +1000 (EST) Received: from ogre.dtir.qld.gov.au(167.123.8.3) by ren.dtir.qld.gov.au via smap (3.2) id xma021446; Mon, 20 Oct 97 17:07:45 +1000 Received: from localhost.dtir.qld.gov.au (localhost.dtir.qld.gov.au [127.0.0.1]) by ogre.dtir.qld.gov.au (8.8.7/8.8.7) with SMTP id QAA18393; Mon, 20 Oct 1997 16:56:52 +1000 (EST) Message-Id: <199710200656.QAA18393@ogre.dtir.qld.gov.au> X-Authentication-Warning: ogre.dtir.qld.gov.au: localhost.dtir.qld.gov.au [127.0.0.1] didn't use HELO protocol To: Neil Ludban cc: freebsd-hackers@freebsd.org, syssgm@dtir.qld.gov.au Subject: Re: NCR 53c875j support? References: In-Reply-To: from Neil Ludban at "Mon, 20 Oct 1997 02:58:34 +0000" Date: Mon, 20 Oct 1997 16:56:52 +1000 From: Stephen McKay Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Monday, 20th October 1997, Neil Ludban wrote: >I'm trying to get FreeBSD 2.2.2-RELEASE to recognize a Diamond FirePort40 >SCSI adapter, which uses the NCR 53c875j chip. The 53c875j has a different ID than the 53c875. If you add that ID to the appropriate switch statements in sys/pci/ncr.c, you'll be fine, assuming you have some other way to do a 2.2.2 install. The latest code has these defines: #define NCR_875_ID (0x000f1000ul) #define NCR_875_ID2 (0x008f1000ul) so you should be able to work this out from that. Alternatively, an improved ncr driver (supporting the 875j and 875 at full speed) is part of the very-soon-to-be-released 2.2.5. So, you could wait a few days and install 2.2.5-release, or install a beta version right now. >A possibly related problem is that having both SCSI cards installed at >once, or the Asus with a PCI NIC (ed2, RealTek 8029) causes the boot to >hang after the imasks line. The next thing should have been the BIOS >disk geometries. FWIW, the geometry of the SCSI disk is correct for >either controller. I don't know what is happening here. Perhaps 2.2.5 will help here also. Stephen. From owner-freebsd-hackers Mon Oct 20 00:17:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA04465 for hackers-outgoing; Mon, 20 Oct 1997 00:17:24 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from lab321.ru (anonymous1.omsk.net.ru [194.226.32.34]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA04458 for ; Mon, 20 Oct 1997 00:17:15 -0700 (PDT) (envelope-from Eugeny.Kuzakov@lab321.ru) Received: from lab321.ru (kev.l321.omsk.net.ru [194.226.33.68]) by lab321.ru (8.8.5-MVC-230497/8.8.5) with ESMTP id JAA25253; Mon, 20 Oct 1997 09:41:17 +0600 (OSK) Message-ID: <344AC4CD.362245D9@lab321.ru> Date: Mon, 20 Oct 1997 09:41:17 +0700 From: Eugeny Kuzakov Organization: Powered by FreeBSD. X-Mailer: Mozilla 4.03b8 [en] (X11; I; FreeBSD 3.0-971012-SNAP i386) MIME-Version: 1.0 To: Douglas Carmichael CC: freebsd-hackers@FreeBSD.ORG Subject: Re: Any X.25 support for FreeBSD? References: <19971019210220.51925@dcarmich.pr.mcs.net> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Douglas Carmichael wrote: > Is there any support coming for X.25 in FreeBSD, e.g. Eicon cards? > (I'd love to hook up a BBS machine to Sprintnet/Tymnet) I known about drivers for QZHS cards that support X.25. Send mail to mailto://wolodn@novoch.ru -- Best wishes, Eugeny Kuzakov Laboratory 321 ( Omsk, Russia ) http://www.lab321.ru/~kev kev@lab321.ru From owner-freebsd-hackers Mon Oct 20 00:24:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA04841 for hackers-outgoing; Mon, 20 Oct 1997 00:24:17 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id AAA04836 for ; Mon, 20 Oct 1997 00:24:13 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA01452 for freebsd-hackers@freebsd.org; Mon, 20 Oct 1997 09:23:23 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id JAA05038; Mon, 20 Oct 1997 09:22:56 +0200 (MET DST) Message-ID: <19971020092256.EF31838@uriah.heep.sax.de> Date: Mon, 20 Oct 1997 09:22:56 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@freebsd.org (FreeBSD hackers) Subject: Urge to apply the vn device hack even to 2.2.5 X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Here's a confirmation that Mr. KATO's hack for the lockmgr panic on vn devices does also fix the problems on 2.2.5. I would strongly recommend that we apply this hack, instead of shipping 2.2.5 in the current state, where it's got a high probability that our users can't successfully run a `make release' on it without hitting a panic! -----Forwarded message from tarkhil@mgt.msk.ru (Alexander B. Povolotsky)----- Reply-To: tarkhil@mgt.msk.ru Subject: Re: Repeated panic during work with vn Date: Mon, 20 Oct 1997 09:10:41 +0400 From: "Alexander B. Povolotsky" > > I've tried the patch, but ... was it for -CURRENT or for -STABLE? > > vn.c fails to compile. > > It was a CVS diff straight out of my -current system. Ok, I've made it manually for -STABLE. Thanx, it helped! Alex. -----End of forwarded message----- -- 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-hackers Mon Oct 20 00:40:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA05846 for hackers-outgoing; Mon, 20 Oct 1997 00:40:18 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA05831 for ; Mon, 20 Oct 1997 00:40:13 -0700 (PDT) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id AAA23979; Mon, 20 Oct 1997 00:34:26 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd023977; Mon Oct 20 07:34:22 1997 Date: Mon, 20 Oct 1997 00:32:57 -0700 (PDT) From: Julian Elischer To: adrian@virginia.edu cc: FreeBSD Hackers List Subject: Re: Rhapsody is 4.4BSD based!? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk the NeXT OS was based on MACH with BSD 4.3++ parts I would presme that they have continued to keep their code up-to-date to at least some extent since then.. On Thu, 16 Oct 1997, Adrian T. Filipi-Martin wrote: > Hi folks, > > Has anyone else seen this? Aparently Apples next generation OS > is 4.4BSD based. Do I smell a new emmulation to support? > > You can get the basics from the following PCmag URL: > > http://www.zdnet.com/pcmag/news/trends/t971016a.htm > > I wonder which 4.4BSD they started with? It is reported to be > multithreaded. I wonder if them mean kernel-multithreaded? > > Adrian > -- > adrian@virginia.edu ---->>>>| If I were stranded on a desert island, and > System Administrator --->>>| I could only have one OS for my computer, > Neurosurgical Visualzation Lab -->>| it would be FreeBSD. Think about it..... > http://www.nvl.virginia.edu/ ->| http://www.freebsd.org/ > > From owner-freebsd-hackers Mon Oct 20 05:13:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA18171 for hackers-outgoing; Mon, 20 Oct 1997 05:13:22 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from seagull.cdrom.com (cracauer@seagull.cdrom.com [204.216.27.14]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA18165 for ; Mon, 20 Oct 1997 05:13:20 -0700 (PDT) (envelope-from cracauer@seagull.cdrom.com) Received: (from cracauer@localhost) by seagull.cdrom.com (8.8.6/8.6.6) id FAA20236 ; Mon, 20 Oct 1997 05:12:05 -0700 (PDT) Message-ID: <19971020141203.20645@cons.org> Date: Mon, 20 Oct 1997 14:12:03 +0200 From: Martin Cracauer To: Stefan Arentz Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Linux Emulation - clone() References: <19971018222208.49710@kalkoen.sateh.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81 In-Reply-To: <19971018222208.49710@kalkoen.sateh.com>; from Stefan Arentz on Sat, Oct 18, 1997 at 10:22:08PM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In <19971018222208.49710@kalkoen.sateh.com>, Stefan Arentz wrote: > I'm trying to implement the linux clone() system call in 2.2.2. Good news :-) > It > looks like this can be done with the FreeBSD rfork call except that > Linux also allows you to set the user stack pointer for the new > process. > > pid_t clone(void *sp, unsigned long flags) > > I'm still reading 'The design and implementation of the 4.4BSD > operating system' to get a clue about where to setup the stack > pointer, but it's still a big mystery to me ;) The information in the book is outdated and doesn't apply to FreeBSD anymore. About a month ago, the semantics to FreeBSD's rfork system call has been changed. The former behaviour left you with identical stacks in parent and child. The new behaviour is to always copy the stack to a new location, which is chosen by the system call. Check the mail archives of -current from Sep, 18-20. To emulate the Linux call, you can probably do it like this (I assume the caller already allocated space for the stack): - in the clone call, put the address of the user-supplied stack on the stack. - call rfork - in the new child, do a return instruction from assembly, so that the stack pointer now points to the user's location. This should even work before and after the behaviour change I noted above, since you don't use any rfork-supplied stack at all. In a similar thread John Dyson noted that you might want to hold signals until the new stack is in use in the child. See -hackers archives from Sep, 16. I hope this helps, but please note that I'm speaking from theory, never tangled with this myself. Aren't there some other problems, BTW? I know Linux planned to implement clone flags so that process IDs are shared. This is needed to be Posix threads compliant with plain fork/clone-based thread packages. And how are user's of clone() supposed to know how large the stack region should be? If I'm not mistaken, the current FreeBSD rfork implementation has grow-on-demand stacks as any usual process. It seems to me this is an ugly performance hack to save the kernel from allocating some space (but not from copying the contents, so it's probably not worth the effort). comp.prorgramming.threads is full of people claiming Linuxthreads can launch threads x-times faster than any other system. Oh well... Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ BSD User Group Hamburg/Germany http://www.bsdhh.org/ From owner-freebsd-hackers Mon Oct 20 06:38:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA22584 for hackers-outgoing; Mon, 20 Oct 1997 06:38:32 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from mbunix.mitre.org (mbunix.mitre.org [129.83.20.100]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA22577 for ; Mon, 20 Oct 1997 06:38:28 -0700 (PDT) (envelope-from guhl@mail90.mitre.org) Received: from FUZZY (fuzzy.mitre.org [129.83.20.83]) by mbunix.mitre.org (8.8.6/8.8.6/mitre.0) with SMTP id JAA03813; Mon, 20 Oct 1997 09:38:19 -0400 (EDT) Date: Mon, 20 Oct 1997 09:38:19 -0400 (EDT) Received: from m15081-mac.mitre.org (128.29.114.90) by fuzzy.mitre.org with SMTP id 8228; Mon, 20 Oct 1997 09:38:17 EST X-Sender: guhl@mail90.mitre.org Message-Id: In-Reply-To: <19971019210220.51925@dcarmich.pr.mcs.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: dcarmich@mcs.com (Douglas Carmichael), freebsd-hackers@freebsd.org From: guhl@mitre.org (George Uhl) Subject: OSI and X.25 support in FreeBSD Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk MITRE's ACET Lab supports X.25 over hdlc using ADAX APC cards in FreeBSD version 2.2.1. We also support OSI protocols (clnp, tp4 and cltp) in our 2.2.1 kernel. E-mail guhl@mitre.org if you are interested in more information. >Is there any support coming for X.25 in FreeBSD, e.g. Eicon cards? >(I'd love to hook up a BBS machine to Sprintnet/Tymnet) George Uhl email: phone: 703-883-7305 The MITRE Corporation Center for Advanced Aviation Systems Development 1820 Dolley Madison Blvd. McLean, VA. 22102 From owner-freebsd-hackers Mon Oct 20 07:49:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA26794 for hackers-outgoing; Mon, 20 Oct 1997 07:49:01 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from citadel.cdsec.com (citadel.cdsec.com [192.96.22.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA26653 for ; Mon, 20 Oct 1997 07:45:12 -0700 (PDT) (envelope-from gram@cdsec.com) Received: (from nobody@localhost) by citadel.cdsec.com (8.8.5/8.6.9) id QAA16483 for ; Mon, 20 Oct 1997 16:54:54 +0200 (SAT) Received: by citadel via recvmail id 16450; Mon Oct 20 16:54:04 1997 by gram.cdsec.com (8.8.5/8.8.5) id QAA11500 for hackers@freebsd.org; Mon, 20 Oct 1997 16:22:11 +0200 (SAT) From: Graham Wheeler Message-Id: <199710201422.QAA11500@cdsec.com> Subject: Bug in 2.2.2 To: hackers@freebsd.org Date: Mon, 20 Oct 1997 16:22:10 +0200 (SAT) X-Mailer: ELM [version 2.4 PL25-h4.1] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi all This is just a brief follow up to the discussion that took place last month about the possible bug in PHKmalloc. There are two points worth mentioning: * the problem has not reoccurred with the firewall gateway program since linking with the alternative libmalloc. * the problem has been noted with other programs, including the firewall's authentication daemon (which I have since linked with libmalloc). More significantly, the problem has also occurred with the Midnight Commander, and with `ps'. [For those who missed the earlier discussion, the problem was corruption of the heap, which resulted in a circularly linked list of memory blocks in the internal heap data structures. At some point, a call to malloc/free then never returns but keeps the process in a running state, chewing up CPU cycles, and the process needs to be killed]. For the ps and mc cases, I could not verify that the code pointer was indeed in the malloc library at the time, but the symptoms displayed were exactly the same as with the earlier gateway problem, which was always in the malloc library. So it seems there is indeed a bug, either in phkmalloc or in some other FreeBSD library code which uses phkmalloc. I apologise for not being able to provide more detail than this. -- Dr Graham Wheeler E-mail: gram@cdsec.com Citadel Data Security Phone: +27(21)23-6065/6/7 Internet/Intranet Network Specialists Mobile: +27(83)-253-9864 Firewalls/Virtual Private Networks Fax: +27(21)24-3656 Data Security Products WWW: http://www.cdsec.com/ From owner-freebsd-hackers Mon Oct 20 08:18:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA28252 for hackers-outgoing; Mon, 20 Oct 1997 08:18:23 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from whqvax.picker.com (whqvax.picker.com [144.54.1.1]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id IAA28241; Mon, 20 Oct 1997 08:18:15 -0700 (PDT) (envelope-from rhh@ct.picker.com) Received: from ct.picker.com by whqvax.picker.com with SMTP; Mon, 20 Oct 1997 11:17:39 -0400 (EDT) Received: from elmer.ct.picker.com by ct.picker.com (4.1/SMI-4.1) id AA16535; Mon, 20 Oct 97 11:17:36 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id LAA20524; Mon, 20 Oct 1997 11:13:17 -0400 Message-Id: <19971020111316.33689@ct.picker.com> Date: Mon, 20 Oct 1997 11:13:16 -0400 From: Randall Hopper To: Kristian Kennaway , "Jonathan M. Bresler" Cc: hackers@FreeBSD.ORG Subject: Re: pulling email addresses from freebsd lists References: <9710170446.AA20901@compton> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81 In-Reply-To: <9710170446.AA20901@compton>; from Kristian Kennaway on Fri, Oct 17, 1997 at 02:16:47PM +0930 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Kristian Kennaway: |I'd just like to note that today I received my first ever spam-mail, |after posting to this list for the first time a few days ago. Until now |I've been successfully "hiding" by not having my email address make it |out onto UseNet or anywhere else grepped by spammers. Jonathan M. Bresler: | we seem to be seeing a new tactic, | evil spammer subscribes and harvests addresses from the | list traffic. I'd hazard a guess that the spammers aren't harvesting from the list e-mail distribution directly but from NetNews (because of those numerous list-to-NetNews gateways that some folks in the world funnel the FreeBSD list traffic into). These pseudo-groups get out and into spam farmer newsrc's without any real action on their part. Easy pickins'. If I didn't choose to post to NetNews with my real e-mail address anyway, I'd complain about these news gateways. As is, I just grin and have some fun bustin' spammers with their ISPs. And procmail bounce rules to postmaster,abuse,root for those ISPs that don't seem to care. Randall From owner-freebsd-hackers Mon Oct 20 08:37:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA29464 for hackers-outgoing; Mon, 20 Oct 1997 08:37:54 -0700 (PDT) (envelope-from owner-freebsd-hackers) 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 IAA29449 for ; Mon, 20 Oct 1997 08:37:45 -0700 (PDT) (envelope-from rivers@dignus.com) 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 LAA12648; Mon, 20 Oct 1997 11:33:03 -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 LAA00287; Mon, 20 Oct 1997 11:09:11 -0400 (EDT) Received: (from rivers@localhost) by lakes.dignus.com (8.8.5/8.6.9) id KAA19512; Mon, 20 Oct 1997 10:59:36 -0400 (EDT) Date: Mon, 20 Oct 1997 10:59:36 -0400 (EDT) From: Thomas David Rivers Message-Id: <199710201459.KAA19512@lakes.dignus.com> To: brian@awfulhak.org, rivers@dignus.com Subject: Re: two natd's running? Cc: freebsd-hackers@freefall.FreeBSD.org Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk All of this is included for context (since this is a rather slow-running thread....) > > > > This is a rather old question I'm just now getting around to... > > > > What I have is a situation where I'd like to two SL/IP connections > > going with multiple natd's running. > > > > Several people had suggested simply having two divert rules in > > rc.firewall and running the two natd's that way. > > > > Here's what I've got the gateway (a 2.2-970510-RELENG machine) at > > 10.0.0.1: > > > > ipfw -f flush > > ipfw -f add 10 divert 32001 ip from any to 192.42.243.0/24 via sl1 > > You can't masquerade in just one direction.... add > > ipfw -f add 10 divert 32001 ip from 192.42.243.0/24 to any via sl1 > > > ipfw -f add 20 divert 32000 ip from any to any via sl0 > > ipfw -f add pass ip from any to any > [.....] > > - Thanks - > > - Dave Rivers - > > > > -- > Brian , , > I followed Brian's suggestion and now have: ipfw -f add 10 divert 32001 ip from any to 192.42.243.0/24 via sl1 ipfw -f add 15 divert 32001 ip from 192.42.243.0/24 to any via sl1 ipfw -f add 20 divert 32000 ip from any to any via sl0 ipfw -f add pass ip from any to any as my firewall configuration.... and - I'm running two natd's: /usr/local/bin/natd -l -port 32000 -interface sl0 -m -u -dynamic /usr/local/bin/natd -l -port 32001 -interface sl1 -m -u -dynamic This appears to be an improvement; as the gateway machine correctly forwards traffic to 192.42.243.0/24 via sl1 (and natd it doing the proper translation.) However; something isn't working in the route tables... On the gateway machine I have: # netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire 10/24 link#1 UC 0 0 10.0.0.3 0:40:33:22:a2:6b UHLW 6 1206 ed0 591 10.23.1.112 192.42.243.1 UGHS 0 0 sl1 10.23.1.115 192.42.243.1 UGHS 0 0 sl1 10.26.1.153 192.42.243.1 UGHS 0 0 sl1 10.26.1.157 192.42.243.1 UGHS 0 0 sl1 10.26.149.40 192.42.243.1 UGHS 0 0 sl1 10.252.1.2 192.42.243.1 UGHS 0 0 sl1 10.253.1.2 192.42.243.1 UGHS 0 0 sl1 127.0.0.1 127.0.0.1 UH 0 0 lo0 130.96.1.21 192.42.243.1 UGHS 0 0 sl1 149.173.52.101 192.42.243.1 UGHS 0 0 sl1 149.173.52.209 192.42.243.1 UGHS 0 0 sl1 149.173.160.12 192.42.243.1 UGHS 0 132 sl1 149.173.166.232 192.42.243.1 UGHS 0 0 sl1 172.16.0.200 192.42.243.1 UGHS 0 0 sl1 192.42.243.1 192.42.243.10 UH 16 12 sl1 192.42.243.10 192.42.243.1 UGHS 0 22 sl1 and, on an interior node, I can ping 192.42.243.10 and 192.42.243.1; but I can't get to any of the other addresses... (e.g. 130.96.1.21 doesn't go out via sl1 as I would like it to...) I'm guessing I have to add more rules for each of the networks I'd like to go out to there - but I was hoping the routing table would take care of that... should it? - Dave Rivers - From owner-freebsd-hackers Mon Oct 20 09:16:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA02306 for hackers-outgoing; Mon, 20 Oct 1997 09:16:05 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA02233 for ; Mon, 20 Oct 1997 09:15:55 -0700 (PDT) (envelope-from nate@rocky.mt.sri.com) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id KAA14139; Mon, 20 Oct 1997 10:15:45 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id KAA29216; Mon, 20 Oct 1997 10:15:44 -0600 (MDT) Date: Mon, 20 Oct 1997 10:15:44 -0600 (MDT) Message-Id: <199710201615.KAA29216@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Cc: freebsd-hackers@freebsd.org (FreeBSD hackers) Subject: Re: Urge to apply the vn device hack even to 2.2.5 In-Reply-To: <19971020092256.EF31838@uriah.heep.sax.de> References: <19971020092256.EF31838@uriah.heep.sax.de> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Here's a confirmation that Mr. KATO's hack for the lockmgr panic on > vn devices does also fix the problems on 2.2.5. > > I would strongly recommend that we apply this hack, instead of > shipping 2.2.5 in the current state, where it's got a high probability > that our users can't successfully run a `make release' on it without > hitting a panic! My advice is to 'just do it'. I suspect Jordan must have the patch on his build box in order for him to roll the release, and since there are few hours left to do it in, it should be done ASAP. With no 'official' FreeBSD-RE experience, I'd be afraid to get yelled at as not understanding all the issues, so I don't dare. :) :) Nate From owner-freebsd-hackers Mon Oct 20 09:16:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA02391 for hackers-outgoing; Mon, 20 Oct 1997 09:16:45 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from wafu.netgate.net (wafu.netgate.net [204.145.147.80]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA02377 for ; Mon, 20 Oct 1997 09:16:35 -0700 (PDT) (envelope-from shigio@wafu.netgate.net) Received: from chiota.signet.or.jp (INS49.tama.dti.ne.jp [210.159.144.3]) by wafu.netgate.net (8.7.5/8.7.3) with ESMTP id IAA21452; Mon, 20 Oct 1997 08:17:18 GMT Message-Id: <199710200817.IAA21452@wafu.netgate.net> Received: from chiota.signet.or.jp (localhost.signet.or.jp [127.0.0.1]) by chiota.signet.or.jp (8.8.5/) with ESMTP id BAA09363; Tue, 21 Oct 1997 01:15:35 +0900 (JST) To: hackers@freebsd.org Cc: shigio@wafu.netgate.net Subject: Re: Kernel Index Date: Tue, 21 Oct 1997 01:15:34 +0900 From: Shigio Yamaguchi Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Oct 9, 1997 23:10:19 -0500, Jonathan wrote: >On Oct 10, 1997 at 08:01:25PM -0700, mdean wrote: >> >> Does anyone have an index of all structs and functions they could send me? >> make GTAGS bombed out on stable for me. >> I'd really like to be able to reference the kernel source quickly. > >Did you run it on the entire src/ tree, or just the src/sys kernel subtree? >I can generate a GTAGS file for the kernel subtree, albeit not for the >entire distribution. I have fixed this bug. Sorry for my late reply. By the way, If you are going to execute gtags(1) at '/usr/src', please confirm the room of your disk. Tag files become very large. # cd /usr/src # gtags # ls -l G*S -rw-r--r-- 1 root wheel 82370560 Oct 20 22:13 GRTAGS -rw-r--r-- 1 root wheel 75882496 Oct 21 00:47 GSYMS -rw-r--r-- 1 root wheel 9904128 Oct 20 20:44 GTAGS # GLOBAL-2.1 make new tag file GSYMS for symbols other than function. If you are not interested in these symbols, you had better to execute gtags like this. % gtags -o '-o' option means 'old', that is, make GTAGS and GRTAGS but doesn't make GSYMS. -- Shigio Yamaguchi (Freelance programmer) Mail: shigio@wafu.netgate.net, WWW: http://wafu.netgate.net/tama/ From owner-freebsd-hackers Mon Oct 20 09:27:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA03198 for hackers-outgoing; Mon, 20 Oct 1997 09:27:21 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from citadel.cdsec.com (citadel.cdsec.com [192.96.22.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA03183; Mon, 20 Oct 1997 09:27:06 -0700 (PDT) (envelope-from gram@cdsec.com) Received: (from nobody@localhost) by citadel.cdsec.com (8.8.5/8.6.9) id SAA19702; Mon, 20 Oct 1997 18:36:55 +0200 (SAT) Received: by citadel via recvmail id 19669; Mon Oct 20 18:36:37 1997 by gram.cdsec.com (8.8.5/8.8.5) id SAA11653; Mon, 20 Oct 1997 18:04:36 +0200 (SAT) From: Graham Wheeler Message-Id: <199710201604.SAA11653@cdsec.com> Subject: Re: Bug in 2.2.2 To: jmb@FreeBSD.ORG (Jonathan M. Bresler) Date: Mon, 20 Oct 1997 18:04:35 +0200 (SAT) Cc: hackers@FreeBSD.ORG In-Reply-To: <199710201613.JAA02114@hub.freebsd.org> from "Jonathan M. Bresler" at Oct 20, 97 09:13:23 am X-Mailer: ELM [version 2.4 PL25-h4.1] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Jon > can you tell me how to reproduce it within X hours? > if i remember correctly, it was failing every X hours > for you. if its statically linked i can hack on > the shared library and see if i can track this down. > The original problem with the gateway usually occurred within less than an hour, but it certainly wasn't a fixed interval. The Midnight Commander instance happened after the mc had been running for quite some time (possibly since the previous week). The mc and ps instances were noticed at the same time. I now speculate that the problem was within mc, not ps - the ps was probably run from the mc command line, and inherited a corrupt heap from the parent process. I can't provide much more detail than this - the sites where it happened are in different cities, and I am mostly just summarising what was reported to me by the administrators of the various firewalls, and, when I can get them to do it, from looking at core dumps generated with SIGABRT. I will write a small program to exercise the heap, and see if I can replicate the problem at all. -- Dr Graham Wheeler E-mail: gram@cdsec.com Citadel Data Security Phone: +27(21)23-6065/6/7 Internet/Intranet Network Specialists Mobile: +27(83)-253-9864 Firewalls/Virtual Private Networks Fax: +27(21)24-3656 Data Security Products WWW: http://www.cdsec.com/ From owner-freebsd-hackers Mon Oct 20 09:48:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA04356 for hackers-outgoing; Mon, 20 Oct 1997 09:48:56 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from intercore.com (num1sun.intercore.com [199.181.243.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA04351 for ; Mon, 20 Oct 1997 09:48:53 -0700 (PDT) (envelope-from robin@intercore.com) Received: (robin@localhost) by intercore.com (8.7.1/8.6.4) id MAA26282; Mon, 20 Oct 1997 12:45:47 -0400 (EDT) Message-ID: <19971020124546.62622@num1sun.intercore.com> Date: Mon, 20 Oct 1997 12:45:46 -0400 From: Robin Cutshaw To: "Matthew D. Fuller" Cc: Robin Cutshaw , Joerg Wunsch , hackers@FreeBSD.ORG Subject: Re: fsck problem with 2.2.5-971015-BETA References: <19971019212958.33788@num1sun.intercore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.79 In-Reply-To: ; from Matthew D. Fuller on Sun, Oct 19, 1997 at 10:04:50PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, Oct 19, 1997 at 10:04:50PM -0500, Matthew D. Fuller wrote: > > > > Why does the fsck work correctly once the system is up in multi-user > > mode? > Because in multi-user, it has access to swap. If your turn swapon in > single-user, I'll bet the fsck will work. > Swap is added just before the fsck (as is evidenced by the swapon message appearing first and pstat -s showing it's there). robin -- ---- Robin Cutshaw internet: robin@interlabs.com robin@intercore.com Internet Labs, Inc. BellNet: 404-817-9787 robin@XFree86.Org "Time is just one damn thing after another" -- PBS/Nova ---- -- From owner-freebsd-hackers Mon Oct 20 10:13:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA06068 for hackers-outgoing; Mon, 20 Oct 1997 10:13:28 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from nagual.pp.ru (ache.relcom.ru [194.58.229.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA06037 for ; Mon, 20 Oct 1997 10:12:35 -0700 (PDT) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.8.7/8.8.7) id UAA01642; Mon, 20 Oct 1997 20:55:11 +0400 (MSD) (envelope-from ache) Date: Mon, 20 Oct 1997 20:55:09 +0400 (MSD) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= To: Joerg Wunsch cc: FreeBSD-Hackers List , Robin Cutshaw , Alexey Bulushev , Mishania Sokolov Subject: Re: fsck problem with 2.2.5-971015-BETA In-Reply-To: <19971019183550.SV35032@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 19 Oct 1997, J Wunsch wrote: > As Robin Cutshaw wrote: > > > "fsck -p" in /etc/rc fails when it gets to the 1st 9GB drive > > with "cannot alloc 2088961 bytes for statemap". > > ISTR a comment that you need to increase the VM resource limits to > fsck large filesystems. We already have PR about this problem, sparse files involved somehow. -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/ From owner-freebsd-hackers Mon Oct 20 10:15:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA06193 for hackers-outgoing; Mon, 20 Oct 1997 10:15:03 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from citadel.cdsec.com (citadel.cdsec.com [192.96.22.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA05900 for ; Mon, 20 Oct 1997 10:11:11 -0700 (PDT) (envelope-from gram@cdsec.com) Received: (from nobody@localhost) by citadel.cdsec.com (8.8.5/8.6.9) id TAA21063 for ; Mon, 20 Oct 1997 19:20:56 +0200 (SAT) Received: by citadel via recvmail id 21028; Mon Oct 20 19:20:14 1997 by gram.cdsec.com (8.8.5/8.8.5) id SAA11704 for hackers@freebsd.org; Mon, 20 Oct 1997 18:48:13 +0200 (SAT) From: Graham Wheeler Message-Id: <199710201648.SAA11704@cdsec.com> Subject: Re: Bug in 2.2.2 To: hackers@freebsd.org Date: Mon, 20 Oct 1997 18:48:12 +0200 (SAT) X-Mailer: ELM [version 2.4 PL25-h4.1] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > can you tell me how to reproduce it within X hours? > if i remember correctly, it was failing every X hours > for you. if its statically linked i can hack on > the shared library and see if i can track this down. I wrote a small program to exercise the heap and ran it for about ten million iterations without a problem. Then I decided to add a periodic call to fork(), as both Midnight Commander and the firewall gateway program both do plenty of these. When I ran this the O/S panicked almost immediately. Here is the program: // A simple program to exercise the heap. #include #include #include #include #include main() { const int vsize = 10000; char **vector = new char*[vsize]; int i, allocs = 0, deletes = 0; int seed = time(0); srand(seed); for (i = 0; i < vsize; i++) vector[i] = 0; i = 0; for (;;) { if ((i%100000) == 0) printf("%d: alloc %d delete %d seed %d\n", i, allocs, deletes, seed); if ((i % 100) == 0) { int pid = fork(); if (pid == 0) exit(0); } int slot = random() % vsize; if (vector[slot]) { delete [] vector[slot]; vector[slot] = 0; deletes++; } else { int l = (random() % 4096)+1; vector[slot] = new char[l]; memset(vector[slot], l, l); allocs++; } if (++i < 0) i = 0; } } I hadn't bothered doing any signal catching here; this was quick 'n dirty. Still, it shouldn't cause a panic. Perhaps there is a connection between this and the other problem? > > So it seems there is indeed a bug, either in phkmalloc or in some > > other FreeBSD library code which uses phkmalloc. I strongly suspect the latter may be the case, and that the nature of the bug is such that it affects phkmalloc but not the other malloc. cheers gram -- Dr Graham Wheeler E-mail: gram@cdsec.com Citadel Data Security Phone: +27(21)23-6065/6/7 Internet/Intranet Network Specialists Mobile: +27(83)-253-9864 Firewalls/Virtual Private Networks Fax: +27(21)24-3656 Data Security Products WWW: http://www.cdsec.com/ From owner-freebsd-hackers Mon Oct 20 11:01:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA09626 for hackers-outgoing; Mon, 20 Oct 1997 11:01:20 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA09612 for ; Mon, 20 Oct 1997 11:01:12 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id SAA16058 for ; Mon, 20 Oct 1997 18:00:45 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.6/8.8.6) id UAA01441; Mon, 20 Oct 1997 20:00:44 +0200 (MET DST) Date: Mon, 20 Oct 1997 20:00:44 +0200 (MET DST) Message-Id: <199710201800.UAA01441@bitbox.follo.net> From: Eivind Eklund To: freebsd-hackers@freebsd.org Subject: Kernel config for web hosts Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Have anybody got a well-tuned (kernel or sysctl) configuration for web hosts? This might be an idea to include on the distribution CD (which is why I'm posting this here); most people don't know how to tune a kernel well enough. The configs we use have a tendency to introduce 5s lags at random points, for some inexplicable reason (different network-cards, different Apache-versions, different motherboards, different nets - the only common feature seems to be FreeBSD 2.2.2 with some apache version) Eivind. From owner-freebsd-hackers Mon Oct 20 11:24:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA11047 for hackers-outgoing; Mon, 20 Oct 1997 11:24:51 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA11039 for ; Mon, 20 Oct 1997 11:24:37 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.7/8.8.7) id LAA23047; Mon, 20 Oct 1997 11:23:29 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpd023030; Mon Oct 20 11:23:23 1997 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id LAA09061; Mon, 20 Oct 1997 11:23:20 -0700 (MST) From: Terry Lambert Message-Id: <199710201823.LAA09061@usr05.primenet.com> Subject: Re: values for exit() To: joerg_wunsch@uriah.heep.sax.de Date: Mon, 20 Oct 1997 18:23:19 +0000 (GMT) Cc: hackers@FreeBSD.ORG, jacques@wired.ctech.ac.za In-Reply-To: <19971018085300.UT45874@uriah.heep.sax.de> from "J Wunsch" at Oct 18, 97 08:53:00 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > > > Where can I find the exit values for > > > > > exit()? Meaning, what is the difference > > > > > between eg exit(1) and exit(2)? > > > > errno.h > > Only in TerryBSD. In FreeBSD, stick with sysexits(3). Too bad you didn't quote the rest of my message. The other OS's whose shells output messages for the program exit values for non-script driven program starts are: UnixWare 1.x UnixWare 2.x Solaris 2.x SCO Version 5 Of course, Jorg could be right, and everyone else could be wrong. 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-hackers Mon Oct 20 11:35:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA11647 for hackers-outgoing; Mon, 20 Oct 1997 11:35:00 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA11632 for ; Mon, 20 Oct 1997 11:34:51 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.7/8.8.7) id LAA16051; Mon, 20 Oct 1997 11:34:43 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp04.primenet.com, id smtpd016047; Mon Oct 20 11:34:40 1997 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id LAA09783; Mon, 20 Oct 1997 11:34:31 -0700 (MST) From: Terry Lambert Message-Id: <199710201834.LAA09783@usr05.primenet.com> Subject: Re: Freebsd 3.0 current fails ipfilter 3.2b8 build (fwd) To: darrenr@cyber.com.au (Darren Reed) Date: Mon, 20 Oct 1997 18:34:31 +0000 (GMT) Cc: tlambert@primenet.com, julian@whistle.com, hackers@FreeBSD.ORG In-Reply-To: <199710190545.PAA19458@plum.cyber.com.au> from "Darren Reed" at Oct 19, 97 03:45:30 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > If the code isn't portable to Linux, SVR4, and Solaris without > > compile time switches, why write it? > > Well, prior to these changes to FreeBSD, it was portable between > *BSD/SunOS4/Solaris2 without any compile time switches - not sure > about Linux. Why ? Because up until recently, all would give > you "struct ifnet" if you included net/if.h. > > So there you have it. > > This makes it harder to port code to FreeBSD. > > Or, from the other angle, FreeBSD code is less portable. > > Isn't that just wonderful ? *spew* It seems your complaint is that the use of the struct ifnet in the internal structures is not bracketed by: #ifdef __IF_VAR_H__ #endif If you are using structures that contain this opaque data object, then you are doing something wrong. This is not to say that I'm happy with the code (I'm not), but that this type of interface seperation is both (1) necessary, and (2) desirable, from a "pure environment" perspective. 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-hackers Mon Oct 20 11:43:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA12151 for hackers-outgoing; Mon, 20 Oct 1997 11:43:43 -0700 (PDT) (envelope-from owner-freebsd-hackers) 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 LAA12139 for ; Mon, 20 Oct 1997 11:43:34 -0700 (PDT) (envelope-from jkh@time.cdrom.com) 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 LAA13795; Mon, 20 Oct 1997 11:41:34 -0700 (PDT) To: Nate Williams cc: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch), freebsd-hackers@FreeBSD.ORG (FreeBSD hackers) Subject: Re: Urge to apply the vn device hack even to 2.2.5 In-reply-to: Your message of "Mon, 20 Oct 1997 10:15:44 MDT." <199710201615.KAA29216@rocky.mt.sri.com> Date: Mon, 20 Oct 1997 11:41:33 -0700 Message-ID: <13791.877372893@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > My advice is to 'just do it'. I suspect Jordan must have the patch on > his build box in order for him to roll the release, and since there are > few hours left to do it in, it should be done ASAP. I don't, that's the weird thing. I'm running a standard 2.2-stable kernel here. Maybe it only hits in situations where you have a certain amount of RAM? In any case, the tag is going down in just over 6 hours, so a decision will need to be made quickly. :) Jordan From owner-freebsd-hackers Mon Oct 20 12:48:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA15180 for hackers-outgoing; Mon, 20 Oct 1997 12:48:28 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA15173 for ; Mon, 20 Oct 1997 12:48:25 -0700 (PDT) (envelope-from nate@rocky.mt.sri.com) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id NAA15483; Mon, 20 Oct 1997 13:48:13 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id NAA00007; Mon, 20 Oct 1997 13:48:13 -0600 (MDT) Date: Mon, 20 Oct 1997 13:48:13 -0600 (MDT) Message-Id: <199710201948.NAA00007@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Jordan K. Hubbard" Cc: Nate Williams , joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch), freebsd-hackers@freebsd.org (FreeBSD hackers) Subject: Re: Urge to apply the vn device hack even to 2.2.5 In-Reply-To: <13791.877372893@time.cdrom.com> References: <199710201615.KAA29216@rocky.mt.sri.com> <13791.877372893@time.cdrom.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > My advice is to 'just do it'. I suspect Jordan must have the patch on > > his build box in order for him to roll the release, and since there are > > few hours left to do it in, it should be done ASAP. > > I don't, that's the weird thing. I'm running a standard 2.2-stable > kernel here. Maybe it only hits in situations where you have a > certain amount of RAM? Hmm, I don't know. It's been seen by lots of folks though. > In any case, the tag is going down in just over 6 hours, so a decision > will need to be made quickly. :) I decided to take the heat for it. I haven't been in a good flame wars in awhile. It won't break the compile in any case, and I know enough people who build 'private' releases that breaking it seems silly. Nate ps. It *shouldn't* break your build, but if it does yell at me and yank it out. From owner-freebsd-hackers Mon Oct 20 12:54:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA15508 for hackers-outgoing; Mon, 20 Oct 1997 12:54:04 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA15497; Mon, 20 Oct 1997 12:53:56 -0700 (PDT) (envelope-from jamil@trojanhorse.ml.org) Received: from localhost (jamil@localhost) by trojanhorse.ml.org (8.8.7/8.8.5) with SMTP id MAA28921; Mon, 20 Oct 1997 12:53:15 -0700 (PDT) Date: Mon, 20 Oct 1997 12:53:15 -0700 (PDT) From: "Jamil J. Weatherbee" To: Randall Hopper cc: Kristian Kennaway , "Jonathan M. Bresler" , hackers@FreeBSD.ORG Subject: Re: pulling email addresses from freebsd lists In-Reply-To: <19971020111316.33689@ct.picker.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk One thing that might help is possibly assigning handles to email addresses on freebsd.org like 189291@freebsd.org = jamil@trojanhorse.ml.org and only allowing mail from other handles on that list to be redirected through freebsd.org to the mailer It would be much less likely for a spammer to attack because they would half to attack from a subscribed account. Or something like this... On Mon, 20 Oct 1997, Randall Hopper wrote: > Kristian Kennaway: > |I'd just like to note that today I received my first ever spam-mail, > |after posting to this list for the first time a few days ago. Until now > |I've been successfully "hiding" by not having my email address make it > |out onto UseNet or anywhere else grepped by spammers. > > Jonathan M. Bresler: > | we seem to be seeing a new tactic, > | evil spammer subscribes and harvests addresses from the > | list traffic. > > > I'd hazard a guess that the spammers aren't harvesting from the list e-mail > distribution directly but from NetNews (because of those numerous > list-to-NetNews gateways that some folks in the world funnel the FreeBSD > list traffic into). These pseudo-groups get out and into spam farmer > newsrc's without any real action on their part. Easy pickins'. > > If I didn't choose to post to NetNews with my real e-mail address anyway, > I'd complain about these news gateways. As is, I just grin and have some > fun bustin' spammers with their ISPs. And procmail bounce rules to > postmaster,abuse,root for those ISPs that don't seem to care. > > Randall > > From owner-freebsd-hackers Mon Oct 20 13:08:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA16502 for hackers-outgoing; Mon, 20 Oct 1997 13:08:12 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from news.IAEhv.nl (root@news.IAEhv.nl [194.151.64.4]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id NAA16454 for ; Mon, 20 Oct 1997 13:07:51 -0700 (PDT) (envelope-from devet@adv.IAEhv.nl) Received: from LOCAL (uucp@localhost) by news.IAEhv.nl (8.6.13/1.63) with IAEhv.nl; pid 23145 on Mon, 20 Oct 1997 20:07:29 GMT; id UAA23145 efrom: devet@adv.IAEhv.nl; eto: hackers@freebsd.org Received: (from devet@localhost) by adv.IAEhv.nl (8.8.5/8.8.6) id WAA06920; Mon, 20 Oct 1997 22:03:28 +0200 (CEST) Date: Mon, 20 Oct 1997 22:03:28 +0200 (CEST) From: Arjan de Vet Message-Id: <199710202003.WAA06920@adv.IAEhv.nl> To: hackers@freebsd.org Subject: Re: Urge to apply the vn device hack even to 2.2.5 X-Newsgroups: list.freebsd.hackers In-Reply-To: <13791.877372893@time.cdrom.com> References: <199710201615.KAA29216@rocky.mt.sri.com> Organization: Internet Access Eindhoven, the Netherlands Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <13791.877372893@time.cdrom.com> you write: >> My advice is to 'just do it'. I suspect Jordan must have the patch on >> his build box in order for him to roll the release, and since there are >> few hours left to do it in, it should be done ASAP. > >I don't, that's the weird thing. I'm running a standard 2.2-stable >kernel here. Maybe it only hits in situations where you have a >certain amount of RAM? I've done a 'make release' for 2.2-stable at least 5 times last week and I haven't seen the vn panics either (with 64MB of RAM). Only some ioctl message, see below. Arjan [...] Compressing doc files... sh -e /usr/src/release/doFS.sh /R/stage /mnt 1440 /R/stage/mfsfd 8000 minimum ioctl DIOCWLABEL: Operation not supported by device Warning: Block size restricts cylinders per group to 8. /dev/rvn0c: 2880 sectors in 1 cylinders of 1 tracks, 2880 sectors 1.4MB in 1 cyl groups (8 c/g, 11.25MB/g, 1312 i/g) super-block backups (for fsck -b #) at: 32, 2287 blocks Filesystem 1K-blocks Used Avail Capacity iused ifree %iused Mounted on /dev/vn0c 1247 1159 88 93% 190 1120 15% /mnt /dev/rvn0c: clean, 176 free (8 frags, 21 blocks, 0.3% fragmentation) >>> Filesystem is 1440 K, 88 left >>> 8000 bytes/inode, 1120 left >>> 184 mv fs-image fs-image.std mv fs-image.size fs-image.std.size [...] kzip data end address will be: 0x39ff28 sh -e /usr/src/release/doFS.sh /R/stage /mnt 1440 /R/stage/boot.std 100000 fd1440 ioctl DIOCWLABEL: Operation not supported by device Warning: Block size restricts cylinders per group to 9. /dev/rvn0c: 2880 sectors in 1 cylinders of 1 tracks, 2880 sectors 1.4MB in 1 cyl groups (9 c/g, 12.66MB/g, 128 i/g) super-block backups (for fsck -b #) at: 32, 2397 blocks Filesystem 1K-blocks Used Avail Capacity iused ifree %iused Mounted on /dev/vn0c 1395 1206 189 86% 5 121 4% /mnt /dev/rvn0c: clean, 379 free (11 frags, 46 blocks, 0.4% fragmentation) mv fs-image /R/stage/floppies/bootstd.flp mv /R/stage/floppies/bootstd.flp /R/stage/floppies/boot.flp Regular boot floppy made. touch release.8 From owner-freebsd-hackers Mon Oct 20 13:20:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA17289 for hackers-outgoing; Mon, 20 Oct 1997 13:20:57 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: (from jmb@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA17269; Mon, 20 Oct 1997 13:20:37 -0700 (PDT) (envelope-from jmb) From: "Jonathan M. Bresler" Message-Id: <199710202020.NAA17269@hub.freebsd.org> Subject: Re: pulling email addresses from freebsd lists To: jamil@trojanhorse.ml.org (Jamil J. Weatherbee) Date: Mon, 20 Oct 1997 13:20:37 -0700 (PDT) Cc: rhh@ct.picker.com, kkennawa@physics.adelaide.edu.au, jmb@FreeBSD.ORG, hackers@FreeBSD.ORG In-Reply-To: from "Jamil J. Weatherbee" at Oct 20, 97 12:53:15 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jamil J. Weatherbee wrote: > > > > One thing that might help is possibly assigning handles to email addresses > on freebsd.org like > > 189291@freebsd.org = jamil@trojanhorse.ml.org > > and only allowing mail from other handles on that list > to be redirected through freebsd.org to the mailer > > It would be much less likely for a spammer to attack because they would > half to attack from a subscribed account. > > Or something like this... > while this is correct, it defeatss on of the purposes of the mailing lists...to provide quick answers to users questions. and it does not prevent people from subscribing and spamming the lists. sendmail.cf blocked 14 spam messages today. jmb From owner-freebsd-hackers Mon Oct 20 13:22:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA17393 for hackers-outgoing; Mon, 20 Oct 1997 13:22:43 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id NAA17388 for ; Mon, 20 Oct 1997 13:22:38 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id WAA08668 for freebsd-hackers@freebsd.org; Mon, 20 Oct 1997 22:22:37 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id WAA06381; Mon, 20 Oct 1997 22:18:16 +0200 (MET DST) Message-ID: <19971020221816.FF50549@uriah.heep.sax.de> Date: Mon, 20 Oct 1997 22:18:16 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@freebsd.org (FreeBSD hackers) Subject: Re: Urge to apply the vn device hack even to 2.2.5 References: <199710201615.KAA29216@rocky.mt.sri.com> <13791.877372893@time.cdrom.com> <199710201948.NAA00007@rocky.mt.sri.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199710201948.NAA00007@rocky.mt.sri.com>; from Nate Williams on Oct 20, 1997 13:48:13 -0600 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Nate Williams wrote: > I decided to take the heat for it. I haven't been in a good flame wars > in awhile. It won't break the compile in any case, and I know enough > people who build 'private' releases that breaking it seems silly. Thanks, Nate! I'll immediately give it a try. -- 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-hackers Mon Oct 20 13:44:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA18693 for hackers-outgoing; Mon, 20 Oct 1997 13:44:24 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA18685 for ; Mon, 20 Oct 1997 13:44:17 -0700 (PDT) (envelope-from mrcpu@cdsnet.net) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by mail.cdsnet.net (8.8.6/8.8.6) with SMTP id NAA18089 for ; Mon, 20 Oct 1997 13:44:14 -0700 (PDT) Date: Mon, 20 Oct 1997 13:44:14 -0700 (PDT) From: Jaye Mathisen To: hackers@freebsd.org Subject: Is there any way to build a completely static system? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I mean no .so's, nothing. Just the necessare .a's, and all binaries statically linked... Getting the binaries statically linked is easy, but I was hoping NOSHARED would stop building the .so's for /usr/lib, but it seems to anyway. Not critical, just curious. From owner-freebsd-hackers Mon Oct 20 13:53:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA19270 for hackers-outgoing; Mon, 20 Oct 1997 13:53:36 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from milehigh.denver.net (milehigh.denver.net [204.144.180.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA19261 for ; Mon, 20 Oct 1997 13:53:23 -0700 (PDT) (envelope-from jdc@milehigh.denver.net) Received: (from jdc@localhost) by milehigh.denver.net (8.8.5/8.8.5) id OAA08780; Mon, 20 Oct 1997 14:53:53 -0600 (MDT) Message-ID: <19971020145352.23528@denver.net> Date: Mon, 20 Oct 1997 14:53:52 -0600 From: John-David Childs To: hackers@freebsd.org Subject: Re: Need source... References: <199710172000.OAA21209@rocky.mt.sri.com> <199710171834.MAA03146@harmony.village.org> <199710172030.OAA03665@harmony.village.org> <199710172034.OAA21410@rocky.mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.79 In-Reply-To: <199710172034.OAA21410@rocky.mt.sri.com>; from Nate Williams on Fri, Oct 17, 1997 at 02:34:11PM -0600 Organization: Enterprise Internet Solutions Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Or you could buy an external Jaz-drive and SCSI PCMCIA card ;-) When I wanted to load 2.2-stable + X on my 800meg hard drive (not a laptop), I partitioned my h.d. into a 100-meg 95 partition where C:\WINDOWS sits and used the rest for FreeBSD. Win95 apps run from E: Unfortunately, I was stupid (and cheap) and purchased an Adaptec-2920 before I ran outta money..so I can't use my Jaz drive with 2.2-stable/2.2.5 until the PAO stuff (and maybe the "hack" posted here a few months ago) is updated. -- John-David Childs (JC612) Enterprise Internet Solutions Systems Administration @denver.net/internet-coach/@ronan.net & Network Engineering 1031 S. Parker Rd. #I-8 Denver, CO 80231 Our country has plenty of good five-cent cigars, but the trouble is they charge fifteen cents for them. On Friday October 17, 1997, Nate Williams had this to say about "Re: Need source...": > > : And the problem is? I've got 3 OS's on my 800MB drive, Win95, > > : FreeBSD-2.1 (stable non-changing unix environment), and FreeBSD-current > > : (development environ with OS sources on it that is *very* tight on disk > > : space.) I had to double-space the Win95 partition to get it to work, > > : but it does. Unfortunately, I wasn't able to squeeze X onto the FreeBSD > > : installations due to disk space. > > > > But I want X :-). It sounds like I can get most of what I want under > > FreeBSD, however. -current has been stable enough for me for a long > > time, so I may just run that. > > Then you probably have enough room for X. The double-space under Win95 > was the biggest factor in me being able to get both on the 800MB. (That > and the fact that I don't do a whole lot under '95). > [SNIP] From owner-freebsd-hackers Mon Oct 20 15:15:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA23829 for hackers-outgoing; Mon, 20 Oct 1997 15:15:24 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from bcarsde4.localhost (mailgate.nortel.ca [192.58.194.74]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA23821 for ; Mon, 20 Oct 1997 15:15:18 -0700 (PDT) (envelope-from atrens@nortel.ca) Message-Id: <199710202215.PAA23821@hub.freebsd.org> Received: from bcars520.ca.nortel.com (actually 47.128.5.188) by bcarsde4.localhost; Mon, 20 Oct 1997 18:13:00 -0400 Received: from bnr.ca by bcars520.bnr.ca id <07023-0@bcars520.bnr.ca>; Mon, 20 Oct 1997 18:12:30 -0400 Date: 20 Oct 1997 18:12 EDT To: hackers@FreeBSD.ORG From: "Andrew Atrens" Subject: Re: pulling email addresses from freebsd lists Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk www.vix.com/spam seems to have been updated since my last visit in August - they have several new tools (or at least new to me) that you may find helpful. Imho the (more or less) free and open nature of the net, means that spammers will always be a problem. I think our biggest advantage is that we outnumber them. I think our biggest weakness is that we address the issue as individuals, ie we don't leverage our numbers. Perhaps we could come up with some sort of automated mechanism for collecting and collectively complaining to joe spammer's isp. What I'm getting at it is that when one of us on the list gets spam, likely we all do. Yet in most instances we all need to go through the effort of identifying the guilty party, and sending an appropriate complaint. if this information was captured somewhere, and accessible by (perhaps) a web interface, then it would save all of the duplicated investigation work required to nail down the spammer's identity. Opinions anyone? Andrew. (opinions are mine, not Nortel's) > > One thing that might help is possibly assigning handles to email addresses > on freebsd.org like > > 189291@freebsd.org = jamil@trojanhorse.ml.org > > and only allowing mail from other handles on that list > to be redirected through freebsd.org to the mailer > > It would be much less likely for a spammer to attack because they would > half to attack from a subscribed account. > > Or something like this... > > > > > On Mon, 20 Oct 1997, Randall Hopper wrote: > > > Kristian Kennaway: > > |I'd just like to note that today I received my first ever spam-mail, > > |after posting to this list for the first time a few days ago. Until now > > |I've been successfully "hiding" by not having my email address make it > > |out onto UseNet or anywhere else grepped by spammers. > > > > Jonathan M. Bresler: > > | we seem to be seeing a new tactic, > > | evil spammer subscribes and harvests addresses from the > > | list traffic. > > > > > > I'd hazard a guess that the spammers aren't harvesting from the list e-mail > > distribution directly but from NetNews (because of those numerous > > list-to-NetNews gateways that some folks in the world funnel the FreeBSD > > list traffic into). These pseudo-groups get out and into spam farmer > > newsrc's without any real action on their part. Easy pickins'. > > > > If I didn't choose to post to NetNews with my real e-mail address anyway, > > I'd complain about these news gateways. As is, I just grin and have some > > fun bustin' spammers with their ISPs. And procmail bounce rules to > > postmaster,abuse,root for those ISPs that don't seem to care. > > > > Randall > > > > > > From owner-freebsd-hackers Mon Oct 20 15:17:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA23950 for hackers-outgoing; Mon, 20 Oct 1997 15:17:08 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from monk.via.net (monk.via.net [140.174.204.10]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id PAA23940 for ; Mon, 20 Oct 1997 15:17:03 -0700 (PDT) (envelope-from joe@via.net) Received: (from joe@localhost) by monk.via.net (8.6.11/8.6.12) id PAA17351 for freebsd-hackers@freebsd.org; Mon, 20 Oct 1997 15:06:28 -0700 Date: Mon, 20 Oct 1997 15:06:28 -0700 From: Joe McGuckin Message-Id: <199710202206.PAA17351@monk.via.net> To: freebsd-hackers@freebsd.org Subject: 2.2.2-RELEASE '875 SCSI won't negotiage X-Sun-Charset: US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk (ncr0:0:0): "QUANTUM XP32275W LXY4" type 0 fixed SCSI 2 sd0(ncr0:0:0): Direct-Access sd0(ncr0:0:0): WIDE SCSI (16 bit) enabled sd0(ncr0:0:0): 20.0 MB/s (100 ns, offset 16) Shouldn't this report back 40.0 MB/s for fast wide ultra ? From owner-freebsd-hackers Mon Oct 20 15:53:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA26237 for hackers-outgoing; Mon, 20 Oct 1997 15:53:40 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id PAA26228 for ; Mon, 20 Oct 1997 15:53:29 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id AAA10385 for hackers@FreeBSD.ORG; Tue, 21 Oct 1997 00:52:57 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id AAA15149; Tue, 21 Oct 1997 00:36:21 +0200 (MET DST) Message-ID: <19971021003621.XE33370@uriah.heep.sax.de> Date: Tue, 21 Oct 1997 00:36:21 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Subject: Re: Urge to apply the vn device hack even to 2.2.5 References: <199710201615.KAA29216@rocky.mt.sri.com> <199710202003.WAA06920@adv.IAEhv.nl> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199710202003.WAA06920@adv.IAEhv.nl>; from Arjan de Vet on Oct 20, 1997 22:03:28 +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Arjan de Vet wrote: > I've done a 'make release' for 2.2-stable at least 5 times last week and I > haven't seen the vn panics either (with 64MB of RAM). Only some ioctl > message, see below. I didn't have an occasion to run a full `make release' after applying Nate's fix within the short time remaining before 2.2.5 is due. However, i've tried to torture the vn device of such a kernel, and haven't seen any ill effect. So i think we are safe with it. Perhaps it's indeed that you've got too much RAM. I remember Mr. KATO telling something about a condition that the lockmgr panic happened whenever something (from the vn object) was about to be paged in or out. So my normal (-current) `make release' machine has 32 MB of RAM (and X11 running by the same time), perhaps that condition is simply more likely then. -- 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-hackers Mon Oct 20 16:11:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA27286 for hackers-outgoing; Mon, 20 Oct 1997 16:11:18 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id QAA27262; Mon, 20 Oct 1997 16:11:05 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id BAA10796; Tue, 21 Oct 1997 01:10:57 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id BAA15227; Tue, 21 Oct 1997 01:02:55 +0200 (MET DST) Message-ID: <19971021010255.JX53463@uriah.heep.sax.de> Date: Tue, 21 Oct 1997 01:02:55 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG, hardware@FreeBSD.ORG Cc: tarkhil@mgt.msk.ru Subject: Re: on Worm detection References: <199710200519.JAA24209@asteroid.mgt.msk.ru> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199710200519.JAA24209@asteroid.mgt.msk.ru>; from Alexander B. Povolotsky on Oct 20, 1997 09:19:21 +0400 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Alexander B. Povolotsky wrote: > Since my 2.2-STABLE fails to detect Pinnacle Micro 4X4 CD-R as worm, and > 2.2.2 or 2.2.1 did it, and I don't want to fetch it and install again, can't > one wise man describe me process of worm detection, so I'll try to make it > working? All the magic is in /sys/scsi/scsiconf.c. If you'd care to quote the boot messages, i could tell you what to add there. -- 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-hackers Mon Oct 20 16:35:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA28677 for hackers-outgoing; Mon, 20 Oct 1997 16:35:53 -0700 (PDT) (envelope-from owner-freebsd-hackers) 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 QAA28670 for ; Mon, 20 Oct 1997 16:35:45 -0700 (PDT) (envelope-from jkh@time.cdrom.com) 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 QAA15924; Mon, 20 Oct 1997 16:34:42 -0700 (PDT) To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) cc: hackers@FreeBSD.ORG Subject: Re: Urge to apply the vn device hack even to 2.2.5 In-reply-to: Your message of "Tue, 21 Oct 1997 00:36:21 +0200." <19971021003621.XE33370@uriah.heep.sax.de> Date: Mon, 20 Oct 1997 16:34:42 -0700 Message-ID: <15920.877390482@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Perhaps it's indeed that you've got too much RAM. I remember Mr. KATO > telling something about a condition that the lockmgr panic happened > whenever something (from the vn object) was about to be paged in or > out. So my normal (-current) `make release' machine has 32 MB of RAM > (and X11 running by the same time), perhaps that condition is simply I was going to ask if RAM was a factor since I have 128MB in my release building box and don't hit a lot of low memory problems that others do as a result (and current.freebsd.org is another 128MB box - maybe we should make our release-a-day server a 486SX with 8MB of memory and switch it to being a release-a-week server instead. We'd not have as useful a service by far, but it sure would catch those load sensitive bugs early. :-) Jordan P.S. Yes, of course I'm just joking. :) From owner-freebsd-hackers Mon Oct 20 16:52:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA29596 for hackers-outgoing; Mon, 20 Oct 1997 16:52:15 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA29589 for ; Mon, 20 Oct 1997 16:52:07 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.7/8.8.7) id QAA04335; Mon, 20 Oct 1997 16:51:51 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp04.primenet.com, id smtpd004333; Mon Oct 20 16:51:50 1997 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id QAA27105; Mon, 20 Oct 1997 16:51:43 -0700 (MST) From: Terry Lambert Message-Id: <199710202351.QAA27105@usr05.primenet.com> Subject: Re: Freebsd 3.0 current fails ipfilter 3.2b8 build (fwd) To: darrenr@cyber.com.au (Darren Reed) Date: Mon, 20 Oct 1997 23:51:43 +0000 (GMT) Cc: tlambert@primenet.com, hackers@FreeBSD.ORG In-Reply-To: <199710190548.PAA19493@plum.cyber.com.au> from "Darren Reed" at Oct 19, 97 03:48:32 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > well, ifconfig, netstat, etc. all need it. They reference kernel internal structures as an API. > > > if you're writing your own LKM for a network driver, you need it. LKM code is kernel code. Kernel code can have any requirements that the kernel environment chooses to place on it (one of which is what include files are necessary). > > > if you're writing firewalling packet filtering code, you need it. Again, kernel code. > > > "struct ifnet" is used in _lots_ of places. Not lots of places outside kernel code. > > > if you want to simulate kernel code, then you also need it. [ ... ] > What if I mention this: > > I was using "struct ifnet" _WITHOUT_ wanting to look at kernel memory. > > > Why would you want to do that, you ask. > > So you can more easily build userland code which interfaces with the > code used in the kernel and test it that way. In other words, unit testing. I'd claim that your test framework must include whatever the kernel includes, in order to properly simulate a kernel. Further, the code you are unit testing in this fashion is -- kernel code. I don't see this as being inconvenient except for users of "promiscuous" interfaces (like your examples: ifconfig, netstat, etc.). I personally *like* the idea of a "speed-bump" to slow down people going hell bent for leather down the wrong road to an interface... 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-hackers Mon Oct 20 16:58:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA00117 for hackers-outgoing; Mon, 20 Oct 1997 16:58:20 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from plum.cyber.com.au (plum.cyber.com.au [203.7.155.24]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id QAA00111 for ; Mon, 20 Oct 1997 16:58:14 -0700 (PDT) (envelope-from darrenr@cyber.com.au) Received: (from darrenr@localhost) by plum.cyber.com.au (8.6.12/8.6.6) id JAA09206; Tue, 21 Oct 1997 09:57:17 +1000 From: Darren Reed Message-Id: <199710202357.JAA09206@plum.cyber.com.au> Subject: FreeBSD 3.0 kernel API ?! To: tlambert@primenet.com (Terry Lambert) Date: Tue, 21 Oct 1997 09:57:17 +1000 (EST) Cc: julian@whistle.com, hackers@FreeBSD.ORG In-Reply-To: <199710201834.LAA09783@usr05.primenet.com> from "Terry Lambert" at Oct 20, 97 06:34:31 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In some mail I received from Terry Lambert, sie wrote > > > > If the code isn't portable to Linux, SVR4, and Solaris without > > > compile time switches, why write it? > > > > Well, prior to these changes to FreeBSD, it was portable between > > *BSD/SunOS4/Solaris2 without any compile time switches - not sure > > about Linux. Why ? Because up until recently, all would give > > you "struct ifnet" if you included net/if.h. > > > > So there you have it. > > > > This makes it harder to port code to FreeBSD. > > > > Or, from the other angle, FreeBSD code is less portable. > > > > Isn't that just wonderful ? *spew* > > It seems your complaint is that the use of the struct ifnet in > the internal structures is not bracketed by: > > #ifdef __IF_VAR_H__ > #endif No, it isn't. > If you are using structures that contain this opaque data object, > then you are doing something wrong. > This is not to say that I'm happy with the code (I'm not), but > that this type of interface seperation is both (1) necessary, and > (2) desirable, from a "pure environment" perspective. Sigh. This is all very amusing, I guess. Here's a tip for you: if you *really* want to separate what user programs can and can not include (or should and should not), don't put any "kernel only" include files under /usr/include and remove all references from /usr/include files to anything that should only be in the kernel. Sure, you'll break lots of software out there, be totally incompatible with everything else and annoy lots of 3rd party software writers, but it _will_ achieve the goal you're aiming for: - penalising anyone and everyone who makes use of a kernel structure for non-kernel code, irrespective of its use. Personally, I don't think any changes should be made for the sake of making a change to hide structures but rather, effort should be put into developing useful interfaces which software can take advantage of. Darren p.s. what's up with hackers@freebsd ? I haven't seen any mail come through it for a while now... From owner-freebsd-hackers Mon Oct 20 17:01:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA00417 for hackers-outgoing; Mon, 20 Oct 1997 17:01:09 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA00404 for ; Mon, 20 Oct 1997 17:01:01 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id RAA28205 for ; Mon, 20 Oct 1997 17:00:29 -0700 (PDT) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma028203; Mon Oct 20 17:00:24 1997 Received: (from archie@localhost) by bubba.whistle.com (8.8.5/8.6.12) id RAA11140 for freebsd-hackers@freebsd.org; Mon, 20 Oct 1997 17:00:24 -0700 (PDT) From: Archie Cobbs Message-Id: <199710210000.RAA11140@bubba.whistle.com> Subject: Broken device LKM in 2.2 To: freebsd-hackers@freebsd.org Date: Mon, 20 Oct 1997 17:00:23 -0700 (PDT) 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I guess nobody makes device type LKM's in 2.2.. but sys/lkm.h is broken with respect to them. Here's a hack that fixes this. Perhaps the "name ## _module", which is different from the other module types, is there for some reason (?) Anyway, it's incompatible with the DISPATCH macro defined later in the file, and this fixes it... More properly we should use MOD_DISPATCH instead of DISPATCH, keep the "name ## _module" in MOD_DEV, add it also to the other types, and use the first argument of MOD_DISPATCH -- the module name -- in that macro to do a similar concatenation there. -Archie Index: lkm.h =================================================================== RCS file: /cvs/freebsd/src/sys/sys/lkm.h,v retrieving revision 1.12.2.1 diff -c -r1.12.2.1 lkm.h *** 1.12.2.1 1997/06/29 08:45:45 --- lkm.h 1997/10/20 23:23:49 *************** *** 234,240 **** #define MOD_DEV(name,devtype,devslot,devp) \ MOD_DECL(name); \ ! static struct lkm_dev name ## _module = { \ LM_DEV, \ LKM_VERSION, \ #name ## "_mod", \ --- 234,240 ---- #define MOD_DEV(name,devtype,devslot,devp) \ MOD_DECL(name); \ ! static struct lkm_dev _module = { \ LM_DEV, \ LKM_VERSION, \ #name ## "_mod", \ ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Mon Oct 20 17:11:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA01084 for hackers-outgoing; Mon, 20 Oct 1997 17:11:31 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.5.83]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA01077 for ; Mon, 20 Oct 1997 17:11:27 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.7/8.8.5) id RAA01527; Mon, 20 Oct 1997 17:11:13 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp02.primenet.com, id smtpd001515; Mon Oct 20 17:11:08 1997 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id RAA28373; Mon, 20 Oct 1997 17:11:05 -0700 (MST) From: Terry Lambert Message-Id: <199710210011.RAA28373@usr05.primenet.com> Subject: Re: FreeBSD 3.0 kernel API ?! To: darrenr@cyber.com.au (Darren Reed) Date: Tue, 21 Oct 1997 00:11:04 +0000 (GMT) Cc: tlambert@primenet.com, julian@whistle.com, hackers@FreeBSD.ORG In-Reply-To: <199710202357.JAA09206@plum.cyber.com.au> from "Darren Reed" at Oct 21, 97 09:57:17 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Sigh. This is all very amusing, I guess. Here's a tip for you: > if you *really* want to separate what user programs can and can not > include (or should and should not), don't put any "kernel only" > include files under /usr/include and remove all references from > /usr/include files to anything that should only be in the kernel. The idea, I believe, is to clean up our own misuse of KVM as a non-procedural interface to kernel data. Non-procedural interfaces are bad because: 1) You can't hook them 2) A data version change equals an interface change, and requires you to rebuild everything that references the data 3) You can't "version" the interface so that the program using it can operate against both old and new versions. > Sure, you'll break lots of software out there, be totally > incompatible with everything else and annoy lots of 3rd party > software writers, but it _will_ achieve the goal you're aiming > for: - penalising anyone and everyone who makes use of a kernel > structure for non-kernel code, irrespective of its use. The only thing we intended to break was ourselves, because we knew we were engaging in bad programming habits. It's only your poor fortune to have *also* been engaging in bad programming habits. > Personally, I don't think any changes should be made for the > sake of making a change to hide structures but rather, effort > should be put into developing useful interfaces which software > can take advantage of. I agree. But how can we get a picture of the spanning set of new interfaces needed unless we take away all of the old interfaces, and log what fails? Sure, we could organically grow things, and let duplicate functionality (say like /procfs and sysinit) creep up on us, so that we can't really point at "here is the right way", but do we really want that? Brass tacks time: Why do *you, personally* need the kernel internal structure defined by struct ifnet? 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-hackers Mon Oct 20 17:55:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA04620 for hackers-outgoing; Mon, 20 Oct 1997 17:55:07 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from plum.cyber.com.au (plum.cyber.com.au [203.7.155.24]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id RAA04594 for ; Mon, 20 Oct 1997 17:55:02 -0700 (PDT) (envelope-from darrenr@cyber.com.au) Received: (from darrenr@localhost) by plum.cyber.com.au (8.6.12/8.6.6) id KAA09620; Tue, 21 Oct 1997 10:54:24 +1000 From: Darren Reed Message-Id: <199710210054.KAA09620@plum.cyber.com.au> Subject: Re: FreeBSD 3.0 kernel API ?! To: tlambert@primenet.com (Terry Lambert) Date: Tue, 21 Oct 1997 10:54:23 +1000 (EST) Cc: julian@whistle.com, hackers@Freebsd.org In-Reply-To: <199710210011.RAA28373@usr05.primenet.com> from "Terry Lambert" at Oct 21, 97 00:11:04 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@Freebsd.org X-Loop: FreeBSD.org Precedence: bulk In some mail I received from Terry Lambert, sie wrote > > I agree. But how can we get a picture of the spanning set of new > interfaces needed unless we take away all of the old interfaces, > and log what fails? Sure, we could organically grow things, and > let duplicate functionality (say like /procfs and sysinit) creep > up on us, so that we can't really point at "here is the right way", > but do we really want that? Hmmm, I think that duplicate functionality has some merit. For one, it allows you to migrate from old to new rather than having to choose - providing that it is posible to have both in a sane way. So whilst the old functionality will not be available in the future, you can use the old one whilst you refit to use the new one. > Brass tacks time: > > Why do *you, personally* need the kernel internal structure > defined by struct ifnet? Because I try to use the same code for compiling into the kernel as into the testing code. If I have to fake struct ifnet, I'll only end up building a structure which has the same fields anyway. Even though things like if_output aren't going to call the same device driver output routine, I can use it to write to a file and verify what's getting written out. Darren From owner-freebsd-hackers Mon Oct 20 18:05:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA05419 for hackers-outgoing; Mon, 20 Oct 1997 18:05:14 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: (from jmb@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA05395; Mon, 20 Oct 1997 18:05:03 -0700 (PDT) (envelope-from jmb) From: "Jonathan M. Bresler" Message-Id: <199710210105.SAA05395@hub.freebsd.org> Subject: Re: Bug in 2.2.2 To: gram@cdsec.com (Graham Wheeler) Date: Mon, 20 Oct 1997 18:05:02 -0700 (PDT) Cc: hackers@FreeBSD.ORG In-Reply-To: <199710201648.SAA11704@cdsec.com> from "Graham Wheeler" at Oct 20, 97 06:48:12 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Graham Wheeler wrote: > > > > > can you tell me how to reproduce it within X hours? > > if i remember correctly, it was failing every X hours > > for you. if its statically linked i can hack on > > the shared library and see if i can track this down. > > I wrote a small program to exercise the heap and ran it for about ten million > iterations without a problem. Then I decided to add a periodic call to fork(), > as both Midnight Commander and the firewall gateway program both do plenty > of these. When I ran this the O/S panicked almost immediately. > > Here is the program: > > // A simple program to exercise the heap. Graham, i have run your test program, both with and without fork(), against phkmalloc from 2.2 upgraded to CTM 470 for over 10 million iterations. the upgrade replaces /home/src/lib/libc/stdlib/malloc.c version 1.18.2.2 with version 1.18.2.3. there are changes in the way that phkmalloc deals with changing sizes fo allocated memory and more. ;) can you upgrade from 2.2.2 to 2.2.5 and run your code again? 2.2.5 will be out very soon. the source tree will be tagged within the hour (Oct 20th 6pm PDT). jmb From owner-freebsd-hackers Mon Oct 20 18:24:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA06485 for hackers-outgoing; Mon, 20 Oct 1997 18:24:53 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from fly.HiWAAY.net (root@fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA06474 for ; Mon, 20 Oct 1997 18:24:48 -0700 (PDT) (envelope-from dkelly@nospam.hiwaay.net) Received: from nospam.hiwaay.net (tnt2-162.HiWAAY.net [208.147.148.162]) by fly.HiWAAY.net (8.8.7/8.8.6) with ESMTP id UAA20202; Mon, 20 Oct 1997 20:24:38 -0500 (CDT) Received: from nospam.hiwaay.net (localhost [127.0.0.1]) by nospam.hiwaay.net (8.8.7/8.8.4) with ESMTP id UAA14405; Mon, 20 Oct 1997 20:24:37 -0500 (CDT) Message-Id: <199710210124.UAA14405@nospam.hiwaay.net> X-Mailer: exmh version 2.0zeta 7/24/97 To: Joe McGuckin cc: freebsd-hackers@FreeBSD.ORG From: dkelly@hiwaay.net Subject: Re: 2.2.2-RELEASE '875 SCSI won't negotiage In-reply-to: Message from Joe McGuckin of "Mon, 20 Oct 1997 15:06:28 PDT." <199710202206.PAA17351@monk.via.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 20 Oct 1997 20:24:34 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Joe McGuckin writes: > > (ncr0:0:0): "QUANTUM XP32275W LXY4" type 0 fixed SCSI 2 > sd0(ncr0:0:0): Direct-Access > sd0(ncr0:0:0): WIDE SCSI (16 bit) enabled > sd0(ncr0:0:0): 20.0 MB/s (100 ns, offset 16) > > > Shouldn't this report back 40.0 MB/s for fast wide ultra ? Probably should. But it might not really be up to 40 MB/sec. The MB/sec and ns numbers agree. I got this the other day on my new Asus SC875 and 9G IBM UW drive: ncr0 rev 3 int a irq 11 on pci0:11 ncr0 waiting for scsi devices to settle (ncr0:0:0): WIDE SCSI (16 bit) enabled(ncr0:0:0): 10.0 MB/s (200 ns, offset 15) (ncr0:0:0): "IBM OEM DCHS09W 2222" type 0 fixed SCSI 2 sd1(ncr0:0:0): Direct-Access sd1(ncr0:0:0): WIDE SCSI (16 bit) enabled sd1(ncr0:0:0): 20.0 MB/s (100 ns, offset 15) 8689MB (17796077 512 byte sectors) Am mildly concerned about the 10.0 MB/s message that starts it off. And I'm thinking about the whole issue because I'm not certian my performance is up to snuff. Using bonnie: IBM OEM DCHS09W on Asus SC875, new & empty 2.4G filesystem at end of disk: -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 100 3972 41.8 3986 14.6 2234 7.5 6700 76.3 8228 16.4 108.4 2.6 ^^^^ this seems low SEAGATE ST32550N on Adaptec 2940 (AIC-7870) old 86% full 1.8G fs -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 100 3980 43.2 4402 13.9 1774 5.0 4260 48.3 3759 5.7 71.5 1.5 System is an Asus P6NP5 PPro-166/512k 32M RAM. # scsi -f /dev/rsd1c -m 8 -P 3 WCE: 0 MF: 0 RCD: 0 Demand Retention Priority: 1 Write Retention Priority: 1 Disable Pre-fetch Transfer Length: 65535 Minimum Pre-fetch: 0 Maximum Pre-fetch: 65535 Maximum Pre-fetch Ceiling: 65535 Observed the Seagate had the WCE set (Write Cache Enable) so I did the same for the IBM. Flipped the WCE bit from 0 to 1 and got this on the IBM (last fs): -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 100 7402 76.5 7927 31.0 2311 7.8 6587 75.2 8207 16.2 110.3 2.5 ^^^^ ^^^^ both of these are *much* better. After enabling the write cache, this drive is comparable to the new Seagate 4.3G Barracuda on an Adaptec 2940AU (AIC-7860) and P-133 I'm playing with at work: -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 100 3653 75.6 8523 36.4 2293 15.9 3595 70.6 9183 38.4 92.2 4.3 It really bugged me that my UW HD on PentiumPro was being beat by a P-133 with narrow SCSI. Then I began to wonder if there was a difference between inner and outer tracks. This fs starts about 200M past block 0, while the above (up 2, the IBM) starts 2.4G from the end of the disk: -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 100 8098 79.7 9385 38.3 2758 9.2 6426 74.0 9772 20.1 111.2 2.5 ...and that's more like it! What really brought all this about was when a dump | restore from old 2.1G Seagate to new 9.1G IBM reported 500k/sec thruput. The IBM fs's were still mounted async as sysinstall left them. -- David Kelly N4HHE, dkelly@hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. From owner-freebsd-hackers Mon Oct 20 18:32:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA06906 for hackers-outgoing; Mon, 20 Oct 1997 18:32:53 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.5.83]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA06883 for ; Mon, 20 Oct 1997 18:32:36 -0700 (PDT) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.7/8.8.5) id SAA08273; Mon, 20 Oct 1997 18:31:25 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp02.primenet.com, id smtpd008268; Mon Oct 20 18:31:23 1997 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id SAA24304; Mon, 20 Oct 1997 18:31:21 -0700 (MST) From: Terry Lambert Message-Id: <199710210131.SAA24304@usr08.primenet.com> Subject: Re: FreeBSD 3.0 kernel API ?! To: darrenr@cyber.com.au (Darren Reed) Date: Tue, 21 Oct 1997 01:31:21 +0000 (GMT) Cc: hackers@freebsd.org In-Reply-To: <199710210054.KAA09620@plum.cyber.com.au> from "Darren Reed" at Oct 21, 97 10:54:23 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Hmmm, I think that duplicate functionality has some merit. For one, > it allows you to migrate from old to new rather than having to choose - > providing that it is posible to have both in a sane way. So whilst > the old functionality will not be available in the future, you can > use the old one whilst you refit to use the new one. This is the Novell NetWare API problem. If I have an old interface and a new interface, I will choose to use the old interface. Why? Because it's the larger market: my code will run on both old and new. If I used the new interface, I'd only be able to run on new. The market "old + new" > the market "old". Simple economics. > > Brass tacks time: > > > > Why do *you, personally* need the kernel internal structure > > defined by struct ifnet? > > Because I try to use the same code for compiling into the kernel > as into the testing code. If I have to fake struct ifnet, I'll > only end up building a structure which has the same fields anyway. > Even though things like if_output aren't going to call the same > device driver output routine, I can use it to write to a file > and verify what's getting written out. I still don't understand. If it is kernel code, even if you plan on running it in user space, you will define KERNEL. If you don't you are not testing the code you will be running. If it's kernel code you are testing, you will need to include if_var.h for it to run in the kernel; therefore you need to include if_var.h for it to run in the test jig, which pretends to be the kernel. I think the issue is maybe that your test environment doesn't look sufficiently like a kernel... 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-hackers Mon Oct 20 18:36:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA07190 for hackers-outgoing; Mon, 20 Oct 1997 18:36:30 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id SAA07182 for ; Mon, 20 Oct 1997 18:36:26 -0700 (PDT) (envelope-from tom@sdf.com) Received: from tom by misery.sdf.com with smtp (Exim 1.73 #1) id 0xNTDx-00025N-00; Mon, 20 Oct 1997 18:35:09 -0700 Date: Mon, 20 Oct 1997 18:35:04 -0700 (PDT) From: Tom To: freebsd-hackers@freebsd.org Subject: DLT drives Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk DLT tape drives will work under FreeBSD, right? I would think that they would be just be a standard tape device. I'm looking at one of the Quantum DLT drives. Tom From owner-freebsd-hackers Mon Oct 20 19:01:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA08783 for hackers-outgoing; Mon, 20 Oct 1997 19:01:26 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA08778 for ; Mon, 20 Oct 1997 19:01:19 -0700 (PDT) (envelope-from durian@plutotech.com) Received: from shane.plutotech.com (shane.plutotech.com [206.168.67.149]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id UAA10419 for ; Mon, 20 Oct 1997 20:01:12 -0600 (MDT) Message-Id: <199710210201.UAA10419@pluto.plutotech.com> From: "Mike Durian" To: hackers@freebsd.org Subject: user vm addr to kernel vm addr Date: Mon, 20 Oct 1997 20:01:11 -0600 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In my virtual file system I'd like to speed up reads and writes by copying directly from the uio structure to a vm address of a buffer in the user process running on behalf of the filesystem. I'm currently shoving all the data through a socket that the user process reads from and copies into a buffer. I'd like to go direct and skip the socket writing part. Does that make sense? Anyway, I want to copy from a uio to a different process's vm space. I can get the vm address of the destination buffer over a socket and think I can use vm_fault_wire to make sure it stays accessable, but I don't know how to convert that user space vm address into a kernel space vm address that I can then use with copyout. Is there an easy (or any) way to do this? mike From owner-freebsd-hackers Mon Oct 20 19:37:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA10828 for hackers-outgoing; Mon, 20 Oct 1997 19:37:43 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from plum.cyber.com.au (plum.cyber.com.au [203.7.155.24]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id TAA10110 for ; Mon, 20 Oct 1997 19:20:31 -0700 (PDT) (envelope-from darrenr@cyber.com.au) Received: (from darrenr@localhost) by plum.cyber.com.au (8.6.12/8.6.6) id MAA11955; Tue, 21 Oct 1997 12:18:59 +1000 From: Darren Reed Message-Id: <199710210218.MAA11955@plum.cyber.com.au> Subject: Re: FreeBSD 3.0 kernel API ?! To: tlambert@primenet.com (Terry Lambert) Date: Tue, 21 Oct 1997 12:18:59 +1000 (EST) Cc: darrenr@cyber.com.au, hackers@freebsd.org In-Reply-To: <199710210131.SAA24304@usr08.primenet.com> from "Terry Lambert" at Oct 21, 97 01:31:21 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In some mail I received from Terry Lambert, sie wrote > > > > Brass tacks time: > > > > > > Why do *you, personally* need the kernel internal structure > > > defined by struct ifnet? > > > > Because I try to use the same code for compiling into the kernel > > as into the testing code. If I have to fake struct ifnet, I'll > > only end up building a structure which has the same fields anyway. > > Even though things like if_output aren't going to call the same > > device driver output routine, I can use it to write to a file > > and verify what's getting written out. > > I still don't understand. If it is kernel code, even if you plan on > running it in user space, you will define KERNEL. If you don't you > are not testing the code you will be running. There are a couple of things lacking from the typical libc that are in kernels. Things like mbuf functions, etc. > If it's kernel code you are testing, you will need to include if_var.h > for it to run in the kernel; therefore you need to include if_var.h > for it to run in the test jig, which pretends to be the kernel. Well, you see, that's just it. It doesn't need anything else, only the "struct ifnet". I'd argue that a structure can be used and should be available anywhere, it just describes a way to store some values in memory. I have no problems with keeping variable names and function prototypes away from users (in different .h files or whatever), it even makes sense. But I don't think the same logic should be extended to structures. I assume things like struct proc and struct user are still available without defining KERNEL ? > I think the issue is maybe that your test environment doesn't look > sufficiently like a kernel... No, it doesn't. Given that malloc(3) doesn't quite grok M_WAITOK, probably never will :-) Darren From owner-freebsd-hackers Mon Oct 20 19:44:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA11185 for hackers-outgoing; Mon, 20 Oct 1997 19:44:37 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA11180 for ; Mon, 20 Oct 1997 19:44:35 -0700 (PDT) (envelope-from karl@Mars.mcs.net) Received: from Mars.mcs.net (karl@Mars.mcs.net [192.160.127.85]) by Kitten.mcs.com (8.8.5/8.8.2) with ESMTP id VAA22574; Mon, 20 Oct 1997 21:44:34 -0500 (CDT) Received: (from karl@localhost) by Mars.mcs.net (8.8.7/8.8.2) id VAA29554; Mon, 20 Oct 1997 21:44:34 -0500 (CDT) Message-ID: <19971020214434.06832@Mars.Mcs.Net> Date: Mon, 20 Oct 1997 21:44:34 -0500 From: Karl Denninger To: Tom Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: DLT drives References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.64 In-Reply-To: ; from Tom on Mon, Oct 20, 1997 at 06:35:04PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, Oct 20, 1997 at 06:35:04PM -0700, Tom wrote: > > DLT tape drives will work under FreeBSD, right? I would think that they > would be just be a standard tape device. I'm looking at one of the > Quantum DLT drives. > > Tom Yes, they do, and quite nicely. We use them here (they're the only media that has enough capacity and speed to be useful in our environment). -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | NEW! K56Flex modem support is now available Voice: [+1 312 803-MCS1 x219]| 56kbps DIGITAL ISDN DOV on analog lines! Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal From owner-freebsd-hackers Mon Oct 20 19:50:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA11476 for hackers-outgoing; Mon, 20 Oct 1997 19:50:15 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA11422 for ; Mon, 20 Oct 1997 19:49:46 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.7/8.8.7) id LAA15928; Mon, 20 Oct 1997 11:27:24 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp04.primenet.com, id smtpd015926; Mon Oct 20 11:27:23 1997 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id LAA09252; Mon, 20 Oct 1997 11:27:21 -0700 (MST) From: Terry Lambert Message-Id: <199710201827.LAA09252@usr05.primenet.com> Subject: Re: FreeBSD authentication... To: dec@phoenix.its.rpi.edu (David E. Cross) Date: Mon, 20 Oct 1997 18:27:21 +0000 (GMT) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: from "David E. Cross" at Oct 18, 97 10:29:58 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Is there any interest (should there be) to mooving to Pluggabl > Authentication Modules. (Since they are implimented as shared libraries, > that you link in as needed, would we need to rewrite ld.so a bit to ensure > that people couldn't set their LD_LIBRARY_PATH, and then run su to get > full root acces, sans password?) Have you located a PAM implementation (not necessarily modules, but the framework itself) which is under UCB copyright instead of GPL? User authentication is a system critical function, like the kernel; it's unlikely that PAM would be any more acceptable than a GPL'ed driver if it's critical to system operation. 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-hackers Mon Oct 20 19:55:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA11773 for hackers-outgoing; Mon, 20 Oct 1997 19:55:30 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id TAA11765 for ; Mon, 20 Oct 1997 19:55:26 -0700 (PDT) (envelope-from tom@sdf.com) Received: from tom by misery.sdf.com with smtp (Exim 1.73 #1) id 0xNURs-00027h-00; Mon, 20 Oct 1997 19:53:36 -0700 Date: Mon, 20 Oct 1997 19:53:33 -0700 (PDT) From: Tom To: Karl Denninger cc: freebsd-hackers@freebsd.org Subject: Re: DLT drives In-Reply-To: <19971020214434.06832@Mars.Mcs.Net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 20 Oct 1997, Karl Denninger wrote: > On Mon, Oct 20, 1997 at 06:35:04PM -0700, Tom wrote: > > > > DLT tape drives will work under FreeBSD, right? I would think that they > > would be just be a standard tape device. I'm looking at one of the > > Quantum DLT drives. > > > > Tom > > Yes, they do, and quite nicely. We use them here (they're the only media > that has enough capacity and speed to be useful in our environment). What kind? Quantum, HP, or... Since you apparently need a lot of capacity, do also you use a changer? > -- > -- > Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin > http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service > | NEW! K56Flex modem support is now available > Voice: [+1 312 803-MCS1 x219]| 56kbps DIGITAL ISDN DOV on analog lines! > Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal > > Tom From owner-freebsd-hackers Mon Oct 20 20:09:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA12458 for hackers-outgoing; Mon, 20 Oct 1997 20:09:03 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA12444 for ; Mon, 20 Oct 1997 20:08:37 -0700 (PDT) (envelope-from karl@Mars.mcs.net) Received: from Mars.mcs.net (karl@Mars.mcs.net [192.160.127.85]) by Kitten.mcs.com (8.8.5/8.8.2) with ESMTP id WAA24160; Mon, 20 Oct 1997 22:07:45 -0500 (CDT) Received: (from karl@localhost) by Mars.mcs.net (8.8.7/8.8.2) id WAA00484; Mon, 20 Oct 1997 22:07:44 -0500 (CDT) Message-ID: <19971020220744.21190@Mars.Mcs.Net> Date: Mon, 20 Oct 1997 22:07:44 -0500 From: Karl Denninger To: Tom Cc: Karl Denninger , freebsd-hackers@FreeBSD.ORG Subject: Re: DLT drives References: <19971020214434.06832@Mars.Mcs.Net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.64 In-Reply-To: ; from Tom on Mon, Oct 20, 1997 at 07:53:33PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, Oct 20, 1997 at 07:53:33PM -0700, Tom wrote: > > On Mon, 20 Oct 1997, Karl Denninger wrote: > > > On Mon, Oct 20, 1997 at 06:35:04PM -0700, Tom wrote: > > > > > > DLT tape drives will work under FreeBSD, right? I would think that they > > > would be just be a standard tape device. I'm looking at one of the > > > Quantum DLT drives. > > > > > > Tom > > > > Yes, they do, and quite nicely. We use them here (they're the only media > > that has enough capacity and speed to be useful in our environment). > > What kind? Quantum, HP, or... I run two Compaq/Quantum 15/30s. > Since you apparently need a lot of capacity, do also you use a changer? 2x30GB works ok for us at present, but we don't back up the news spool :-) -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | NEW! K56Flex modem support is now available Voice: [+1 312 803-MCS1 x219]| 56kbps DIGITAL ISDN DOV on analog lines! Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal From owner-freebsd-hackers Mon Oct 20 20:22:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA13265 for hackers-outgoing; Mon, 20 Oct 1997 20:22:04 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from shell.futuresouth.com (shell.futuresouth.com [207.141.254.20]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA13257 for ; Mon, 20 Oct 1997 20:22:01 -0700 (PDT) (envelope-from fullermd@futuresouth.com) Received: from shell.futuresouth.com (mail.futuresouth.com [207.141.254.21]) by shell.futuresouth.com (8.8.5/8.8.5) with SMTP id WAA15712 for ; Mon, 20 Oct 1997 22:21:53 -0500 (CDT) Date: Mon, 20 Oct 1997 22:21:52 -0500 (CDT) From: "Matthew D. Fuller" To: hackers@freebsd.org Subject: Boot.flp + parallel ZIP...? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'm considering trying to assemble a boot floppy with parallel port ZIP drive support. If it works, it'll be a lot easier to install from than floppies (I know from unfortunate experience), but still have the easy, do-it-yourself type of experience. It would also be easier for people with small hard drives who don't want to waste space on a DOS partition to install from, but don't want to much around with installing another hard drive, or a SCSI bus for ZIP, etc. This would be useful for me in a few situations, at least a little fun, and (I think) a nice addition to our repetoir of installation methods. I've often wished to install from a single ZIP disk instead of 50 floppies. So here're my questions: 1) Anyone already done it? 2) Is there any technical reason it can't be done? 3) Any reason it shouldn't be done? 4) Would it require any extraordinary means? i.e., serious source hacking 5) Any hints? 6) Want it if I make it? *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* | FreeBSD; the way computers were meant to be | * "The only reason I'm burning my candle at both ends, is * | that I haven't figured out how to light the middle yet."| * fullermd@futuresouth.com :-} MAtthew Fuller * | http://keystone.westminster.edu/~fullermd | *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* From owner-freebsd-hackers Mon Oct 20 20:26:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA13533 for hackers-outgoing; Mon, 20 Oct 1997 20:26:21 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from sasami.jurai.net (winter@sasami.jurai.net [207.96.1.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA13521 for ; Mon, 20 Oct 1997 20:26:16 -0700 (PDT) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.7/8.8.7) with SMTP id XAA05988; Mon, 20 Oct 1997 23:25:54 -0400 (EDT) Date: Mon, 20 Oct 1997 23:25:54 -0400 (EDT) From: "Matthew N. Dodd" To: dkelly@hiwaay.net cc: Joe McGuckin , freebsd-hackers@FreeBSD.ORG Subject: Re: 2.2.2-RELEASE '875 SCSI won't negotiage In-Reply-To: <199710210124.UAA14405@nospam.hiwaay.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 20 Oct 1997 dkelly@hiwaay.net wrote: > It really bugged me that my UW HD on PentiumPro was being beat by a P-133 > with narrow SCSI. Then I began to wonder if there was a difference between > inner and outer tracks. This fs starts about 200M past block 0, while the > above (up 2, the IBM) starts 2.4G from the end of the disk: Which is why you buy the largest, fastest drives available and short stroke them when you want a really fast RAID system. 10k RPM drives are nice but the track to track seek delay is still a large factor in performance. Ideally I'd have an array of 100s of disk, each using only the outer track. In a RAID 0/1 set, this would be really fast. :) /* Matthew N. Dodd | A memory retaining a love you had for life winter@jurai.net | As cruel as it seems nothing ever seems to http://www.jurai.net/~winter | go right - FLA M 3.1:53 */ From owner-freebsd-hackers Mon Oct 20 20:52:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA15010 for hackers-outgoing; Mon, 20 Oct 1997 20:52:01 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA14988 for ; Mon, 20 Oct 1997 20:51:54 -0700 (PDT) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (localhost [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id JAA02577; Tue, 21 Oct 1997 09:25:10 +0930 (CST) Message-Id: <199710202355.JAA02577@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Graham Wheeler cc: hackers@freebsd.org Subject: Re: Bug in 2.2.2 In-reply-to: Your message of "Sat, 20 Oct 1997 18:48:12 +0200." <199710201648.SAA11704@cdsec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Oct 1997 09:25:08 +0930 From: Mike Smith Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > > can you tell me how to reproduce it within X hours? > > if i remember correctly, it was failing every X hours > > for you. if its statically linked i can hack on > > the shared library and see if i can track this down. > > I wrote a small program to exercise the heap and ran it for about ten million > iterations without a problem. Then I decided to add a periodic call to fork(), > as both Midnight Commander and the firewall gateway program both do plenty > of these. When I ran this the O/S panicked almost immediately. This is starting to sound as though it might be related to the problem that Marc Slemko and I (at least) are seeing with programs occupying 3x required swap. I'm not sure if his system forks a lot, but our code certainly does. No crashes/panics/arena corruption, but if there's collateral damage in the VM system, then I can imagine that phkmalloc is going to get its knickers much more twisted than other mallocs, because it seems to dovetail closely with the VM behaviour. > Here is the program: Saved. I'm hoping to have a monster release-builder box going this morning, and if I do I'll try this on 2.2.5 and 3.x. mike From owner-freebsd-hackers Mon Oct 20 21:06:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA16018 for hackers-outgoing; Mon, 20 Oct 1997 21:06:18 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id VAA16010 for ; Mon, 20 Oct 1997 21:06:12 -0700 (PDT) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id DAA20149; Tue, 21 Oct 1997 03:50:28 +0100 From: Luigi Rizzo Message-Id: <199710210250.DAA20149@labinfo.iet.unipi.it> Subject: How to deal with ERESTART ? To: hackers@freebsd.org Date: Tue, 21 Oct 1997 03:50:28 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I am having a problem in dealing with ERESTART in the audio driver. Right now I have a sequence like res = tsleep(..., PRIBIO | PCATCH , ..., timeout ) if (res == EINTR || res = ERESTART) ... do the same thing, typically abort operations. the aim was to make it easy for apps to gain control on the driver. Catching ERESTART this way had some interesting side effects on some applications which makes me thing that it is probably wrong to assimilate ERESTART and EINTR ? So my question is: when can i get ERESTART as a result from tsleep(), and would it be better to just restart the tsleep in this case ? Cheers Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-hackers Mon Oct 20 21:17:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA16777 for hackers-outgoing; Mon, 20 Oct 1997 21:17:08 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA16760 for ; Mon, 20 Oct 1997 21:16:58 -0700 (PDT) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (localhost.gsoft.com.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id NAA00473; Tue, 21 Oct 1997 13:43:31 +0930 (CST) Message-Id: <199710210413.NAA00473@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: "Mike Durian" cc: hackers@freebsd.org Subject: Re: user vm addr to kernel vm addr In-reply-to: Your message of "Mon, 20 Oct 1997 20:01:11 CST." <199710210201.UAA10419@pluto.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Oct 1997 13:43:30 +0930 From: Mike Smith Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > In my virtual file system I'd like to speed up reads and writes > by copying directly from the uio structure to a vm address of > a buffer in the user process running on behalf of the filesystem. uiomove() does this. > I'm currently shoving all the data through a socket that the > user process reads from and copies into a buffer. I'd like to > go direct and skip the socket writing part. Does that make sense? Yup. mike From owner-freebsd-hackers Mon Oct 20 21:18:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA16850 for hackers-outgoing; Mon, 20 Oct 1997 21:18:12 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA16836 for ; Mon, 20 Oct 1997 21:18:07 -0700 (PDT) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (localhost.gsoft.com.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id NAA00457; Tue, 21 Oct 1997 13:42:33 +0930 (CST) Message-Id: <199710210412.NAA00457@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Terry Lambert cc: dec@phoenix.its.rpi.edu (David E. Cross), freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD authentication... In-reply-to: Your message of "Mon, 20 Oct 1997 18:27:21 GMT." <199710201827.LAA09252@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Oct 1997 13:42:33 +0930 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Is there any interest (should there be) to mooving to Pluggabl > > Authentication Modules. (Since they are implimented as shared libraries, > > that you link in as needed, would we need to rewrite ld.so a bit to ensure > > that people couldn't set their LD_LIBRARY_PATH, and then run su to get > > full root acces, sans password?) > > Have you located a PAM implementation (not necessarily modules, but the > framework itself) which is under UCB copyright instead of GPL? The Linux-PAM library is available under a dual (either-or) license. Again, please see my page at http://www.smith.net.au/~mike. There is a working and mostly-functional port of a slightly out-of-date version linked off there, and the Linux-PAM people have been very easy to work with. At one point Randy Terbush was attacking the libpwdb code (similarly licensed), but I haven't heard from him for some time. This module adds significant and useful functionality, but the code is Bad. > User authentication is a system critical function, like the kernel; > it's unlikely that PAM would be any more acceptable than a GPL'ed > driver if it's critical to system operation. The problems with PAM and our current model are more related to the current woolly concept of a "session", particularly associating an "end" with a "beginning". mike From owner-freebsd-hackers Mon Oct 20 21:20:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA17020 for hackers-outgoing; Mon, 20 Oct 1997 21:20:43 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA17015 for ; Mon, 20 Oct 1997 21:20:39 -0700 (PDT) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id VAA26456; Mon, 20 Oct 1997 21:19:01 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd026454; Tue Oct 21 04:18:59 1997 Date: Mon, 20 Oct 1997 21:17:32 -0700 (PDT) From: Julian Elischer To: Terry Lambert cc: "David E. Cross" , freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD authentication... In-Reply-To: <199710201827.LAA09252@usr05.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 20 Oct 1997, Terry Lambert wrote: > > Is there any interest (should there be) to mooving to Pluggabl > > Authentication Modules. (Since they are implimented as shared libraries, > > that you link in as needed, would we need to rewrite ld.so a bit to ensure > > that people couldn't set their LD_LIBRARY_PATH, and then run su to get > > full root acces, sans password?) > > Have you located a PAM implementation (not necessarily modules, but the > framework itself) which is under UCB copyright instead of GPL? > The MIT PAM which Linux uses is under a dual BSD/GNU copyright. > User authentication is a system critical function, like the kernel; > it's unlikely that PAM would be any more acceptable than a GPL'ed > driver if it's critical to system operation. > > > 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-hackers Mon Oct 20 22:10:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA19307 for hackers-outgoing; Mon, 20 Oct 1997 22:10:21 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from gate.mgt.msk.ru (mgtrep.24h.dialup.ru [194.87.18.139]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA19299 for ; Mon, 20 Oct 1997 22:10:12 -0700 (PDT) (envelope-from tarkhil@mgt.msk.ru) Received: from asteroid.mgt.msk.ru (asteroid.mgt.msk.ru [192.168.133.145]) by gate.mgt.msk.ru (8.8.6/8.8.6) with ESMTP id JAA18194; Tue, 21 Oct 1997 09:10:20 +0400 (MSD) Received: from asteroid.mgt.msk.ru (localhost.mgt.msk.ru [127.0.0.1]) by asteroid.mgt.msk.ru (8.8.7/8.8.6) with ESMTP id JAA01364; Tue, 21 Oct 1997 09:09:21 +0400 (MSD) Message-Id: <199710210509.JAA01364@asteroid.mgt.msk.ru> To: Arjan de Vet cc: hackers@FreeBSD.ORG Reply-To: tarkhil@mgt.msk.ru Subject: Re: Urge to apply the vn device hack even to 2.2.5 In-reply-to: Your message of "Mon, 20 Oct 1997 22:03:28 +0200." <199710202003.WAA06920@adv.IAEhv.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Oct 1997 09:09:21 +0400 From: "Alexander B. Povolotsky" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I've done a 'make release' for 2.2-stable at least 5 times last week and I > haven't seen the vn panics either (with 64MB of RAM). Only some ioctl > message, see below. Failed, with 32 and 128 MB... Anyway, I hope it's now history ;-) Alex. From owner-freebsd-hackers Mon Oct 20 22:14:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA19455 for hackers-outgoing; Mon, 20 Oct 1997 22:14:47 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA19447 for ; Mon, 20 Oct 1997 22:14:41 -0700 (PDT) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (localhost.gsoft.com.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id OAA00653; Tue, 21 Oct 1997 14:40:31 +0930 (CST) Message-Id: <199710210510.OAA00653@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Julian Elischer cc: Terry Lambert , "David E. Cross" , freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD authentication... In-reply-to: Your message of "Mon, 20 Oct 1997 21:17:32 MST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Oct 1997 14:40:31 +0930 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Have you located a PAM implementation (not necessarily modules, but the > > framework itself) which is under UCB copyright instead of GPL? > > The MIT PAM which Linux uses is under a dual BSD/GNU copyright. Which PAM is this? Are you referring to "Linux-PAM", ie. the Andrew Morgan code? This is heavily supported by RedHat. mike From owner-freebsd-hackers Mon Oct 20 22:17:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA19608 for hackers-outgoing; Mon, 20 Oct 1997 22:17:24 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from pluto.plutotech.com (ken@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA19602 for ; Mon, 20 Oct 1997 22:17:21 -0700 (PDT) (envelope-from ken@plutotech.com) Received: (from ken@localhost) by pluto.plutotech.com (8.8.5/8.8.5) id XAA18704; Mon, 20 Oct 1997 23:17:20 -0600 (MDT) From: Kenneth Merry Message-Id: <199710210517.XAA18704@pluto.plutotech.com> Subject: Re: user vm addr to kernel vm addr In-Reply-To: <199710210201.UAA10419@pluto.plutotech.com> from Mike Durian at "Oct 20, 97 08:01:11 pm" To: durian@plutotech.com (Mike Durian) Date: Mon, 20 Oct 1997 23:17:20 -0600 (MDT) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Mike Durian wrote... > In my virtual file system I'd like to speed up reads and writes > by copying directly from the uio structure to a vm address of > a buffer in the user process running on behalf of the filesystem. > I'm currently shoving all the data through a socket that the > user process reads from and copies into a buffer. I'd like to > go direct and skip the socket writing part. Does that make sense? > Anyway, I want to copy from a uio to a different process's vm space. > I can get the vm address of the destination buffer over a socket and > think I can use vm_fault_wire to make sure it stays accessable, but > I don't know how to convert that user space vm address into a > kernel space vm address that I can then use with copyout. > Is there an easy (or any) way to do this? I'm not positive this is what you're looking for, but... one way to do it is to map the user address into the kernel address space using vmapbuf(). If you want a specific code example, just let me know. (or look in the CAM SCSI passthrough driver for the passmapmem() and passunmapmem() functions) Ken -- Kenneth Merry ken@plutotech.com From owner-freebsd-hackers Mon Oct 20 23:06:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA21678 for hackers-outgoing; Mon, 20 Oct 1997 23:06:10 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from safeconcept.utimaco.co.at (mail-gw.utimaco.co.at [195.96.28.162]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA21670 for ; Mon, 20 Oct 1997 23:06:01 -0700 (PDT) (envelope-from Michael.Schuster@utimaco.co.at) Received: (from uucp@localhost) by safeconcept.utimaco.co.at (8.8.5/8.8.5) id HAA03404 for ; Tue, 21 Oct 1997 07:53:59 +0200 (CEST) Received: from wshpux.utimaco.co.at(10.0.0.18) by safeconcept via smap (V2.0) id xma003402; Tue, 21 Oct 97 07:53:45 +0200 Message-ID: <344C45CA.C98D731F@utimaco.co.at> Date: Tue, 21 Oct 1997 08:03:54 +0200 From: Michael Schuster Organization: Utimaco Safe Concept GmbH., Linz, Austria X-Mailer: Mozilla 4.03 [de] (X11; I; HP-UX B.10.01 9000/715) MIME-Version: 1.0 To: "hackers@FreeBSD.ORG" Subject: Re: outb() / inb() Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk James Raynard wrote: > > On Mon, Oct 20, 1997 at 08:44:33AM +0200, Michael Schuster wrote: > > > > >#define outb(port,data) \ > > > <....> \ > > > ? outbc(port,data):outbv(port,data)) > > > > which means that if you write > > outb (0x250, *c++); > > then the expression "*c++" gets evaluated twice > > Sorry, but this isn't true: only one of the outbc/outbv expressions will > be evaluated (the rules are exactly the same as for an if-else statement). oops! I got things mixed up there ... actually, it's the first argument (port) that gets evaluated (at least) twice, since it's in the expression before the "?" which I left out. sorry about that & thanks for the hint Michael -- Michael Schuster Utimaco Safe Concept GmbH. | Tel: +43 732 655755 41 Europaplatz 6 | Fax: +43 732 655755 5 A-4020 Linz Austria | email: Michael.Schuster@utimaco.co.at From owner-freebsd-hackers Mon Oct 20 23:20:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA22256 for hackers-outgoing; Mon, 20 Oct 1997 23:20:56 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA22248 for ; Mon, 20 Oct 1997 23:20:52 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id IAA13844; Tue, 21 Oct 1997 08:20:34 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id IAA17010; Tue, 21 Oct 1997 08:15:17 +0200 (MET DST) Message-ID: <19971021081517.PE48415@uriah.heep.sax.de> Date: Tue, 21 Oct 1997 08:15:17 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Cc: darrenr@cyber.com.au (Darren Reed) Subject: Re: FreeBSD 3.0 kernel API ?! References: <199710201834.LAA09783@usr05.primenet.com> <199710202357.JAA09206@plum.cyber.com.au> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199710202357.JAA09206@plum.cyber.com.au>; from Darren Reed on Oct 21, 1997 09:57:17 +1000 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Darren Reed wrote: > Sigh. This is all very amusing, I guess. Here's a tip for you: > if you *really* want to separate what user programs can and can not > include (or should and should not), don't put any "kernel only" > include files under /usr/include and remove all references from > /usr/include files to anything that should only be in the kernel. You're missing the point of /usr/include/sys/ and friends. This directory is intended to carry the common interface declarations between kernel and userland. The most consistent way for a development machine is, of course, to symlink these directories into the kernel tree. (NB: this doesn't necessarily i agree with all those *_var.h's. IMHO, an #ifdef _KERNEL (still misspelled without the underscore in FreeBSD) should suffice. LKMs do need to define this macro, too, of course.) > p.s. what's up with hackers@freebsd ? I haven't seen any mail come > through it for a while now... Well, maybe your site caused excessive bounces, so Jonathan had to remove you? I'm dropping you a Cc this time. -- 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-hackers Mon Oct 20 23:21:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA22282 for hackers-outgoing; Mon, 20 Oct 1997 23:21:36 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA22276 for ; Mon, 20 Oct 1997 23:21:32 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id IAA13850 for freebsd-hackers@FreeBSD.ORG; Tue, 21 Oct 1997 08:21:25 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id IAA17019; Tue, 21 Oct 1997 08:18:00 +0200 (MET DST) Message-ID: <19971021081759.TH50130@uriah.heep.sax.de> Date: Tue, 21 Oct 1997 08:17:59 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG Subject: Re: 2.2.2-RELEASE '875 SCSI won't negotiage References: <199710210124.UAA14405@nospam.hiwaay.net> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199710210124.UAA14405@nospam.hiwaay.net>; from dkelly@hiwaay.net on Oct 20, 1997 20:24:34 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As dkelly@hiwaay.net wrote: > > sd0(ncr0:0:0): WIDE SCSI (16 bit) enabled > > sd0(ncr0:0:0): 20.0 MB/s (100 ns, offset 16) > > > > > > Shouldn't this report back 40.0 MB/s for fast wide ultra ? > > Probably should. Probably should not. It should read as ``20 MHz'', this makes no promises about the actual speed. -- 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-hackers Mon Oct 20 23:21:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA22303 for hackers-outgoing; Mon, 20 Oct 1997 23:21:41 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA22294 for ; Mon, 20 Oct 1997 23:21:37 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id IAA13851 for freebsd-hackers@FreeBSD.ORG; Tue, 21 Oct 1997 08:21:35 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id IAA17031; Tue, 21 Oct 1997 08:19:04 +0200 (MET DST) Message-ID: <19971021081904.GT30220@uriah.heep.sax.de> Date: Tue, 21 Oct 1997 08:19:04 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG Subject: Re: DLT drives References: X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Tom on Oct 20, 1997 18:35:04 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Tom wrote: > DLT tape drives will work under FreeBSD, right? They were a very boring :) experience to me. Just plug it in, nothing else. -- 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-hackers Mon Oct 20 23:23:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA22524 for hackers-outgoing; Mon, 20 Oct 1997 23:23:57 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA22518 for ; Mon, 20 Oct 1997 23:23:53 -0700 (PDT) (envelope-from jamil@trojanhorse.ml.org) Received: from localhost (jamil@localhost) by trojanhorse.ml.org (8.8.7/8.8.5) with SMTP id XAA00272 for ; Mon, 20 Oct 1997 23:23:44 -0700 (PDT) Date: Mon, 20 Oct 1997 23:23:43 -0700 (PDT) From: "Jamil J. Weatherbee" To: freebsd-hackers@freebsd.org Subject: Solid State Disks Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Anybody seen any good literature/prices on this sort of thing lately. How long are they rumored to exist. It would be really cool if a PC was like an hp48, damn thing never crashes and is basically always on. My vision for the PC: (It will happen) Pizzabox case, no fan. Seperate AC/DC transformer externally (like the old C64's). No moving parts, 17" active color lcd panel (touch). Voice interface, keyboard area that can reconfigure itself. Fiberoptic wide area networking port built in. Never shuts down, goes off or resets. Memory can be maintained indefinitely without application of external power via eeprom mirroring. Battery powered main memory/storage. Second built in battery can act as ups to keep the machine up and function throughout extended power outages. From owner-freebsd-hackers Mon Oct 20 23:28:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA22820 for hackers-outgoing; Mon, 20 Oct 1997 23:28:55 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA22812 for ; Mon, 20 Oct 1997 23:28:51 -0700 (PDT) (envelope-from root@trojanhorse.ml.org) Received: from localhost (root@localhost) by trojanhorse.ml.org (8.8.7/8.8.5) with SMTP id XAA00288 for ; Mon, 20 Oct 1997 23:28:45 -0700 (PDT) Date: Mon, 20 Oct 1997 23:28:45 -0700 (PDT) From: 0000-Administrator To: freebsd-hackers@freebsd.org Subject: Floppy Disk Driver (RELENG-stable) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I witnessed an interesting thing the other day. I mounted a dos disk copied over a big file in the background and then went to bash and tried to do file completion on the file before it was done copying. This managed to lock up the floppy disk permantely, plus hang any related things like running "mount" or "df" or "ls /" the system still was able to run but the root did not get unmounted properly on shutdown and had to be fixed after reboot. From owner-freebsd-hackers Tue Oct 21 00:36:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA26294 for hackers-outgoing; Tue, 21 Oct 1997 00:36:51 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from heron.doc.ic.ac.uk (lExgEBkQ9UjPzeJI99id0Nf7uHDe4PS4@heron.doc.ic.ac.uk [146.169.2.31]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id AAA26286 for ; Tue, 21 Oct 1997 00:36:43 -0700 (PDT) (envelope-from njs3@doc.ic.ac.uk) Received: from oak67.doc.ic.ac.uk [146.169.33.67] ([Ul6DOs820hazxxEWdBkPMQcqlk4JVj9y]) by heron.doc.ic.ac.uk with smtp (Exim 1.62 #3) id 0xNYsl-00025W-00; Tue, 21 Oct 1997 08:37:40 +0100 Received: from njs3 by oak67.doc.ic.ac.uk with local (Exim 1.62 #3) id 0xNYrc-0004nJ-00; Tue, 21 Oct 1997 08:36:28 +0100 From: njs3@doc.ic.ac.uk (Niall Smart) Date: Tue, 21 Oct 1997 08:36:27 +0100 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: "Andrew Atrens" Subject: Re: pulling email addresses from freebsd lists Cc: hackers@freebsd.org Message-Id: Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > www.vix.com/spam seems to have been updated since my last visit in August - > they have several new tools (or at least new to me) that you may find helpful. > > Imho the (more or less) free and open nature of the net, means that spammers > will always be a problem. I disagree, I believe that (mail) protocols which require authentication and tracability of the sender would cut spam dramatically, the problem is that the internet's core protocols were designed with the assumption that no-one would deliberately abuse them, that was fine in the 70's and 80's but isn't the case today. If, when you received spam, you could determine the senders email, name, and phone number the amount of complaints to spammers and their ISP's would rise massively. It would also provide the technological infrastructure that governments need to enforce anti-spam legislation. If the spammers knew their identity was available, and knew they would get caught and prosecuted, then they wouldn't do it. > I think our biggest advantage is that we outnumber > them. I think our biggest weakness is that we address the issue as individuals, > ie we don't leverage our numbers. I agree. > > Perhaps we could come up with some sort of automated mechanism for collecting > and collectively complaining to joe spammer's isp. What I'm getting at it is > that when one of us on the list gets spam, likely we all do. Yet in most > instances we all need to go through the effort of identifying the guilty party, > and sending an appropriate complaint. if this information was captured somewhere, > and accessible by (perhaps) a web interface, then it would save all of the > duplicated investigation work required to nail down the spammer's identity. This sounds like a good idea. Also, how about modifying majordomo so that it does not show the senders email address, just their name? Obviously this makes things awkward if two people on the list want to communicate privately and do not know each others email address.. an obfuscated email in the signature would help this. (e.g. n_js3_@do_c.ic.a_c.u_k) Niall From owner-freebsd-hackers Tue Oct 21 00:49:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA27143 for hackers-outgoing; Tue, 21 Oct 1997 00:49:43 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA27131 for ; Tue, 21 Oct 1997 00:49:33 -0700 (PDT) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (localhost.gsoft.com.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id RAA00387; Tue, 21 Oct 1997 17:16:16 +0930 (CST) Message-Id: <199710210746.RAA00387@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: "Matthew D. Fuller" cc: hackers@FreeBSD.ORG Subject: Re: Boot.flp + parallel ZIP...? In-reply-to: Your message of "Mon, 20 Oct 1997 22:21:52 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Oct 1997 17:16:14 +0930 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I'm considering trying to assemble a boot floppy with parallel port ZIP > drive support. Yay! Please do! > 1) Anyone already done it? No. > 2) Is there any technical reason it can't be done? No. > 3) Any reason it shouldn't be done? Guilt on my part that the ppa driver isn't in 2.2.5? > 4) Would it require any extraordinary means? i.e., serious source hacking It may be moderately magic getting ppa into the boot kernel config as part of the release build process (if you do go that way). > 5) Any hints? Have patience. Working out how the boot floppy build process works can be a challenge. > 6) Want it if I make it? I'm sure we can put it somewhere useful, yes! mike From owner-freebsd-hackers Tue Oct 21 01:11:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA28417 for hackers-outgoing; Tue, 21 Oct 1997 01:11:22 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from ren.dtir.qld.gov.au (firewall-user@ns.dtir.qld.gov.au [203.108.138.66]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA28406 for ; Tue, 21 Oct 1997 01:11:15 -0700 (PDT) (envelope-from syssgm@dtir.qld.gov.au) Received: by ren.dtir.qld.gov.au; id SAA26660; Tue, 21 Oct 1997 18:21:58 +1000 (EST) Received: from ogre.dtir.qld.gov.au(167.123.8.3) by ren.dtir.qld.gov.au via smap (3.2) id xma026656; Tue, 21 Oct 97 18:21:32 +1000 Received: from localhost.dtir.qld.gov.au (localhost.dtir.qld.gov.au [127.0.0.1]) by ogre.dtir.qld.gov.au (8.8.7/8.8.7) with SMTP id SAA12294; Tue, 21 Oct 1997 18:10:14 +1000 (EST) Message-Id: <199710210810.SAA12294@ogre.dtir.qld.gov.au> X-Authentication-Warning: ogre.dtir.qld.gov.au: localhost.dtir.qld.gov.au [127.0.0.1] didn't use HELO protocol To: freebsd-hackers@freebsd.org cc: syssgm@dtir.qld.gov.au Subject: Re: Urge to apply the vn device hack even to 2.2.5 References: <15920.877390482@time.cdrom.com> In-Reply-To: <15920.877390482@time.cdrom.com> from "Jordan K. Hubbard" at "Mon, 20 Oct 1997 23:34:42 +0000" Date: Tue, 21 Oct 1997 18:10:13 +1000 From: Stephen McKay Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Monday, 20th October 1997, "Jordan K. Hubbard" wrote: >maybe we should make our release-a-day server a 486SX with 8MB of >memory and switch it to being a release-a-week server instead. >We'd not have as useful a service by far, but it sure would catch >those load sensitive bugs early. :-) Hey, I used to do this for ya! I used to have a 386sx16 with 4Mb ram and 13.5 Mb of swap. Yes, every byte of swap counted! It didn't have enough disk to store anything, so /usr/src and /usr/obj were NFS. It used to take around 10 days to crank out a make world. Sort of a continuing lesson in patience. It did find real bugs though. Unfortunately, it took sick and died. :-( >P.S. Yes, of course I'm just joking. :) I've always been fascinated by those bald blokes that whip themselves in the name of religious purification. They don't joke either. Stephen. From owner-freebsd-hackers Tue Oct 21 01:46:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA00416 for hackers-outgoing; Tue, 21 Oct 1997 01:46:07 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from citadel.cdsec.com (citadel.cdsec.com [192.96.22.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA00408 for ; Tue, 21 Oct 1997 01:46:02 -0700 (PDT) (envelope-from gram@cdsec.com) Received: (from nobody@localhost) by citadel.cdsec.com (8.8.5/8.6.9) id KAA26850 for ; Tue, 21 Oct 1997 10:56:05 +0200 (SAT) Received: by citadel via recvmail id 26817; Tue Oct 21 10:55:42 1997 by gram.cdsec.com (8.8.5/8.8.5) id KAA12807 for hackers@freebsd.org; Tue, 21 Oct 1997 10:22:20 +0200 (SAT) From: Graham Wheeler Message-Id: <199710210822.KAA12807@cdsec.com> Subject: Re: Bug in 2.2.2 To: hackers@freebsd.org Date: Tue, 21 Oct 1997 10:22:19 +0200 (SAT) X-Mailer: ELM [version 2.4 PL25-h4.1] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I wrote a small program to exercise the heap and ran it for about ten million > > iterations without a problem. Then I decided to add a periodic call to fork(), > > as both Midnight Commander and the firewall gateway program both do plenty > > of these. When I ran this the O/S panicked almost immediately. > > > Graham, > i have run your test program, both with and without fork(), > against phkmalloc from 2.2 upgraded to CTM 470 for over 10 > million iterations. the upgrade replaces > /home/src/lib/libc/stdlib/malloc.c version 1.18.2.2 with > version 1.18.2.3. there are changes in the way that > phkmalloc deals with changing sizes fo allocated memory > and more. ;) > > can you upgrade from 2.2.2 to 2.2.5 and run your code again? > 2.2.5 will be out very soon. the source tree will be > tagged within the hour (Oct 20th 6pm PDT). We have a subscription, which means I will be able to do this, but only in a few weeks time. I upgraded my HDD at home last night, and, not having a 2.2.2 CD there, installed 2.2.1. If I remember I will run the program there tonight, and see what happens, just for interest. Would it be possible to use the newer malloc.c with 2.2.2, without changing anything else? That would be a test I could do in the short term. -- Dr Graham Wheeler E-mail: gram@cdsec.com Citadel Data Security Phone: +27(21)23-6065/6/7 Internet/Intranet Network Specialists Mobile: +27(83)-253-9864 Firewalls/Virtual Private Networks Fax: +27(21)24-3656 Data Security Products WWW: http://www.cdsec.com/ From owner-freebsd-hackers Tue Oct 21 01:55:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA00950 for hackers-outgoing; Tue, 21 Oct 1997 01:55:05 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from citadel.cdsec.com (citadel.cdsec.com [192.96.22.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA00944 for ; Tue, 21 Oct 1997 01:55:01 -0700 (PDT) (envelope-from gram@cdsec.com) Received: (from nobody@localhost) by citadel.cdsec.com (8.8.5/8.6.9) id LAA27137 for ; Tue, 21 Oct 1997 11:05:05 +0200 (SAT) Received: by citadel via recvmail id 27104; Tue Oct 21 11:04:17 1997 by gram.cdsec.com (8.8.5/8.8.5) id KAA12877 for hackers@freebsd.org; Tue, 21 Oct 1997 10:30:56 +0200 (SAT) From: Graham Wheeler Message-Id: <199710210830.KAA12877@cdsec.com> Subject: Re: Bug in 2.2.2 To: hackers@freebsd.org Date: Tue, 21 Oct 1997 10:30:55 +0200 (SAT) X-Mailer: ELM [version 2.4 PL25-h4.1] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I see the fork() in your code, but I don't see where it's doing a wait() t= > o = > > pick up the childs exit status. Am I missing something? No - I wrote the program very quickly. As I saved it I remembered I hadn't caught the SIGCHLDs to reap the zombies, but decided to run it anyway, and add the reap code afterwards. Which is why I said in my original message: > I hadn't bothered doing any signal catching here; this was quick 'n dirty. This doesn't change the point - which is that the program should not cause a panic. It should just cause the process table to fill up and for the fork()s to fail after a while. Admittedly this could cause problems with the O/S if it tries to fork something else, but the first message I saw was not a `cannot fork', but a `panic: vmstat...' (or something along those lines; I don't remember the exact message but I do remember that it was a VM related message). cheers gram -- Dr Graham Wheeler E-mail: gram@cdsec.com Citadel Data Security Phone: +27(21)23-6065/6/7 Internet/Intranet Network Specialists Mobile: +27(83)-253-9864 Firewalls/Virtual Private Networks Fax: +27(21)24-3656 Data Security Products WWW: http://www.cdsec.com/ From owner-freebsd-hackers Tue Oct 21 02:36:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA03480 for hackers-outgoing; Tue, 21 Oct 1997 02:36:59 -0700 (PDT) (envelope-from owner-freebsd-hackers) 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 CAA03474 for ; Tue, 21 Oct 1997 02:36:52 -0700 (PDT) (envelope-from roberto@keltia.freenix.fr) 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 LAA32082 for ; Tue, 21 Oct 1997 11:36:52 +0200 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.8.6/brasil-1.2) with UUCP id LAA10868 for freebsd-hackers@FreeBSD.ORG; Tue, 21 Oct 1997 11:36:34 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.7/keltia-2.11/nospam) id HAA01628; Tue, 21 Oct 1997 07:57:54 +0200 (CEST) (envelope-from roberto) Message-ID: <19971021075754.42358@keltia.freenix.fr> Date: Tue, 21 Oct 1997 07:57:54 +0200 From: Ollivier Robert To: freebsd-hackers@FreeBSD.ORG Subject: Re: 2.2.2-RELEASE '875 SCSI won't negotiage References: <199710210124.UAA14405@nospam.hiwaay.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: <199710210124.UAA14405@nospam.hiwaay.net>; from dkelly@hiwaay.net on Mon, Oct 20, 1997 at 08:24:34PM -0500 X-Operating-System: FreeBSD 3.0-CURRENT ctm#3745 AMD-K6 MMX @ 208 MHz Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to dkelly@hiwaay.net: > ncr0 rev 3 int a irq 11 on pci0:11 > ncr0 waiting for scsi devices to settle > (ncr0:0:0): WIDE SCSI (16 bit) enabled > (ncr0:0:0): 10.0 MB/s (200 ns, offset 15) > (ncr0:0:0): "IBM OEM DCHS09W 2222" type 0 fixed SCSI 2 > sd1(ncr0:0:0): Direct-Access > sd1(ncr0:0:0): WIDE SCSI (16 bit) enabled > sd1(ncr0:0:0): 20.0 MB/s (100 ns, offset 15) > 8689MB (17796077 512 byte sectors) I'm very surprised because I have a DCAS (the 5400 rpm version) on a 875 as well (the ASUS one) and it reports: ncr0: rev 0x03 int a irq 12 on pci0.11.0 scbus0 at ncr0 bus 0 sd0 at scbus0 target 0 lun 0 sd0: type 0 fixed SCSI 2 sd0: Direct-Access sd0: WIDE SCSI (16 bit) enabled sd0: 40.0 MB/s (50 ns, offset 15) 4134MB (8467200 512 byte sectors) sd2 at scbus0 target 2 lun 0 sd2: type 0 fixed SCSI 2 sd2: Direct-Access sd2: 20.0 MB/s (50 ns, offset 15) 2063MB (4226725 512 byte sectors) sd2 is a Ultra narrow drive. WCE was enabled on the DCAS from the factory. -- Ollivier ROBERT -=- FreeBSD: There are no limits -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #41: Sat Oct 18 18:47:01 CEST 1997 From owner-freebsd-hackers Tue Oct 21 03:53:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA06978 for hackers-outgoing; Tue, 21 Oct 1997 03:53:09 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from gate.mgt.msk.ru (mgtrep.24h.dialup.ru [194.87.18.139]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA06955 for ; Tue, 21 Oct 1997 03:52:49 -0700 (PDT) (envelope-from tarkhil@mgt.msk.ru) Received: from asteroid.mgt.msk.ru (asteroid.mgt.msk.ru [192.168.133.145]) by gate.mgt.msk.ru (8.8.6/8.8.6) with ESMTP id OAA18739 for ; Tue, 21 Oct 1997 14:53:04 +0400 (MSD) Received: from asteroid.mgt.msk.ru (localhost.mgt.msk.ru [127.0.0.1]) by asteroid.mgt.msk.ru (8.8.7/8.8.6) with ESMTP id OAA12808 for ; Tue, 21 Oct 1997 14:52:02 +0400 (MSD) Message-Id: <199710211052.OAA12808@asteroid.mgt.msk.ru> To: hackers@freebsd.org Reply-To: tarkhil@mgt.msk.ru Subject: on ccd and large disk array Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Oct 1997 14:52:01 +0400 From: "Alexander B. Povolotsky" Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello! We're making a (relatively) large disk array using ccd: 5 Micropolis HDDs, 8.7 Gb each, i.e. about 40 Gb total. Does anyone know possible traps on our way? Is FFS as-is stable on 40 Gb filesystems? What may we need to patch? We're running FreeBSD 2.2.2, PPro-200, 128 Mb RAM, AHA 2940 Ultra and AHA 2940 Ultra Wide (all HDDs in ccd are on Ultra Wide). Alex. From owner-freebsd-hackers Tue Oct 21 04:55:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA09152 for hackers-outgoing; Tue, 21 Oct 1997 04:55:20 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA09134 for ; Tue, 21 Oct 1997 04:55:13 -0700 (PDT) (envelope-from dag-erli@ifi.uio.no) Received: from bera.ifi.uio.no (2602@bera.ifi.uio.no [129.240.65.84]) by ifi.uio.no (8.8.7/8.8.7/ifi0.2) with ESMTP id NAA11721 for ; Tue, 21 Oct 1997 13:54:35 +0200 (MET DST) Received: (from dag-erli@localhost) by bera.ifi.uio.no ; Tue, 21 Oct 1997 13:54:32 +0200 (MET DST) To: hackers@FreeBSD.ORG Subject: Re: pulling email addresses from freebsd lists References: <199710202215.PAA23821@hub.freebsd.org> Organization: Not unless it can't be avoided. X-url: http://www.ifi.uio.no/~dag-erli/ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit From: dag-erli@ifi.uio.no (Dag-Erling Coidan Smųrgrav) Date: 21 Oct 1997 13:54:29 +0200 In-Reply-To: "Andrew Atrens"'s message of 20 Oct 1997 18:12 EDT Message-ID: Lines: 9 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk "Andrew Atrens" writes: > Perhaps we could come up with some sort of automated mechanism for collecting > and collectively complaining to joe spammer's isp. What I'm getting at it is Such a mechanism already exists. 'pkg_add adcomplain-1.6'. -- * Finrod (INTJ) * Unix weenie * dag-erli@ifi.uio.no * cellular +47-92835919 * RFC1123: "Be liberal in what you accept, and conservative in what you send" From owner-freebsd-hackers Tue Oct 21 06:41:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA13055 for hackers-outgoing; Tue, 21 Oct 1997 06:41:16 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from unix.tfs.net (root@unix.tfs.net [199.79.146.60]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA13032 for ; Tue, 21 Oct 1997 06:41:07 -0700 (PDT) (envelope-from jbryant@argus.tfs.net) Received: from argus.tfs.net (pm3-p19.tfs.net [206.154.183.211]) by unix.tfs.net (8.8.5/8.8.5) with ESMTP id IAA30272; Tue, 21 Oct 1997 08:40:28 -0500 Received: (from jbryant@localhost) by argus.tfs.net (8.8.7/8.8.5) id IAA11750; Tue, 21 Oct 1997 08:41:01 -0500 (CDT) From: Jim Bryant Message-Id: <199710211341.IAA11750@argus.tfs.net> Subject: Re: Solid State Disks In-Reply-To: from "Jamil J. Weatherbee" at "Oct 20, 97 11:23:43 pm" To: jamil@trojanhorse.ml.org (Jamil J. Weatherbee) Date: Tue, 21 Oct 1997 08:41:01 -0500 (CDT) Cc: freebsd-hackers@freebsd.org Reply-to: jbryant@tfs.net X-Windows: R00LZ!@# MS-Winbl0wz DR00LZ!@# X-Operating-System: FreeBSD 2.2.2-RELEASE #0: Wed Jul 9 01:01:24 CDT 1997 X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In reply: > Anybody seen any good literature/prices on this sort of thing lately. How > long are they rumored to exist. It would be really cool if a PC was like > an hp48, damn thing never crashes and is basically always on. kinda cool... SS disks have been around for a while, but i don't recall non-volatility though. > Memory can be maintained indefinitely without application of > external power via eeprom mirroring. > > Battery powered main memory/storage. > Second built in battery can act as ups to keep the machine up and function > throughout extended power outages. how about bringing back a tried but true technology: bubbles... magnetic bubble memory is inherently non-volatile, and the only problems to be overcome would be speed, and price. but then again, have you seen the prices on DEC and IBM's SS disks??? another option could be a good 10AH gellcell on some micropower-standby ram. would add some weight, but is the best option for data retention at ram speeds. jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" ------------------------------------------------------------------------------ Inet: jbryant@tfs.net AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28pw voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant ------------------------------------------------------------------------------ HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ From owner-freebsd-hackers Tue Oct 21 07:53:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA16570 for hackers-outgoing; Tue, 21 Oct 1997 07:53:29 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from sunmbx.netmbx.de (sunmbx.netmbx.de [192.76.152.9]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id HAA16565 for ; Tue, 21 Oct 1997 07:53:26 -0700 (PDT) (envelope-from TG@TechSoft.de) Received: by sunmbx.netmbx.de (Smail3.2.0.96) from TechSoft.de (193.101.167.2) with smtp id ; Tue, 21 Oct 1997 16:53:12 +0200 (MET DST) Received: from PROSIGNIA/SpoolDir by TechSoft.de (Mercury 1.31); 21 Oct 97 16:55:41 GMT+0100 Received: from SpoolDir by PROSIGNIA (Mercury 1.31); 21 Oct 97 16:55:28 GMT+0100 From: "Thilo Gelenk" Organization: Tech Soft GmbH To: freebsd-hackers@FreeBSD.org Date: Tue, 21 Oct 1997 16:55:20 MET Subject: source from FBSD2.2.2 decompressing Priority: normal X-mailer: Pegasus Mail for Windows (v2.54DE) Message-ID: <1DDACE6256E@TechSoft.de> Sender: owner-freebsd-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hi folks, I have bought the FreeBSD 2.2.2 CDs to get the source code. It is contained on the CD under /src, but I need to run "sh install.sh", what seems to be possible only under BSD (so I have first to install it). - I am searching for a way to decompress all source files from Dir /src under DOS/Windows directly. -Or should I try to read the CD Rom in an UNIX machine (HP) and then - what is needed to uncompress the source files ? Any help would be great - please email me directly TG@techsoft.de Thanks from Berlin Thilo From owner-freebsd-hackers Tue Oct 21 09:05:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA20740 for hackers-outgoing; Tue, 21 Oct 1997 09:05:04 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from tahiti.oss.uswest.net (tahiti.oss.uswest.net [204.147.85.151]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA20721 for ; Tue, 21 Oct 1997 09:04:58 -0700 (PDT) (envelope-from rantapaa@uswest.net) Received: (from rantapaa@localhost) by tahiti.oss.uswest.net (8.8.5/8.6.12) id LAA05204; Tue, 21 Oct 1997 11:04:57 -0500 (CDT) Date: Tue, 21 Oct 1997 11:04:56 -0500 (CDT) From: Erik E Rantapaa To: freebsd-hackers@freebsd.org Subject: PROT_READ needed for read() call? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk While porting some code to FreeBSD 2.2-STABLE I noticed that in order to read() into a mmap-ed address space you need PROT_READ as well as PROT_WRITE, otherwise you get a "Bad address" error (EFAULT). The original code (Solaris) only requires PROT_WRITE. This is not a big deal, but I was wondering what the current thinking was on such issues. -- Erik Rantapaa rantapaa@math.umn.edu From owner-freebsd-hackers Tue Oct 21 09:07:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA20871 for hackers-outgoing; Tue, 21 Oct 1997 09:07:07 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA20855 for ; Tue, 21 Oct 1997 09:07:04 -0700 (PDT) (envelope-from jdp@austin.polstra.com) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.7/8.8.5) with ESMTP id JAA16013; Tue, 21 Oct 1997 09:06:49 -0700 (PDT) Message-Id: <199710211606.JAA16013@austin.polstra.com> To: dec@phoenix.its.rpi.edu Subject: Re: FreeBSD authentication... In-Reply-To: References: Organization: Polstra & Co., Seattle, WA Cc: hackers@freebsd.org Date: Tue, 21 Oct 1997 09:06:48 -0700 From: John Polstra Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article , David E. Cross wrote: > (Since they are implimented as shared libraries, that you link in as > needed, would we need to rewrite ld.so a bit to ensure that people > couldn't set their LD_LIBRARY_PATH, and then run su to get full root > acces, sans password?) The dynamic linker ignores LD_LIBRARY_PATH when running setuid or setgid. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-hackers Tue Oct 21 09:51:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA24303 for hackers-outgoing; Tue, 21 Oct 1997 09:51:31 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from pluto.plutotech.com (ken@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA24294 for ; Tue, 21 Oct 1997 09:51:29 -0700 (PDT) (envelope-from ken@plutotech.com) Received: (from ken@localhost) by pluto.plutotech.com (8.8.5/8.8.5) id KAA18361; Tue, 21 Oct 1997 10:50:49 -0600 (MDT) From: Kenneth Merry Message-Id: <199710211650.KAA18361@pluto.plutotech.com> Subject: Re: on ccd and large disk array In-Reply-To: <199710211052.OAA12808@asteroid.mgt.msk.ru> from "Alexander B. Povolotsky" at "Oct 21, 97 02:52:01 pm" To: tarkhil@mgt.msk.ru Date: Tue, 21 Oct 1997 10:50:49 -0600 (MDT) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Alexander B. Povolotsky wrote... > Hello! > > We're making a (relatively) large disk array using ccd: 5 Micropolis HDDs, > 8.7 Gb each, i.e. about 40 Gb total. > > Does anyone know possible traps on our way? Is FFS as-is stable on 40 Gb > filesystems? What may we need to patch? You'll need to make sure that you edit login.conf and increase the limits on memory usage, etc., so that you can fsck the partition. > We're running FreeBSD 2.2.2, PPro-200, 128 Mb RAM, AHA 2940 Ultra and AHA > 2940 Ultra Wide (all HDDs in ccd are on Ultra Wide). I built a 60G ccd array a couple of months ago, it seemed to work just fine. I think it should work okay for you as well, but you might want to get input from some of the folks running news servers, etc., on big ccd arrays. Ken -- Kenneth Merry ken@plutotech.com From owner-freebsd-hackers Tue Oct 21 10:25:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA26724 for hackers-outgoing; Tue, 21 Oct 1997 10:25:41 -0700 (PDT) (envelope-from owner-freebsd-hackers) 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 KAA26719 for ; Tue, 21 Oct 1997 10:25:35 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id KAA01399; Tue, 21 Oct 1997 10:23:04 -0700 (PDT) Message-ID: <19971021102303.60699@hydrogen.nike.efn.org> Date: Tue, 21 Oct 1997 10:23:03 -0700 From: John-Mark Gurney To: Thilo Gelenk Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: source from FBSD2.2.2 decompressing References: <1DDACE6256E@TechSoft.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <1DDACE6256E@TechSoft.de>; from Thilo Gelenk on Tue, Oct 21, 1997 at 05:11:06PM +0100 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-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Thilo Gelenk scribbled this message on Oct 21: > Hi folks, > I have bought the FreeBSD 2.2.2 CDs to get the source > code. It is contained on the CD under /src, but I need to > run "sh install.sh", what seems to be possible only under > BSD (so I have first to install it). > > - I am searching for a way to decompress all source files from Dir > /src under DOS/Windows directly. > -Or should I try to read the CD Rom in an UNIX machine (HP) > and then - what is needed to uncompress the source > files ? any program that can handle both tar and gz files will work.. the files are just one large file that were split into 240k chunks.. copy file.aa+file.ab+...+file.zz file.tgz will reassemble the file for you... the other thing is that the source probably isn't to useful on a dos machine.. by my opinion only... -- 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-hackers Tue Oct 21 11:05:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA29632 for hackers-outgoing; Tue, 21 Oct 1997 11:05:54 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id LAA29627 for ; Tue, 21 Oct 1997 11:05:50 -0700 (PDT) (envelope-from tom@sdf.com) Received: from tom by misery.sdf.com with smtp (Exim 1.73 #1) id 0xNieV-0002mC-00; Tue, 21 Oct 1997 11:03:35 -0700 Date: Tue, 21 Oct 1997 11:03:28 -0700 (PDT) From: Tom To: Kenneth Merry cc: tarkhil@mgt.msk.ru, hackers@freebsd.org Subject: Re: on ccd and large disk array In-Reply-To: <199710211650.KAA18361@pluto.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 21 Oct 1997, Kenneth Merry wrote: > I built a 60G ccd array a couple of months ago, it seemed to work > just fine. I think it should work okay for you as well, but you might > want to get input from some of the folks running news servers, etc., on big > ccd arrays. Many news servers are setup with multiple ccd arrays, especially since you need to add aditional storage every 6 months. > Ken > -- > Kenneth Merry > ken@plutotech.com > > Tom From owner-freebsd-hackers Tue Oct 21 11:13:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA00431 for hackers-outgoing; Tue, 21 Oct 1997 11:13:37 -0700 (PDT) (envelope-from owner-freebsd-hackers) 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 LAA00422 for ; Tue, 21 Oct 1997 11:13:31 -0700 (PDT) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.7/8.8.5) id NAA02391; Tue, 21 Oct 1997 13:13:23 -0500 (EST) From: "John S. Dyson" Message-Id: <199710211813.NAA02391@dyson.iquest.net> Subject: Re: PROT_READ needed for read() call? In-Reply-To: from Erik E Rantapaa at "Oct 21, 97 11:04:56 am" To: rantapaa@uswest.net (Erik E Rantapaa) Date: Tue, 21 Oct 1997 13:13:23 -0500 (EST) Cc: freebsd-hackers@FreeBSD.ORG Reply-To: dyson@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-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Erik E Rantapaa said: > > While porting some code to FreeBSD 2.2-STABLE I noticed that in order > to read() into a mmap-ed address space you need PROT_READ as well as > PROT_WRITE, otherwise you get a "Bad address" error (EFAULT). > The original code (Solaris) only requires PROT_WRITE. > > This is not a big deal, but I was wondering what the current thinking > was on such issues. > As I remember, POSIX suggests/requires PROT_WRITE also imply PROT_READ. If it does, I'll correct the situation. (I have a copy of POSIX.) -- John dyson@freebsd.org jdyson@nc.com From owner-freebsd-hackers Tue Oct 21 11:30:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA01779 for hackers-outgoing; Tue, 21 Oct 1997 11:30:42 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from iafnl.es.iaf.nl (uucp@iafnl.es.iaf.nl [195.108.17.20]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id LAA01764 for ; Tue, 21 Oct 1997 11:30:36 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: by iafnl.es.iaf.nl with UUCP id AA28247 (5.67b/IDA-1.5 for freebsd-hackers@FreeBSD.ORG); Tue, 21 Oct 1997 20:30:46 +0200 Received: (from wilko@localhost) by yedi.iaf.nl (8.8.5/8.6.12) id TAA00963; Tue, 21 Oct 1997 19:54:32 +0100 (MET) From: Wilko Bulte Message-Id: <199710211854.TAA00963@yedi.iaf.nl> Subject: Re: Solid State Disks To: jbryant@tfs.net Date: Tue, 21 Oct 1997 19:54:32 +0100 (MET) Cc: jamil@trojanhorse.ml.org, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199710211341.IAA11750@argus.tfs.net> from "Jim Bryant" at Oct 21, 97 08:41:01 am X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-Pgp-Info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4 PL24 ME8a] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Jim Bryant wrote... > In reply: > > Anybody seen any good literature/prices on this sort of thing lately. How > > long are they rumored to exist. It would be really cool if a PC was like > > an hp48, damn thing never crashes and is basically always on. > > kinda cool... SS disks have been around for a while, but i don't > recall non-volatility though. Oh sure, they exist. DEC sells (Quantum) SSDs which also contain a NiCD battery and a normal magnetic disk. When power fails the SSD contents are dumped onto the magnetic one to get data retention. > bubbles... magnetic bubble memory is inherently non-volatile, and the > only problems to be overcome would be speed, and price. but then > again, have you seen the prices on DEC and IBM's SS disks??? Qute he? ;-) _ ____________________________________________________________________ | / o / / _ Bulte email: wilko@yedi.iaf.nl http://www.tcja.nl/~wilko |/|/ / / /( (_) Arnhem, The Netherlands - Do, or do not. There is no 'try' ------------------ Support your local daemons: run FreeBSD Unix -----Yoda From owner-freebsd-hackers Tue Oct 21 11:31:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA01834 for hackers-outgoing; Tue, 21 Oct 1997 11:31:30 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from iafnl.es.iaf.nl (uucp@iafnl.es.iaf.nl [195.108.17.20]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id LAA01812 for ; Tue, 21 Oct 1997 11:31:17 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: by iafnl.es.iaf.nl with UUCP id AA28253 (5.67b/IDA-1.5 for freebsd-hackers@FreeBSD.ORG); Tue, 21 Oct 1997 20:30:59 +0200 Received: (from wilko@localhost) by yedi.iaf.nl (8.8.5/8.6.12) id TAA01003; Tue, 21 Oct 1997 19:57:18 +0100 (MET) From: Wilko Bulte Message-Id: <199710211857.TAA01003@yedi.iaf.nl> Subject: Re: DLT drives To: tom@sdf.com (Tom) Date: Tue, 21 Oct 1997 19:57:18 +0100 (MET) Cc: karl@Mcs.Net, freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Tom" at Oct 20, 97 07:53:33 pm X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-Pgp-Info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4 PL24 ME8a] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Tom wrote... > > On Mon, 20 Oct 1997, Karl Denninger wrote: > > > On Mon, Oct 20, 1997 at 06:35:04PM -0700, Tom wrote: > > > > > > DLT tape drives will work under FreeBSD, right? I would think that they > > > would be just be a standard tape device. I'm looking at one of the > > > Quantum DLT drives. > > > > > > Tom > > > > Yes, they do, and quite nicely. We use them here (they're the only media > > that has enough capacity and speed to be useful in our environment). > > What kind? Quantum, HP, or... All are built by Quantum, who bought the tape and disk business from Digital (DEC). So, Sun, SGI, DEC, etc all just rebadge them. Wilko _ ____________________________________________________________________ | / o / / _ Bulte email: wilko@yedi.iaf.nl http://www.tcja.nl/~wilko |/|/ / / /( (_) Arnhem, The Netherlands - Do, or do not. There is no 'try' ------------------ Support your local daemons: run FreeBSD Unix -----Yoda From owner-freebsd-hackers Tue Oct 21 11:57:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA03286 for hackers-outgoing; Tue, 21 Oct 1997 11:57:39 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA03275 for ; Tue, 21 Oct 1997 11:57:24 -0700 (PDT) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.7/8.8.7) id LAA23766; Tue, 21 Oct 1997 11:56:45 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp03.primenet.com, id smtpd023751; Tue Oct 21 11:56:42 1997 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id LAA13887; Tue, 21 Oct 1997 11:56:41 -0700 (MST) From: Terry Lambert Message-Id: <199710211856.LAA13887@usr04.primenet.com> Subject: Re: FreeBSD 3.0 kernel API ?! To: darrenr@cyber.com.au (Darren Reed) Date: Tue, 21 Oct 1997 18:56:40 +0000 (GMT) Cc: tlambert@primenet.com, darrenr@cyber.com.au, hackers@freebsd.org In-Reply-To: <199710210218.MAA11955@plum.cyber.com.au> from "Darren Reed" at Oct 21, 97 12:18:59 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > If it's kernel code you are testing, you will need to include if_var.h > > for it to run in the kernel; therefore you need to include if_var.h > > for it to run in the test jig, which pretends to be the kernel. > > Well, you see, that's just it. It doesn't need anything else, only the > "struct ifnet". I'd argue that a structure can be used and should be > available anywhere, it just describes a way to store some values in > memory. I have no problems with keeping variable names and function > prototypes away from users (in different .h files or whatever), it > even makes sense. But I don't think the same logic should be extended > to structures. I assume things like struct proc and struct user are > still available without defining KERNEL ? Say I agree with you. How will you deal with struct ifnet when we rename all the member variables from their current names to "opaque_variable_01" through "opaque_variable_NN"? Even if you can depend on the structure, you can't reasonably expect the kernel internal interface to not change. > > I think the issue is maybe that your test environment doesn't look > > sufficiently like a kernel... > > No, it doesn't. Given that malloc(3) doesn't quite grok M_WAITOK, > probably never will :-) Setting aside for the moment that your test malloc whould grok M_NOWAIT, and your code meant to run in the kernel should not be referencing the malloc(3) function in the first place... What exactly are you expecting to be able to test? Certainly, you can't test any of the interfaces that implement struct ifnet type derived parameters, and certainly you can't test race windows and spl issues triggered by a malloc(..., M_NOWAIT) returning a failed (NULL) allocation, etc.. I think your test case may be a bit contrived to justify your wanting to access the internal structure. 8-|. 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-hackers Tue Oct 21 12:28:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA04648 for hackers-outgoing; Tue, 21 Oct 1997 12:28:14 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from zibbi.mikom.csir.co.za (zibbi.mikom.csir.co.za [146.64.24.58]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA04502 for ; Tue, 21 Oct 1997 12:25:45 -0700 (PDT) (envelope-from jhay@zibbi.mikom.csir.co.za) Received: (from jhay@localhost) by zibbi.mikom.csir.co.za (8.8.7/8.8.7) id VAA20535; Tue, 21 Oct 1997 21:24:56 +0200 (SAT) From: John Hay Message-Id: <199710211924.VAA20535@zibbi.mikom.csir.co.za> Subject: Re: FreeBSD 3.0 kernel API ?! In-Reply-To: <199710211856.LAA13887@usr04.primenet.com> from Terry Lambert at "Oct 21, 97 06:56:40 pm" To: tlambert@primenet.com (Terry Lambert) Date: Tue, 21 Oct 1997 21:24:56 +0200 (SAT) Cc: hackers@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-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > If it's kernel code you are testing, you will need to include if_var.h > > > for it to run in the kernel; therefore you need to include if_var.h > > > for it to run in the test jig, which pretends to be the kernel. > > > > Well, you see, that's just it. It doesn't need anything else, only the > > "struct ifnet". I'd argue that a structure can be used and should be > > available anywhere, it just describes a way to store some values in > > memory. I have no problems with keeping variable names and function > > prototypes away from users (in different .h files or whatever), it > > even makes sense. But I don't think the same logic should be extended > > to structures. I assume things like struct proc and struct user are > > still available without defining KERNEL ? > > > Say I agree with you. > > How will you deal with struct ifnet when we rename all the member > variables from their current names to "opaque_variable_01" through > "opaque_variable_NN"? Even if you can depend on the structure, you > can't reasonably expect the kernel internal interface to not change. Well, I'll ask that you also fix snmpd then and keep on fixing the new versions. :-) Although it probably isn't a good example. The snmpd code is already so full of #ifdef's a few hundred more will probably not be noticed. :-) John -- John Hay -- John.Hay@mikom.csir.co.za From owner-freebsd-hackers Tue Oct 21 13:17:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA07415 for hackers-outgoing; Tue, 21 Oct 1997 13:17:15 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from charon.ccnvhi.com (wkstn.ccnvhi.com [207.247.3.162] (may be forged)) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id NAA07408 for ; Tue, 21 Oct 1997 13:17:13 -0700 (PDT) (envelope-from pnorton@ccnvhi.com) Received: by charon.ccnvhi.com; (5.65v3.2/1.3/10May95) id AA16670; Tue, 21 Oct 1997 12:12:57 -0700 Date: Tue, 21 Oct 1997 12:21:32 -0700 From: Paul Norton Subject: Re: DLT drives In-Reply-To: <199710211857.TAA01003@yedi.iaf.nl> To: Wilko Bulte Cc: tom@sdf.com (Tom), karl@Mcs.Net, freebsd-hackers@FreeBSD.ORG Message-Id: <199710211921.MAA00740@grumpy.ccnvhi.com> Mime-Version: 1.0 X-Mailer: VM 6.22 under 19.15 XEmacs Lucid Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <"Tom"@Oct> <199710211857.TAA01003@yedi.iaf.nl> Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Not so. Some load their own version of the DLT firmware. Wilko Bulte writes: > All are built by Quantum, who bought the tape and disk business from > Digital (DEC). > > So, Sun, SGI, DEC, etc all just rebadge them. > > Wilko > _ ____________________________________________________________________ > | / o / / _ Bulte email: wilko@yedi.iaf.nl http://www.tcja.nl/~wilko > |/|/ / / /( (_) Arnhem, The Netherlands - Do, or do not. There is no 'try' > ------------------ Support your local daemons: run FreeBSD Unix -----Yoda From owner-freebsd-hackers Tue Oct 21 14:33:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA11089 for hackers-outgoing; Tue, 21 Oct 1997 14:33:43 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from post.mail.demon.net (post-10.mail.demon.net [194.217.242.154]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id OAA11073 for ; Tue, 21 Oct 1997 14:33:24 -0700 (PDT) (envelope-from fhackers@jraynard.demon.co.uk) Received: from jraynard.demon.co.uk ([158.152.42.77]) by post.mail.demon.net id aa1000615; 21 Oct 97 22:20 BST Received: (from fhackers@localhost) by jraynard.demon.co.uk (8.8.7/8.8.7) id UAA07339; Tue, 21 Oct 1997 20:54:09 +0100 (BST) (envelope-from fhackers) Message-ID: <19971021205409.64823@jraynard.demon.co.uk> Date: Tue, 21 Oct 1997 20:54:09 +0100 From: James Raynard To: Stephen McKay Cc: freebsd-hackers@freebsd.org Subject: Old hardware Reply-To: freebsd-chat@jraynard.demon.co.uk References: <15920.877390482@time.cdrom.com> <199710210810.SAA12294@ogre.dtir.qld.gov.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199710210810.SAA12294@ogre.dtir.qld.gov.au>; from Stephen McKay on Tue, Oct 21, 1997 at 06:10:13PM +1000 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [reply-to set to chat] On Tue, Oct 21, 1997 at 06:10:13PM +1000, Stephen McKay wrote: > On Monday, 20th October 1997, "Jordan K. Hubbard" wrote: > > >maybe we should make our release-a-day server a 486SX with 8MB of > >memory and switch it to being a release-a-week server instead. > >We'd not have as useful a service by far, but it sure would catch > >those load sensitive bugs early. :-) I've always believed that developers should have the fastest possible machines and testers should have the slowest known to mankind... > I used to have a 386sx16 with 4Mb ram > and 13.5 Mb of swap. > > Unfortunately, it took sick and died. :-( I have an advert in front of me for an identical machine - (UKP85 or about US$150 for the complete system, half that for a headless system unit). Advertised as "ideal for keeping the kids off your PC!" > I've always been fascinated by those bald blokes that whip themselves > in the name of religious purification. They don't joke either. "Oh system, who art great and mighty, do not crash upon us in our hour of need, we beseech thee. For nothing can be done except at thy command prompt" "Give us this day our daily uptime" "Forgive us our flamewars, as we forgive those who advocate against us" "And lead us not unto Linux, but deliver us from Windows" -- James Raynard, Edinburgh, Scotland. james@jraynard.demon.co.uk http://www.freebsd.org/~jraynard/ From owner-freebsd-hackers Tue Oct 21 15:11:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA13113 for hackers-outgoing; Tue, 21 Oct 1997 15:11:22 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA13107 for ; Tue, 21 Oct 1997 15:11:16 -0700 (PDT) (envelope-from se@X14.MI.Uni-Koeln.DE) Received: from x14.mi.uni-koeln.de ([134.95.219.124]) by Octopussy.MI.Uni-Koeln.DE (8.8.7/8.8.7) with ESMTP id AAA27759; Wed, 22 Oct 1997 00:10:18 +0200 (MET DST) Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.7/8.6.9) id AAA01009; Wed, 22 Oct 1997 00:10:22 +0200 (CEST) X-Face: " Date: Wed, 22 Oct 1997 00:10:22 +0200 From: Stefan Esser To: Joe McGuckin Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: 2.2.2-RELEASE '875 SCSI won't negotiage References: <199710202206.PAA17351@monk.via.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: <199710202206.PAA17351@monk.via.net>; from Joe McGuckin on Mon, Oct 20, 1997 at 03:06:28PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On 1997-10-20 15:06 -0700, Joe McGuckin wrote: > > > (ncr0:0:0): "QUANTUM XP32275W LXY4" type 0 fixed SCSI 2 > sd0(ncr0:0:0): Direct-Access > sd0(ncr0:0:0): WIDE SCSI (16 bit) enabled > sd0(ncr0:0:0): 20.0 MB/s (100 ns, offset 16) > > > Shouldn't this report back 40.0 MB/s for fast wide ultra ? Yes it should, if it supported UW ... But 2.2.2 doesn't and never will (it is history). 2.2-stable does for some time, and 2.2.5 will. So just update your sources to 2.2-stable or wait for the next release ... Regards, STefan From owner-freebsd-hackers Tue Oct 21 15:13:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA13351 for hackers-outgoing; Tue, 21 Oct 1997 15:13:40 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA13337 for ; Tue, 21 Oct 1997 15:13:32 -0700 (PDT) (envelope-from se@X14.MI.Uni-Koeln.DE) Received: from x14.mi.uni-koeln.de ([134.95.219.124]) by Octopussy.MI.Uni-Koeln.DE (8.8.7/8.8.7) with ESMTP id AAA27789; Wed, 22 Oct 1997 00:13:21 +0200 (MET DST) Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.7/8.6.9) id AAA01028; Wed, 22 Oct 1997 00:13:26 +0200 (CEST) X-Face: " Date: Wed, 22 Oct 1997 00:13:26 +0200 From: Stefan Esser To: Joerg Wunsch Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: 2.2.2-RELEASE '875 SCSI won't negotiage References: <199710210124.UAA14405@nospam.hiwaay.net> <19971021081759.TH50130@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: <19971021081759.TH50130@uriah.heep.sax.de>; from J Wunsch on Tue, Oct 21, 1997 at 08:17:59AM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On 1997-10-21 08:17 +0200, J Wunsch wrote: > As dkelly@hiwaay.net wrote: > > > > sd0(ncr0:0:0): WIDE SCSI (16 bit) enabled > > > sd0(ncr0:0:0): 20.0 MB/s (100 ns, offset 16) > > > > > > > > > Shouldn't this report back 40.0 MB/s for fast wide ultra ? > > > > Probably should. > > Probably should not. It should read as ``20 MHz'', this makes no > promises about the actual speed. Yes, I've been thinking so for quite some time, to. But I changed the message to report MB/s, anyway, on popular demand :) If 40MB/s is reported, you still won't be able to get more than some 37MB/s moved, actually, but well, it is the number claimed by the drive and controller vendors, and so it can't be wrong to report it :) Regards, STefan From owner-freebsd-hackers Tue Oct 21 15:23:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA13855 for hackers-outgoing; Tue, 21 Oct 1997 15:23:25 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id PAA13826 for ; Tue, 21 Oct 1997 15:23:15 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id AAA23006 for freebsd-hackers@FreeBSD.ORG; Wed, 22 Oct 1997 00:23:14 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id AAA18786; Wed, 22 Oct 1997 00:18:54 +0200 (MET DST) Message-ID: <19971022001854.DS19056@uriah.heep.sax.de> Date: Wed, 22 Oct 1997 00:18:54 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG Subject: Re: DLT drives References: <"Tom"@Oct> <199710211857.TAA01003@yedi.iaf.nl> <199710211921.MAA00740@grumpy.ccnvhi.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199710211921.MAA00740@grumpy.ccnvhi.com>; from Paul Norton on Oct 21, 1997 12:21:32 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Paul Norton wrote: > > So, Sun, SGI, DEC, etc all just rebadge them. > Not so. Some load their own version of the DLT firmware. Their own versions, or just their own vendor string only? I'd rather assume the latter. The little brother of the NIH syndrome... -- 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-hackers Tue Oct 21 15:23:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA13893 for hackers-outgoing; Tue, 21 Oct 1997 15:23:38 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id PAA13887 for ; Tue, 21 Oct 1997 15:23:34 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id AAA23008 for freebsd-hackers@FreeBSD.ORG; Wed, 22 Oct 1997 00:23:29 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id AAA18609; Wed, 22 Oct 1997 00:03:18 +0200 (MET DST) Message-ID: <19971022000318.WS35693@uriah.heep.sax.de> Date: Wed, 22 Oct 1997 00:03:18 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG Subject: Re: Urge to apply the vn device hack even to 2.2.5 References: <15920.877390482@time.cdrom.com> <199710210810.SAA12294@ogre.dtir.qld.gov.au> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199710210810.SAA12294@ogre.dtir.qld.gov.au>; from Stephen McKay on Oct 21, 1997 18:10:13 +1000 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Stephen McKay wrote: > Hey, I used to do this for ya! I used to have a 386sx16 with 4Mb ram > and 13.5 Mb of swap. Yes, every byte of swap counted! It didn't have > enough disk to store anything, so /usr/src and /usr/obj were NFS. It > used to take around 10 days to crank out a make world. Don't use a blatant `make world' on such a slow machine. You could perhaps cut it in five days by doing the steps manually. :) That is, make -k and install the libs, make -k and install the rest, then make the rest again, look where it still falls over, and resolve any bootstrapping conflicts. I usually do it this way even on much faster machines. I'm using `make world' only for hardware tests. ;-) -- 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-hackers Tue Oct 21 16:41:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA18386 for hackers-outgoing; Tue, 21 Oct 1997 16:41:22 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from cynic.portal.ca (root@cynic.portal.ca [204.174.36.7]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA18373 for ; Tue, 21 Oct 1997 16:41:14 -0700 (PDT) (envelope-from cjs@portal.ca) Received: from localhost ([[UNIX: localhost]]) by cynic.portal.ca (8.8.5/8.8.5) with SMTP id QAA02947; Tue, 21 Oct 1997 16:40:27 -0700 (PDT) X-Authentication-Warning: cynic.portal.ca: cjs owned process doing -bs Date: Tue, 21 Oct 1997 16:40:27 -0700 (PDT) From: Curt Sampson Reply-To: Curt Sampson To: "Alexander B. Povolotsky" cc: hackers@FreeBSD.ORG, netbsd-users@netbsd.org Subject: Re: on ccd and large disk array In-Reply-To: <199710211052.OAA12808@asteroid.mgt.msk.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 21 Oct 1997, Alexander B. Povolotsky wrote: > We're making a (relatively) large disk array using ccd: 5 Micropolis HDDs, > 8.7 Gb each, i.e. about 40 Gb total. > > Does anyone know possible traps on our way? Is FFS as-is stable on 40 Gb > filesystems? What may we need to patch? I can't see any reason why a little one like that would be a problem. :-) If you wanted to do a slightly larger one, you might follow the lead of NASA Ames Research Laboratory. Take a couple of racks of 9 x 9 GB drives and put a hardware RAID-5 across them, for about 150 GB of storage: sd9: 156260MB, 12594 cyl, 64 head, 141 sec, 512 bytes/sect x 320020992 sectors Then take 4 of those and put a ccd across it, and put FFS on that: Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ccd0a 637453560 8 605580872 0% /mnt That gives you a little over 600 GB on a single FFS. Of course, that's probably not enough storage, so you want to have a couple of those to bring it over a terrabite. This is NetBSD running on a smallish AlphaServer 8400 (only 2 GB RAM, 72 PCI slots [on 19 buses], one or two 800 MB HPPI buses). There's four more with similar amounts of storage kicking around the lab, too. (If you FreeBSD guys ever feel like upgrading that little FTP server of yours you have over at Walnut Creek, feel free to give us a call. :-)) cjs Curt Sampson cjs@portal.ca Info at http://www.portal.ca/ Internet Portal Services, Inc. Through infinite myst, software reverberates Vancouver, BC (604) 257-9400 In code possess'd of invisible folly. From owner-freebsd-hackers Tue Oct 21 16:48:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA18760 for hackers-outgoing; Tue, 21 Oct 1997 16:48:01 -0700 (PDT) (envelope-from owner-freebsd-hackers) 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 QAA18733; Tue, 21 Oct 1997 16:47:45 -0700 (PDT) (envelope-from gdonl@tsc.tdk.com) 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 QAA05116; Tue, 21 Oct 1997 16:47:44 -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 QAA18441; Tue, 21 Oct 1997 16:47:43 -0700 (PDT) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id QAA09208; Tue, 21 Oct 1997 16:47:42 -0700 (PDT) From: Don Lewis Message-Id: <199710212347.QAA09208@salsa.gv.tsc.tdk.com> Date: Tue, 21 Oct 1997 16:47:42 -0700 In-Reply-To: Stefan Esser "Re: 2.2.2-RELEASE '875 SCSI won't negotiage" (Oct 22, 12:13am) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Stefan Esser , Joerg Wunsch Subject: Re: 2.2.2-RELEASE '875 SCSI won't negotiage Cc: freebsd-hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Oct 22, 12:13am, Stefan Esser wrote: } Subject: Re: 2.2.2-RELEASE '875 SCSI won't negotiage } On 1997-10-21 08:17 +0200, J Wunsch wrote: } > As dkelly@hiwaay.net wrote: } > } > > > sd0(ncr0:0:0): WIDE SCSI (16 bit) enabled } > > > sd0(ncr0:0:0): 20.0 MB/s (100 ns, offset 16) } > Probably should not. It should read as ``20 MHz'', this makes no } > promises about the actual speed. } } Yes, I've been thinking so for quite some time, to. } But I changed the message to report MB/s, anyway, on } popular demand :) } } If 40MB/s is reported, you still won't be able to get } more than some 37MB/s moved, actually, but well, it is } the number claimed by the drive and controller vendors, } and so it can't be wrong to report it :) But isn't this misleading if it's only connected to narrow devices? From owner-freebsd-hackers Tue Oct 21 17:20:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA20836 for hackers-outgoing; Tue, 21 Oct 1997 17:20:59 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from fly.HiWAAY.net (root@fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA20831 for ; Tue, 21 Oct 1997 17:20:55 -0700 (PDT) (envelope-from dkelly@nospam.hiwaay.net) Received: from nospam.hiwaay.net (max4-120.HiWAAY.net [208.147.145.120]) by fly.HiWAAY.net (8.8.7/8.8.6) with ESMTP id TAA20787 for ; Tue, 21 Oct 1997 19:20:47 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by nospam.hiwaay.net (8.8.7/8.8.4) with ESMTP id TAA18051 for ; Tue, 21 Oct 1997 19:09:47 -0500 (CDT) Message-Id: <199710220009.TAA18051@nospam.hiwaay.net> X-Mailer: exmh version 2.0zeta 7/24/97 To: freebsd-hackers@FreeBSD.ORG From: dkelly@hiwaay.net Subject: Re: 2.2.2-RELEASE '875 SCSI won't negotiage In-reply-to: Message from j@uriah.heep.sax.de (J Wunsch) of "Tue, 21 Oct 1997 08:17:59 +0200." <19971021081759.TH50130@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Oct 1997 19:09:47 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Joerg Wunsch replies: > > As dkelly@hiwaay.net wrote: > > > > sd0(ncr0:0:0): WIDE SCSI (16 bit) enabled > > > sd0(ncr0:0:0): 20.0 MB/s (100 ns, offset 16) > > > > > > > > > Shouldn't this report back 40.0 MB/s for fast wide ultra ? > > > > Probably should. > > Probably should not. It should read as ``20 MHz'', this makes no > promises about the actual speed. Poor choice of words on my part. The ncr driver is calling things exactly right. Went back and RTFM'ed my Asus SC875 manual and obsverved on page 11 the default Synchronous Transfer Rate (MS/Sec) (sic) is 20. So is this MB/ sec or MHz? Time to reboot and see what numbers I can enter in the BIOS. -- David Kelly N4HHE, dkelly@hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. From owner-freebsd-hackers Tue Oct 21 17:23:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA21009 for hackers-outgoing; Tue, 21 Oct 1997 17:23:36 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from stox.sa.enteract.com (stox.sa.enteract.com [207.229.132.161]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA21002 for ; Tue, 21 Oct 1997 17:23:32 -0700 (PDT) (envelope-from ken@stox.sa.enteract.com) Received: from localhost (localhost.stox.sa.enteract.com [127.0.0.1]) by stox.sa.enteract.com (8.8.7/8.6.12) with SMTP id TAA10158; Tue, 21 Oct 1997 19:22:43 -0500 (CDT) Date: Tue, 21 Oct 1997 19:22:40 -0500 (CDT) From: "Kenneth P. Stox" Reply-To: stox@enteract.com To: Joerg Wunsch cc: freebsd-hackers@FreeBSD.ORG Subject: Re: DLT drives In-Reply-To: <19971022001854.DS19056@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 22 Oct 1997, J Wunsch wrote: >> > So, Sun, SGI, DEC, etc all just rebadge them. > >> Not so. Some load their own version of the DLT firmware. > >Their own versions, or just their own vendor string only? I'd rather >assume the latter. The little brother of the NIH syndrome... Well, I can speak from experience that the DEC, Quantum, and SGI versions are different. Whether they are actually different, or that each vendor has chosen different loads from the same code base is a good question. There have been many different loads of firmware since Digital first introduced them, and Quantum took over. Of course, if one has access to them, one may load SGI firware on a Quantum drive, etc. -Ken Stox "If you work with Petabytes, does that make you a Petaphile ?" stox@enteract.com From owner-freebsd-hackers Tue Oct 21 19:03:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA26043 for hackers-outgoing; Tue, 21 Oct 1997 19:03:31 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from plum.cyber.com.au (plum.cyber.com.au [203.7.155.24]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id TAA26037 for ; Tue, 21 Oct 1997 19:03:25 -0700 (PDT) (envelope-from darrenr@cyber.com.au) Received: (from darrenr@localhost) by plum.cyber.com.au (8.6.12/8.6.6) id MAA01643; Wed, 22 Oct 1997 12:02:37 +1000 From: Darren Reed Message-Id: <199710220202.MAA01643@plum.cyber.com.au> Subject: Re: FreeBSD 3.0 kernel API ?! To: tlambert@primenet.com (Terry Lambert) Date: Wed, 22 Oct 1997 12:02:36 +1000 (EST) Cc: hackers@freebsd.org In-Reply-To: <199710211856.LAA13887@usr04.primenet.com> from "Terry Lambert" at Oct 21, 97 06:56:40 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In some mail I received from Terry Lambert, sie wrote > > > > If it's kernel code you are testing, you will need to include if_var.h > > > for it to run in the kernel; therefore you need to include if_var.h > > > for it to run in the test jig, which pretends to be the kernel. > > > > Well, you see, that's just it. It doesn't need anything else, only the > > "struct ifnet". I'd argue that a structure can be used and should be > > available anywhere, it just describes a way to store some values in > > memory. I have no problems with keeping variable names and function > > prototypes away from users (in different .h files or whatever), it > > even makes sense. But I don't think the same logic should be extended > > to structures. I assume things like struct proc and struct user are > > still available without defining KERNEL ? > > Say I agree with you. > > How will you deal with struct ifnet when we rename all the member > variables from their current names to "opaque_variable_01" through > "opaque_variable_NN"? Even if you can depend on the structure, you > can't reasonably expect the kernel internal interface to not change. This sort of change I think is, to put it bluntly, fucked. (I'm probably putting a lot of people who `control' freebsd offside here). I'd heartily recommend spending time on something worthwhile rather than going around making life more difficult for people that. It's a change for the sake of a change with no reasonable reason to happen. To recite an old adage: if it's not broken, don't fix it. Things weren't broken. > I think your test case may be a bit contrived to justify your wanting > to access the internal structure. 8-|. Well, at least if I implement a fake list of interfaces using other code, I can still look them up, etc. blah, time to giveup on FreeBSD and use Linux I think...at least Linus doesn't allow silly changes that achieve nothing and just cause more work. Darren From owner-freebsd-hackers Tue Oct 21 19:14:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA26593 for hackers-outgoing; Tue, 21 Oct 1997 19:14:38 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from plum.cyber.com.au (plum.cyber.com.au [203.7.155.24]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id TAA26575 for ; Tue, 21 Oct 1997 19:14:25 -0700 (PDT) (envelope-from darrenr@cyber.com.au) Received: (from darrenr@localhost) by plum.cyber.com.au (8.6.12/8.6.6) id MAA01798 for hackers@freebsd.org; Wed, 22 Oct 1997 12:14:23 +1000 Received: from satay.cyber.com.au (satay.cyber.com.au [203.7.155.20]) by plum.cyber.com.au (8.6.12/8.6.6) with ESMTP id GAA29580 for ; Sat, 18 Oct 1997 06:17:55 +1000 Received: (from uucp@localhost) by satay.cyber.com.au (8.7.4/8.7.3) id GAA18029 for ; Sat, 18 Oct 1997 06:14:40 +1000 (EST) Received: from homeworld.cygnus.com(205.180.83.70) by satay.cyber.com.au via smap (V1.3) id sma018025; Sat Oct 18 06:14:22 1997 Received: (qmail 5136 invoked by uid 1110); 17 Oct 1997 10:45:20 -0000 Delivered-To: darrenr@netbsd.org Received: (qmail 4659 invoked by uid 605); 17 Oct 1997 10:43:25 -0000 Received: (qmail 4619 invoked by alias); 17 Oct 1997 10:43:12 -0000 Delivered-To: developers@netbsd.org Received: (qmail 4605 invoked from network); 17 Oct 1997 10:43:10 -0000 Received: from kechara.flame.org (192.80.44.209) by homeworld.cygnus.com with SMTP; 17 Oct 1997 10:43:10 -0000 Received: (qmail 11041 invoked by uid 173); 17 Oct 1997 10:42:13 -0000 Date: 17 Oct 1997 10:42:13 -0000 Message-ID: <19971017104213.11040.qmail@kechara.flame.org> From: explorer@flame.org To: developers@NetBSD.ORG Subject: Possible SERIOUS bug in open()? Delivered-To: netbsd-developers@NetBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk This was sent to me recently... It seems to be a pretty serious hole in open() and permissions... Note, in the following, open() succeeds, and ioctls are probably executed... /* * This will give you a file descriptor on a device you should not have * access to. This seems really, really screwed up, since holding a fd * lets you do a lot of ioctls that you should not be able to do... */ #include #include #include #include int main(int argc, char **argv) { int fd; fd = open("/dev/rsd0a", -1, 0); if (fd < 0) err(1, "open"); } From owner-freebsd-hackers Tue Oct 21 19:30:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA27547 for hackers-outgoing; Tue, 21 Oct 1997 19:30:34 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA27542 for ; Tue, 21 Oct 1997 19:30:31 -0700 (PDT) (envelope-from durian@plutotech.com) Received: from shane.plutotech.com (shane.plutotech.com [206.168.67.149]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id UAA15838; Tue, 21 Oct 1997 20:30:28 -0600 (MDT) Message-Id: <199710220230.UAA15838@pluto.plutotech.com> From: "Mike Durian" To: "Mike Durian" cc: hackers@FreeBSD.ORG Subject: Re: user vm addr to kernel vm addr In-reply-to: Your message of "Mon, 20 Oct 1997 20:01:11 MDT." Date: Tue, 21 Oct 1997 20:30:28 -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 20 Oct 1997 20:01:11 MDT, "Mike Durian" wrote: > In my virtual file system I'd like to speed up reads and writes >by copying directly from the uio structure to a vm address of >a buffer in the user process running on behalf of the filesystem. >I'm currently shoving all the data through a socket that the >user process reads from and copies into a buffer. I'd like to >go direct and skip the socket writing part. Does that make sense? > Anyway, I want to copy from a uio to a different process's vm space. >I can get the vm address of the destination buffer over a socket and >think I can use vm_fault_wire to make sure it stays accessable, but >I don't know how to convert that user space vm address into a >kernel space vm address that I can then use with copyout. > Is there an easy (or any) way to do this? I'm following up to my own post. I should mention that the user process containing the vm buffer that I want to convert is *not* curproc. I want to go between that buffer and a struct uio in my VOP_READ and VOP_WRITE functions. I did find something that works, but perhaps someone has a better/cleaner way of doing it. I don't think I need to do the vm_fault_wire either. for each page in the vm buffer vm_map_lookup to get the vm object vm_page_lookup to get the page for the object kmem_alloc_pageable to allocate kernel vm space pmap_qenter to map the pages into the kernel vm address uiomove copy from the new kernel address to uio pmap_qremove to unmap the pages kmem_free to release the kernel vm space mike From owner-freebsd-hackers Tue Oct 21 19:56:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA29029 for hackers-outgoing; Tue, 21 Oct 1997 19:56:10 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.235]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA28931 for ; Tue, 21 Oct 1997 19:55:44 -0700 (PDT) (envelope-from koshy@india.hp.com) Received: from postbox.india.hp.com (postbox.india.hp.com [15.10.45.1]) by palrel1.hp.com (8.8.6/8.8.5tis) with ESMTP id TAA06692 for ; Tue, 21 Oct 1997 19:55:33 -0700 (PDT) Message-Id: <199710220255.TAA06692@palrel1.hp.com> Received: from localhost by postbox.india.hp.com with ESMTP (1.39.111.2/16.2) id AA095678614; Wed, 22 Oct 1997 08:20:14 +0530 To: freebsd-hackers@freebsd.org Subject: "UNIX An OS for the people" Date: Wed, 22 Oct 1997 08:20:13 +0530 From: A Joseph Koshy Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Press coverage on BSD (i.e. BSDI) and Linux. No mention of FreeBSD :-(. http://www.wcmh.com/lantimes/97/97oct/710b061a.html Koshy My Personal Opinions Only. From owner-freebsd-hackers Tue Oct 21 19:59:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA29196 for hackers-outgoing; Tue, 21 Oct 1997 19:59:37 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA29191 for ; Tue, 21 Oct 1997 19:59:34 -0700 (PDT) (envelope-from dcarmich@Mars.mcs.net) Received: from Mars.mcs.net (dcarmich@Mars.mcs.net [192.160.127.85]) by Kitten.mcs.com (8.8.5/8.8.2) with ESMTP id VAA27429 for ; Tue, 21 Oct 1997 21:59:33 -0500 (CDT) Received: (from dcarmich@localhost) by Mars.mcs.net (8.8.7/8.8.2) id VAA20051 for freebsd-hackers@freebsd.org; Tue, 21 Oct 1997 21:59:33 -0500 (CDT) From: Douglas Carmichael Message-Id: <199710220259.VAA20051@Mars.mcs.net> Subject: Hardware RAID-x controllers for FreeBSD? To: freebsd-hackers@freebsd.org Date: Tue, 21 Oct 1997 21:59:33 -0500 (CDT) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Do any you know of any hardware RAID-x controllers (x = >1, preferably 5) that work with FreeBSD and either: 1) Have a native driver in FreeBSD for them or 2) Appear as just another big disk From owner-freebsd-hackers Tue Oct 21 20:24:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA00882 for hackers-outgoing; Tue, 21 Oct 1997 20:24:49 -0700 (PDT) (envelope-from owner-freebsd-hackers) 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 UAA00873 for ; Tue, 21 Oct 1997 20:24:41 -0700 (PDT) (envelope-from jkh@time.cdrom.com) 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 UAA16063; Tue, 21 Oct 1997 20:23:04 -0700 (PDT) To: Darren Reed cc: tlambert@primenet.com (Terry Lambert), hackers@FreeBSD.ORG Subject: Re: FreeBSD 3.0 kernel API ?! In-reply-to: Your message of "Wed, 22 Oct 1997 12:02:36 +1000." <199710220202.MAA01643@plum.cyber.com.au> Date: Tue, 21 Oct 1997 20:23:03 -0700 Message-ID: <16059.877490583@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > blah, time to giveup on FreeBSD and use Linux I think...at least Linus > doesn't allow silly changes that achieve nothing and just cause more > work. I think it's more likely time to stop bitching about things which don't and never did merit such a degree of vitriol or personal attachment. I suspect that you, like us, have better things to do with your life than quibble over minutiae like this in the header files and I strongly suggest that you simply get back to it rather than continue to draw out what started as a pointless debate and has only declined from there. Jordan From owner-freebsd-hackers Tue Oct 21 20:34:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA01345 for hackers-outgoing; Tue, 21 Oct 1997 20:34:24 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA01339 for ; Tue, 21 Oct 1997 20:34:22 -0700 (PDT) (envelope-from sef@Kithrup.COM) Received: (from sef@localhost) by kithrup.com (8.8.5/8.6.6) id UAA23820; Tue, 21 Oct 1997 20:34:20 -0700 (PDT) Date: Tue, 21 Oct 1997 20:34:20 -0700 (PDT) From: Sean Eric Fagan Message-Id: <199710220334.UAA23820@kithrup.com> To: hackers@freebsd.org Reply-To: hackers@freebsd.org Subject: Re: FreeBSD 3.0 kernel API ?! In-Reply-To: <199710220202.MAA01643.kithrup.freebsd.hackers@plum.cyber.com.au> References: <199710211856.LAA13887@usr04.primenet.com> from "Terry Lambert" at Oct 21, 97 06:56:40 pm Organization: Kithrup Enterprises, Ltd. Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> How will you deal with struct ifnet when we rename all the member >> variables from their current names to "opaque_variable_01" through >> "opaque_variable_NN"? Even if you can depend on the structure, you >> can't reasonably expect the kernel internal interface to not change. >This sort of change I think is, to put it bluntly, fucked. Terry's problem is that he is forgetting that non-kernel bits are part of the OS in unix. This means that some non-kernel bits have to know the format (and location) of some kernel data structures, sometimes. (While there are many cases where you can abstract this into a usable API, there are many other cases where you can't -- because what you want to get at is, indeed, exactly what the kernel is using.) This is further complicated by the fact that some utilities people have decided are part of the OS are not maintained by us. Ah, well. Reply to me, or the list, but not both, please. From owner-freebsd-hackers Tue Oct 21 20:37:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA01522 for hackers-outgoing; Tue, 21 Oct 1997 20:37:32 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from phoenix.its.rpi.edu (phoenix.its.rpi.edu [128.113.161.45]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA01517 for ; Tue, 21 Oct 1997 20:37:30 -0700 (PDT) (envelope-from dec@phoenix.its.rpi.edu) Received: from localhost (dec@localhost) by phoenix.its.rpi.edu (8.8.7/8.8.7) with SMTP id XAA08592 for ; Tue, 21 Oct 1997 23:38:21 -0400 (EDT) Date: Tue, 21 Oct 1997 23:38:21 -0400 (EDT) From: "David E. Cross" To: freebsd-hackers@freebsd.org Subject: Where's the beef^Wcdrom image? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I thought that we/you (whatever) would be distributing a CDROM image of the new RELEASEs? If this is true, could someone point me at it? -- David Cross ACS Consultant From owner-freebsd-hackers Tue Oct 21 20:55:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA02432 for hackers-outgoing; Tue, 21 Oct 1997 20:55:00 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from plum.cyber.com.au (plum.cyber.com.au [203.7.155.24]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id UAA02426 for ; Tue, 21 Oct 1997 20:54:56 -0700 (PDT) (envelope-from darrenr@cyber.com.au) Received: (from darrenr@localhost) by plum.cyber.com.au (8.6.12/8.6.6) id NAA03087; Wed, 22 Oct 1997 13:54:02 +1000 From: Darren Reed Message-Id: <199710220354.NAA03087@plum.cyber.com.au> Subject: Re: FreeBSD 3.0 kernel API ?! To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 22 Oct 1997 13:54:01 +1000 (EST) Cc: tlambert@primenet.com, hackers@FreeBSD.ORG In-Reply-To: <16059.877490583@time.cdrom.com> from "Jordan K. Hubbard" at Oct 21, 97 08:23:03 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In some mail I received from Jordan K. Hubbard, sie wrote > > > blah, time to giveup on FreeBSD and use Linux I think...at least Linus > > doesn't allow silly changes that achieve nothing and just cause more > > work. > > I think it's more likely time to stop bitching about things which > don't and never did merit such a degree of vitriol or personal > attachment. I suspect that you, like us, have better things to do > with your life than quibble over minutiae like this in the header > files and I strongly suggest that you simply get back to it rather > than continue to draw out what started as a pointless debate and has > only declined from there. Couldn't agree more. I've wondered a few times, how much time I've wasted on this thread compared with how long it would have taken me to accomodate this change in FreeBSD... Darren From owner-freebsd-hackers Tue Oct 21 21:20:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA03628 for hackers-outgoing; Tue, 21 Oct 1997 21:20:13 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA03538 for ; Tue, 21 Oct 1997 21:19:02 -0700 (PDT) (envelope-from jamil@trojanhorse.ml.org) Received: from localhost (jamil@localhost) by trojanhorse.ml.org (8.8.7/8.8.5) with SMTP id VAA01050; Tue, 21 Oct 1997 21:16:04 -0700 (PDT) Date: Tue, 21 Oct 1997 21:16:03 -0700 (PDT) From: "Jamil J. Weatherbee" To: Douglas Carmichael cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Hardware RAID-x controllers for FreeBSD? In-Reply-To: <199710220259.VAA20051@Mars.mcs.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I think adaptec have some that just look like a 2940, I saw one for about $800. On Tue, 21 Oct 1997, Douglas Carmichael wrote: > Do any you know of any hardware RAID-x controllers (x = >1, preferably 5) > that work with FreeBSD and either: > 1) Have a native driver in FreeBSD for them > or 2) Appear as just another big disk > > From owner-freebsd-hackers Tue Oct 21 22:00:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA05642 for hackers-outgoing; Tue, 21 Oct 1997 22:00:41 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from cs4.cs.ait.ac.th (root@cs4.cs.ait.ac.th [192.41.170.15]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id WAA05637 for ; Tue, 21 Oct 1997 22:00:30 -0700 (PDT) (envelope-from a96456@cs.ait.ac.th) Received: from bazooka.cs.ait.ac.th (a96456@bazooka.cs.ait.ac.th [192.41.170.2]) by cs4.cs.ait.ac.th (8.6.12/) with ESMTP id LAA05692 for ; Wed, 22 Oct 1997 11:48:56 +0700 Received: from localhost (a96456@localhost) by bazooka.cs.ait.ac.th (8.8.5/8.8.5) with SMTP id LAA19938 for ; Wed, 22 Oct 1997 11:48:50 +0700 (GMT) X-Authentication-Warning: bazooka.cs.ait.ac.th: a96456 owned process doing -bs Date: Wed, 22 Oct 1997 11:48:49 +0700 (GMT) From: Sunthiti Patchararungruang To: hackers@freebsd.org Subject: Problem with FreeBSD2.2.2 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Dear Everyboy I have a computer with FreeBSD2.2.2. I have a problem about system resource. When I login as a normal user up to 4 session, I cannot use "man" command. It always report that "cannot fork" and "resource is temporary unavailable". However, the problem does not occur when I login as root. I think the problem is come from the swap space. Maybe normal user cannot use it because all swap space is empty, checked by "swapinfo". However, I don't know how to solve it. Please help me. My system has 12MB RAM, 120MB HD for system, 70MB for swap. I compiled the kernel with "users 40". Finally, the following is the data in "/etc/fstab". # Device Mountpoint FStype Options Dump Pass# /dev/wd0s2b none swap sw 0 0 /dev/wd0a / ufs rw 1 1 proc /proc procfs rw 0 0 Sincerely Yours, Sunthiti Patchararungraung From owner-freebsd-hackers Tue Oct 21 23:02:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA08110 for hackers-outgoing; Tue, 21 Oct 1997 23:02:10 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA08096 for ; Tue, 21 Oct 1997 23:02:07 -0700 (PDT) (envelope-from tom@sdf.com) Received: from tom by misery.sdf.com with smtp (Exim 1.73 #1) id 0xNtqH-00036Z-00; Tue, 21 Oct 1997 23:00:29 -0700 Date: Tue, 21 Oct 1997 23:00:27 -0700 (PDT) From: Tom To: "Jamil J. Weatherbee" cc: Douglas Carmichael , freebsd-hackers@freebsd.org Subject: Re: Hardware RAID-x controllers for FreeBSD? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 21 Oct 1997, Jamil J. Weatherbee wrote: > I think adaptec have some that just look like a 2940, I saw one for about > $800. I don't know about that. I believe those controllers do look like a 2940, but the RAID functionality requires software support. So basically, the looks AND acts like a 2940. The DPT SmartRaid IV works well. The driver is not incorporated into the base distribution, but you can get it for 2.2-stable and freebsd-current. I also like this card, because unlike the Mylex cards, additional channels can be added later via a daughtercard. Tom From owner-freebsd-hackers Tue Oct 21 23:03:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA08198 for hackers-outgoing; Tue, 21 Oct 1997 23:03:41 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA08189 for ; Tue, 21 Oct 1997 23:03:38 -0700 (PDT) (envelope-from tom@sdf.com) Received: from tom by misery.sdf.com with smtp (Exim 1.73 #1) id 0xNtrS-00036c-00; Tue, 21 Oct 1997 23:01:42 -0700 Date: Tue, 21 Oct 1997 23:01:41 -0700 (PDT) From: Tom To: Sunthiti Patchararungruang cc: hackers@freebsd.org Subject: Re: Problem with FreeBSD2.2.2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 22 Oct 1997, Sunthiti Patchararungruang wrote: > Dear Everyboy > > I have a computer with FreeBSD2.2.2. I have a problem about system > resource. When I login as a normal user up to 4 session, I cannot use > "man" command. It always report that "cannot fork" and "resource is You should use the freebsd-questions list, not freebsd-hackers Your problem is caused by resource limits set in login.conf. See the man page. Tom From owner-freebsd-hackers Tue Oct 21 23:04:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA08287 for hackers-outgoing; Tue, 21 Oct 1997 23:04:21 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from shell.futuresouth.com (shell.futuresouth.com [207.141.254.20]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA08282 for ; Tue, 21 Oct 1997 23:04:18 -0700 (PDT) (envelope-from fullermd@futuresouth.com) Received: from shell.futuresouth.com (mail.futuresouth.com [207.141.254.21]) by shell.futuresouth.com (8.8.5/8.8.5) with SMTP id BAA11424; Wed, 22 Oct 1997 01:04:05 -0500 (CDT) Date: Wed, 22 Oct 1997 01:04:05 -0500 (CDT) From: "Matthew D. Fuller" To: Sunthiti Patchararungruang cc: hackers@FreeBSD.ORG Subject: Re: Problem with FreeBSD2.2.2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 22 Oct 1997, Sunthiti Patchararungruang wrote: > Dear Everyboy > > I have a computer with FreeBSD2.2.2. I have a problem about system > resource. When I login as a normal user up to 4 session, I cannot use > "man" command. It always report that "cannot fork" and "resource is > temporary unavailable". However, the problem does not occur when I login > as root. I think the problem is come from the swap space. Maybe normal > user cannot use it because all swap space is empty, checked by > "swapinfo". However, I don't know how to solve it. Please help me. See man login.conf(5?) you have to edit your login class in /etc/login.conf or change it using vipw. the default user class has CPU and process resource limit which you're hitting there. > > Sincerely Yours, > Sunthiti Patchararungraung > > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* | FreeBSD; the way computers were meant to be | * "The only reason I'm burning my candle at both ends, is * | that I haven't figured out how to light the middle yet."| * fullermd@futuresouth.com :-} MAtthew Fuller * | http://keystone.westminster.edu/~fullermd | *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* From owner-freebsd-hackers Tue Oct 21 23:14:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA08898 for hackers-outgoing; Tue, 21 Oct 1997 23:14:37 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA08888 for ; Tue, 21 Oct 1997 23:14:33 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id IAA26733 for freebsd-hackers@FreeBSD.ORG; Wed, 22 Oct 1997 08:14:29 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id HAA20644; Wed, 22 Oct 1997 07:59:19 +0200 (MET DST) Message-ID: <19971022075919.IP16123@uriah.heep.sax.de> Date: Wed, 22 Oct 1997 07:59:19 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG Subject: Re: DLT drives References: <19971022001854.DS19056@uriah.heep.sax.de> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Kenneth P. Stox on Oct 21, 1997 19:22:40 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Kenneth P. Stox wrote: > >> Not so. Some load their own version of the DLT firmware. > > > >Their own versions, or just their own vendor string only? > Well, I can speak from experience that the DEC, Quantum, and SGI > versions are different. Again, in what respect are they different? If it's just the vendor string, you can certainly ignore it. I would find it hard that they e.g. would implement all their different set of mode pages. -- 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-hackers Tue Oct 21 23:14:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA08943 for hackers-outgoing; Tue, 21 Oct 1997 23:14:53 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA08930 for ; Tue, 21 Oct 1997 23:14:49 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id IAA26737 for freebsd-hackers@FreeBSD.ORG; Wed, 22 Oct 1997 08:14:44 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id IAA20666; Wed, 22 Oct 1997 08:03:41 +0200 (MET DST) Message-ID: <19971022080341.HR59190@uriah.heep.sax.de> Date: Wed, 22 Oct 1997 08:03:41 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG Subject: Re: 2.2.2-RELEASE '875 SCSI won't negotiage References: <19971021081759.TH50130@uriah.heep.sax.de> <199710220009.TAA18051@nospam.hiwaay.net> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199710220009.TAA18051@nospam.hiwaay.net>; from dkelly@hiwaay.net on Oct 21, 1997 19:09:47 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As dkelly@hiwaay.net wrote: > Went back and RTFM'ed my Asus SC875 manual and obsverved on page 11 > the default Synchronous Transfer Rate (MS/Sec) (sic) is 20. So is this MB/ > sec or MHz? MHz. Together with the 16-bit bus, it makes a theoretical maximum of 40 MB/s (minus transaction overhead which is, as Stefan mentioned, not neglicible). -- 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-hackers Wed Oct 22 00:02:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA11459 for hackers-outgoing; Wed, 22 Oct 1997 00:02:20 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from casparc.ppp.net (mail.ppp.net [194.64.12.35]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id AAA11442 for ; Wed, 22 Oct 1997 00:02:10 -0700 (PDT) (envelope-from ernie!bert.kts.org!hm@ppp.net) Received: from ernie by casparc.ppp.net with uucp (Smail3.1.28.1 #1) id m0xNunr-0032TrC; Wed, 22 Oct 97 08:02 MET Received: from bert.kts.org(really [194.55.156.2]) by ernie.kts.org via sendmail with smtp id for ; Wed, 22 Oct 1997 08:44:25 +0200 (MET DST) (Smail-3.2.0.91 1997-Jan-14 #2 built 1997-Feb-8) Received: by bert.kts.org via sendmail with stdio id for freebsd-hackers@FreeBSD.ORG; Wed, 22 Oct 1997 08:36:40 +0200 (CEST) (Smail-3.2.0.94 1997-Apr-22 #7 built 1997-Jul-4) Message-Id: From: hm@kts.org (Hellmuth Michaelis) Subject: Re: DLT drives In-Reply-To: <19971022001854.DS19056@uriah.heep.sax.de> from J Wunsch at "Oct 22, 97 00:18:54 am" To: joerg_wunsch@uriah.heep.sax.de Date: Wed, 22 Oct 1997 08:36:40 +0200 (CEST) Cc: freebsd-hackers@FreeBSD.ORG Organization: Kitchen Table Systems Reply-To: hm@kts.org X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk J Wunsch wrote: > > > Not so. Some load their own version of the DLT firmware. > > Their own versions, or just their own vendor string only? I'd rather > assume the latter. Their own versions. HP has a DLT (version) which can be run in 7980 mode (which is an HP reel to reel tape) and i doubt this is possible with the standard firmware. hellmuth -- Hellmuth Michaelis hm@kts.org Hamburg, Europe "Those who can, do. Those who can't, talk. And those who can't talk, talk about talking." (B. Shaw) From owner-freebsd-hackers Wed Oct 22 00:31:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA13240 for hackers-outgoing; Wed, 22 Oct 1997 00:31:12 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id AAA13231 for ; Wed, 22 Oct 1997 00:31:09 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA27256 for freebsd-hackers@freebsd.org; Wed, 22 Oct 1997 09:31:07 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id JAA00380; Wed, 22 Oct 1997 09:30:40 +0200 (MET DST) Message-ID: <19971022093040.UM28723@uriah.heep.sax.de> Date: Wed, 22 Oct 1997 09:30:40 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@freebsd.org (FreeBSD hackers) Subject: Re: Possible SERIOUS bug in open()? References: <19971017104213.11040.qmail@kechara.flame.org> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <19971017104213.11040.qmail@kechara.flame.org>; from explorer@flame.org on Oct 17, 1997 10:42:13 -0000 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As explorer@flame.org wrote: > This was sent to me recently... It seems to be a pretty serious hole > in open() and permissions... Fixed. -- 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-hackers Wed Oct 22 00:42:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA13951 for hackers-outgoing; Wed, 22 Oct 1997 00:42:15 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA13946 for ; Wed, 22 Oct 1997 00:42:09 -0700 (PDT) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (localhost.gsoft.com.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id RAA01949; Wed, 22 Oct 1997 17:08:28 +0930 (CST) Message-Id: <199710220738.RAA01949@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: jbryant@tfs.net cc: jamil@trojanhorse.ml.org (Jamil J. Weatherbee), freebsd-hackers@freebsd.org Subject: Re: Solid State Disks In-reply-to: Your message of "Tue, 21 Oct 1997 08:41:01 EST." <199710211341.IAA11750@argus.tfs.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 22 Oct 1997 17:08:27 +0930 From: Mike Smith Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > In reply: > > Anybody seen any good literature/prices on this sort of thing lately. How > > long are they rumored to exist. It would be really cool if a PC was like > > an hp48, damn thing never crashes and is basically always on. > > kinda cool... SS disks have been around for a while, but i don't > recall non-volatility though. Several industrial computer suppliers have devices that are basically an IDE interface, a micro, a pile of 72-pin SIMMs and a battery. mike From owner-freebsd-hackers Wed Oct 22 01:39:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA16812 for hackers-outgoing; Wed, 22 Oct 1997 01:39:32 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA16807 for ; Wed, 22 Oct 1997 01:39:30 -0700 (PDT) (envelope-from jamil@trojanhorse.ml.org) Received: from localhost (jamil@localhost) by trojanhorse.ml.org (8.8.7/8.8.5) with SMTP id BAA09787; Wed, 22 Oct 1997 01:38:11 -0700 (PDT) Date: Wed, 22 Oct 1997 01:38:11 -0700 (PDT) From: "Jamil J. Weatherbee" To: Joerg Wunsch cc: FreeBSD hackers Subject: Re: Possible SERIOUS bug in open()? In-Reply-To: <19971022093040.UM28723@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 22 Oct 1997, J Wunsch wrote: > As explorer@flame.org wrote: > > > This was sent to me recently... It seems to be a pretty serious hole > > in open() and permissions... > > Fixed. How exactly did you fix it, this is related to what I was saying about opening a file as RD_ONLY and WR_ONLY, because if oflags = -1 then fflags = 0 and that means the file is not open for read or write which my point was that it should be forced to be open for one or the other. I don't rememer who, but someone seemed to think that it could be actually useful to hav a file not open for read or write > -- > 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-hackers Wed Oct 22 02:09:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA18315 for hackers-outgoing; Wed, 22 Oct 1997 02:09:08 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA18310 for ; Wed, 22 Oct 1997 02:09:04 -0700 (PDT) (envelope-from thorpej@lestat.nas.nasa.gov) Received: from localhost (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.6/8.6.12) with SMTP id CAA13732; Wed, 22 Oct 1997 02:09:46 -0700 (PDT) Message-Id: <199710220909.CAA13732@lestat.nas.nasa.gov> X-Authentication-Warning: lestat.nas.nasa.gov: localhost [127.0.0.1] didn't use HELO protocol To: "Jamil J. Weatherbee" Cc: Joerg Wunsch , FreeBSD hackers Subject: Re: Possible SERIOUS bug in open()? Reply-To: Jason Thorpe From: Jason Thorpe Date: Wed, 22 Oct 1997 02:09:44 -0700 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 22 Oct 1997 01:38:11 -0700 (PDT) "Jamil J. Weatherbee" wrote: > How exactly did you fix it, this is related to what I was saying about > opening a file as RD_ONLY and WR_ONLY, because if oflags = -1 then fflags > = 0 and that means the file is not open for read or write which my point > was that it should be forced to be open for one or the other. I don't > rememer who, but someone seemed to think that it could be actually useful > to hav a file not open for read or write How would opening for !read !write be useful? What else could you possibly want to do? (Yes, this is a trick question :-) Jason R. Thorpe thorpej@nas.nasa.gov NASA Ames Research Center Home: +1 408 866 1912 NAS: M/S 258-6 Work: +1 415 604 0935 Moffett Field, CA 94035 Pager: +1 415 428 6939 From owner-freebsd-hackers Wed Oct 22 02:47:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA19917 for hackers-outgoing; Wed, 22 Oct 1997 02:47:49 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from seagull.cdrom.com (cracauer@seagull.cdrom.com [204.216.27.14]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA19910 for ; Wed, 22 Oct 1997 02:47:47 -0700 (PDT) (envelope-from cracauer@seagull.cdrom.com) Received: (from cracauer@localhost) by seagull.cdrom.com (8.8.6/8.6.6) id CAA24135 ; Wed, 22 Oct 1997 02:46:25 -0700 (PDT) Message-ID: <19971022114622.61668@cons.org> Date: Wed, 22 Oct 1997 11:46:22 +0200 From: Martin Cracauer To: Jaye Mathisen Cc: hackers@FreeBSD.ORG Subject: Re: Is there any way to build a completely static system? References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81 In-Reply-To: ; from Jaye Mathisen on Mon, Oct 20, 1997 at 01:44:14PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In , Jaye Mathisen wrote: > I mean no .so's, nothing. Just the necessare .a's, and all binaries > statically linked... > > Getting the binaries statically linked is easy, but I was hoping NOSHARED > would stop building the .so's for /usr/lib, but it seems to anyway. Look into /usr/share/mk/bsd.lib.mk Around line 115 (in 2.2.2) you find .if !defined(NOPIC) .if defined(SHLIB_MAJOR) && defined(SHLIB_MINOR) _LIBS+=lib${LIB}.so.${SHLIB_MAJOR}.${SHLIB_MINOR} .endif .if defined(INSTALL_PIC_ARCHIVE) _LIBS+=lib${LIB}_pic.a .endif .endif Although it is intended for per-library settings, I looks like globally setting option NOPIC would do what you want. If not, just delete the LIBS+= lines in bsd.lib.mk. Please let me know if it works. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ BSD User Group Hamburg/Germany http://www.bsdhh.org/ From owner-freebsd-hackers Wed Oct 22 03:09:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA20563 for hackers-outgoing; Wed, 22 Oct 1997 03:09:13 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from david.siemens.de (david.siemens.de [139.23.36.11]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA20558 for ; Wed, 22 Oct 1997 03:09:08 -0700 (PDT) (envelope-from Andre.Albsmeier@mchp.siemens.de) Received: from salomon.mchp.siemens.de (mail.siemens.de [139.23.33.13]) by david.siemens.de (8.8.7/8.8.7) with ESMTP id MAA28638 for ; Wed, 22 Oct 1997 12:04:00 +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 MAA28660 for ; Wed, 22 Oct 1997 12:08:06 +0200 (MDT) Received: (from daemon@localhost) by curry.mchp.siemens.de (8.8.7/8.8.7) id MAA06932 for ; Wed, 22 Oct 1997 12:08:05 +0200 (MET DST) From: Andre Albsmeier Message-Id: <199710221007.MAA01578@curry.mchp.siemens.de> Subject: Suggestion for chown -h To: hackers@freebsd.org Date: Wed, 22 Oct 1997 12:07:47 +0200 (CEST) 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, after asking on -questions why "chown -R -h" isn't allowed, I was told that this is due to the possibility that there might be symlinks which point to underlaying directories somewhere else. However, this might really be a problem, but only if the symlinks are followed. So if neither -L nor -H are specified, I think it would be safe to allow -h with -R. The diff's are quite simple: *** chown.c.ORI Wed Oct 22 11:35:40 1997 --- chown.c Tue Oct 21 20:23:30 1997 *************** *** 116,122 **** fts_options = FTS_PHYSICAL; if (Rflag) { ! if (hflag) errx(1, "the -R and -h options may not be specified together"); if (Hflag) fts_options |= FTS_COMFOLLOW; --- 116,122 ---- fts_options = FTS_PHYSICAL; if (Rflag) { ! if (hflag && (Lflag || Hflag) ) errx(1, "the -R and -h options may not be specified together"); if (Hflag) fts_options |= FTS_COMFOLLOW; I have tried it here and it works quite nice. The reason, why I like it is, to pass a whole directory over to another user; of course without the files the symlinks are pointing at. What do you think about that? -Andre From owner-freebsd-hackers Wed Oct 22 05:16:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA25137 for hackers-outgoing; Wed, 22 Oct 1997 05:16:24 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from plum.cyber.com.au (plum.cyber.com.au [203.7.155.24]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id FAA25132 for ; Wed, 22 Oct 1997 05:16:20 -0700 (PDT) (envelope-from darrenr@cyber.com.au) Received: (from darrenr@localhost) by plum.cyber.com.au (8.6.12/8.6.6) id WAA06516; Wed, 22 Oct 1997 22:15:50 +1000 From: Darren Reed Message-Id: <199710221215.WAA06516@plum.cyber.com.au> Subject: more struct ifnet move lossage. To: tlambert@primenet.com Date: Wed, 22 Oct 1997 22:15:50 +1000 (EST) Cc: hackers@freebsd.org In-Reply-To: <199710202351.QAA27105@usr05.primenet.com> from "Terry Lambert" at Oct 20, 97 11:51:43 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Sigh...the changes for 3.0 are more extensive than I first thought, although _all_ the problems stem from "struct ifnet" being moved and it not being included, by default, from net/if.h (it appears to be the _only_ change that isn't backward compatible). Including netinet/if_ether.h, whilst backawrd compatible in -current with itself, is broken because it requires "struct ifnet" in a structure. I'm curious...does tcpdump still compile on -current, `out of the box' ? (Just to state the obvious, you don't compile tcpdump with -DKERNEL) Darren From owner-freebsd-hackers Wed Oct 22 05:48:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA26603 for hackers-outgoing; Wed, 22 Oct 1997 05:48:04 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (word.smith.net.au [202.0.75.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA26571 for ; Wed, 22 Oct 1997 05:47:47 -0700 (PDT) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id WAA00847; Wed, 22 Oct 1997 22:13:17 +0930 (CST) Message-Id: <199710221243.WAA00847@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Darren Reed cc: hackers@freebsd.org Subject: Re: more struct ifnet move lossage. In-reply-to: Your message of "Wed, 22 Oct 1997 22:15:50 +1000." <199710221215.WAA06516@plum.cyber.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 22 Oct 1997 22:13:15 +0930 From: Mike Smith Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I'm curious...does tcpdump still compile on -current, `out of the box' ? src/usr.sbin/tcpdump, src/contrib/tcpdump. And look ma, no diffs. > (Just to state the obvious, you don't compile tcpdump with -DKERNEL) Speaking of stating the obvious; you don't expect to have the kernel-private data structures that are the subject of so much vitriolic hatred to stay put, do you? All of Terry's comments on a procedural interface are 100% on the mark. If you don't like the grief that the structure changes are causing you, now is the time to participating in producing a *BETTER* interface. mike From owner-freebsd-hackers Wed Oct 22 06:23:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA27857 for hackers-outgoing; Wed, 22 Oct 1997 06:23:40 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from plum.cyber.com.au (plum.cyber.com.au [203.7.155.24]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id GAA27850 for ; Wed, 22 Oct 1997 06:23:36 -0700 (PDT) (envelope-from darrenr@cyber.com.au) Received: (from darrenr@localhost) by plum.cyber.com.au (8.6.12/8.6.6) id XAA06956; Wed, 22 Oct 1997 23:22:27 +1000 From: Darren Reed Message-Id: <199710221322.XAA06956@plum.cyber.com.au> Subject: Re: more struct ifnet move lossage. To: mike@smith.net.au (Mike Smith) Date: Wed, 22 Oct 1997 23:22:26 +1000 (EST) Cc: hackers@freebsd.org In-Reply-To: <199710221243.WAA00847@word.smith.net.au> from "Mike Smith" at Oct 22, 97 10:13:15 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In some mail I received from Mike Smith, sie wrote > > > I'm curious...does tcpdump still compile on -current, `out of the box' ? > > src/usr.sbin/tcpdump, src/contrib/tcpdump. And look ma, no diffs. No, I mean get tcpdump from ftp.ee.lbl.gov and compile that (3.4a5). 10:1 it doesn't compile (I'll put money on it :-). > > (Just to state the obvious, you don't compile tcpdump with -DKERNEL) > > Speaking of stating the obvious; you don't expect to have the > kernel-private data structures that are the subject of so much > vitriolic hatred to stay put, do you? I'm not commenting on this because I've had enough of it. > All of Terry's comments on a procedural interface are 100% on the mark. > If you don't like the grief that the structure changes are causing you, > now is the time to participating in producing a *BETTER* interface. Well, I didn't know they even existed until this nasty little thread... maybe I'm just not on the right freebsd email lists where these sort of things are announced and discussed. From owner-freebsd-hackers Wed Oct 22 06:37:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA28593 for hackers-outgoing; Wed, 22 Oct 1997 06:37:37 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (word.smith.net.au [202.0.75.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA28566 for ; Wed, 22 Oct 1997 06:37:28 -0700 (PDT) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id XAA01019; Wed, 22 Oct 1997 23:04:15 +0930 (CST) Message-Id: <199710221334.XAA01019@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Darren Reed cc: hackers@freebsd.org Subject: Re: more struct ifnet move lossage. In-reply-to: Your message of "Wed, 22 Oct 1997 23:22:26 +1000." <199710221322.XAA06956@plum.cyber.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 22 Oct 1997 23:04:13 +0930 From: Mike Smith Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > In some mail I received from Mike Smith, sie wrote > > > > > I'm curious...does tcpdump still compile on -current, `out of the box' ? > > > > src/usr.sbin/tcpdump, src/contrib/tcpdump. And look ma, no diffs. > > No, I mean get tcpdump from ftp.ee.lbl.gov and compile that (3.4a5). > 10:1 it doesn't compile (I'll put money on it :-). You don't appear to understand. That *is* what's in src/contrib/ tcpdump. Try it yourself: # cd /usr/src/contrib/tcpdump # cvs diff -u -r LBL Note that having the repo lets you see these things. If you check the logs, you will see that it is a virgin LBL tcpdump, at revision 3.3. So what does this mean? Probably that LBL write better code than you do, I guess. > > Speaking of stating the obvious; you don't expect to have the > > kernel-private data structures that are the subject of so much > > vitriolic hatred to stay put, do you? > > I'm not commenting on this because I've had enough of it. I was referring to general slagging of the BSD network stack; I *agree* that these structures don't belong as they are, where they are. > > All of Terry's comments on a procedural interface are 100% on the mark. > > If you don't like the grief that the structure changes are causing you, > > now is the time to participating in producing a *BETTER* interface. > > Well, I didn't know they even existed until this nasty little thread... > maybe I'm just not on the right freebsd email lists where these sort of > things are announced and discussed. Um, as a committer you can't avoid receiving all the commit messages. Dump the ones that don't affect you, and just keep an eye on the ones that do. There's been slow change and declaration of intent in there for many months now. And if you don't understand something, please say "I don't understand why this was done", not "you're f'ing stupid for doing this". It saves an enormous amount of grief. 8) mike From owner-freebsd-hackers Wed Oct 22 06:52:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA29316 for hackers-outgoing; Wed, 22 Oct 1997 06:52:49 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from plum.cyber.com.au (plum.cyber.com.au [203.7.155.24]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id GAA29307 for ; Wed, 22 Oct 1997 06:52:42 -0700 (PDT) (envelope-from darrenr@cyber.com.au) Received: (from darrenr@localhost) by plum.cyber.com.au (8.6.12/8.6.6) id XAA07214; Wed, 22 Oct 1997 23:52:27 +1000 From: Darren Reed Message-Id: <199710221352.XAA07214@plum.cyber.com.au> Subject: Re: more struct ifnet move lossage. To: mike@smith.net.au (Mike Smith) Date: Wed, 22 Oct 1997 23:52:26 +1000 (EST) Cc: hackers@freebsd.org In-Reply-To: <199710221334.XAA01019@word.smith.net.au> from "Mike Smith" at Oct 22, 97 11:04:13 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In some mail I received from Mike Smith, sie wrote > > > In some mail I received from Mike Smith, sie wrote > > > > > > > I'm curious...does tcpdump still compile on -current, `out of the box' ? > > > > > > src/usr.sbin/tcpdump, src/contrib/tcpdump. And look ma, no diffs. > > > > No, I mean get tcpdump from ftp.ee.lbl.gov and compile that (3.4a5). > > 10:1 it doesn't compile (I'll put money on it :-). > > You don't appear to understand. That *is* what's in src/contrib/ > tcpdump. Try it yourself: You've missed the point totally of what I originally said and that is that tcpdump no longer compiles "out of the box". "out of the box" means ftp'ing it from LBL, not using what's in src/contrib/tcpdump. Or do you want to debate about that too ? What's in src/contrib/tcpdump is the LBL tcpdump PLUS FreeBSD compatibility hacks. Do you want to disagree on that ? > # cd /usr/src/contrib/tcpdump > # cvs diff -u -r LBL > > Note that having the repo lets you see these things. If you check the > logs, you will see that it is a virgin LBL tcpdump, at revision 3.3. > > So what does this mean? Probably that LBL write better code than you > do, I guess. # cvs diff -u -r LBL | grep if_var.h cvs diff: Diffing . cvs diff: tag LBL is not in file FREEBSD-upgrade cvs diff: tag LBL is not in file nfs.h +#include cvs diff: Diffing lbl There - that's my point. More crapola because of it being moved. There is no such include in 3.4a5. cripes...I thought this was going to be simple and not a debate about what's in src/contrib/tcpdump vs what is in the tcpdump.tar.gz people ftp from LBL! > > > All of Terry's comments on a procedural interface are 100% on the mark. > > > If you don't like the grief that the structure changes are causing you, > > > now is the time to participating in producing a *BETTER* interface. > > > > Well, I didn't know they even existed until this nasty little thread... > > maybe I'm just not on the right freebsd email lists where these sort of > > things are announced and discussed. > > Um, as a committer you can't avoid receiving all the commit messages. > Dump the ones that don't affect you, and just keep an eye on the ones > that do. There's been slow change and declaration of intent in there > for many months now. Sorry, I don't keep months worth of cvs commit messages in my head or on disk. I just scan things for relevance to myself, which is usually limited to reading the subject line :) But CVS commit messages do not make a discussion or announcement...(to me anyway). From owner-freebsd-hackers Wed Oct 22 07:01:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA29961 for hackers-outgoing; Wed, 22 Oct 1997 07:01:15 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (word.smith.net.au [202.0.75.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA29956 for ; Wed, 22 Oct 1997 07:01:09 -0700 (PDT) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id XAA01139; Wed, 22 Oct 1997 23:27:45 +0930 (CST) Message-Id: <199710221357.XAA01139@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Darren Reed cc: mike@smith.net.au (Mike Smith), hackers@freebsd.org Subject: Re: more struct ifnet move lossage. In-reply-to: Your message of "Wed, 22 Oct 1997 23:52:26 +1000." <199710221352.XAA07214@plum.cyber.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 22 Oct 1997 23:27:44 +0930 From: Mike Smith Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > You've missed the point totally of what I originally said and that is > that tcpdump no longer compiles "out of the box". "out of the box" > means ftp'ing it from LBL, not using what's in src/contrib/tcpdump. > Or do you want to debate about that too ? No, I'll confess that /usr/src on the box I checked on (I'm not completely stupid 8) is 2.2, not -current (I've been beating on 2.2.5 pre-release). > What's in src/contrib/tcpdump is the LBL tcpdump PLUS FreeBSD > compatibility hacks. Do you want to disagree on that ? No. Mea culpa. > > Um, as a committer you can't avoid receiving all the commit messages. > > Dump the ones that don't affect you, and just keep an eye on the ones > > that do. There's been slow change and declaration of intent in there > > for many months now. > > Sorry, I don't keep months worth of cvs commit messages in my head or > on disk. I just scan things for relevance to myself, which is usually > limited to reading the subject line :) No offense, but I think you need to at least keep a little continuity going... > But CVS commit messages do not make a discussion or announcement...(to > me anyway). A trend in commits, or attached comments thereto can generally be taken as an announcement. The people responsible for these changes (mostly Bruce and Garrett) aren't given to lengthy pontification. If one of them commits something, it's worth paying attention to. mike From owner-freebsd-hackers Wed Oct 22 07:30:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA01453 for hackers-outgoing; Wed, 22 Oct 1997 07:30:01 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from sasami.jurai.net (winter@sasami.jurai.net [207.96.1.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA01416 for ; Wed, 22 Oct 1997 07:29:55 -0700 (PDT) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.7/8.8.7) with SMTP id KAA26003; Wed, 22 Oct 1997 10:26:24 -0400 (EDT) Date: Wed, 22 Oct 1997 10:26:24 -0400 (EDT) From: "Matthew N. Dodd" To: Douglas Carmichael cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Hardware RAID-x controllers for FreeBSD? In-Reply-To: <199710220259.VAA20051@Mars.mcs.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 21 Oct 1997, Douglas Carmichael wrote: > Do any you know of any hardware RAID-x controllers (x = >1, preferably 5) > that work with FreeBSD and either: > 1) Have a native driver in FreeBSD for them > or 2) Appear as just another big disk http://www.cmd.com/ /* Matthew N. Dodd | A memory retaining a love you had for life winter@jurai.net | As cruel as it seems nothing ever seems to http://www.jurai.net/~winter | go right - FLA M 3.1:53 */ From owner-freebsd-hackers Wed Oct 22 09:50:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA10673 for hackers-outgoing; Wed, 22 Oct 1997 09:50:27 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: (from jmb@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA10663; Wed, 22 Oct 1997 09:50:16 -0700 (PDT) (envelope-from jmb) From: "Jonathan M. Bresler" Message-Id: <199710221650.JAA10663@hub.freebsd.org> Subject: Re: more struct ifnet move lossage. To: mike@smith.net.au (Mike Smith) Date: Wed, 22 Oct 1997 09:50:15 -0700 (PDT) Cc: darrenr@cyber.com.au, mike@smith.net.au, hackers@freebsd.org In-Reply-To: <199710221357.XAA01139@word.smith.net.au> from "Mike Smith" at Oct 22, 97 11:27:44 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk these changes should be announced in commercial@freebsd.org. Mike Smith wrote: > Darren Reed wrote: > > But CVS commit messages do not make a discussion or announcement...(to > > me anyway). > > A trend in commits, or attached comments thereto can generally be taken > as an announcement. The people responsible for these changes (mostly > Bruce and Garrett) aren't given to lengthy pontification. If one of > them commits something, it's worth paying attention to. > > mike > > > From owner-freebsd-hackers Wed Oct 22 10:23:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA13135 for hackers-outgoing; Wed, 22 Oct 1997 10:23:10 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id KAA13121 for ; Wed, 22 Oct 1997 10:22:59 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id TAA03228 for freebsd-hackers@FreeBSD.ORG; Wed, 22 Oct 1997 19:22:57 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id TAA01413; Wed, 22 Oct 1997 19:02:25 +0200 (MET DST) Message-ID: <19971022190225.DV50844@uriah.heep.sax.de> Date: Wed, 22 Oct 1997 19:02:25 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG (FreeBSD hackers) Subject: Re: Possible SERIOUS bug in open()? References: <19971022093040.UM28723@uriah.heep.sax.de> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Jamil J. Weatherbee on Oct 22, 1997 01:38:11 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Jamil J. Weatherbee wrote: > > > This was sent to me recently... It seems to be a pretty serious hole > > > in open() and permissions... > > > > Fixed. > > How exactly did you fix it, this is related to what I was saying about > opening a file as RD_ONLY and WR_ONLY, ... Yep, this was in the same boat. The way the fix works, only one of O_RDONLY, O_WRONLY, or O_RDWR should be possible now, and anything else should be rejected as EINVAL. -- 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-hackers Wed Oct 22 10:45:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA14438 for hackers-outgoing; Wed, 22 Oct 1997 10:45:06 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from srv.net (snake.srv.net [199.104.81.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA14364; Wed, 22 Oct 1997 10:44:09 -0700 (PDT) (envelope-from cmott@srv.net) Received: from darkstar.home (dialin1.anlw.anl.gov [141.221.254.101]) by srv.net (8.8.5/8.8.5) with SMTP id LAA21235; Wed, 22 Oct 1997 11:43:53 -0600 (MDT) Date: Wed, 22 Oct 1997 10:43:21 -0700 (MST) From: Charles Mott X-Sender: cmott@darkstar.home To: freebsd-hackers@freebsd.org, freebsd-isp@freebsd.org Subject: Password files and virtual IP addresses Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Suppose that one wanted to create different virtual IP addresses with ifconfig alias, and when people telnet or ftp or access pop3/imap2 at a virtual address, a password file specific to that virtual address would be used. This would allow username re-use. Has this sort of thing been considered before? If not, what sort of things would have to be hacked? If password access routines could somehow be informed what virtual address they were being accessed from, then it would be possible to have multiple password files. Of course, there are always unintended security implications to doing these things... Charles Mott From owner-freebsd-hackers Wed Oct 22 11:13:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA16113 for hackers-outgoing; Wed, 22 Oct 1997 11:13:04 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from iafnl.es.iaf.nl (uucp@iafnl.es.iaf.nl [195.108.17.20]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id LAA16102 for ; Wed, 22 Oct 1997 11:12:57 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: by iafnl.es.iaf.nl with UUCP id AA21467 (5.67b/IDA-1.5 for freebsd-hackers@FreeBSD.ORG); Wed, 22 Oct 1997 20:12:41 +0200 Received: (from wilko@localhost) by yedi.iaf.nl (8.8.5/8.6.12) id XAA02980; Tue, 21 Oct 1997 23:15:20 +0100 (MET) From: Wilko Bulte Message-Id: <199710212215.XAA02980@yedi.iaf.nl> Subject: Re: DLT drives To: pnorton@ccnvhi.com (Paul Norton) Date: Tue, 21 Oct 1997 23:15:19 +0100 (MET) Cc: tom@sdf.com, karl@Mcs.Net, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199710211921.MAA00740@grumpy.ccnvhi.com> from "Paul Norton" at Oct 21, 97 12:21:32 pm X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-Pgp-Info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4 PL24 ME8a] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Paul Norton wrote... > Not so. Some load their own version of the DLT firmware. Which are different OEM 'personalities' provided (in the end) by Quantum. You can as OEM ask for a specific feature. We do things like that at work (== DEC). But for VendorID and ProductID you can just use DLTtools (on the Quantum web site) > Wilko Bulte writes: > > All are built by Quantum, who bought the tape and disk business from > > Digital (DEC). > > > > So, Sun, SGI, DEC, etc all just rebadge them. _ ____________________________________________________________________ | / o / / _ Bulte email: wilko@yedi.iaf.nl http://www.tcja.nl/~wilko |/|/ / / /( (_) Arnhem, The Netherlands - Do, or do not. There is no 'try' ------------------ Support your local daemons: run FreeBSD Unix -----Yoda From owner-freebsd-hackers Wed Oct 22 11:22:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA16594 for hackers-outgoing; Wed, 22 Oct 1997 11:22:28 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from phoenix.its.rpi.edu (phoenix.its.rpi.edu [128.113.161.45]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA16589 for ; Wed, 22 Oct 1997 11:22:23 -0700 (PDT) (envelope-from dec@phoenix.its.rpi.edu) Received: from localhost (dec@localhost) by phoenix.its.rpi.edu (8.8.7/8.8.7) with SMTP id OAA16665; Wed, 22 Oct 1997 14:22:11 -0400 (EDT) Date: Wed, 22 Oct 1997 14:22:11 -0400 (EDT) From: "David E. Cross" To: J Wunsch cc: FreeBSD hackers Subject: Re: Possible SERIOUS bug in open()? In-Reply-To: <19971022190225.DV50844@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 22 Oct 1997, J Wunsch wrote: > As Jamil J. Weatherbee wrote: > > > > > This was sent to me recently... It seems to be a pretty serious hole > > > > in open() and permissions... > > > > > > Fixed. > > > > How exactly did you fix it, this is related to what I was saying about > > opening a file as RD_ONLY and WR_ONLY, ... > > Yep, this was in the same boat. The way the fix works, only one of > O_RDONLY, O_WRONLY, or O_RDWR should be possible now, and anything > else should be rejected as EINVAL. I thought that O_RDRW = O_RDONLY | O_WRONLY. -- David Cross ACS Consultant From owner-freebsd-hackers Wed Oct 22 11:25:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA16830 for hackers-outgoing; Wed, 22 Oct 1997 11:25:17 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from shasta.wstein.com (joes@shasta.wstein.com [207.173.11.132]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA16801; Wed, 22 Oct 1997 11:25:09 -0700 (PDT) (envelope-from joes@shasta.wstein.com) Received: (from joes@localhost) by shasta.wstein.com (8.8.7/8.8.7) id LAA17618; Wed, 22 Oct 1997 11:25:02 -0700 (PDT) From: Joseph Stein Message-Id: <199710221825.LAA17618@shasta.wstein.com> Subject: Interesting behaviour from sysctl(kern.boottime) To: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Date: Wed, 22 Oct 1997 11:25:01 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've written myself a utility that polls the boot time (okay, I stole that part from w(1)) and sends a message to my pager so that I know that everything is hunky-dory. The actual message to my pager would look like this: Oct 22 11:00:05 shasta status: up 1+13:40:20 [2 users] But, I've come to notice the following: (five executions worth of data:) ----------------- cut here -------------- System time is (877528801) Wed Oct 22 07:00:01 1997 System Booted at (877407594) Mon Oct 20 21:19:54 1997 ^^^^^^^^^^^^^^^^^^^ Difference is: 121207 seconds ----- System time is (877532401) Wed Oct 22 08:00:01 1997 System Booted at (877407591) Mon Oct 20 21:19:51 1997 ^^^^^^^^^^^^^^^^^^^ Difference is: 124810 seconds ----- System time is (877536000) Wed Oct 22 09:00:00 1997 System Booted at (877407589) Mon Oct 20 21:19:49 1997 ^^^^^^^^^^^^^^^^^^^ Difference is: 128411 seconds ----- System time is (877539600) Wed Oct 22 10:00:00 1997 System Booted at (877407587) Mon Oct 20 21:19:47 1997 ^^^^^^^^^^^^^^^^^^^ Difference is: 132013 seconds ----- System time is (877543205) Wed Oct 22 11:00:05 1997 System Booted at (877407585) Mon Oct 20 21:19:45 1997 ^^^^^^^^^^^^^^^^^^^ Difference is: 135620 seconds ----------------- cut here -------------- Is this a "feature" or a "bug". I would think that the boottime should _not_ change. I run xntpd. Could that be a factor? (updating the clock ticks or whatever?) I haven't yet looked at the kernel sources that track the boot time, but it does get kind of interesting to see the system be up for two more seconds (or so) every hour... joe From owner-freebsd-hackers Wed Oct 22 11:48:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA18062 for hackers-outgoing; Wed, 22 Oct 1997 11:48:16 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from jake.csh.rit.edu (jake.csh.rit.edu [129.21.60.8]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA18010 for ; Wed, 22 Oct 1997 11:47:00 -0700 (PDT) (envelope-from tad@mcp.csh.rit.edu) Received: from localhost (tad@localhost) by jake.csh.rit.edu (8.8.5/8.8.5) with SMTP id OAA01419 for ; Wed, 22 Oct 1997 14:46:27 -0400 Message-Id: <199710221846.OAA01419@jake.csh.rit.edu> X-Authentication-Warning: jake.csh.rit.edu: tad owned process doing -bs X-Authentication-Warning: jake.csh.rit.edu: tad@localhost didn't use HELO protocol Reply-To: Tad Hunt To: freebsd-hackers@freebsd.org Subject: -lc_r and setjmp (BUG) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1374.877545901.1@mail.csh.rit.edu> Date: Wed, 22 Oct 1997 14:45:01 -0400 From: Tad Hunt Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I was looking at the libc_r implementation of setjmp (lib/libc_r/uthread/uthread_setjmp.c) from (FreeBSD-2.2.5-101897) from lib/libc_r/uthread/uthread_setjmp.c: int setjmp(jmp_buf env) { return (_thread_sys_setjmp(env)); } where _thread_sys_setjmp is implemented in lib/libc/i386/gen/setjmp.S as something like the following: #ifdef _THREAD_SAFE ENTRY(_thread_sys_setjmp) #else ENTRY(setjmp) #endif [... essentially the same implementation for both cases, except for some signal stuff] In the case of threaded programs calling setjmp() (instead of calling _thread_sys_setjmp()) the wrong environment gets saved in the jmp_buf. When longjmp does it's work, it returns into setjmp() (instead of returning into the caller of setjmp(). Essentially the following is happening: jmp_buf foo; main() { bar(); longjmp(foo, 1); } bar() { setjmp(foo); } -Tad P.S. I don't know if this is the right place to report the bug, please redirect me if necessary. From owner-freebsd-hackers Wed Oct 22 11:52:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA18348 for hackers-outgoing; Wed, 22 Oct 1997 11:52:31 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from iafnl.es.iaf.nl (uucp@iafnl.es.iaf.nl [195.108.17.20]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id LAA18322 for ; Wed, 22 Oct 1997 11:52:18 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: by iafnl.es.iaf.nl with UUCP id AA23544 (5.67b/IDA-1.5 for freebsd-hackers@FreeBSD.ORG); Wed, 22 Oct 1997 20:52:01 +0200 Received: (from wilko@localhost) by yedi.iaf.nl (8.8.5/8.6.12) id UAA02767; Wed, 22 Oct 1997 20:18:27 +0100 (MET) From: Wilko Bulte Message-Id: <199710221918.UAA02767@yedi.iaf.nl> Subject: Re: DLT drives To: hm@kts.org Date: Wed, 22 Oct 1997 20:18:27 +0100 (MET) Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Hellmuth Michaelis" at Oct 22, 97 08:36:40 am X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-Pgp-Info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4 PL24 ME8a] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Hellmuth Michaelis wrote... > J Wunsch wrote: > > > > > Not so. Some load their own version of the DLT firmware. > > > > Their own versions, or just their own vendor string only? I'd rather > > assume the latter. > > Their own versions. HP has a DLT (version) which can be run in 7980 mode > (which is an HP reel to reel tape) and i doubt this is possible with the > standard firmware. Check out http://www.quantum.com There are something like 5 or so firmware personalities, e.g. also one that pretends to be an Exabyte. Wilko _ ____________________________________________________________________ | / o / / _ Bulte email: wilko@yedi.iaf.nl http://www.tcja.nl/~wilko |/|/ / / /( (_) Arnhem, The Netherlands - Do, or do not. There is no 'try' ------------------ Support your local daemons: run FreeBSD Unix -----Yoda From owner-freebsd-hackers Wed Oct 22 11:53:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA18410 for hackers-outgoing; Wed, 22 Oct 1997 11:53:45 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from out2.ibm.net (out2.ibm.net [165.87.194.229]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA18390 for ; Wed, 22 Oct 1997 11:53:13 -0700 (PDT) (envelope-from SimsS@IBM.Net) Received: from Elvis.RatsNest.VaBeach.Va.Us (slip166-72-229-113.va.us.ibm.net [166.72.229.113]) by out2.ibm.net (8.8.5/8.6.9) with SMTP id SAA124956 for ; Wed, 22 Oct 1997 18:52:30 GMT Received: by localhost with Microsoft MAPI; Wed, 22 Oct 1997 14:52:31 -0400 Message-ID: <01BCDEFA.1F723560.SimsS@IBM.Net> From: Steve Sims Reply-To: "SimsS@IBM.Net" To: "'hackers@freebsd.org'" Subject: SMP P-Pro MoBo - Recommendations? Date: Wed, 22 Oct 1997 14:52:29 -0400 X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4128 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I know this is a rehash of a thread from a couple of months ago, but..... I'm thinking of plopping a dual P-Pro motherboard in my overstressed P5/120. There was a brief thread of pros & cons about various manufacturers and features, but after an hour or so munging through the archives I come up dry on trying to re-construct the thread. One thing of interest was an URL to some "great motherboard web site in the sky"(tm) that had the low-down on all sorts of mobo's, plus a few hackers offered their 2-cent's worth. Can anyone pass me a pointer or offer their experiences? ...sjs... From owner-freebsd-hackers Wed Oct 22 12:21:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA19997 for hackers-outgoing; Wed, 22 Oct 1997 12:21:50 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from coal.nis.newscorp.com (mxa.newscorp.com [206.15.105.135]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA19916 for ; Wed, 22 Oct 1997 12:20:02 -0700 (PDT) (envelope-from ben@multivac.narcissus.net) Received: from multivac.narcissus.net (ts2port12.port.net [207.38.248.140]) by coal.nis.newscorp.com (News Corp SMTP GW 1.1) with SMTP id PAA10100; Wed, 22 Oct 1997 15:20:18 -0400 (EDT) Received: from localhost by multivac.narcissus.net (NX5.67e/NX3.0S) id AA00270; Wed, 22 Oct 97 15:11:53 -0400 Date: Wed, 22 Oct 1997 15:11:52 -0400 (GMT-0400) From: Snob Art Genre Reply-To: benedict@echonyc.com To: "David E. Cross" Cc: J Wunsch , FreeBSD hackers Subject: Re: Possible SERIOUS bug in open()? In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 22 Oct 1997, David E. Cross wrote: > I thought that O_RDRW = O_RDONLY | O_WRONLY. Tsk -- do your research. From /usr/include/fcntl.h: #define O_RDONLY 0x0000 /* open for reading only */ #define O_WRONLY 0x0001 /* open for writing only */ #define O_RDWR 0x0002 /* open for reading and writing */ Ben "You have your mind on computers, it seems." From owner-freebsd-hackers Wed Oct 22 12:23:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA20099 for hackers-outgoing; Wed, 22 Oct 1997 12:23:16 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from iafnl.es.iaf.nl (root@iafnl.es.iaf.nl [195.108.17.20]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id MAA20093 for ; Wed, 22 Oct 1997 12:23:13 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: by iafnl.es.iaf.nl with UUCP id AA23548 (5.67b/IDA-1.5 for freebsd-hackers@FreeBSD.ORG); Wed, 22 Oct 1997 20:52:57 +0200 Received: (from wilko@localhost) by yedi.iaf.nl (8.8.5/8.6.12) id UAA02858; Wed, 22 Oct 1997 20:29:58 +0100 (MET) From: Wilko Bulte Message-Id: <199710221929.UAA02858@yedi.iaf.nl> Subject: Re: 2.2.2-RELEASE '875 SCSI won't negotiage To: joerg_wunsch@uriah.heep.sax.de Date: Wed, 22 Oct 1997 20:29:58 +0100 (MET) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <19971022080341.HR59190@uriah.heep.sax.de> from "J Wunsch" at Oct 22, 97 08:03:41 am X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-Pgp-Info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4 PL24 ME8a] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As J Wunsch wrote... > As dkelly@hiwaay.net wrote: > > > Went back and RTFM'ed my Asus SC875 manual and obsverved on page 11 > > the default Synchronous Transfer Rate (MS/Sec) (sic) is 20. So is this MB/ > > sec or MHz? > > MHz. Together with the 16-bit bus, it makes a theoretical maximum of > 40 MB/s (minus transaction overhead which is, as Stefan mentioned, not > neglicible). Stick to mega-transfers/sec , covers both cases. _ ____________________________________________________________________ | / o / / _ Bulte email: wilko@yedi.iaf.nl http://www.tcja.nl/~wilko |/|/ / / /( (_) Arnhem, The Netherlands - Do, or do not. There is no 'try' ------------------ Support your local daemons: run FreeBSD Unix -----Yoda From owner-freebsd-hackers Wed Oct 22 12:24:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA20310 for hackers-outgoing; Wed, 22 Oct 1997 12:24:37 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from biggusdiskus.flyingfox.com (biggusdiskus.flyingfox.com [206.14.52.27]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA20267; Wed, 22 Oct 1997 12:24:24 -0700 (PDT) (envelope-from jas@flyingfox.com) Received: (from jas@localhost) by biggusdiskus.flyingfox.com (8.8.5/8.8.5) id MAA06912; Wed, 22 Oct 1997 12:24:22 -0700 (PDT) Date: Wed, 22 Oct 1997 12:24:22 -0700 (PDT) From: Jim Shankland Message-Id: <199710221924.MAA06912@biggusdiskus.flyingfox.com> To: freebsd-hackers@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG, joes@seaport.net Subject: Re: Interesting behaviour from sysctl(kern.boottime) Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I've written myself a utility that polls the boot time (okay, I stole > that part from w(1)) and sends a message to my pager so that I know > that everything is hunky-dory.... > > [ kernel's notion of boot time is changing ] How fast are you moving relative to the machine at the time you get these pages? It sounds to me as though relativity could be a factor here. Jim Shankland Flying Fox Computer Systems, Inc. From owner-freebsd-hackers Wed Oct 22 13:22:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA24283 for hackers-outgoing; Wed, 22 Oct 1997 13:22:43 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from sos.freebsd.dk (sos.freebsd.dk [195.8.129.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA24275 for ; Wed, 22 Oct 1997 13:22:38 -0700 (PDT) (envelope-from sos@sos.freebsd.dk) Received: (from sos@localhost) by sos.freebsd.dk (8.8.7/8.7.3) id WAA11525; Wed, 22 Oct 1997 22:21:48 +0200 (MEST) Message-Id: <199710222021.WAA11525@sos.freebsd.dk> Subject: Re: SMP P-Pro MoBo - Recommendations? In-Reply-To: <01BCDEFA.1F723560.SimsS@IBM.Net> from Steve Sims at "Oct 22, 97 02:52:29 pm" To: SimsS@IBM.Net Date: Wed, 22 Oct 1997 22:21:48 +0200 (MEST) Cc: hackers@FreeBSD.ORG From: Sųren Schmidt Reply-to: sos@FreeBSD.dk X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In reply to Steve Sims who wrote: > I know this is a rehash of a thread from a couple of months ago, but..... > > I'm thinking of plopping a dual P-Pro motherboard in my overstressed > P5/120. > > There was a brief thread of pros & cons about various manufacturers and > features, but after an hour or so munging through the archives I come up > dry on trying to re-construct the thread. > > One thing of interest was an URL to some "great motherboard web site in the > sky"(tm) that had the low-down on all sorts of mobo's, plus a few hackers > offered their 2-cent's worth. > > Can anyone pass me a pointer or offer their experiences? Not exactly, but I plan to buy a TYAN TITAN dual PPro AT in the next couble of weeks, so if anybody has any experience with that I'd like to know -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Sųren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-hackers Wed Oct 22 13:29:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA24852 for hackers-outgoing; Wed, 22 Oct 1997 13:29:41 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA24845 for ; Wed, 22 Oct 1997 13:29:39 -0700 (PDT) (envelope-from thorpej@lestat.nas.nasa.gov) Received: from localhost (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.6/8.6.12) with SMTP id NAA20863; Wed, 22 Oct 1997 13:30:30 -0700 (PDT) Message-Id: <199710222030.NAA20863@lestat.nas.nasa.gov> X-Authentication-Warning: lestat.nas.nasa.gov: localhost [127.0.0.1] didn't use HELO protocol To: dk+@ua.net Cc: freebsd-hackers@freebsd.org Subject: Re: Possible SERIOUS bug in open()? Reply-To: Jason Thorpe From: Jason Thorpe Date: Wed, 22 Oct 1997 13:30:28 -0700 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 22 Oct 1997 13:05:02 -0700 (PDT) Dmitry Kohmanyuk wrote: > > How would opening for !read !write be useful? What else could you possibly > > want to do? (Yes, this is a trick question :-) > > just for ioctl()s? Ah, that's the trick part of the question :-) For ioctls that change the state of the device, you absolutely want to have it open for writing. This is sort of obvious. For ioctls that don't change the state of the device, you absolutely want to have it open for reading. I.e. if you have a device that can expose sensitive information by ioctl, and you set the mode to 600, you won't want random people opening it via the neat little open hole and performing that read-only ioctl. Jason R. Thorpe thorpej@nas.nasa.gov NASA Ames Research Center Home: +1 408 866 1912 NAS: M/S 258-6 Work: +1 415 604 0935 Moffett Field, CA 94035 Pager: +1 415 428 6939 From owner-freebsd-hackers Wed Oct 22 14:31:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA29634 for hackers-outgoing; Wed, 22 Oct 1997 14:31:24 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from earth.mat.net (root@earth.mat.net [206.246.122.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA29624 for ; Wed, 22 Oct 1997 14:31:18 -0700 (PDT) (envelope-from chuckr@glue.umd.edu) Received: from picnic.mat.net (picnic.mat.net [206.246.122.117]) by earth.mat.net (8.8.7/8.6.12) with SMTP id RAA09368; Wed, 22 Oct 1997 17:29:55 -0400 (EDT) Date: Wed, 22 Oct 1997 16:29:42 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@picnic.mat.net To: =?iso-8859-1?Q?S=F8ren_Schmidt?= cc: SimsS@IBM.Net, hackers@FreeBSD.ORG Subject: Re: SMP P-Pro MoBo - Recommendations? In-Reply-To: <199710222021.WAA11525@sos.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.freebsd.org id OAA29629 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 22 Oct 1997, Sųren Schmidt wrote: > In reply to Steve Sims who wrote: > > I know this is a rehash of a thread from a couple of months ago, but..... > > > > I'm thinking of plopping a dual P-Pro motherboard in my overstressed > > P5/120. > > > > There was a brief thread of pros & cons about various manufacturers and > > features, but after an hour or so munging through the archives I come up > > dry on trying to re-construct the thread. > > > > One thing of interest was an URL to some "great motherboard web site in the > > sky"(tm) that had the low-down on all sorts of mobo's, plus a few hackers > > offered their 2-cent's worth. > > > > Can anyone pass me a pointer or offer their experiences? > > Not exactly, but I plan to buy a TYAN TITAN dual PPro AT in the > next couble of weeks, so if anybody has any experience with that > I'd like to know I've got one, I have 2 PPro 166's in it, 512K cache per CPU. No problems, works SMP just fine. BTW, it's a Titan II, I think the latest is a III, I don't have any info about that one. > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Sųren Schmidt (sos@FreeBSD.org) FreeBSD Core Team > Even more code to hack -- will it ever end > .. > > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-hackers Wed Oct 22 14:48:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA01463 for hackers-outgoing; Wed, 22 Oct 1997 14:48:57 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA01448 for ; Wed, 22 Oct 1997 14:48:51 -0700 (PDT) (envelope-from jamil@trojanhorse.ml.org) Received: from localhost (jamil@localhost) by trojanhorse.ml.org (8.8.7/8.8.5) with SMTP id OAA00811 for ; Wed, 22 Oct 1997 14:48:08 -0700 (PDT) Date: Wed, 22 Oct 1997 14:48:08 -0700 (PDT) From: "Jamil J. Weatherbee" To: freebsd-hackers@FreeBSD.ORG Subject: using acquire_timer0() in drivers In-Reply-To: <199710222021.WAA11525@sos.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Am I correct to gather that on the 8253 timer chip. clock 0 is freely available clock 1 is used for scheduling interrupt (i.e. HZ) clock 2 is connected to the speaker If so I think there is a better way to utilize the clock 0 resource. I was thinking that using acquire_timer0() is bad for any drivers that may need it (such as data acquisition drivers). I wish to use it to clock input from an analog board at around 1024hz, I am already certain that this is perfectly doable. However, I am concerned that it might be a bad architectural idea to acquire_timer0() for long periods of time in a driver (or at all for that matter), since according to the clock.c code it looks to me like only one interrupt routine can be acquired at a time. But suppose I have 2 or three drivers needing polling service like this it might be a good Idea to reimplement the 8253(8254 i think) acquire_timer0() code so that more than one driver routine can be linked to the interrupt routine. So polling hardware like this which does (and will continue to exist) can get serviced properly. What I propose is that multiple acquisitions are allowed which will make it easy to check which routines will be run at that interrupt. The interrupt can be maintained at the highest frequency requested. like this: Routine Freq Reset val Phase val 1 256 4 1 2 512 2 0 3 1024 1 0 We could limit the counters to like 8 or more. When a counter = 0 call the routine and set back to original counter value. I would be interested in any analysis of the overhead here, we are hopefully talking about small routines anyhow. The phase value for instance would be a snapshot of the couter values at one one point which would be the insertion point for dynamically added routines. That way with 3 routines as above you optimize your distribution of Timer Service Routines getting called. This would look like (in this case). So with phase only 2 routines are getting executed on any one interrupt. 2 1 2 2 1 2 3 3 3 3 3 3 3 3 Some of you may scream overhead and that your going to miss interrupts, but if you had three boards on 3 different interrupts as above (their own clocks presumably) I don't think it is going to look any better in terms of overhead and chances of an interrupt getting missed (which is probably the main concern). From owner-freebsd-hackers Wed Oct 22 14:59:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA02310 for hackers-outgoing; Wed, 22 Oct 1997 14:59:41 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA02301 for ; Wed, 22 Oct 1997 14:59:38 -0700 (PDT) (envelope-from jamil@trojanhorse.ml.org) Received: from localhost (jamil@localhost) by trojanhorse.ml.org (8.8.7/8.8.5) with SMTP id OAA00848; Wed, 22 Oct 1997 14:57:51 -0700 (PDT) Date: Wed, 22 Oct 1997 14:57:50 -0700 (PDT) From: "Jamil J. Weatherbee" To: benedict@echonyc.com cc: "David E. Cross" , J Wunsch , FreeBSD hackers Subject: Re: Possible SERIOUS bug in open()? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk We had this discussion last week. It is really the fflags that matter, as long as (fflags & 0x03) is true were ok. On Wed, 22 Oct 1997, Snob Art Genre wrote: > On Wed, 22 Oct 1997, David E. Cross wrote: > > > I thought that O_RDRW = O_RDONLY | O_WRONLY. > > Tsk -- do your research. From /usr/include/fcntl.h: From owner-freebsd-hackers Wed Oct 22 15:01:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA02466 for hackers-outgoing; Wed, 22 Oct 1997 15:01:00 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from murrow.prognet.com (prognet.com [205.219.198.1]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id PAA02460 for ; Wed, 22 Oct 1997 15:00:54 -0700 (PDT) (envelope-from psh1@cornell.edu) Received: from dirtboy.rih.org (ppp-206-170-1-173.snfc21.pacbell.net) by murrow.prognet.com with SMTP id AA06594 (5.67b/IDA-1.5 for ); Wed, 22 Oct 1997 15:04:32 -0700 Message-Id: <3.0.32.19971022150012.00686f44@mail.real.com> X-Sender: peterh@mail.real.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 22 Oct 1997 15:00:47 -0700 To: freebsd-hackers@freebsd.org From: Peter Haight Subject: Re: SMP P-Pro MoBo - Recommendations? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 02:52 PM 10/22/97 -0400, you wrote: >One thing of interest was an URL to some "great motherboard web site in the >sky"(tm) that had the low-down on all sorts of mobo's, plus a few hackers >offered their 2-cent's worth. You are probably talking about Tom's Hardware Guide at http://sysdoc.pair.com. He rates a lot of motherboards and explains a lot of the issues involved. From owner-freebsd-hackers Wed Oct 22 15:09:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA03220 for hackers-outgoing; Wed, 22 Oct 1997 15:09:50 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from panda.hilink.com.au (panda.hilink.com.au [203.8.15.25]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA03211; Wed, 22 Oct 1997 15:09:43 -0700 (PDT) (envelope-from danny@panda.hilink.com.au) Received: (from danny@localhost) by panda.hilink.com.au (8.8.5/8.8.5) id IAA13172; Thu, 23 Oct 1997 08:09:25 +1000 (EST) Date: Thu, 23 Oct 1997 08:09:24 +1000 (EST) From: "Daniel O'Callaghan" To: Charles Mott cc: freebsd-hackers@FreeBSD.ORG, freebsd-isp@FreeBSD.ORG Subject: Re: Password files and virtual IP addresses In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 22 Oct 1997, Charles Mott wrote: > Suppose that one wanted to create different virtual > IP addresses with ifconfig alias, and when people telnet > or ftp or access pop3/imap2 at a virtual address, a > password file specific to that virtual address would be > used. This would allow username re-use. You *could* do it by hacking getpw*(3) and including a call to getsockname(2). I do it by building virtual machines using a hacked inetd(8) which does a getsockname(2) followed by a chroot(2) to the virtual machine. The vm needs to have ld.so and lib/* etc, etc, etc. It is great for allowing telnet access to web sites while preventing customers from peeking at each other's stuff. /* Daniel O'Callaghan */ /* HiLink Internet danny@hilink.com.au */ /* FreeBSD - works hard, plays hard... danny@freebsd.org */ From owner-freebsd-hackers Wed Oct 22 15:20:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA04184 for hackers-outgoing; Wed, 22 Oct 1997 15:20:49 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id PAA04177 for ; Wed, 22 Oct 1997 15:20:44 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id AAA02134 for freebsd-hackers@FreeBSD.ORG; Thu, 23 Oct 1997 00:20:32 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id AAA02035; Thu, 23 Oct 1997 00:17:17 +0200 (MET DST) Message-ID: <19971023001717.AU43421@uriah.heep.sax.de> Date: Thu, 23 Oct 1997 00:17:17 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG (FreeBSD hackers) Subject: Re: Possible SERIOUS bug in open()? References: <19971022190225.DV50844@uriah.heep.sax.de> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from David E. Cross on Oct 22, 1997 14:22:11 -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As David E. Cross wrote: > I thought that O_RDRW = O_RDONLY | O_WRONLY. You better look at the actual values of these macros. ;-) Inside the kernel, it's indeed this way (FREAD and FWRITE). However in open(), O_RDONLY is 0, O_WRONLY is 1. Thus, your idea would just yield O_WRONLY. The worse case was an attempt to use O_WRONLY|O_RDWR. -- 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-hackers Wed Oct 22 15:21:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA04252 for hackers-outgoing; Wed, 22 Oct 1997 15:21:24 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id PAA04243 for ; Wed, 22 Oct 1997 15:21:18 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id AAA02138 for freebsd-hackers@FreeBSD.ORG; Thu, 23 Oct 1997 00:20:47 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id AAA02047; Thu, 23 Oct 1997 00:18:42 +0200 (MET DST) Message-ID: <19971023001841.RF25584@uriah.heep.sax.de> Date: Thu, 23 Oct 1997 00:18:41 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG Subject: Re: DLT drives References: <199710221918.UAA02767@yedi.iaf.nl> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199710221918.UAA02767@yedi.iaf.nl>; from Wilko Bulte on Oct 22, 1997 20:18:27 +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Wilko Bulte wrote: > Check out http://www.quantum.com There are something like 5 or so > firmware personalities, e.g. also one that pretends to be an Exabyte. Oh, i hope it doesn't jam the cassette as often as Exabytes tend to do. :-] -- 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-hackers Wed Oct 22 15:21:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA04315 for hackers-outgoing; Wed, 22 Oct 1997 15:21:46 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id PAA04302 for ; Wed, 22 Oct 1997 15:21:43 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id AAA02145; Thu, 23 Oct 1997 00:21:30 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id AAA02010; Thu, 23 Oct 1997 00:10:44 +0200 (MET DST) Message-ID: <19971023001043.MK60020@uriah.heep.sax.de> Date: Thu, 23 Oct 1997 00:10:43 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG Cc: cmott@srv.net (Charles Mott) Subject: Re: Password files and virtual IP addresses References: X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Charles Mott on Oct 22, 1997 10:43:21 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Charles Mott wrote: > Suppose that one wanted to create different virtual > IP addresses with ifconfig alias, and when people telnet > or ftp or access pop3/imap2 at a virtual address, a > password file specific to that virtual address would be > used. This would allow username re-use. Make a standalone telnetd that doesn't bind to INADDR_ANY, but to each virtual address separately, and make them call different login programs. -- 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-hackers Wed Oct 22 16:25:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA08925 for hackers-outgoing; Wed, 22 Oct 1997 16:25:55 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from inspace.net (root@nova.ispace.com [207.204.40.7]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA08892; Wed, 22 Oct 1997 16:25:43 -0700 (PDT) (envelope-from gme@inspace.net) Received: from caffeine (caffeine.inspace.net [207.204.40.248]) by inspace.net (8.8.6) (8.8.6) (SPAM Stopper: 3.0b2) with SMTP id TAA02620; Wed, 22 Oct 1997 19:24:59 -0400 (EDT) From: "George M. Ellenburg" To: "Daniel O'Callaghan" , "Charles Mott" Cc: , Subject: Re: Password files and virtual IP addresses Date: Wed, 22 Oct 1997 19:24:20 -0400 Message-ID: <01bcdf41$9f805fb0$f828cccf@caffeine> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id QAA08901 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk What about the problem with "username re-use" with the effective UIDs of the users? Wouldn't 'webmaster@somedomain.com' and 'webmaster@anotherdomain.com' effectively have the same UID (excluding Sendmail tables/ tricks)? That is, if both users physically log in to the server with the user of 'webmaster'. How would you bypass the UIDs physically recorded in the UFS directory structure? G.M.E. -----Original Message----- From: Daniel O'Callaghan To: Charles Mott Cc: freebsd-hackers@FreeBSD.ORG ; freebsd-isp@FreeBSD.ORG Date: Wednesday, October 22, 1997 7:04 PM Subject: Re: Password files and virtual IP addresses | |On Wed, 22 Oct 1997, Charles Mott wrote: | |> Suppose that one wanted to create different virtual |> IP addresses with ifconfig alias, and when people telnet |> or ftp or access pop3/imap2 at a virtual address, a |> password file specific to that virtual address would be |> used. This would allow username re-use. | |You *could* do it by hacking getpw*(3) and including a call to |getsockname(2). | |I do it by building virtual machines using a hacked inetd(8) which does a |getsockname(2) followed by a chroot(2) to the virtual machine. The vm |needs to have ld.so and lib/* etc, etc, etc. It is great for allowing |telnet access to web sites while preventing customers from peeking at |each other's stuff. | | |/* Daniel O'Callaghan */ |/* HiLink Internet danny@hilink.com.au */ |/* FreeBSD - works hard, plays hard... danny@freebsd.org */ | | | From owner-freebsd-hackers Wed Oct 22 16:45:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA10051 for hackers-outgoing; Wed, 22 Oct 1997 16:45:03 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from panda.hilink.com.au (panda.hilink.com.au [203.8.15.25]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA10038; Wed, 22 Oct 1997 16:44:58 -0700 (PDT) (envelope-from danny@panda.hilink.com.au) Received: (from danny@localhost) by panda.hilink.com.au (8.8.5/8.8.5) id JAA13299; Thu, 23 Oct 1997 09:44:14 +1000 (EST) Date: Thu, 23 Oct 1997 09:44:14 +1000 (EST) From: "Daniel O'Callaghan" To: "George M. Ellenburg" cc: Charles Mott , freebsd-hackers@FreeBSD.ORG, freebsd-isp@FreeBSD.ORG Subject: Re: Password files and virtual IP addresses In-Reply-To: <01bcdf41$9f805fb0$f828cccf@caffeine> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 22 Oct 1997, George M. Ellenburg wrote: > | > |I do it by building virtual machines using a hacked inetd(8) which does a > |getsockname(2) followed by a chroot(2) to the virtual machine. The vm > |needs to have ld.so and lib/* etc, etc, etc. It is great for allowing > |telnet access to web sites while preventing customers from peeking at > |each other's stuff. > What about the problem with "username re-use" with the effective UIDs of > the users? Wouldn't 'webmaster@somedomain.com' and > 'webmaster@anotherdomain.com' effectively have the same UID (excluding > Sendmail tables/ tricks)? That is, if both users physically log in to the > server with the user of 'webmaster'. How would you bypass the UIDs > physically recorded in the UFS directory structure? No. You have separate /etc directories for each vm and you can use different uids. Even if the uid is the same from one vm to another, how much does it matter? It only matters in that you, the sysadmin, can't tell who owns a file specifically without doing a pwd to find out which vm you are in. Danny From owner-freebsd-hackers Wed Oct 22 17:02:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA11153 for hackers-outgoing; Wed, 22 Oct 1997 17:02:16 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id RAA11148 for ; Wed, 22 Oct 1997 17:02:13 -0700 (PDT) (envelope-from tom@sdf.com) Received: from tom by misery.sdf.com with smtp (Exim 1.73 #1) id 0xOAhG-0003ar-00; Wed, 22 Oct 1997 17:00:18 -0700 Date: Wed, 22 Oct 1997 17:00:13 -0700 (PDT) From: Tom To: Steve Sims cc: "'hackers@freebsd.org'" Subject: Re: SMP P-Pro MoBo - Recommendations? In-Reply-To: <01BCDEFA.1F723560.SimsS@IBM.Net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 22 Oct 1997, Steve Sims wrote: > I know this is a rehash of a thread from a couple of months ago, but..... > > I'm thinking of plopping a dual P-Pro motherboard in my overstressed > P5/120. ASUS has a nice dual-PPro board. The CPUs are on a daughter-card. You can get dual-P5, dual-P6, and dual-PII daughtercards (there is only one daughtercard slot). I've got two of these in 24x7 servers. Work well. Tom From owner-freebsd-hackers Wed Oct 22 17:36:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA13560 for hackers-outgoing; Wed, 22 Oct 1997 17:36:35 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA13554 for ; Wed, 22 Oct 1997 17:36:32 -0700 (PDT) (envelope-from mrcpu@cdsnet.net) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by mail.cdsnet.net (8.8.6/8.8.6) with SMTP id RAA28141 for ; Wed, 22 Oct 1997 17:36:24 -0700 (PDT) Date: Wed, 22 Oct 1997 17:36:24 -0700 (PDT) From: Jaye Mathisen To: hackers@freebsd.org Subject: Locking process 0, and vm_page_alloc errors. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I just upgraded to 2.2.5, supped a couple of days ago. I'm getting the following on the console: Oct 22 17:30:59 chop /kernel: pid 15918 (perl), uid 170, was killed: out of swap space Oct 22 17:31:04 chop /kernel: locking by process 0 Oct 22 17:31:05 chop last message repeated 3 times Oct 22 17:31:17 chop /kernel: vm_page_alloc(ZERO): missing pages on cache queue: 2 Yet pstat -s shows: Device 1K-blocks Used Avail Capacity Type /dev/sd0b 262144 215844 46236 82% Interleaved /dev/?? 64000 61752 2184 97% Interleaved Total 326016 277596 48420 85% /dev/?? is a vn0b swap file. (I don't know why the ?? is there). As I see it, there should be plenty of swap space, so I'm not sure what's happening. Also, the vm_page_alloc(ZERO) messages are a bit disconcerting. Any ideas appreciated. From owner-freebsd-hackers Wed Oct 22 18:24:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA17267 for hackers-outgoing; Wed, 22 Oct 1997 18:24:51 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from earth.mat.net (earth.mat.net [206.246.122.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA17260 for ; Wed, 22 Oct 1997 18:24:47 -0700 (PDT) (envelope-from chuckr@glue.umd.edu) Received: from picnic.mat.net (picnic.mat.net [206.246.122.117]) by earth.mat.net (8.8.7/8.6.12) with SMTP id VAA18826; Wed, 22 Oct 1997 21:23:51 -0400 (EDT) Date: Wed, 22 Oct 1997 20:23:29 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@picnic.mat.net To: Tom cc: Steve Sims , "'hackers@freebsd.org'" Subject: Re: SMP P-Pro MoBo - Recommendations? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 22 Oct 1997, Tom wrote: > > On Wed, 22 Oct 1997, Steve Sims wrote: > > > I know this is a rehash of a thread from a couple of months ago, but..... > > > > I'm thinking of plopping a dual P-Pro motherboard in my overstressed > > P5/120. > > ASUS has a nice dual-PPro board. The CPUs are on a daughter-card. You > can get dual-P5, dual-P6, and dual-PII daughtercards (there is only one > daughtercard slot). I've got two of these in 24x7 servers. Work well. I don't doubt it's good, but it seemed to me to be nearly twice the cost of the Tyan Titan that I settled on, for no difference in performance. The Tyan Titan didn't use the motherboard, and I thin maybe that's the largest reason for the higher cost. Either that, or maybe I didn't search out the lowest cost ... > > Tom > > > > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-hackers Wed Oct 22 19:11:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA20094 for hackers-outgoing; Wed, 22 Oct 1997 19:11:19 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id TAA20087 for ; Wed, 22 Oct 1997 19:11:15 -0700 (PDT) (envelope-from tom@sdf.com) Received: from tom by misery.sdf.com with smtp (Exim 1.73 #1) id 0xOCiD-0003eF-00; Wed, 22 Oct 1997 19:09:26 -0700 Date: Wed, 22 Oct 1997 19:09:23 -0700 (PDT) From: Tom To: Chuck Robey cc: Steve Sims , "'hackers@freebsd.org'" Subject: Re: SMP P-Pro MoBo - Recommendations? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 22 Oct 1997, Chuck Robey wrote: > On Wed, 22 Oct 1997, Tom wrote: > > > On Wed, 22 Oct 1997, Steve Sims wrote: > > > > > I know this is a rehash of a thread from a couple of months ago, but..... > > > > > > I'm thinking of plopping a dual P-Pro motherboard in my overstressed > > > P5/120. > > > > ASUS has a nice dual-PPro board. The CPUs are on a daughter-card. You > > can get dual-P5, dual-P6, and dual-PII daughtercards (there is only one > > daughtercard slot). I've got two of these in 24x7 servers. Work well. > > I don't doubt it's good, but it seemed to me to be nearly twice the cost > of the Tyan Titan that I settled on, for no difference in performance. > The Tyan Titan didn't use the motherboard, and I thin maybe that's the > largest reason for the higher cost. Either that, or maybe I didn't search > out the lowest cost ... Which Tyan Titan? I see about 9 different Titan boards. I find the cost difference kind of hard to believe, but I get a pretty good deal on ASUS stuff when buying from Supercom. The daughtercard thing is pretty cool. If the system ever needs a bit more kick, just put in the PII/300. Downtime is minimal, as you don't have to remove the motherboad to install a different daughtercard. I wish ASUS made a motherboard with two daughtercard slots, and up to 4 CPUs. Tom From owner-freebsd-hackers Wed Oct 22 19:20:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA20582 for hackers-outgoing; Wed, 22 Oct 1997 19:20:28 -0700 (PDT) (envelope-from owner-freebsd-hackers) 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 TAA20575 for ; Wed, 22 Oct 1997 19:20:20 -0700 (PDT) (envelope-from rivers@dignus.com) 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 WAA07318; Wed, 22 Oct 1997 22:20:07 -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 TAA01761; Wed, 22 Oct 1997 19:52:48 -0400 (EDT) Received: (from rivers@localhost) by lakes.dignus.com (8.8.5/8.6.9) id TAA05037; Wed, 22 Oct 1997 19:41:57 -0400 (EDT) Date: Wed, 22 Oct 1997 19:41:57 -0400 (EDT) From: Thomas David Rivers Message-Id: <199710222341.TAA05037@lakes.dignus.com> To: freebsd-hackers@freefall.FreeBSD.org, joerg_wunsch@uriah.heep.sax.de Subject: Re: Possible SERIOUS bug in open()? Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk J"org writes: > As Jamil J. Weatherbee wrote: > > > > > This was sent to me recently... It seems to be a pretty serious hole > > > > in open() and permissions... > > > > > > Fixed. > > > > How exactly did you fix it, this is related to what I was saying about > > opening a file as RD_ONLY and WR_ONLY, ... > > Yep, this was in the same boat. The way the fix works, only one of > O_RDONLY, O_WRONLY, or O_RDWR should be possible now, and anything > else should be rejected as EINVAL. > > -- > cheers, J"org Umm... I don't know the answer to this; it's just a thought I had. Couldn't you do something like: f = open("name", 0); if(f>0) { /* file exists... */ } else { /* file doesn't exist. */ } to see if the file exists? (You should use stat(), or access, but I'm just devil's advocate here...) Or, are the semantics for that simply not defined? What do other operating systems do in this case? - Dave Rivers - From owner-freebsd-hackers Wed Oct 22 19:25:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA20996 for hackers-outgoing; Wed, 22 Oct 1997 19:25:14 -0700 (PDT) (envelope-from owner-freebsd-hackers) 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 TAA20991 for ; Wed, 22 Oct 1997 19:25:11 -0700 (PDT) (envelope-from rivers@dignus.com) 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 WAA07304; Wed, 22 Oct 1997 22:20:03 -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 TAA01778; Wed, 22 Oct 1997 19:59:53 -0400 (EDT) Received: (from rivers@localhost) by lakes.dignus.com (8.8.5/8.6.9) id TAA05113; Wed, 22 Oct 1997 19:49:02 -0400 (EDT) Date: Wed, 22 Oct 1997 19:49:02 -0400 (EDT) From: Thomas David Rivers Message-Id: <199710222349.TAA05113@lakes.dignus.com> To: freebsd-hackers@freefall.FreeBSD.org, joerg_wunsch@uriah.heep.sax.de Subject: Re: Possible SERIOUS bug in open()? Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Well - to answer my own question: f = open("name", 0) would be the same as f = open("name", O_RDONLY) (since O_RDONLY is defined as 0x0000).... So - please ignore the previous drivel.... - Dave Rivers - From owner-freebsd-hackers Wed Oct 22 19:35:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA21691 for hackers-outgoing; Wed, 22 Oct 1997 19:35:12 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from elvis.mu.org (paul@elvis.mu.org [206.156.231.253]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA21679 for ; Wed, 22 Oct 1997 19:35:08 -0700 (PDT) (envelope-from paul@elvis.mu.org) Received: (from paul@localhost) by elvis.mu.org (4.1/4.1) id VAA00538 for freebsd-hackers@freebsd.org; Wed, 22 Oct 1997 21:34:58 -0500 (CDT) From: Paul Saab Message-Id: <199710230234.VAA00538@elvis.mu.org> Subject: page fault To: freebsd-hackers@freebsd.org Date: Wed, 22 Oct 1997 21:34:58 -0500 (CDT) X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello, I have a PPRO 200 that is running FreeBSD 2.2.2-RELEASE. This machine has been running flawlessly for months now but today I had a spontaneous reboot of the machine and when I came to the console savecore reported that there was a page fault and then it proceeded to save the stuff to /var/crash. My question is without debugging symbols it is not possible to find out what caused the crash is it? There is nothing in the syslog to tell me what happened so I am kind of baffled. Thanks, Paul From owner-freebsd-hackers Wed Oct 22 21:16:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA26430 for hackers-outgoing; Wed, 22 Oct 1997 21:16:13 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from netroplex.com (ns1.netroplex.com [206.171.95.130]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA26422 for ; Wed, 22 Oct 1997 21:16:05 -0700 (PDT) (envelope-from info@pagecreators.com) Received: from awd (max008-34.netroplex.com [207.212.27.34]) by netroplex.com (8.8.5/8.8.2) with ESMTP id VAA07867 for ; Wed, 22 Oct 1997 21:17:31 -0700 (PDT) Message-ID: <344ECE3F.846776A7@pagecreators.com> Date: Wed, 22 Oct 1997 21:10:39 -0700 From: Rod Ebrahimi X-Mailer: Mozilla 4.01 [en] (Win95; I) MIME-Version: 1.0 To: hackers@freebsd.org Subject: Upgrade X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have read the install notes and still am unclear on the best method of upgrading from 2.2.2 to 2.2.5 with little change of our source configuration. Any help would be greatly appreciated. Thank you, Rod From owner-freebsd-hackers Wed Oct 22 21:57:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA28566 for hackers-outgoing; Wed, 22 Oct 1997 21:57:39 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA28559 for ; Wed, 22 Oct 1997 21:57:37 -0700 (PDT) (envelope-from henrich@crh.cl.msu.edu) Received: (from henrich@localhost) by crh.cl.msu.edu (8.8.5/8.8.5) id AAA05508; Thu, 23 Oct 1997 00:57:35 -0400 (EDT) Message-ID: <19971023005735.38504@crh.cl.msu.edu> Date: Thu, 23 Oct 1997 00:57:35 -0400 From: Charles Henrich To: freebsd-hackers@freebsd.org Subject: de0 errors Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 X-Operating-System: FreeBSD 2.2.2-RELEASE X-PGP-Fingerprint: 1024/F7 FD C7 3A F5 6A 23 BF 76 C4 B8 C9 6E 41 A4 4F Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk After moving to 2.2.5-RELEASE im seeing: Oct 23 00:32:12 msunews /kernel: ccd0-3: Concatenated disk drivers Oct 23 00:35:45 msunews /kernel: de0: abnormal interrupt: transmit underflow (raising TX threshold to 96|256) Oct 23 00:36:01 msunews /kernel: de0: abnormal interrupt: transmit underflow (raising TX threshold to 8|512) Oct 23 00:37:41 msunews /kernel: de0: abnormal interrupt: transmit underflow (raising TX threshold to 1024) Oct 23 00:55:14 msunews /kernel: de0: abnormal interrupt: transmit underflow (switching to store-and-forward mode) Any ideas? Are these informational, or are they bad? -Crh Charles Henrich Michigan State University henrich@msu.edu http://pilot.msu.edu/~henrich From owner-freebsd-hackers Thu Oct 23 00:06:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA04284 for hackers-outgoing; Thu, 23 Oct 1997 00:06:56 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA04276 for ; Thu, 23 Oct 1997 00:06:52 -0700 (PDT) (envelope-from henrich@crh.cl.msu.edu) Received: (from henrich@localhost) by crh.cl.msu.edu (8.8.5/8.8.5) id DAA06751; Thu, 23 Oct 1997 03:06:51 -0400 (EDT) Message-ID: <19971023030651.02177@crh.cl.msu.edu> Date: Thu, 23 Oct 1997 03:06:51 -0400 From: Charles Henrich To: freebsd-hackers@freebsd.org Subject: CHILD_MAX no longer valid in 2.2.5-RELEASE? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 X-Operating-System: FreeBSD 2.2.2-RELEASE X-PGP-Fingerprint: 1024/F7 FD C7 3A F5 6A 23 BF 76 C4 B8 C9 6E 41 A4 4F Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've send CHILD_MAX to 512 on my news server, which (used) to have the effect of making the default maximum procs set to 512.. Bonus. Under 2.2.5-RELEASE it doesnt appear to be having any effect :( The only thing I can think of is, its placement in the config file is order important, or its no longer supported? If the latter, how do you effect the same change in 2.2.5? -Crh Charles Henrich Michigan State University henrich@msu.edu http://pilot.msu.edu/~henrich From owner-freebsd-hackers Thu Oct 23 00:09:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA04459 for hackers-outgoing; Thu, 23 Oct 1997 00:09:30 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA04453 for ; Thu, 23 Oct 1997 00:09:28 -0700 (PDT) (envelope-from mrcpu@cdsnet.net) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by mail.cdsnet.net (8.8.6/8.8.6) with SMTP id AAA14794; Thu, 23 Oct 1997 00:08:45 -0700 (PDT) Date: Thu, 23 Oct 1997 00:08:45 -0700 (PDT) From: Jaye Mathisen To: Charles Henrich cc: freebsd-hackers@FreeBSD.ORG Subject: Re: de0 errors In-Reply-To: <19971023005735.38504@crh.cl.msu.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I am getting these as well in droves. I notice it especially when the machine is serving NFS files. 2.2.5-BETA, supped 10/21/97. On Thu, 23 Oct 1997, Charles Henrich wrote: > After moving to 2.2.5-RELEASE im seeing: > > Oct 23 00:32:12 msunews /kernel: ccd0-3: Concatenated disk drivers > Oct 23 00:35:45 msunews /kernel: de0: abnormal interrupt: transmit underflow > (raising TX threshold to 96|256) > Oct 23 00:36:01 msunews /kernel: de0: abnormal interrupt: transmit underflow > (raising TX threshold to 8|512) > Oct 23 00:37:41 msunews /kernel: de0: abnormal interrupt: transmit underflow > (raising TX threshold to 1024) > Oct 23 00:55:14 msunews /kernel: de0: abnormal interrupt: transmit underflow > (switching to store-and-forward mode) > > Any ideas? Are these informational, or are they bad? > > -Crh > > Charles Henrich Michigan State University henrich@msu.edu > > http://pilot.msu.edu/~henrich > From owner-freebsd-hackers Thu Oct 23 00:33:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA06199 for hackers-outgoing; Thu, 23 Oct 1997 00:33:46 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id AAA06192 for ; Thu, 23 Oct 1997 00:33:37 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA07307 for hackers@FreeBSD.ORG; Thu, 23 Oct 1997 09:33:35 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id JAA04206; Thu, 23 Oct 1997 09:28:48 +0200 (MET DST) Message-ID: <19971023092847.TP39265@uriah.heep.sax.de> Date: Thu, 23 Oct 1997 09:28:47 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Subject: Re: ACLs [Was: C2 Trusted FreeBSD?] References: <19971021205331.53826@worldgate.com> <199710230105.TAA13328@xmission.xmission.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199710230105.TAA13328@xmission.xmission.com>; from Wes Peters - Softweyr LLC on Oct 22, 1997 19:05:39 -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk (Moved back to -hackers, it's technicall stuff.) As Wes Peters - Softweyr LLC wrote: > Yes, but how do you back them up, or, worse yet, restore them? How do > you copy your HTML directory tree to another drive you're bringing > on-line and preserve all the ACL settings? As noted before, *none* > of the system tools support the ACLs. I think you could make compatible changes to dump and restore to support ACLs. Perhaps, drop a second record containing the ACLs right behind an inode record (or even before, so the restore program knows about the intended ACLs before actually even seeing the inode information). The unknown records should simply be ignored by a restore that doesn't understand them. I once thought about extending dump to support gzip'ed files as well, but never got around to actually do it. The idea is to invent a new flag for the gzip'ed stored files, and then store the filename(s) as `originalname.gz'. If the archive goes on to a restore that doesn't understand the extension, it would extract the files with the new .gz suffix, so not all is lost. If the archive goes on to a restore that does understand the extension, it can decompress on the fly, and restore the original filename(s). Files that did already have the suffix .gz simply don't set the flag when being archived, and go to the tape verbatim. -- 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-hackers Thu Oct 23 00:33:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA06238 for hackers-outgoing; Thu, 23 Oct 1997 00:33:59 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id AAA06225 for ; Thu, 23 Oct 1997 00:33:54 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA07309; Thu, 23 Oct 1997 09:33:45 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id JAA04218; Thu, 23 Oct 1997 09:32:20 +0200 (MET DST) Message-ID: <19971023093219.WB10314@uriah.heep.sax.de> Date: Thu, 23 Oct 1997 09:32:19 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG Cc: paul@mu.org (Paul Saab) Subject: Re: page fault References: <199710230234.VAA00538@elvis.mu.org> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199710230234.VAA00538@elvis.mu.org>; from Paul Saab on Oct 22, 1997 21:34:58 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Paul Saab wrote: > My question is without debugging > symbols it is not possible to find out what caused the crash is > it? Even without debugging symbols, the kernel usually has the default symbol table, so you could find out in which function it happened. My normal way of analyzation is then to recompile parts of the kernel (the interesting parts according to the stacktrace) with -g, and have a closer look at them. Fortunately, gcc usually produces the same code with or without -g, provided the -O etc. flags remain the same. Hava a look at the section about kernel debugging in the handbook. -- 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-hackers Thu Oct 23 00:36:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA06513 for hackers-outgoing; Thu, 23 Oct 1997 00:36:56 -0700 (PDT) (envelope-from owner-freebsd-hackers) 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 AAA06508 for ; Thu, 23 Oct 1997 00:36:53 -0700 (PDT) (envelope-from kuku@gilberto.physik.RWTH-Aachen.DE) 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 JAA04952 for ; Thu, 23 Oct 1997 09:36:20 +0200 (MET DST) Received: (from kuku@localhost) by gil.physik.rwth-aachen.de (8.8.5/8.6.9) id JAA13974 for freebsd-hackers@freefall.cdrom.com; Thu, 23 Oct 1997 09:46:58 +0200 (MEST) Date: Thu, 23 Oct 1997 09:46:58 +0200 (MEST) From: Christoph Kukulies Message-Id: <199710230746.JAA13974@gil.physik.rwth-aachen.de> To: freebsd-hackers@freefall.FreeBSD.org Subject: need help in ISA memory mapping Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I have an industrial controller card (ISA) which has an ISA memory window (0xc8000-0xcffff e.g.). A user program should be able to directly read/write into these memory locations via a pointer (byte or word). Is there a way tp 'map' this into a user address space? Is it possible at all? I can use the isa_dev structure in the kernel driver (I have written a minimum driver that probes the card) but this only works in kernel mode. I thoughht of opening /dev/mem but that appears to be handled like a file and operationg via a pointer seems weird. Even weirder when I thing of mmapping that file. Any ideas? -- Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-hackers Thu Oct 23 00:54:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA07316 for hackers-outgoing; Thu, 23 Oct 1997 00:54:49 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id AAA07305 for ; Thu, 23 Oct 1997 00:54:34 -0700 (PDT) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id HAA26030; Thu, 23 Oct 1997 07:38:27 +0100 From: Luigi Rizzo Message-Id: <199710230638.HAA26030@labinfo.iet.unipi.it> Subject: zipfs filesystem anyone ? To: hackers@freebsd.org Date: Thu, 23 Oct 1997 07:38:26 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I was thinking of possible solutions for implementing a "zip file system", ie a method to access pieces of a compressed archive as if they were mounted in the filesystem [see Note 1 and 2] Basically I would like to do something like vnconfig /dev/vn0 /usr/distfiles/ports.zip mount -t zipfs /dev/vn0 /usr/ports The obvious approach of creating a new filesystem type is not very attractive though, for the complexity involved in this work and also for debugging purposes. Thus, I was looking at something which would pass all filesystem (or vn ?) calls to some user-space process which could then handle them properly. Using this approach, little modifications to, say, a standard "unzip" program, would permit such a filesystem to be implemented relatively easily. Efficiency is not a major concern for this type of application (especially because the typical use would be sequential access to files). I have been looking at the portal filesystem, but this only provides an "open" service, i.e. only the open() call is passed to the user-space process. So I think my only choice is to try a merge of the "portal" and "nullfs" filesystem to build the thing I need. But maybe such implementations already exist, in some form or some other ? NOTE 1: Motivation The motivation for this is relatively simple. Many times one needs to browse through things like a software package, which are available as a compressed archive. The common approach is to extract the archive to the filesystem and then use the file. But this approach tends to leave garbage on your disk, and is time-consuming (ever noticed how slow is to extract ports.tgz with its thousands of files and directories ?). NOTE 2: Why ZIP and not .tar.gz Implementing such a "filesystem" in user space is much easier if the directory structure is directly available in the archive, rather than being scattered all around and mixed with data. gzipped tar files have this problem: you need to decompress data before being able to use them. Conversely, I think zip archives have the directory structure in clear and so it is easier to move through the tree, and decompression is only necessary on the single components. Cheers Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-hackers Thu Oct 23 01:00:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA07773 for hackers-outgoing; Thu, 23 Oct 1997 01:00:23 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA07751; Thu, 23 Oct 1997 01:00:17 -0700 (PDT) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id AAA07182; Thu, 23 Oct 1997 00:54:56 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd007180; Thu Oct 23 07:54:55 1997 Date: Thu, 23 Oct 1997 00:53:22 -0700 (PDT) From: Julian Elischer To: Charles Mott cc: freebsd-hackers@FreeBSD.ORG, freebsd-isp@FreeBSD.ORG Subject: Re: Password files and virtual IP addresses In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk We have a whole virtual machine using chroot, and a few other tricks such as a hacked inetd. It was described recently on either hackers or questions (I forget which) by Doug Ambrisko. (I think it was questions) julian On Wed, 22 Oct 1997, Charles Mott wrote: > Suppose that one wanted to create different virtual > IP addresses with ifconfig alias, and when people telnet > or ftp or access pop3/imap2 at a virtual address, a > password file specific to that virtual address would be > used. This would allow username re-use. > > Has this sort of thing been considered before? If not, > what sort of things would have to be hacked? If password > access routines could somehow be informed what virtual > address they were being accessed from, then it would > be possible to have multiple password files. > > Of course, there are always unintended security > implications to doing these things... > > Charles Mott > > From owner-freebsd-hackers Thu Oct 23 01:57:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA11712 for hackers-outgoing; Thu, 23 Oct 1997 01:57:11 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA11687; Thu, 23 Oct 1997 01:57:05 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.6.9) id SAA29257; Thu, 23 Oct 1997 18:53:26 +1000 Date: Thu, 23 Oct 1997 18:53:26 +1000 From: Bruce Evans Message-Id: <199710230853.SAA29257@godzilla.zeta.org.au> To: freebsd-hackers@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG, joes@seaport.net Subject: Re: Interesting behaviour from sysctl(kern.boottime) Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >But, I've come to notice the following: (five executions worth of data:) > >----------------- cut here -------------- >System time is (877528801) Wed Oct 22 07:00:01 1997 >System Booted at (877407594) Mon Oct 20 21:19:54 1997 > ^^^^^^^^^^^^^^^^^^^ >Difference is: 121207 seconds >----- >System time is (877532401) Wed Oct 22 08:00:01 1997 >System Booted at (877407591) Mon Oct 20 21:19:51 1997 > ^^^^^^^^^^^^^^^^^^^ >Difference is: 124810 seconds >----- >... >I run xntpd. Could that be a factor? (updating the clock ticks or whatever?) Yes, it changes the boot time whenever it calls settimeofday() to step the clock. settimeofday() always adjusts `boottime' when it adjust `time'. This is correct when both were wrong originally, but completely wrong if the clock has drifted. A drift of 3 seconds per day is good if xntpd is _not_ used, but xntpd not step the clock if it is correctly configured and the system is always connected. Bruce From owner-freebsd-hackers Thu Oct 23 02:04:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA12496 for hackers-outgoing; Thu, 23 Oct 1997 02:04:00 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from ns2.accesscom.com (ns2.accesscom.com [205.226.156.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA12468 for ; Thu, 23 Oct 1997 02:03:49 -0700 (PDT) (envelope-from reneem@ns2.accesscom.com) From: reneem@ns2.accesscom.com Received: from Default (user8.accesscom.com [205.226.158.8]) by ns2.accesscom.com (8.8.7/8.8.7) with SMTP id CAA09181 for ; Thu, 23 Oct 1997 02:03:47 -0700 Message-Id: <199710230903.CAA09181@ns2.accesscom.com> To: reneem@accesscom.com Date: Thu, 23 Oct 1997 02:02:39 PDT Subject: Pre-launch Opportunity Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk This message is being brought to you by EMAIL BLASTER 2.5 software. If you would like a FREE copy of this software or any of our other HOT programs ABSOLTELY FREE call our FAX ON DEMAND number at 213-960-7822. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dear: Friend Promotors needed for a unique new program in pre-launch. Get in now at the very top, don't let this one pass you by. Recruit other promotors and customers. The product and the program are something you will not find anywhere else on the web. We offer free expert information. That's right, in the privacy of your own home you can have an expert respond with an answer, all for FREE!! Our experts are trained professionals. Lawyers, Doctors, Accountants, Real Estate and Banking just to name a few, there are many other professions covered also. Now, how hard can it be to recruit promotors and customers for a FREE service like this? This is a win/win program. Now is the time to join us and tell all your friends about this too. If you would like more information on this FREE opportunity please e-mail me at the following: reneem@accesscom.com Thank you for your time and please forgive me if this e-mail has caused you any inconvience. From owner-freebsd-hackers Thu Oct 23 02:19:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA13490 for hackers-outgoing; Thu, 23 Oct 1997 02:19:42 -0700 (PDT) (envelope-from owner-freebsd-hackers) 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 CAA13473; Thu, 23 Oct 1997 02:19:37 -0700 (PDT) (envelope-from gdonl@tsc.tdk.com) 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 CAA19877; Thu, 23 Oct 1997 02:19:26 -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 CAA19407; Thu, 23 Oct 1997 02:19:25 -0700 (PDT) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id CAA13620; Thu, 23 Oct 1997 02:19:24 -0700 (PDT) From: Don Lewis Message-Id: <199710230919.CAA13620@salsa.gv.tsc.tdk.com> Date: Thu, 23 Oct 1997 02:19:24 -0700 In-Reply-To: "Daniel O'Callaghan" "Re: Password files and virtual IP addresses" (Oct 23, 9:44am) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: "Daniel O'Callaghan" , "George M. Ellenburg" Subject: Re: Password files and virtual IP addresses Cc: Charles Mott , freebsd-hackers@FreeBSD.ORG, freebsd-isp@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Oct 23, 9:44am, "Daniel O'Callaghan" wrote: } Subject: Re: Password files and virtual IP addresses } Even if the uid is the same from one vm to another, how } much does it matter? How do you keep users with the same uid's in different vm's from killing each others processes? What about ps? From owner-freebsd-hackers Thu Oct 23 02:55:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA15319 for hackers-outgoing; Thu, 23 Oct 1997 02:55:36 -0700 (PDT) (envelope-from owner-freebsd-hackers) 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 CAA15312 for ; Thu, 23 Oct 1997 02:55:34 -0700 (PDT) (envelope-from gdonl@tsc.tdk.com) 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 CAA20070; Thu, 23 Oct 1997 02:55:31 -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 CAA20001; Thu, 23 Oct 1997 02:55:30 -0700 (PDT) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id CAA13696; Thu, 23 Oct 1997 02:55:29 -0700 (PDT) From: Don Lewis Message-Id: <199710230955.CAA13696@salsa.gv.tsc.tdk.com> Date: Thu, 23 Oct 1997 02:55:29 -0700 In-Reply-To: Charles Henrich "de0 errors" (Oct 23, 12:57am) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Charles Henrich , freebsd-hackers@FreeBSD.ORG Subject: Re: de0 errors Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Oct 23, 12:57am, Charles Henrich wrote: } Subject: de0 errors } After moving to 2.2.5-RELEASE im seeing: } } Oct 23 00:32:12 msunews /kernel: ccd0-3: Concatenated disk drivers } Oct 23 00:35:45 msunews /kernel: de0: abnormal interrupt: transmit underflow } (raising TX threshold to 96|256) } Oct 23 00:36:01 msunews /kernel: de0: abnormal interrupt: transmit underflow } (raising TX threshold to 8|512) } Oct 23 00:37:41 msunews /kernel: de0: abnormal interrupt: transmit underflow } (raising TX threshold to 1024) } Oct 23 00:55:14 msunews /kernel: de0: abnormal interrupt: transmit underflow } (switching to store-and-forward mode) The 2114x chips have an internal FIFO into which they load transmit data before sending the packet. To cut down on latency and increase performance, they don't require that the entire packet be loaded into the FIFO before starting transmission. There are a couple of bits in a control register to tell the 2114x how much data to load before starting, and their meaning is adjusted by another control bit that is supposed to indicate the transmission speed that adjusts the values. In 10Mb mode, the threshold values before transmission starts are 72, 96, 128, and 160 bytes. In 100Mb mode, the values are 128, 256, 512, and 1024 bytes. The threshold has to be set large enough so that the 2114x won't run out of data to transmit even if there are delays in transferring data across the PCI bus, since you can't pause the transmission of a packet to wait for the rest of the data to arrive. Since the FIFO drains faster at 100Mb, the threshold values are larger in that mode. There's also another control bit to force the 2114x to load the entire packet into the FIFO before starting to transmit, which will guarantee that it won't run out of data. Depending on the card, it is possible for the PHY chip to automatically sense the network speed so that it can communicate with the network. This will automatically set the data rate into and out of the 2114x. Since there are so many different variations of 2114x-based cards the driver may not be able to always correctly detect the speed the card is running at and may incorrectly set the network speed bit in the 2114x. If the card is connected to a 100Mb network but the driver thinks it's only 10Mb, the transmit threshold values will be to small and the FIFO will empty of data in the middle of a packet. The messages you see are this sort of underflow occuring. The four transmit underflows that you see indicate that four corrupted packets have been sent, which the driver detected and compensated for. Once the driver configures the store-and-forward mode, no more corrupted packets will be sent, but your card may not be operating as efficiently as possible. What speed is your network (10Mb or 100Mb)? What speed does the de driver think it's running at? What kind of card do you have? The other possibility is excessive delays in copying data across the PCI bus. This could indicate a configuration problem, like the latency timer values being mis-programmed. From owner-freebsd-hackers Thu Oct 23 03:15:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA16731 for hackers-outgoing; Thu, 23 Oct 1997 03:15:51 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from panda.hilink.com.au (panda.hilink.com.au [203.8.15.25]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA16726; Thu, 23 Oct 1997 03:15:45 -0700 (PDT) (envelope-from danny@panda.hilink.com.au) Received: (from danny@localhost) by panda.hilink.com.au (8.8.5/8.8.5) id UAA14008; Thu, 23 Oct 1997 20:13:15 +1000 (EST) Date: Thu, 23 Oct 1997 20:13:15 +1000 (EST) From: "Daniel O'Callaghan" To: Don Lewis cc: "George M. Ellenburg" , Charles Mott , freebsd-hackers@FreeBSD.ORG, freebsd-isp@FreeBSD.ORG Subject: Re: Password files and virtual IP addresses In-Reply-To: <199710230919.CAA13620@salsa.gv.tsc.tdk.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 23 Oct 1997, Don Lewis wrote: > On Oct 23, 9:44am, "Daniel O'Callaghan" wrote: > } Subject: Re: Password files and virtual IP addresses > > } Even if the uid is the same from one vm to another, how > } much does it matter? > > How do you keep users with the same uid's in different vm's from killing > each others processes? What about ps? > Ah, that's a good point. I had not thought of it because I don't put ps or kill in the vm. But anyway, I allocate users within each vm and give them a disabled entry in the main password file, with the same uid used in the main passwd file and the vm passwd file. That way I get sensible information when I do an ls. The vm users don't get root access within their own vm. /* Daniel O'Callaghan */ /* HiLink Internet danny@hilink.com.au */ /* FreeBSD - works hard, plays hard... danny@freebsd.org */ From owner-freebsd-hackers Thu Oct 23 03:29:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA17463 for hackers-outgoing; Thu, 23 Oct 1997 03:29:27 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from terra.Sarnoff.COM (terra.sarnoff.com [130.33.11.203]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id DAA17453 for ; Thu, 23 Oct 1997 03:29:23 -0700 (PDT) (envelope-from rminnich@Sarnoff.COM) Received: (from rminnich@localhost) by terra.Sarnoff.COM (8.6.12/8.6.12) id GAA26370; Thu, 23 Oct 1997 06:28:39 -0400 Date: Thu, 23 Oct 1997 06:28:39 -0400 (EDT) From: "Ron G. Minnich" X-Sender: rminnich@terra To: Steve Sims cc: "'hackers@freebsd.org'" Subject: Re: SMP P-Pro MoBo - Recommendations? In-Reply-To: <01BCDEFA.1F723560.SimsS@IBM.Net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk for low cost i like the tyan, but it is a shared cache. Works well on clusters, where shared cache is mostly a win. ron Ron Minnich |Java: an operating-system-independent, rminnich@sarnoff.com |architecture-independent programming language (609)-734-3120 |for Windows/95 and Windows/NT on the Pentium ftp://ftp.sarnoff.com/pub/mnfs/www/docs/cluster.html From owner-freebsd-hackers Thu Oct 23 05:12:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA21664 for hackers-outgoing; Thu, 23 Oct 1997 05:12:16 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from dcarmich.pr.mcs.net (dcarmich.pr.mcs.net [204.95.63.202]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA21650 for ; Thu, 23 Oct 1997 05:12:12 -0700 (PDT) (envelope-from dcarmich@dcarmich.pr.mcs.net) Received: (from dcarmich@localhost) by dcarmich.pr.mcs.net (8.8.5/8.8.5) id HAA00397; Thu, 23 Oct 1997 07:15:47 -0500 (CDT) Message-ID: <19971023071547.41059@dcarmich.pr.mcs.net> Date: Thu, 23 Oct 1997 07:15:47 -0500 From: Douglas Carmichael To: freebsd-hackers@freebsd.org Subject: Running DOSEMU on FreeBSD? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74e Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Have any of you people been able to run the latest NetBSD version of DOSEMU on FreeBSD? From owner-freebsd-hackers Thu Oct 23 06:09:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA24057 for hackers-outgoing; Thu, 23 Oct 1997 06:09:51 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from monoid.cs.tcd.ie (monoid.cs.tcd.ie [134.226.38.99]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA24049 for ; Thu, 23 Oct 1997 06:09:48 -0700 (PDT) (envelope-from careilly@monoid.cs.tcd.ie) Received: from monoid.cs.tcd.ie (localhost.my.domain [127.0.0.1]) by monoid.cs.tcd.ie (8.8.5/8.8.5) with ESMTP id OAA04169 for ; Thu, 23 Oct 1997 14:09:08 +0100 (IST) Message-Id: <199710231309.OAA04169@monoid.cs.tcd.ie> To: hackers@FreeBSD.ORG Subject: Security Policies [Was: ACLs [Was: C2 Trusted FreeBSD?] ] X-Address: Department of Computer Science, Trinity College, Dublin 2, Ireland. X-Phone: +353-(0)1-6081321 In-reply-to: Your message dated today at 09:28. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4164.877612147.1@monoid.cs.tcd.ie> Content-Description: text Date: Thu, 23 Oct 1997 14:09:08 +0100 From: Colman Reilly Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk [Deleted discussion about how difficult ACLs are to implement in UNIX] The basic problem with implementing ACLs, multi-level labelling and so on is that FreeBSD has very little support for security policies. It's not really a part of the architecture and seems to be done on an ad hoc basis subsystem by subsystem. I think we'd be better off considering a more general solution rather than trying to hack support in on a case by case basis. So to this weeks insane plot; A layered security model, similiar in conception to the layered filesystem, which allows a choice of access control models or model and which is used by all subsystems to make access control decisions. This way an installation could choose between (say) standard UNIX access control, ACL based access control, MAC style multi-level access control or role based access control or combinations thereof. It would also allow for more specialised access control models to be plugged in, and for the layers to be used on a system by system basis, so that the news directory was using standard UNIX access control while user directories were using ACLs on top of MAC based controls. The system would also be able to control things other than files - it could give us the socket level controls suggested previously, and possibly access controls on processes, so that unpriviledged users could send signals to daemons, that sort of thing. The main problem see (beyond the size of the task!) is where to store the access control information. The system tools would need to be changed, but thats doable - that's why we have a full distribution rather than just a kernel. We should be able to wrap most of the required stuff into a library to make changes easier. Third party tools are more of a problem. How many of them will have problems? Should we expect tar to handle this information? Does tar know how to preserve ownership even now? Colman, rambling again. From owner-freebsd-hackers Thu Oct 23 06:46:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA26551 for hackers-outgoing; Thu, 23 Oct 1997 06:46:37 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA26541 for ; Thu, 23 Oct 1997 06:46:32 -0700 (PDT) (envelope-from matt@3am-software.com) Received: from chop.cdsnet.net (chop.cdsnet.net [204.118.244.3]) by mail.cdsnet.net (8.8.6/8.8.6) with ESMTP id GAA10263; Thu, 23 Oct 1997 06:46:26 -0700 (PDT) Received: from nowin (1Cust33.max3.boston.ma.ms.uu.net [153.35.70.161]) by chop.cdsnet.net (8.8.7/8.8.5) with SMTP id EAA27427; Thu, 23 Oct 1997 04:56:08 -0700 (PDT) Message-Id: <3.0.3.32.19971023075157.031f9f3c@ranier.altavista-software.com> X-Sender: 3ampop@ranier.altavista-software.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 23 Oct 1997 07:51:57 -0400 To: Charles Henrich , Jaye Mathisen From: Matt Thomas Subject: Re: de0 errors Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <19971023005735.38504@crh.cl.msu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 12:57 AM 10/23/97 -0400, Charles Henrich wrote: >After moving to 2.2.5-RELEASE im seeing: > >Oct 23 00:32:12 msunews /kernel: ccd0-3: Concatenated disk drivers >Oct 23 00:35:45 msunews /kernel: de0: abnormal interrupt: transmit underflow >(raising TX threshold to 96|256) >Oct 23 00:36:01 msunews /kernel: de0: abnormal interrupt: transmit underflow >(raising TX threshold to 8|512) >Oct 23 00:37:41 msunews /kernel: de0: abnormal interrupt: transmit underflow >(raising TX threshold to 1024) >Oct 23 00:55:14 msunews /kernel: de0: abnormal interrupt: transmit underflow >(switching to store-and-forward mode) > >Any ideas? Are these informational, or are they bad? they are informational. -- Matt Thomas Internet: matt@3am-software.com 3am Software Foundry WWW URL: http://www.3am-software.com/bio/matt/ Nashua, NH Disclaimer: I disavow all knowledge of this message From owner-freebsd-hackers Thu Oct 23 06:54:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA27140 for hackers-outgoing; Thu, 23 Oct 1997 06:54:54 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from cs.iastate.edu (root@cs.iastate.edu [129.186.3.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA27135 for ; Thu, 23 Oct 1997 06:54:51 -0700 (PDT) (envelope-from ghelmer@cs.iastate.edu) Received: from popeye.cs.iastate.edu (popeye.cs.iastate.edu [129.186.3.4]) by cs.iastate.edu (8.8.7/8.8.7) with ESMTP id IAA02676; Thu, 23 Oct 1997 08:54:47 -0500 (CDT) Received: from localhost (ghelmer@localhost) by popeye.cs.iastate.edu (8.8.7/8.7.1) with SMTP id IAA07091; Thu, 23 Oct 1997 08:54:46 -0500 (CDT) X-Authentication-Warning: popeye.cs.iastate.edu: ghelmer owned process doing -bs Date: Thu, 23 Oct 1997 08:54:44 -0500 (CDT) From: Guy Helmer To: Charles Henrich cc: freebsd-hackers@FreeBSD.ORG Subject: Re: CHILD_MAX no longer valid in 2.2.5-RELEASE? In-Reply-To: <19971023030651.02177@crh.cl.msu.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 23 Oct 1997, Charles Henrich wrote: > I've send CHILD_MAX to 512 on my news server, which (used) to have the effect > of making the default maximum procs set to 512.. Bonus. Under 2.2.5-RELEASE > it doesnt appear to be having any effect :( The only thing I can think of is, > its placement in the config file is order important, or its no longer > supported? If the latter, how do you effect the same change in 2.2.5? init uses the "daemon" entry in /etc/login.conf to set process resource limits before executing /etc/rc; it appears to me that the "maxproc" entry (maxproc=256) is the one you need to adjust (see also login.conf(5) and getcap(3)). Hope that solves your problem, Guy Guy Helmer, Computer Science Graduate Student - ghelmer@cs.iastate.edu Iowa State University http://www.cs.iastate.edu/~ghelmer Research Assistant, Scalable Computing Laboratory, Ames Laboratory From owner-freebsd-hackers Thu Oct 23 07:16:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA28701 for hackers-outgoing; Thu, 23 Oct 1997 07:16:05 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from plum.cyber.com.au (plum.cyber.com.au [203.7.155.24]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id HAA28692 for ; Thu, 23 Oct 1997 07:16:01 -0700 (PDT) (envelope-from darrenr@cyber.com.au) Received: (from darrenr@localhost) by plum.cyber.com.au (8.6.12/8.6.6) id AAA06574 for hackers@freebsd.org; Fri, 24 Oct 1997 00:15:50 +1000 From: Darren Reed Message-Id: <199710231415.AAA06574@plum.cyber.com.au> Subject: MTU Path discovery. To: hackers@freebsd.org Date: Fri, 24 Oct 1997 00:15:50 +1000 (EST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'm want to add a sysctl knob to control this (default to on). At present, MTU path discovery only seems to be enabled for TCP, but I'm reluctant to make it "net.inet.tcp.mtupathdiscovery" as I don't want to limit its scope. However, I'm open for comments about whether it should be ip or icmp. I don't think the current behaviour (is on and cannot be controlled) is all that desirable. Darren From owner-freebsd-hackers Thu Oct 23 07:21:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA29090 for hackers-outgoing; Thu, 23 Oct 1997 07:21:14 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (word.smith.net.au [202.0.75.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA29085 for ; Thu, 23 Oct 1997 07:21:04 -0700 (PDT) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id XAA00411; Thu, 23 Oct 1997 23:47:11 +0930 (CST) Message-Id: <199710231417.XAA00411@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Colman Reilly cc: hackers@FreeBSD.ORG Subject: Re: Security Policies [Was: ACLs [Was: C2 Trusted FreeBSD?] ] In-reply-to: Your message of "Thu, 23 Oct 1997 14:09:08 +0100." <199710231309.OAA04169@monoid.cs.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 23 Oct 1997 23:47:10 +0930 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > [Deleted discussion about how difficult ACLs are to implement in UNIX] [Serious security model revamp proposal] > The main problem see (beyond the size of the task!) is where to store the > access control information. That too. Another would be making it clear to people how to work well with the new model(s). Having said all that, I'd still suggest that it's worth pursuing. If you approach the problem generalistically, you'd end up with something that could be applied to a not inconsiderable number of like systems, and achieve a pretty major breakthrough in that regard. mike From owner-freebsd-hackers Thu Oct 23 07:31:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA29646 for hackers-outgoing; Thu, 23 Oct 1997 07:31:02 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (word.smith.net.au [202.0.75.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA29632 for ; Thu, 23 Oct 1997 07:30:29 -0700 (PDT) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id XAA00457; Thu, 23 Oct 1997 23:56:23 +0930 (CST) Message-Id: <199710231426.XAA00457@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Christoph Kukulies cc: freebsd-hackers@freefall.FreeBSD.org Subject: Re: need help in ISA memory mapping In-reply-to: Your message of "Thu, 23 Oct 1997 09:46:58 +0200." <199710230746.JAA13974@gil.physik.rwth-aachen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 23 Oct 1997 23:56:07 +0930 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > A user program should be able to directly read/write into these memory > locations via a pointer (byte or word). Is there a way tp 'map' > this into a user address space? Is it possible at all? Yup. You just need to mmap() a friendly driver or memory extent. > I can use the isa_dev structure in the kernel driver (I have written > a minimum driver that probes the card) but this only works in kernel > mode. You could extend the driver trivially to offer mmap() facilities; this would be ideal as it would allow you to detect the correct location for the card & disallow the mapping if the card did not exist. Have a look at the mapping stuff in syscons for an example. mike From owner-freebsd-hackers Thu Oct 23 07:45:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA00800 for hackers-outgoing; Thu, 23 Oct 1997 07:45:36 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA00790 for ; Thu, 23 Oct 1997 07:45:30 -0700 (PDT) (envelope-from henrich@crh.cl.msu.edu) Received: (from henrich@localhost) by crh.cl.msu.edu (8.8.5/8.8.5) id KAA09776; Thu, 23 Oct 1997 10:45:27 -0400 (EDT) Message-ID: <19971023104527.34841@crh.cl.msu.edu> Date: Thu, 23 Oct 1997 10:45:27 -0400 From: Charles Henrich To: Guy Helmer Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: CHILD_MAX no longer valid in 2.2.5-RELEASE? References: <19971023030651.02177@crh.cl.msu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: ; from Guy Helmer on Thu, Oct 23, 1997 at 08:54:44AM -0500 X-Operating-System: FreeBSD 2.2.2-RELEASE X-PGP-Fingerprint: 1024/F7 FD C7 3A F5 6A 23 BF 76 C4 B8 C9 6E 41 A4 4F Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On the subject of Re: CHILD_MAX no longer valid in 2.2.5-RELEASE?, Guy Helmer stated: > > I've send CHILD_MAX to 512 on my news server, which (used) to have the > > effect of making the default maximum procs set to 512.. Bonus. Under > > 2.2.5-RELEASE it doesnt appear to be having any effect :( The only thing > > I can think of is, its placement in the config file is order important, or > > its no longer supported? If the latter, how do you effect the same change > > in 2.2.5? > > init uses the "daemon" entry in /etc/login.conf to set process resource > limits before executing /etc/rc; it appears to me that the "maxproc" entry > (maxproc=256) is the one you need to adjust (see also login.conf(5) and > getcap(3)). > > Hope that solves your problem, Guy I'll give it a shot, thanks! Im wondering that perhaps the name login.conf is a badly named file, especially if its more to do with userresources and nothing to do with the login process. Someone should also take CHILD_MAX out of LINT :) -Crh Charles Henrich Michigan State University henrich@msu.edu http://pilot.msu.edu/~henrich From owner-freebsd-hackers Thu Oct 23 07:52:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA01381 for hackers-outgoing; Thu, 23 Oct 1997 07:52:42 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (word.smith.net.au [202.0.75.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA01375 for ; Thu, 23 Oct 1997 07:52:38 -0700 (PDT) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id AAA00606; Fri, 24 Oct 1997 00:18:53 +0930 (CST) Message-Id: <199710231448.AAA00606@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Archie Cobbs cc: freebsd-hackers@freebsd.org Subject: Re: Broken device LKM in 2.2 In-reply-to: Your message of "Mon, 20 Oct 1997 17:00:23 MST." <199710210000.RAA11140@bubba.whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 24 Oct 1997 00:18:51 +0930 From: Mike Smith Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I guess nobody makes device type LKM's in 2.2.. but sys/lkm.h is > broken with respect to them. Here's a hack that fixes this. Perhaps > the "name ## _module", which is different from the other module > types, is there for some reason (?) IIRC it's there to avoid symbol conflicts with statically loaded versions. Could be wrong of course; there's nothing in the CVS log. > Anyway, it's incompatible with the DISPATCH macro defined later in > the file, and this fixes it... Has anyone looked at this? Should we buy it? mike From owner-freebsd-hackers Thu Oct 23 08:22:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA03878 for hackers-outgoing; Thu, 23 Oct 1997 08:22:41 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA03869 for ; Thu, 23 Oct 1997 08:22:35 -0700 (PDT) (envelope-from henrich@crh.cl.msu.edu) Received: (from henrich@localhost) by crh.cl.msu.edu (8.8.5/8.8.5) id LAA10054; Thu, 23 Oct 1997 11:21:06 -0400 (EDT) Message-ID: <19971023112105.56949@crh.cl.msu.edu> Date: Thu, 23 Oct 1997 11:21:05 -0400 From: Charles Henrich To: Don Lewis Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: de0 errors References: <199710230955.CAA13696@salsa.gv.tsc.tdk.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: <199710230955.CAA13696@salsa.gv.tsc.tdk.com>; from Don Lewis on Thu, Oct 23, 1997 at 02:55:29AM -0700 X-Operating-System: FreeBSD 2.2.2-RELEASE X-PGP-Fingerprint: 1024/F7 FD C7 3A F5 6A 23 BF 76 C4 B8 C9 6E 41 A4 4F Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On the subject of Re: de0 errors, Don Lewis stated: > packets will be sent, but your card may not be operating as efficiently > as possible. > > What speed is your network (10Mb or 100Mb)? What speed does the de driver > think it's running at? What kind of card do you have? Its a 100mbit network, the card thinks its a 100mbit network. de0 rev 18 int a irq 9 on pci0:20 de0: SMC 9332DST 21140 [10-100Mb/s] pass 1.2 de0: address 00:00:c0:9e:ba:c7 de0: enabling 100baseTX port de0: flags=8843 mtu 1500 inet 35.8.2.20 netmask 0xfff80000 broadcast 35.15.255.255 ether 00:00:c0:9e:ba:c7 media: 100baseTX status: active -Crh Charles Henrich Michigan State University henrich@msu.edu http://pilot.msu.edu/~henrich From owner-freebsd-hackers Thu Oct 23 08:32:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA04477 for hackers-outgoing; Thu, 23 Oct 1997 08:32:38 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from korin.warman.org.pl (korin.nask.waw.pl [148.81.160.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA04461 for ; Thu, 23 Oct 1997 08:32:28 -0700 (PDT) (envelope-from abial@korin.warman.org.pl) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.8.7/8.8.5) with SMTP id RAA23876; Thu, 23 Oct 1997 17:33:57 +0200 (CEST) Date: Thu, 23 Oct 1997 17:33:57 +0200 (CEST) From: Andrzej Bialecki To: Luigi Rizzo cc: hackers@FreeBSD.ORG Subject: Re: zipfs filesystem anyone ? In-Reply-To: <199710230638.HAA26030@labinfo.iet.unipi.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 23 Oct 1997, Luigi Rizzo wrote: > So I think my only choice is to try a merge of the "portal" and > "nullfs" filesystem to build the thing I need. But maybe such > implementations already exist, in some form or some other ? As far as I understand it, the CryptoFS (cfs in ports) implements something similar by using a modified NFS daemon. I like the idea of a zipfs. Andrzej Bialecki ---------------------+--------------------------------------------------------- abial@warman.org.pl | if(halt_per_mth > 0) { fetch("http://www.freebsd.org") } Research & Academic | "Be open-minded, but don't let your brains to fall out." Network in Poland | All of the above (and more) is just my personal opinion. ---------------------+--------------------------------------------------------- From owner-freebsd-hackers Thu Oct 23 08:33:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA04531 for hackers-outgoing; Thu, 23 Oct 1997 08:33:37 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from cs.iastate.edu (root@cs.iastate.edu [129.186.3.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA04526 for ; Thu, 23 Oct 1997 08:33:32 -0700 (PDT) (envelope-from ghelmer@cs.iastate.edu) Received: from popeye.cs.iastate.edu (popeye.cs.iastate.edu [129.186.3.4]) by cs.iastate.edu (8.8.7/8.8.7) with ESMTP id KAA15481; Thu, 23 Oct 1997 10:33:28 -0500 (CDT) Received: from localhost (ghelmer@localhost) by popeye.cs.iastate.edu (8.8.7/8.7.1) with SMTP id KAA16023; Thu, 23 Oct 1997 10:33:27 -0500 (CDT) X-Authentication-Warning: popeye.cs.iastate.edu: ghelmer owned process doing -bs Date: Thu, 23 Oct 1997 10:33:26 -0500 (CDT) From: Guy Helmer To: Charles Henrich cc: freebsd-hackers@FreeBSD.ORG Subject: Re: CHILD_MAX no longer valid in 2.2.5-RELEASE? In-Reply-To: <19971023104527.34841@crh.cl.msu.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 23 Oct 1997, Charles Henrich wrote: > On the subject of Re: CHILD_MAX no longer valid in 2.2.5-RELEASE?, Guy Helmer stated: > > init uses the "daemon" entry in /etc/login.conf to set process resource > > limits before executing /etc/rc; it appears to me that the "maxproc" entry > > (maxproc=256) is the one you need to adjust (see also login.conf(5) and > > getcap(3)). > > I'll give it a shot, thanks! Im wondering that perhaps the name login.conf is > a badly named file, especially if its more to do with userresources and > nothing to do with the login process. Someone should also take CHILD_MAX out > of LINT :) login.conf's primary use is for defining authentication methods, setting user resource limits, and setting useful system-wide defaults at login time, based on user class, but it is marginally overloaded (in particular, for init(8) like we've noted). There ought to be a couple of pointers to this use of the daemon entry in login.conf in init(8)'s man page and LINT (assuming CHILD_MAX stays in) -- I suppose that means I ought to make diffs and write a gnats report :-) Guy Helmer, Computer Science Graduate Student - ghelmer@cs.iastate.edu Iowa State University http://www.cs.iastate.edu/~ghelmer Research Assistant, Scalable Computing Laboratory, Ames Laboratory From owner-freebsd-hackers Thu Oct 23 08:40:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA05109 for hackers-outgoing; Thu, 23 Oct 1997 08:40:44 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (word.smith.net.au [202.0.75.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA05089 for ; Thu, 23 Oct 1997 08:40:35 -0700 (PDT) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id BAA00846; Fri, 24 Oct 1997 01:06:19 +0930 (CST) Message-Id: <199710231536.BAA00846@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Darren Reed cc: hackers@freebsd.org Subject: Re: MTU Path discovery. In-reply-to: Your message of "Fri, 24 Oct 1997 00:15:50 +1000." <199710231415.AAA06574@plum.cyber.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 24 Oct 1997 01:06:18 +0930 From: Mike Smith Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I'm want to add a sysctl knob to control this (default to on). Sounds reasonable. > I don't think the current behaviour (is on and cannot be controlled) > is all that desirable. Which part is undesirable? And if the former, why? mike From owner-freebsd-hackers Thu Oct 23 08:42:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA05232 for hackers-outgoing; Thu, 23 Oct 1997 08:42:52 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (word.smith.net.au [202.0.75.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA05218 for ; Thu, 23 Oct 1997 08:42:45 -0700 (PDT) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id BAA00881; Fri, 24 Oct 1997 01:09:30 +0930 (CST) Message-Id: <199710231539.BAA00881@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Dan Walters cc: hackers@freebsd.org Subject: Re: ATAPI CD-RW documentation... In-reply-to: Your message of "Sun, 19 Oct 1997 18:09:07 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 24 Oct 1997 01:09:30 +0930 From: Mike Smith Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Never mind, it's amazing how you always find things right after you give > up and ask. :) For anyone wondering, the motherload of specs can be > found by ftp at fission.dt.wdc.com, including the working draft of the > ATAPI Removable Rewritable Specification, SFF-8070. Wish their web pages > would mention the site. :) Thanks for finding the number for me; I ran out of patience downloading them, struggling to print them and giving up 8) > So, has anyone already began work on this, or should I go ahead and give > it a shot when my drive gets in? Nobody's begun any work, as such. Again, I exhort you to look at Justin Gibbs' CAM framework; it is the future of mass storage interfaces in FreeBSD, and we should be looking towards it. mike From owner-freebsd-hackers Thu Oct 23 09:12:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA06928 for hackers-outgoing; Thu, 23 Oct 1997 09:12:09 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (word.smith.net.au [202.0.75.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA06826 for ; Thu, 23 Oct 1997 09:11:45 -0700 (PDT) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id BAA01020; Fri, 24 Oct 1997 01:37:03 +0930 (CST) Message-Id: <199710231607.BAA01020@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Luigi Rizzo cc: hackers@FreeBSD.ORG Subject: Re: zipfs filesystem anyone ? In-reply-to: Your message of "Thu, 23 Oct 1997 07:38:26 +0100." <199710230638.HAA26030@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 24 Oct 1997 01:37:03 +0930 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Thus, I was looking at something which would pass all filesystem > (or vn ?) calls to some user-space process which could then handle > them properly. Look at the 'rumba' port for an example of using the NFS interface to achieve this. > NOTE 2: Why ZIP and not .tar.gz > > Implementing such a "filesystem" in user space is much easier if the > directory structure is directly available in the archive, rather than > being scattered all around and mixed with data. gzipped tar files have > this problem: you need to decompress data before being able to use > them. Conversely, I think zip archives have the directory structure in > clear and so it is easier to move through the tree, and decompression > is only necessary on the single components. You are correct; gzipped tarfiles are organised the wrong way around (metadata inside the compressed envelope), while zipfiles keep the metadata outside. mike From owner-freebsd-hackers Thu Oct 23 09:13:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA07028 for hackers-outgoing; Thu, 23 Oct 1997 09:13:07 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from horst.bfd.com (horst.bfd.com [204.160.242.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA07021 for ; Thu, 23 Oct 1997 09:13:04 -0700 (PDT) (envelope-from ejs@bfd.com) Received: from harlie.bfd.com (bastion.bfd.com [204.160.242.14]) by horst.bfd.com (8.8.5/8.7.3) with SMTP id JAA04248; Thu, 23 Oct 1997 09:12:37 -0700 (PDT) Date: Thu, 23 Oct 1997 09:12:37 -0700 (PDT) From: "Eric J. Schwertfeger" To: "Ron G. Minnich" cc: Steve Sims , "'hackers@freebsd.org'" Subject: Re: SMP P-Pro MoBo - Recommendations? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 23 Oct 1997, Ron G. Minnich wrote: > for low cost i like the tyan, but it is a shared cache. Works well on > clusters, where shared cache is mostly a win. > ron On the PPro boards, the L2 cache is on chip, so can't be shared. This was an issue on Pentium motherboards, though, and the biggest reason the PPro's do better in SMP environments. From owner-freebsd-hackers Thu Oct 23 09:23:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA07568 for hackers-outgoing; Thu, 23 Oct 1997 09:23:02 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA07560 for ; Thu, 23 Oct 1997 09:22:58 -0700 (PDT) (envelope-from henrich@crh.cl.msu.edu) Received: (from henrich@localhost) by crh.cl.msu.edu (8.8.5/8.8.5) id MAA10511; Thu, 23 Oct 1997 12:22:55 -0400 (EDT) Message-ID: <19971023122255.43108@crh.cl.msu.edu> Date: Thu, 23 Oct 1997 12:22:55 -0400 From: Charles Henrich To: Guy Helmer Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: CHILD_MAX no longer valid in 2.2.5-RELEASE? References: <19971023104527.34841@crh.cl.msu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: ; from Guy Helmer on Thu, Oct 23, 1997 at 10:33:26AM -0500 X-Operating-System: FreeBSD 2.2.2-RELEASE X-PGP-Fingerprint: 1024/F7 FD C7 3A F5 6A 23 BF 76 C4 B8 C9 6E 41 A4 4F Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On the subject of Re: CHILD_MAX no longer valid in 2.2.5-RELEASE?, Guy Helmer stated: > There ought to be a couple of pointers to this use of the daemon entry in > login.conf in init(8)'s man page and LINT (assuming CHILD_MAX stays in) -- > I suppose that means I ought to make diffs and write a gnats report :-) Perhaps. Now I'd like to get up on my soapbox and bitch about this login.conf business. For some assinine reason the defaults for login.conf for system processes (including BOOT!). This bit me big time when trying to fsck a large raid array, the fsck failed with out of memory. What remotely possible, conceivable reason would you ever want to limit root and its ilk from having free run of the system? This seems like a very dangerous policy that can in dire system cases lock the administrators out of the system. I would strongly suggest the defaults in login conf is everything is wide open, and its up to the sysadmin to fix it. In 90 percent of the FreeBSD installations out there, (my guess), this is appropriate, and only in the ISP multi-user-login case is the current defaults usefull. -Crh Charles Henrich Michigan State University henrich@msu.edu http://pilot.msu.edu/~henrich From owner-freebsd-hackers Thu Oct 23 09:23:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA07627 for hackers-outgoing; Thu, 23 Oct 1997 09:23:27 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA07616; Thu, 23 Oct 1997 09:23:24 -0700 (PDT) (envelope-from ambrisko@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id JAA17056; Thu, 23 Oct 1997 09:15:16 -0700 (PDT) Received: from crab.whistle.com(207.76.205.112) via SMTP by alpo.whistle.com, id smtpd017049; Thu Oct 23 16:15:06 1997 Received: (from ambrisko@localhost) by crab.whistle.com (8.8.7/8.6.12) id JAA22205; Thu, 23 Oct 1997 09:13:57 -0700 (PDT) From: Doug Ambrisko Message-Id: <199710231613.JAA22205@crab.whistle.com> Subject: Re: Password files and virtual IP addresses In-Reply-To: from Julian Elischer at "Oct 23, 97 00:53:22 am" To: freebsd-hackers@FreeBSD.ORG, freebsd-isp@FreeBSD.ORG Date: Thu, 23 Oct 1997 09:13:56 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL29 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Julian Elischer writes: | We have a whole virtual machine | using chroot, and a few other tricks such as a hacked inetd. | It was described recently on either hackers or questions (I forget which) | by Doug Ambrisko. (I think it was questions) I was a hacked natd-like program. "inetd" was fine as is. | On Wed, 22 Oct 1997, Charles Mott wrote: | | > Suppose that one wanted to create different virtual | > IP addresses with ifconfig alias, and when people telnet | > or ftp or access pop3/imap2 at a virtual address, a | > password file specific to that virtual address would be | > used. This would allow username re-use. | > | > Has this sort of thing been considered before? If not, | > what sort of things would have to be hacked? If password | > access routines could somehow be informed what virtual | > address they were being accessed from, then it would | > be possible to have multiple password files. | > | > Of course, there are always unintended security | > implications to doing these things... This is a pretty simple case since this services can be controled via inetd. Since inetd is well-behaved (ie uses /etc/services to figure out what ports to use), it is pretty easy to copy the stuff you need into a small chroot and then do a "chroot path /usr/sbin/inetd" to start your services that have been shifted via editing /etc/services in the chroot. The tricky part is to make connections that come in through the alias ip to do a "port shift" from the standard to the ones used in the chroot. This can be done with a hacked natd that does port translation instead of ip translation. Note this problem is simpler then the case I described before since only incoming connections are made so you don't have to worry about translating connections originating from the chroot such as sendmail delivering mail from inside the chroot. The translate code is based on some non-public Whistle code. Doug A. From owner-freebsd-hackers Thu Oct 23 09:40:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA09091 for hackers-outgoing; Thu, 23 Oct 1997 09:40:11 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.5.83]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA09086 for ; Thu, 23 Oct 1997 09:40:06 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.7/8.8.7) id JAA24658 for ; Thu, 23 Oct 1997 09:40:04 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp02.primenet.com, id smtpd024647; Thu Oct 23 09:40:01 1997 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id JAA23174 for hackers@FreeBSD.ORG; Thu, 23 Oct 1997 09:40:01 -0700 (MST) From: Terry Lambert Message-Id: <199710231640.JAA23174@usr02.primenet.com> Subject: Re: FreeBSD 3.0 kernel API ?! To: hackers@FreeBSD.ORG Date: Thu, 23 Oct 1997 16:40:01 +0000 (GMT) In-Reply-To: <199710220334.UAA23820@kithrup.com> from "Sean Eric Fagan" at Oct 21, 97 08:34:20 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >> How will you deal with struct ifnet when we rename all the member > >> variables from their current names to "opaque_variable_01" through > >> "opaque_variable_NN"? Even if you can depend on the structure, you > >> can't reasonably expect the kernel internal interface to not change. > >This sort of change I think is, to put it bluntly, fucked. > > Terry's problem is that he is forgetting that non-kernel bits are part of > the OS in unix. I'm not forgetting this. I'm fine with it. > This means that some non-kernel bits have to know the format (and location) > of some kernel data structures, sometimes. This, I stringly disagree with. Kernel internal structures are *internal*, that's the whole point in calling them that. 8-). What this means is that they should be accessed via accessor functions instead of directly. The best mechanism would be descriptor based to not externalize any structure changes, *ever*. > (While there are many cases where you can abstract this into a usable > API, there are many other cases where you can't -- because what you > want to get at is, indeed, exactly what the kernel is using.) Then I would argue that you are cutting the interface in the wrong place: in the middle of the iterator instead of above it. Let's take an example: the proc struct. I want to iterate the processes on the system, and provide some information as a result of this iteration. This may be because I'm the 'w' command, or it may be that I'm the 'ps' command, or it may be that I'm a to-be-written session manager. Right now, this can be done one of several ways: 1) open /dev/kmem via lib kvm (and need to know the proc struct size and layout) and grovel 2) popen() an existing command that does #1 already (and compound the difficulty of fixing #1) 3) iterate /proc (and need to have it mounted) Of these, the best programatic interface is currently #3. But it fails to operate, as 'ps' currently does, on system dump images. Let's forget for the moment that this functionality belongs in the system dump analysis tool instead of the regular commands. How do we make our putatively "new, improved" 'ps' command do these things? The easiest way would be to associate the iterator interface, not with the 'ps' program (and duplicate the code in all programs like it), but to provide access via an iterator mechanism (as in #3)... only not to depend on a cannonizing-data-exposure interface (like procfs). You don't want to depend on data-exposure because it can only expose the data of a running kernel. And libkvm is a non-cannonizing-data-exposure interface. So what do you do? The obvious soloution is to somehow make an association of an iterator interface with the image that creates the data. You can do this with ELF by making the interface, effectivly, a shared library which resides in the kernel image and exports data by descriptor. With ELF, you can do this. The trick it to make the kernel loader not load sections with a section attribute that indicates they are this interface, and to make the dlopen() interface take a section type argument (actually, you change dlopen() to wrap another interface with the third argument -- otherwise you lose backward compatability and have to do things like actually looking to the future -- ugh!). Another alternative would be to *not* ignore what we did before: remove the system dump analysis capability from 'ps' and 'w' and ..., and put it in a system dump analyzer tool. Then do conversion to approach #3. This makes procfs manadatory (I really don't think this is such a bad thing, myself). > This is further complicated by the fact that some utilities people have > decided are part of the OS are not maintained by us. These utilities must track system changes. That's all there is to it. If it becomes too burdensome, then FreeBSD must pay for the ability to make changes away from the mainstream by picking up maintenance. Can you say a.out? ...I knew you could. Maintenance of old GNU tools is the payment FreeBSD must render for not going to ELF with the rest of the world. Similarly, maintenance of things which grovel /dev/kmem (whether or not via libkvm is irrelevant) falls to FreeBSD as well. Which is the number one reason to eliminate the interface (number two is so you don't have to rebuild libkvm and everything which uses it each time a trivial kernel structure change takes place). Back to the original poster: There are two valid complaints you have, both of which require the core team to establish policy: 1) How do I write portable kernel code on other platforms which can be run on FreeBSD? Right now, if you use kernel structures, you must define "KERNEL (as someone else pointed out, this is a bogus name space incursion, and should be "_KERNEL). This will alleviate your complaint, assuming you are building "live" code. 2) How do I test kernel code in user space? The ability to test kernel codde in user space is a developement environmnet option. The FreeBSD core team is responsible for decisions of policy regarding whether or not this option is to be offered by FreeBSD. My personal take (since I'm not one of them) is that it's a desirable future goal to be able to develop and test kernel code in user space, and that to some extent, this will require a conversion to ELF to be able to externalize the kernel interfaces. I would like to see a formal DDI/DKI definition, and I'd like to see that definition result in a user space test harness and transport layer. But what does this buy you beyond LKM's? It buys you the ability to do source level debugging. Right now, to get source level kernel debugging, it requires two machines. So the answer for right now is to use LKM's, put the code into the running kernel, and use another machine to get source debugging. Hopefully, this subject is now exhausted. Regards, 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-hackers Thu Oct 23 09:47:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA09632 for hackers-outgoing; Thu, 23 Oct 1997 09:47:16 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from elvis.mu.org (elvis.mu.org [206.156.231.253]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA09621 for ; Thu, 23 Oct 1997 09:47:11 -0700 (PDT) (envelope-from paul@elvis.mu.org) Received: (from paul@localhost) by elvis.mu.org (8.8.7/8.8.7) id LAA04258 for freebsd-hackers@freebsd.org; Thu, 23 Oct 1997 11:47:07 -0500 (CDT) (envelope-from paul) From: Paul Saab Message-Id: <199710231647.LAA04258@elvis.mu.org> Subject: Re: page fault To: freebsd-hackers@freebsd.org Date: Thu, 23 Oct 1997 11:47:07 -0500 (CDT) X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk J Wunsch wrote: > As Paul Saab wrote: > > > My question is without debugging > > symbols it is not possible to find out what caused the crash is > > it? > > Even without debugging symbols, the kernel usually has the default > symbol table, so you could find out in which function it happened. My > normal way of analyzation is then to recompile parts of the kernel > (the interesting parts according to the stacktrace) with -g, and have > a closer look at them. Fortunately, gcc usually produces the same > code with or without -g, provided the -O etc. flags remain the same. > > Hava a look at the section about kernel debugging in the handbook. Ok.. here is what I got... IdlePTD 21c000 current pcb at 1f16a4 panic: page fault #0 0xf0113b83 in boot () (kgdb) where #0 0xf0113b83 in boot () #1 0xf0113e42 in panic () #2 0xf01bffc6 in trap_fatal () #3 0xf01bfab4 in trap_pfault () #4 0xf01bf78f in trap () #5 0xf015a48f in tcp_ctlinput () #6 0xf01537aa in icmp_input () #7 0xf01542fe in ip_input () #8 0xf0154374 in ipintr () What does this mean? Paul From owner-freebsd-hackers Thu Oct 23 09:58:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA10379 for hackers-outgoing; Thu, 23 Oct 1997 09:58:17 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA10372 for ; Thu, 23 Oct 1997 09:58:13 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.7/8.8.7) id JAA27342; Thu, 23 Oct 1997 09:58:12 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp03.primenet.com, id smtpd027330; Thu Oct 23 09:58:00 1997 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id JAA24042; Thu, 23 Oct 1997 09:57:59 -0700 (MST) From: Terry Lambert Message-Id: <199710231657.JAA24042@usr02.primenet.com> Subject: Re: FreeBSD 3.0 kernel API ?! To: darrenr@cyber.com.au (Darren Reed) Date: Thu, 23 Oct 1997 16:57:58 +0000 (GMT) Cc: tlambert@primenet.com, hackers@freebsd.org In-Reply-To: <199710220202.MAA01643@plum.cyber.com.au> from "Darren Reed" at Oct 22, 97 12:02:36 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > How will you deal with struct ifnet when we rename all the member > > variables from their current names to "opaque_variable_01" through > > "opaque_variable_NN"? Even if you can depend on the structure, you > > can't reasonably expect the kernel internal interface to not change. > > This sort of change I think is, to put it bluntly, fucked. (I'm > probably putting a lot of people who `control' freebsd offside here). > I'd heartily recommend spending time on something worthwhile rather > than going around making life more difficult for people that. > > It's a change for the sake of a change with no reasonable reason to > happen. To recite an old adage: if it's not broken, don't fix it. It's an example of something that you, as a consumer of the kernel, should not be permitted to tie the hands of kernel developers over, and thereby preclude future dependent progress. It's very like my layering changes to the FS, which add nothing functionally, only architecturally. I can only demostrate small pieces of future functionality (like NFS client locking); it's impossible to say what the big picture is like until the future gets here. I, for one, will not bitch about somone opening the curtains to give me a bigger vista, even if I haven't bothered to step through the window (yet). A more real world example would be the VM system changes, which required interface changes. Anyone who wrote a module that implemented a paging policy on NetBSD is rather screwed trying to port the code to FreeBSD because of similar "arbitrary" changes. Arbitrariness is in the eye of the beholder. On the flip side, if you have a problem with a design choice, provide an alternate implementation which still achieves the design goals of the code you are complaining about, without the drawbacks you perceive in the existing code. > blah, time to giveup on FreeBSD and use Linux I think...at least Linus > doesn't allow silly changes that achieve nothing and just cause more > work. ELF? Linux is still not using the ELF features which I believe are the reasons FreeBSD should switch to ELF; there was no real reason to switch Linux to ELF, except to enable future work along the lines identified by myself and others. For Linux, that work has yet to materialize, and there's no immediate significant advantage to having done the switch. Meanwhile, much old code (mostly code using old shared libraries) has been broken in the process. Where are the cannonized-data-interfaces? Where are the NT SCSI and network drivers? Where is the 'ps' that can run against a system dump image, but that doesn't need recompilation when the proc struct changes? Where is section coloring for kernel paging of non-paging code-path kernel pages? Where is the ELF image archiver so the kernel never needs to be recompiled, only it's archive edited? Where are the objects that can be archived into the kernel image, or alternately loaed as LKM's, without rebuilding them? This is all yet nothing more than open curtains in Linux... but it's still desirable to have the curtains open. Regards, 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-hackers Thu Oct 23 10:05:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA10706 for hackers-outgoing; Thu, 23 Oct 1997 10:05:20 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from mole.mole.org (marmot.mole.org [204.216.57.191]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id KAA10691 for ; Thu, 23 Oct 1997 10:05:14 -0700 (PDT) (envelope-from mrm@mole.mole.org) Received: (from mail@localhost) by mole.mole.org (8.6.12/8.6.12) id RAA23067; Thu, 23 Oct 1997 17:04:27 GMT Received: from meerkat.mole.org(206.197.192.20) by mole.mole.org via smap (V1.3) id sma023065; Thu Oct 23 17:04:02 1997 Received: (from mrm@localhost) by meerkat.mole.org (8.6.11/8.6.9) id KAA06454; Thu, 23 Oct 1997 10:02:06 -0700 Date: Thu, 23 Oct 1997 10:02:06 -0700 From: "M.R.Murphy" Message-Id: <199710231702.KAA06454@meerkat.mole.org> To: darrenr@cyber.com.au Subject: Re: MTU Path discovery. Cc: freebsd-hackers@freebsd.org Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I'm want to add a sysctl knob to control this (default to on). > > At present, MTU path discovery only seems to be enabled for TCP, but > I'm reluctant to make it "net.inet.tcp.mtupathdiscovery" as I don't > want to limit its scope. However, I'm open for comments about > whether it should be ip or icmp. > > I don't think the current behaviour (is on and cannot be controlled) > is all that desirable. > >From experience: MTU path discovery isn't that all fired reliable. Better to just set the MTU to the highest guaranteed value on the last outgoing router under one's control and leave it at that. I can't remember if it's 296. I hate losing my memory :-( The number is in the RFC's. Better to take the performance hit than not have a reliable connection. The hitch is blackhole routers. -- Mike Murphy mrm@Mole.ORG +1 619 598 5874 Better is the enemy of Good From owner-freebsd-hackers Thu Oct 23 10:22:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA11736 for hackers-outgoing; Thu, 23 Oct 1997 10:22:57 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.5.83]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA11731 for ; Thu, 23 Oct 1997 10:22:53 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.7/8.8.7) id KAA27823; Thu, 23 Oct 1997 10:04:53 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp02.primenet.com, id smtpd027803; Thu Oct 23 10:04:47 1997 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id KAA24394; Thu, 23 Oct 1997 10:04:45 -0700 (MST) From: Terry Lambert Message-Id: <199710231704.KAA24394@usr02.primenet.com> Subject: Re: Hardware RAID-x controllers for FreeBSD? To: tom@sdf.com (Tom) Date: Thu, 23 Oct 1997 17:04:45 +0000 (GMT) Cc: jamil@trojanhorse.ml.org, dcarmich@mcs.net, freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Tom" at Oct 21, 97 11:00:27 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > The DPT SmartRaid IV works well. The driver is not incorporated into > the base distribution, but you can get it for 2.2-stable and > freebsd-current. I also like this card, because unlike the Mylex cards, > additional channels can be added later via a daughtercard. The Compaq RAID SCSI controller has a driver available from the author; it has not been rolled into FreeBSD yet. Check the -hackers list archives for details and the email address of the author. 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-hackers Thu Oct 23 10:26:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA11949 for hackers-outgoing; Thu, 23 Oct 1997 10:26:01 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.5.83]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA11944 for ; Thu, 23 Oct 1997 10:25:59 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.7/8.8.7) id KAA00408; Thu, 23 Oct 1997 10:25:28 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp02.primenet.com, id smtpd000392; Thu Oct 23 10:25:25 1997 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id KAA25749; Thu, 23 Oct 1997 10:24:45 -0700 (MST) From: Terry Lambert Message-Id: <199710231724.KAA25749@usr02.primenet.com> Subject: Re: Possible SERIOUS bug in open()? To: thorpej@nas.nasa.gov Date: Thu, 23 Oct 1997 17:24:41 +0000 (GMT) Cc: jamil@trojanhorse.ml.org, joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199710220909.CAA13732@lestat.nas.nasa.gov> from "Jason Thorpe" at Oct 22, 97 02:09:44 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > How exactly did you fix it, this is related to what I was saying about > > opening a file as RD_ONLY and WR_ONLY, because if oflags = -1 then fflags > > = 0 and that means the file is not open for read or write which my point > > was that it should be forced to be open for one or the other. I don't > > rememer who, but someone seemed to think that it could be actually useful > > to hav a file not open for read or write > > How would opening for !read !write be useful? What else could you possibly > want to do? (Yes, this is a trick question :-) Hold a reference instance, but don't let your children have access to read or write the device (ie: things like /dev/io). Hold a reference instance to keep a Streams or similar stack instantiated, even though you personally don't use it, because whoever does has a tendency to crash and would otherwise take the stack with them and make it necessary to rebuild the thing. Call fcntl( fd, F_GETOWN, ...) Call fdopen(), allowing the fd to be there, but not accessable except through stdio updating the mode value Proxy locks for NFS server locking, and use the lack of FREAD|FWRITE to signal close(2) to override POSIX close/lock interaction semantics. Call poll(2) on a directory to see if anything was added to it or removed from it. Become the process group leader on a tty so you get the SIGHUP on ON-to-OFF DCD transition, but not do I/O (for example a session manager on a tty, used as a credential holder for non-UNIX credentials, for things like an SMB or NetWare client FS). For use on a directory by a user usable "mount" command, without giving full corresponding access to the user. There are a *lot* of reasons. 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-hackers Thu Oct 23 10:29:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA12266 for hackers-outgoing; Thu, 23 Oct 1997 10:29:44 -0700 (PDT) (envelope-from owner-freebsd-hackers) 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 KAA12257; Thu, 23 Oct 1997 10:29:41 -0700 (PDT) (envelope-from johnp@milo.lodgenet.com) Received: from garbo.lodgenet.com (garbo.lodgenet.com [204.124.122.252]) by freefall.freebsd.org (8.8.6/8.8.5) with SMTP id KAA28214; Thu, 23 Oct 1997 10:29:17 -0700 (PDT) Received: from milo.lodgenet.com (milo.lodgenet.com [10.0.122.42]) by garbo.lodgenet.com (8.6.12/8.6.9) with ESMTP id MAA06569; Thu, 23 Oct 1997 12:28:28 -0500 Received: from milo.lodgenet.com (localhost [127.0.0.1]) by milo.lodgenet.com (8.8.5/8.8.5) with ESMTP id MAA09336; Thu, 23 Oct 1997 12:28:58 -0500 (CDT) Message-Id: <199710231728.MAA09336@milo.lodgenet.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: hardware@freebsd.com, hackers@freebsd.com Subject: Digi Xem Reply-To: johnp@lodgenet.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 23 Oct 1997 12:28:58 -0500 From: John Prince Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I'v read a few threads regarding Digi's Xem Mulitport, and was still unsure. Do we have a driver that supports the Xem product? Thanks --John From owner-freebsd-hackers Thu Oct 23 10:31:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA12518 for hackers-outgoing; Thu, 23 Oct 1997 10:31:40 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA12513 for ; Thu, 23 Oct 1997 10:31:38 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.7/8.8.7) id KAA13531; Thu, 23 Oct 1997 10:31:32 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp04.primenet.com, id smtpd013522; Thu Oct 23 10:31:30 1997 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id KAA26108; Thu, 23 Oct 1997 10:31:03 -0700 (MST) From: Terry Lambert Message-Id: <199710231731.KAA26108@usr02.primenet.com> Subject: Re: Possible SERIOUS bug in open()? To: thorpej@nas.nasa.gov Date: Thu, 23 Oct 1997 17:31:02 +0000 (GMT) Cc: dk+@ua.net, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199710222030.NAA20863@lestat.nas.nasa.gov> from "Jason Thorpe" at Oct 22, 97 01:30:28 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > For ioctls that don't change the state of the device, you absolutely want > to have it open for reading. I.e. if you have a device that can expose > sensitive information by ioctl, and you set the mode to 600, you won't > want random people opening it via the neat little open hole and performing > that read-only ioctl. What if I want to have a CDROM not mounted, allow users to mount it, but not allow users to eject it? ...and at the same time, I have a different drive that I want to allow users to both mount and eject? I need to hold a reference. The "lock against eject" operation is a side effect of an existing reference forcing the count over 1 for the device in question. So the short answer is "to obtain reference side effects without granting read/write access on the descriptor". 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-hackers Thu Oct 23 10:46:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA13664 for hackers-outgoing; Thu, 23 Oct 1997 10:46:15 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA13659 for ; Thu, 23 Oct 1997 10:46:12 -0700 (PDT) (envelope-from jamil@trojanhorse.ml.org) Received: from localhost (jamil@localhost) by trojanhorse.ml.org (8.8.7/8.8.5) with SMTP id KAA02954; Thu, 23 Oct 1997 10:43:05 -0700 (PDT) Date: Thu, 23 Oct 1997 10:43:05 -0700 (PDT) From: "Jamil J. Weatherbee" To: Terry Lambert cc: thorpej@nas.nasa.gov, joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@FreeBSD.ORG Subject: Re: Possible SERIOUS bug in open()? (Holy Shit!!!) In-Reply-To: <199710231724.KAA25749@usr02.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Hold a reference instance, but don't let your children have access > to read or write the device (ie: things like /dev/io). Wrong! The following code allows the regular joe blow user to read and write to any port on the machine: (This is really bad) I've verified that outb() is actually writing. #include #include #include #include #include int main(int argc, char **argv) { int fd; fd = open("/dev/io", -1, 0); if (fd < 0) err(1, "open"); outb (0x253,0x80); outb (0x250,0xAA); } From owner-freebsd-hackers Thu Oct 23 10:54:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA14334 for hackers-outgoing; Thu, 23 Oct 1997 10:54:18 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA14313 for ; Thu, 23 Oct 1997 10:54:11 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.7/8.8.7) id KAA00365; Thu, 23 Oct 1997 10:54:09 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp03.primenet.com, id smtpd000359; Thu Oct 23 10:54:07 1997 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id KAA27570; Thu, 23 Oct 1997 10:54:06 -0700 (MST) From: Terry Lambert Message-Id: <199710231754.KAA27570@usr02.primenet.com> Subject: Re: zipfs filesystem anyone ? To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Thu, 23 Oct 1997 17:54:06 +0000 (GMT) Cc: hackers@FreeBSD.ORG In-Reply-To: <199710230638.HAA26030@labinfo.iet.unipi.it> from "Luigi Rizzo" at Oct 23, 97 07:38:26 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Thus, I was looking at something which would pass all filesystem > (or vn ?) calls to some user-space process which could then handle > them properly. Using this approach, little modifications to, say, > a standard "unzip" program, would permit such a filesystem to be > implemented relatively easily. Efficiency is not a major concern > for this type of application (especially because the typical use > would be sequential access to files). The VFS interface is not reflexive. Namei would expect your user space code to free your path buffer allocated in the kernel. Also you would have to externalize the lockmgr interface, and alias vnodes in and out of the kernel, instead of treating them as opaque and using a user space pointer in the data pointer. Etc.. Why do you think I go on and on about the VFS layering? It's not because I'm an idiot, despite what some people think... You could do one, but you will have to externalize a hell of a lot of code, and provide proxy allocation and freeing mechanisms for every place that is non-reflexive. I have a device based FS gate for user space FS's, but it assumes all of my FS changes, and is about 3 months out of sync with -current 8-(. A better alternative for now might be to build a user space NFS server at an alternate port (this is what the amd code does; you should look at it, and "cryptofs" [comp.unix.sources] for more information). 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-hackers Thu Oct 23 10:56:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA14533 for hackers-outgoing; Thu, 23 Oct 1997 10:56:19 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.5.83]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA14523 for ; Thu, 23 Oct 1997 10:56:15 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.7/8.8.7) id KAA03717; Thu, 23 Oct 1997 10:56:08 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp02.primenet.com, id smtpd003690; Thu Oct 23 10:55:58 1997 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id KAA27624; Thu, 23 Oct 1997 10:55:57 -0700 (MST) From: Terry Lambert Message-Id: <199710231755.KAA27624@usr02.primenet.com> Subject: Re: ACLs [Was: C2 Trusted FreeBSD?] To: joerg_wunsch@uriah.heep.sax.de Date: Thu, 23 Oct 1997 17:55:57 +0000 (GMT) Cc: hackers@FreeBSD.ORG In-Reply-To: <19971023092847.TP39265@uriah.heep.sax.de> from "J Wunsch" at Oct 23, 97 09:28:47 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Yes, but how do you back them up, or, worse yet, restore them? How do > > you copy your HTML directory tree to another drive you're bringing > > on-line and preserve all the ACL settings? As noted before, *none* > > of the system tools support the ACLs. > > I think you could make compatible changes to dump and restore to > support ACLs. Perhaps, drop a second record containing the ACLs right > behind an inode record (or even before, so the restore program knows > about the intended ACLs before actually even seeing the inode > information). The unknown records should simply be ignored by a > restore that doesn't understand them. If it's a stacking layer that uses a name space excape and uses a real file in the underlying FS for the ACL's, then the answer is simple: back up the underlying FS instead of the top layer of the stack. 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-hackers Thu Oct 23 10:56:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA14577 for hackers-outgoing; Thu, 23 Oct 1997 10:56:38 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA14566 for ; Thu, 23 Oct 1997 10:56:31 -0700 (PDT) (envelope-from jamil@trojanhorse.ml.org) Received: from localhost (jamil@localhost) by trojanhorse.ml.org (8.8.7/8.8.5) with SMTP id KAA03041; Thu, 23 Oct 1997 10:54:25 -0700 (PDT) Date: Thu, 23 Oct 1997 10:54:24 -0700 (PDT) From: "Jamil J. Weatherbee" To: Terry Lambert cc: thorpej@nas.nasa.gov, joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@FreeBSD.ORG Subject: Re: Possible SERIOUS bug in open()? (Big time bug) In-Reply-To: <199710231724.KAA25749@usr02.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Yep, tried reading an ioport on my service providers freebsd machine, works fine. /dev/io is probably not the first and probably won't be the last driver with this problem, in other works force to F_READ or F_WRITE. That is precisely what I did in my dio driver because I depend on F_WRITE and/or F_READ to be set to tell me about what the user wants. From owner-freebsd-hackers Thu Oct 23 10:58:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA14711 for hackers-outgoing; Thu, 23 Oct 1997 10:58:15 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA14705 for ; Thu, 23 Oct 1997 10:58:14 -0700 (PDT) (envelope-from thorpej@lestat.nas.nasa.gov) Received: from localhost (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.7/8.6.12) with SMTP id KAA04569; Thu, 23 Oct 1997 10:56:21 -0700 (PDT) Message-Id: <199710231756.KAA04569@lestat.nas.nasa.gov> X-Authentication-Warning: lestat.nas.nasa.gov: localhost [127.0.0.1] didn't use HELO protocol To: Terry Lambert Cc: dk+@ua.net, freebsd-hackers@freebsd.org Subject: Re: Possible SERIOUS bug in open()? Reply-To: Jason Thorpe From: Jason Thorpe Date: Thu, 23 Oct 1997 10:56:17 -0700 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 23 Oct 1997 17:31:02 +0000 (GMT) Terry Lambert wrote: > I need to hold a reference. The "lock against eject" operation is > a side effect of an existing reference forcing the count over 1 for > the device in question. > > So the short answer is "to obtain reference side effects without > granting read/write access on the descriptor". I think "open for not read not write" is a silly way to do this, personally. If you want to add/delete "artificial references", then invent a real interface for it, don't use a hack like open with non-sensical flags. Jason R. Thorpe thorpej@nas.nasa.gov NASA Ames Research Center Home: +1 408 866 1912 NAS: M/S 258-6 Work: +1 415 604 0935 Moffett Field, CA 94035 Pager: +1 415 428 6939 From owner-freebsd-hackers Thu Oct 23 11:03:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA15092 for hackers-outgoing; Thu, 23 Oct 1997 11:03:48 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA15085 for ; Thu, 23 Oct 1997 11:03:43 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.7/8.8.7) id LAA15386; Thu, 23 Oct 1997 11:03:31 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp04.primenet.com, id smtpd015372; Thu Oct 23 11:03:27 1997 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id LAA28022; Thu, 23 Oct 1997 11:03:19 -0700 (MST) From: Terry Lambert Message-Id: <199710231803.LAA28022@usr02.primenet.com> Subject: Re: Broken device LKM in 2.2 To: mike@smith.net.au (Mike Smith) Date: Thu, 23 Oct 1997 18:03:19 +0000 (GMT) Cc: archie@whistle.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199710231448.AAA00606@word.smith.net.au> from "Mike Smith" at Oct 24, 97 00:18:51 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I guess nobody makes device type LKM's in 2.2.. but sys/lkm.h is > > broken with respect to them. Here's a hack that fixes this. Perhaps > > the "name ## _module", which is different from the other module > > types, is there for some reason (?) > > IIRC it's there to avoid symbol conflicts with statically loaded > versions. Could be wrong of course; there's nothing in the CVS log. > > > Anyway, it's incompatible with the DISPATCH macro defined later in > > the file, and this fixes it... > > Has anyone looked at this? Should we buy it? You want the uniquifier. Think "disk device". A disk device LKM will want to define both a character and a block interface. To do so would result in a symbol conflict without the uniquifier. You could consider any multiheaded device in the same light; for example (bad example, I know... just let me get away with it) a Streams module that was monolithic, but defined /dev/ip, /dev/tdp, i/dev/icmp, and /dev/udp, seperately (to avoid getmsg/putmsg boundry crossing internally adding a scheduling latency per stack element boundry transition). 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-hackers Thu Oct 23 11:05:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA15262 for hackers-outgoing; Thu, 23 Oct 1997 11:05:57 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA15241 for ; Thu, 23 Oct 1997 11:05:51 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.7/8.8.7) id LAA15566; Thu, 23 Oct 1997 11:05:40 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp04.primenet.com, id smtpd015530; Thu Oct 23 11:05:30 1997 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id LAA28160; Thu, 23 Oct 1997 11:05:18 -0700 (MST) From: Terry Lambert Message-Id: <199710231805.LAA28160@usr02.primenet.com> Subject: Re: CHILD_MAX no longer valid in 2.2.5-RELEASE? To: ghelmer@cs.iastate.edu (Guy Helmer) Date: Thu, 23 Oct 1997 18:05:17 +0000 (GMT) Cc: henrich@crh.cl.msu.edu, freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Guy Helmer" at Oct 23, 97 08:54:44 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I've send CHILD_MAX to 512 on my news server, which (used) to have the > > effect of making the default maximum procs set to 512.. Bonus. Under > > 2.2.5-RELEASE it doesnt appear to be having any effect :( The only > > thing I can think of is, its placement in the config file is order > > important, or its no longer supported? If the latter, how do you > > effect the same change in 2.2.5? > > init uses the "daemon" entry in /etc/login.conf to set process resource > limits before executing /etc/rc; it appears to me that the "maxproc" entry > (maxproc=256) is the one you need to adjust (see also login.conf(5) and > getcap(3)). Out of curiosity, what is the function of establishing a limit on rc itself, as opposed to only the things rc runs? 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-hackers Thu Oct 23 11:08:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA15427 for hackers-outgoing; Thu, 23 Oct 1997 11:08:52 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA15422 for ; Thu, 23 Oct 1997 11:08:50 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.7/8.8.7) id LAA15746; Thu, 23 Oct 1997 11:08:50 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp04.primenet.com, id smtpd015739; Thu Oct 23 11:08:44 1997 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id LAA28324; Thu, 23 Oct 1997 11:08:40 -0700 (MST) From: Terry Lambert Message-Id: <199710231808.LAA28324@usr02.primenet.com> Subject: Re: Possible SERIOUS bug in open()? To: thorpej@nas.nasa.gov Date: Thu, 23 Oct 1997 18:08:40 +0000 (GMT) Cc: tlambert@primenet.com, dk+@ua.net, freebsd-hackers@freebsd.org In-Reply-To: <199710231756.KAA04569@lestat.nas.nasa.gov> from "Jason Thorpe" at Oct 23, 97 10:56:17 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I need to hold a reference. The "lock against eject" operation is > > a side effect of an existing reference forcing the count over 1 for > > the device in question. > > > > So the short answer is "to obtain reference side effects without > > granting read/write access on the descriptor". > > I think "open for not read not write" is a silly way to do this, personally. > > If you want to add/delete "artificial references", then invent a real > interface for it, don't use a hack like open with non-sensical flags. By this logic, locking should be implemented via a system call instead of a hack like fcntl(). 8-(. 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-hackers Thu Oct 23 11:15:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA15796 for hackers-outgoing; Thu, 23 Oct 1997 11:15:24 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA15780 for ; Thu, 23 Oct 1997 11:15:14 -0700 (PDT) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id LAA21430; Thu, 23 Oct 1997 11:13:00 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd021424; Thu Oct 23 18:12:50 1997 Date: Thu, 23 Oct 1997 11:11:16 -0700 (PDT) From: Julian Elischer To: Mike Smith cc: Archie Cobbs , freebsd-hackers@FreeBSD.ORG Subject: Re: Broken device LKM in 2.2 In-Reply-To: <199710231448.AAA00606@word.smith.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk well it works with this change and doesn't even compile without it.. terry (who originaly wrote it) works here now, and blessed it.. and I can't see a problem.. how much do you need? I'm planning on committing it myself unless someone gets to it first. julian On Fri, 24 Oct 1997, Mike Smith wrote: > > > > I guess nobody makes device type LKM's in 2.2.. but sys/lkm.h is > > broken with respect to them. Here's a hack that fixes this. Perhaps > > the "name ## _module", which is different from the other module > > types, is there for some reason (?) > > IIRC it's there to avoid symbol conflicts with statically loaded > versions. Could be wrong of course; there's nothing in the CVS log. > > > Anyway, it's incompatible with the DISPATCH macro defined later in > > the file, and this fixes it... > > Has anyone looked at this? Should we buy it? > > mike > > > From owner-freebsd-hackers Thu Oct 23 11:35:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA17251 for hackers-outgoing; Thu, 23 Oct 1997 11:35:10 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from iafnl.es.iaf.nl (uucp@iafnl.es.iaf.nl [195.108.17.20]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id LAA17240 for ; Thu, 23 Oct 1997 11:35:06 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: by iafnl.es.iaf.nl with UUCP id AA15654 (5.67b/IDA-1.5 for freebsd-hackers@FreeBSD.ORG); Thu, 23 Oct 1997 20:35:19 +0200 Received: (from wilko@localhost) by yedi.iaf.nl (8.8.5/8.6.12) id TAA02672; Thu, 23 Oct 1997 19:30:15 +0100 (MET) From: Wilko Bulte Message-Id: <199710231830.TAA02672@yedi.iaf.nl> Subject: Re: DLT drives To: joerg_wunsch@uriah.heep.sax.de Date: Thu, 23 Oct 1997 19:30:15 +0100 (MET) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <19971023001841.RF25584@uriah.heep.sax.de> from "J Wunsch" at Oct 23, 97 00:18:41 am X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-Pgp-Info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4 PL24 ME8a] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As J Wunsch wrote... > As Wilko Bulte wrote: > > > Check out http://www.quantum.com There are something like 5 or so > > firmware personalities, e.g. also one that pretends to be an Exabyte. > > Oh, i hope it doesn't jam the cassette as often as Exabytes tend to > do. :-] Fortunately not. You could speak of a split personality in this case. _ ____________________________________________________________________ | / o / / _ Bulte email: wilko@yedi.iaf.nl http://www.tcja.nl/~wilko |/|/ / / /( (_) Arnhem, The Netherlands - Do, or do not. There is no 'try' ------------------ Support your local daemons: run FreeBSD Unix -----Yoda From owner-freebsd-hackers Thu Oct 23 12:07:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA19628 for hackers-outgoing; Thu, 23 Oct 1997 12:07:25 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from garbo.lodgenet.com (garbo.lodgenet.com [204.124.122.252]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id MAA19574; Thu, 23 Oct 1997 12:07:10 -0700 (PDT) (envelope-from johnp@milo.lodgenet.com) Received: from milo.lodgenet.com (milo.lodgenet.com [10.0.122.42]) by garbo.lodgenet.com (8.6.12/8.6.9) with ESMTP id OAA08574; Thu, 23 Oct 1997 14:05:59 -0500 Received: from milo.lodgenet.com (localhost [127.0.0.1]) by milo.lodgenet.com (8.8.5/8.8.5) with ESMTP id OAA10694; Thu, 23 Oct 1997 14:06:36 -0500 (CDT) Message-Id: <199710231906.OAA10694@milo.lodgenet.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: hardware@freebsd.org, hackers@freebsd.org Subject: Digi Xem Reply-To: johnp@lodgenet.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 23 Oct 1997 14:06:36 -0500 From: John Prince Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'v read a few threads regarding Digi's Xem Mulitport, and was still unsure. Do we have a driver that supports the Xem product? Thanks --John From owner-freebsd-hackers Thu Oct 23 12:13:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA20238 for hackers-outgoing; Thu, 23 Oct 1997 12:13:35 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from citrine.cyberstation.net (hannibal@citrine.cyberstation.net [205.167.0.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA20223 for ; Thu, 23 Oct 1997 12:13:31 -0700 (PDT) (envelope-from hannibal@cyberstation.net) Received: from localhost (hannibal@localhost) by citrine.cyberstation.net (8.8.7/8.8.7) with SMTP id OAA05128; Thu, 23 Oct 1997 14:13:19 -0500 (CDT) Date: Thu, 23 Oct 1997 14:13:19 -0500 (CDT) From: Dan Walters To: Mike Smith cc: hackers@freebsd.org Subject: Re: ATAPI CD-RW documentation... In-Reply-To: <199710231539.BAA00881@word.smith.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 24 Oct 1997, Mike Smith wrote: > > Never mind, it's amazing how you always find things right after you give > > up and ask. :) For anyone wondering, the motherload of specs can be > > found by ftp at fission.dt.wdc.com, including the working draft of the > > ATAPI Removable Rewritable Specification, SFF-8070. Wish their web pages > > would mention the site. :) > > Thanks for finding the number for me; I ran out of patience downloading > them, struggling to print them and giving up 8) It may be SFF-8080 though - I thought 8070 was it, but after reading the intro it sounded more like something for the new floppy drives... 8080 is clearly CD-RW. > Nobody's begun any work, as such. Again, I exhort you to look at > Justin Gibbs' CAM framework; it is the future of mass storage > interfaces in FreeBSD, and we should be looking towards it. Already downloaded it, just havn't had the chance to look at any of it yet. I take it that going the CAM route would be a completely different approach than writing an ATAPI sub-driver? ====================================================================== Dan Walters hannibal@cyberstation.net ====================================================================== From owner-freebsd-hackers Thu Oct 23 12:20:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA20906 for hackers-outgoing; Thu, 23 Oct 1997 12:20:55 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id MAA20899 for ; Thu, 23 Oct 1997 12:20:50 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id VAA14825 for freebsd-hackers@FreeBSD.ORG; Thu, 23 Oct 1997 21:20:39 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id VAA05710; Thu, 23 Oct 1997 21:17:57 +0200 (MET DST) Message-ID: <19971023211757.IO46198@uriah.heep.sax.de> Date: Thu, 23 Oct 1997 21:17:57 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG Subject: Re: page fault References: <199710231647.LAA04258@elvis.mu.org> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199710231647.LAA04258@elvis.mu.org>; from Paul Saab on Oct 23, 1997 11:47:07 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Paul Saab wrote: > Ok.. here is what I got... Hmm, Paul also sent it via private mail, and i've answered this before. -- 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-hackers Thu Oct 23 12:36:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA21798 for hackers-outgoing; Thu, 23 Oct 1997 12:36:00 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA21780 for ; Thu, 23 Oct 1997 12:35:57 -0700 (PDT) (envelope-from nate@rocky.mt.sri.com) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id NAA11547; Thu, 23 Oct 1997 13:35:27 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id NAA16573; Thu, 23 Oct 1997 13:35:27 -0600 (MDT) Date: Thu, 23 Oct 1997 13:35:27 -0600 (MDT) Message-Id: <199710231935.NAA16573@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Terry Lambert Cc: luigi@labinfo.iet.unipi.it (Luigi Rizzo), hackers@freebsd.org Subject: Re: zipfs filesystem anyone ? In-Reply-To: <199710231754.KAA27570@usr02.primenet.com> References: <199710230638.HAA26030@labinfo.iet.unipi.it> <199710231754.KAA27570@usr02.primenet.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Terry Lambert writes: > > Thus, I was looking at something which would pass all filesystem > > (or vn ?) calls to some user-space process which could then handle > > them properly. Using this approach, little modifications to, say, > > a standard "unzip" program, would permit such a filesystem to be > > implemented relatively easily. Efficiency is not a major concern > > for this type of application (especially because the typical use > > would be sequential access to files). > > The VFS interface is not reflexive. Forgive me, but does that mean that the interface doesn't jerk when you hit it in the knee? *grin* Nate From owner-freebsd-hackers Thu Oct 23 13:04:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA23775 for hackers-outgoing; Thu, 23 Oct 1997 13:04:52 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from unix.tfs.net (root@unix.tfs.net [199.79.146.60]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA23759 for ; Thu, 23 Oct 1997 13:04:44 -0700 (PDT) (envelope-from jbryant@argus.tfs.net) Received: from argus.tfs.net (pm3-p42.tfs.net [206.154.183.234]) by unix.tfs.net (8.8.5/8.8.5) with ESMTP id PAA01600; Thu, 23 Oct 1997 15:03:52 -0500 Received: (from jbryant@localhost) by argus.tfs.net (8.8.7/8.8.5) id PAA15951; Thu, 23 Oct 1997 15:04:34 -0500 (CDT) From: Jim Bryant Message-Id: <199710232004.PAA15951@argus.tfs.net> Subject: Re: CHILD_MAX no longer valid in 2.2.5-RELEASE? In-Reply-To: <199710231805.LAA28160@usr02.primenet.com> from Terry Lambert at "Oct 23, 97 06:05:17 pm" To: tlambert@primenet.com (Terry Lambert) Date: Thu, 23 Oct 1997 15:04:33 -0500 (CDT) Cc: freebsd-hackers@freebsd.org Reply-to: jbryant@tfs.net X-Windows: R00LZ!@# MS-Winbl0wz DR00LZ!@# X-Operating-System: FreeBSD 2.2.2-RELEASE #0: Wed Jul 9 01:01:24 CDT 1997 X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In reply: > Out of curiosity, what is the function of establishing a limit on rc > itself, as opposed to only the things rc runs? root's login.conf??? jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" ------------------------------------------------------------------------------ Inet: jbryant@tfs.net AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28pw voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant ------------------------------------------------------------------------------ HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ From owner-freebsd-hackers Thu Oct 23 13:46:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA26414 for hackers-outgoing; Thu, 23 Oct 1997 13:46:17 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from elvis.mu.org (elvis.mu.org [206.156.231.253]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA26404 for ; Thu, 23 Oct 1997 13:46:13 -0700 (PDT) (envelope-from paul@elvis.mu.org) Received: (from paul@localhost) by elvis.mu.org (8.8.7/8.8.7) id PAA13423 for freebsd-hackers@FreeBSD.ORG; Thu, 23 Oct 1997 15:46:10 -0500 (CDT) (envelope-from paul) From: Paul Saab Message-Id: <199710232046.PAA13423@elvis.mu.org> Subject: Re: page fault In-Reply-To: <19971023211757.IO46198@uriah.heep.sax.de> from J Wunsch at "Oct 23, 97 09:17:57 pm" To: freebsd-hackers@FreeBSD.ORG Date: Thu, 23 Oct 1997 15:46:10 -0500 (CDT) X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk sorry about that.. I hit the wrong button when replying. paul J Wunsch wrote: > As Paul Saab wrote: > > > Ok.. here is what I got... > > Hmm, Paul also sent it via private mail, and i've answered this > before. > > -- > 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-hackers Thu Oct 23 14:11:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA28237 for hackers-outgoing; Thu, 23 Oct 1997 14:11:47 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from hda.hda.com (hda-bicnet.bicnet.net [208.220.66.37]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA28231 for ; Thu, 23 Oct 1997 14:11:43 -0700 (PDT) (envelope-from dufault@hda.hda.com) Received: (from dufault@localhost) by hda.hda.com (8.8.5/8.8.5) id QAA12714; Thu, 23 Oct 1997 16:21:40 -0400 (EDT) From: Peter Dufault Message-Id: <199710232021.QAA12714@hda.hda.com> Subject: Re: Broken device LKM in 2.2 In-Reply-To: from Julian Elischer at "Oct 23, 97 11:11:16 am" To: julian@whistle.com (Julian Elischer) Date: Thu, 23 Oct 1997 16:21:39 -0400 (EDT) Cc: mike@smith.net.au, archie@whistle.com, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > well it works with this change and doesn't even compile without it.. > terry (who originaly wrote it) works here now, and blessed it.. > and I can't see a problem.. > how much do you need? > I'm planning on committing it myself unless someone gets to it first. Something like this was broken in -current and I kicked it, look there to see if we're talking the same thing. I don't have source here so I can't help right now. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval From owner-freebsd-hackers Thu Oct 23 14:29:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA29110 for hackers-outgoing; Thu, 23 Oct 1997 14:29:17 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA29105 for ; Thu, 23 Oct 1997 14:29:15 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.7/8.8.7) id OAA12707; Thu, 23 Oct 1997 14:29:00 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpd012699; Thu Oct 23 14:28:58 1997 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id OAA06900; Thu, 23 Oct 1997 14:28:51 -0700 (MST) From: Terry Lambert Message-Id: <199710232128.OAA06900@usr05.primenet.com> Subject: Re: Possible SERIOUS bug in open()? (Big time bug) To: jamil@trojanhorse.ml.org (Jamil J. Weatherbee) Date: Thu, 23 Oct 1997 21:28:51 +0000 (GMT) Cc: tlambert@primenet.com, thorpej@nas.nasa.gov, joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Jamil J. Weatherbee" at Oct 23, 97 10:54:24 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Yep, tried reading an ioport on my service providers freebsd machine, > works fine. /dev/io is probably not the first and probably won't be the > last driver with this problem, in other works force to F_READ or F_WRITE. > That is precisely what I did in my dio driver because I depend on F_WRITE > and/or F_READ to be set to tell me about what the user wants. I agree; this is a driver issue; the driver should enforce permissions when the user attempts the outb. 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-hackers Thu Oct 23 14:40:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA29739 for hackers-outgoing; Thu, 23 Oct 1997 14:40:59 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA29725 for ; Thu, 23 Oct 1997 14:40:31 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.7/8.8.7) id OAA27908; Thu, 23 Oct 1997 14:40:18 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp04.primenet.com, id smtpd027906; Thu Oct 23 14:40:13 1997 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id OAA07475; Thu, 23 Oct 1997 14:40:10 -0700 (MST) From: Terry Lambert Message-Id: <199710232140.OAA07475@usr05.primenet.com> Subject: Re: CHILD_MAX no longer valid in 2.2.5-RELEASE? To: jbryant@tfs.net Date: Thu, 23 Oct 1997 21:40:10 +0000 (GMT) Cc: tlambert@primenet.com, freebsd-hackers@freebsd.org In-Reply-To: <199710232004.PAA15951@argus.tfs.net> from "Jim Bryant" at Oct 23, 97 03:04:33 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Out of curiosity, what is the function of establishing a limit on rc > > itself, as opposed to only the things rc runs? > > root's login.conf??? If I'm root, I should be able to shoot myself in the foot if I want to. I understand the denial of service aspects for non-root users shooting each other in the foot, and the daemon aspects as regards daemons that malfunction. But root has a moral obligation to let me aim at my foot. So I'd still like to know the function of establishing a limit on rc itself... 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-hackers Thu Oct 23 14:46:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA29941 for hackers-outgoing; Thu, 23 Oct 1997 14:46:20 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA29933 for ; Thu, 23 Oct 1997 14:46:10 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.7/8.8.7) id OAA14604; Thu, 23 Oct 1997 14:46:00 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpd014599; Thu Oct 23 14:45:56 1997 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id OAA07834; Thu, 23 Oct 1997 14:45:46 -0700 (MST) From: Terry Lambert Message-Id: <199710232145.OAA07834@usr05.primenet.com> Subject: Re: zipfs filesystem anyone ? To: nate@mt.sri.com (Nate Williams) Date: Thu, 23 Oct 1997 21:45:46 +0000 (GMT) Cc: tlambert@primenet.com, luigi@labinfo.iet.unipi.it, hackers@FreeBSD.ORG In-Reply-To: <199710231935.NAA16573@rocky.mt.sri.com> from "Nate Williams" at Oct 23, 97 01:35:27 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > The VFS interface is not reflexive. > > Forgive me, but does that mean that the interface doesn't jerk when you > hit it in the knee? *grin* No, it's a term from computer science, not medicine. It means that there are side effects to the interface, and that the caller is dependent on the side effects. It's very difficult to proxy a side effect across a procedural only interface (like corssing the user/kernel boundry). 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-hackers Thu Oct 23 14:53:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA00506 for hackers-outgoing; Thu, 23 Oct 1997 14:53:29 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from garbo.lodgenet.com (garbo.lodgenet.com [204.124.122.252]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id OAA00480; Thu, 23 Oct 1997 14:53:22 -0700 (PDT) (envelope-from johnp@milo.lodgenet.com) Received: from milo.lodgenet.com (milo.lodgenet.com [10.0.122.42]) by garbo.lodgenet.com (8.6.12/8.6.9) with ESMTP id QAA13779; Thu, 23 Oct 1997 16:52:13 -0500 Received: from milo.lodgenet.com (localhost [127.0.0.1]) by milo.lodgenet.com (8.8.5/8.8.5) with ESMTP id QAA13502; Thu, 23 Oct 1997 16:52:50 -0500 (CDT) Message-Id: <199710232152.QAA13502@milo.lodgenet.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: hardware@freebsd.org, hackers@freebsd.org Reply-To: johnp@lodgenet.com Mime-Version: 1.0 Content-Type: text/plain Date: Thu, 23 Oct 1997 16:52:50 -0500 From: John Prince Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'v read a few threads regarding Digi's Xem Mulitport, and was still unsure. Do we have a driver that supports the Xem product? Thanks --John From owner-freebsd-hackers Thu Oct 23 15:08:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA01420 for hackers-outgoing; Thu, 23 Oct 1997 15:08:06 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA01411 for ; Thu, 23 Oct 1997 15:08:02 -0700 (PDT) (envelope-from jamil@trojanhorse.ml.org) Received: from localhost (jamil@localhost) by trojanhorse.ml.org (8.8.7/8.8.5) with SMTP id PAA03543; Thu, 23 Oct 1997 15:06:23 -0700 (PDT) Date: Thu, 23 Oct 1997 15:06:23 -0700 (PDT) From: "Jamil J. Weatherbee" To: Terry Lambert cc: thorpej@nas.nasa.gov, joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@FreeBSD.ORG Subject: Re: Possible SERIOUS bug in open()? (Big time bug) In-Reply-To: <199710232128.OAA06900@usr05.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 23 Oct 1997, Terry Lambert wrote: > > Yep, tried reading an ioport on my service providers freebsd machine, > > works fine. /dev/io is probably not the first and probably won't be the > > last driver with this problem, in other works force to F_READ or F_WRITE. > > That is precisely what I did in my dio driver because I depend on F_WRITE > > and/or F_READ to be set to tell me about what the user wants. > > I agree; this is a driver issue; the driver should enforce permissions > when the user attempts the outb. No, the user open() should return error for somebody trying to open for not read and not write. /dev/io gives the process IOPL on the basis that it is able to open /dev/io, not do operations on it. I think it is perfectly reasonable for the driver to expect its open method called only if the user has permissions on the file. When you start putting the responsibility on the driver for maintaining the security of the system and not the kernel then your'e just asking for trouble. Much like most drivers do not check to see if the device being passed is valid once it is opened because it should always be valid (under most circumstances). > > > 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-hackers Thu Oct 23 15:11:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA01611 for hackers-outgoing; Thu, 23 Oct 1997 15:11:53 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA01604 for ; Thu, 23 Oct 1997 15:11:49 -0700 (PDT) (envelope-from nate@rocky.mt.sri.com) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id QAA12560; Thu, 23 Oct 1997 16:11:29 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id QAA17154; Thu, 23 Oct 1997 16:11:28 -0600 (MDT) Date: Thu, 23 Oct 1997 16:11:28 -0600 (MDT) Message-Id: <199710232211.QAA17154@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Terry Lambert Cc: nate@mt.sri.com (Nate Williams), luigi@labinfo.iet.unipi.it, hackers@freebsd.org Subject: Re: zipfs filesystem anyone ? In-Reply-To: <199710232145.OAA07834@usr05.primenet.com> References: <199710231935.NAA16573@rocky.mt.sri.com> <199710232145.OAA07834@usr05.primenet.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > The VFS interface is not reflexive. > > > > Forgive me, but does that mean that the interface doesn't jerk when you > > hit it in the knee? *grin* > > No, it's a term from computer science, not medicine. Never heard it in any of my classes. > It means that there are side effects to the interface, and that the > caller is dependent on the side effects. Kind of like strdup(3)? *grin* Nate From owner-freebsd-hackers Thu Oct 23 15:30:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA02515 for hackers-outgoing; Thu, 23 Oct 1997 15:30:34 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id PAA02510 for ; Thu, 23 Oct 1997 15:30:30 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id AAA17278 for freebsd-hackers@FreeBSD.ORG; Fri, 24 Oct 1997 00:30:22 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id AAA07220; Fri, 24 Oct 1997 00:24:51 +0200 (MET DST) Message-ID: <19971024002450.UZ51487@uriah.heep.sax.de> Date: Fri, 24 Oct 1997 00:24:50 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG Subject: Re: Possible SERIOUS bug in open()? (Big time bug) References: <199710232128.OAA06900@usr05.primenet.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: freebsd-hackers@FreeBSD.ORG In-Reply-To: ; from Jamil J. Weatherbee on Oct 23, 1997 15:06:23 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Jamil J. Weatherbee wrote: > No, the user open() should return error for somebody trying to open for > not read and not write. It does (now). Why the h*ck are you both still arguing about it? For me (being in MET DST timezone), it's already a matter of yesterday... -- 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-hackers Thu Oct 23 17:54:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA09874 for hackers-outgoing; Thu, 23 Oct 1997 17:54:18 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA09863 for ; Thu, 23 Oct 1997 17:54:15 -0700 (PDT) (envelope-from mrcpu@cdsnet.net) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by mail.cdsnet.net (8.8.6/8.8.6) with SMTP id RAA10950 for ; Thu, 23 Oct 1997 17:54:13 -0700 (PDT) Date: Thu, 23 Oct 1997 17:54:13 -0700 (PDT) From: Jaye Mathisen To: hackers@freebsd.org Subject: Weird CVSUP messages. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I cvsup -current about 2-3 times a week on average. So why now am I getting delta's dated back in 1994? Should I be worried? Edit src/usr.sbin/timed/timedc/cmdtab.c Add delta 1.1 94.05.26.05.23.25 rgrimes Add delta 1.2 97.10.22.06.20.04 charnier Edit src/usr.sbin/timed/timedc/timedc.8 Add delta 1.4 97.10.22.06.20.04 charnier Edit src/usr.sbin/timed/timedc/timedc.c Add delta 1.1 94.05.26.05.23.25 rgrimes Add delta 1.2 97.10.22.06.20.04 charnier From owner-freebsd-hackers Thu Oct 23 19:25:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA14009 for hackers-outgoing; Thu, 23 Oct 1997 19:25:09 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (word.smith.net.au [202.0.75.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA14004 for ; Thu, 23 Oct 1997 19:25:05 -0700 (PDT) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id LAA00498; Fri, 24 Oct 1997 11:51:29 +0930 (CST) Message-Id: <199710240221.LAA00498@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Dan Walters cc: Mike Smith , hackers@freebsd.org Subject: Re: ATAPI CD-RW documentation... In-reply-to: Your message of "Thu, 23 Oct 1997 14:13:19 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 24 Oct 1997 11:51:29 +0930 From: Mike Smith Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > > Nobody's begun any work, as such. Again, I exhort you to look at > > Justin Gibbs' CAM framework; it is the future of mass storage > > interfaces in FreeBSD, and we should be looking towards it. > > Already downloaded it, just havn't had the chance to look at any of it > yet. I take it that going the CAM route would be a completely different > approach than writing an ATAPI sub-driver? Yes. Aside from the fact that the code would have a much longer life, adding the requisite ATAPI parts to the CAM framework would automatically buy you CD-RW, IDE tape and ATAPI disk support, modulo a little more work. mike From owner-freebsd-hackers Thu Oct 23 19:26:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA14106 for hackers-outgoing; Thu, 23 Oct 1997 19:26:56 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA14101 for ; Thu, 23 Oct 1997 19:26:53 -0700 (PDT) (envelope-from michaelh@cet.co.jp) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.5/CET-v2.1) with SMTP id CAA18094; Fri, 24 Oct 1997 02:26:00 GMT Date: Fri, 24 Oct 1997 11:25:59 +0900 (JST) From: Michael Hancock To: Terry Lambert cc: Luigi Rizzo , hackers@FreeBSD.ORG Subject: Re: zipfs filesystem anyone ? In-Reply-To: <199710231754.KAA27570@usr02.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 23 Oct 1997, Terry Lambert wrote: > The VFS interface is not reflexive. Namei would expect your user > space code to free your path buffer allocated in the kernel. Also > you would have to externalize the lockmgr interface, and alias vnodes > in and out of the kernel, instead of treating them as opaque and using > a user space pointer in the data pointer. Etc.. [..] > You could do one, but you will have to externalize a hell of a lot > of code, and provide proxy allocation and freeing mechanisms for > every place that is non-reflexive. [..] > A better alternative for now might be to build a user space NFS server > at an alternate port (this is what the amd code does; you should look > at it, and "cryptofs" [comp.unix.sources] for more information). Wouldn't you have to externalize a lot of stuff anyway? We'd need some extra syscalls along the lines of John Heidemann's ook* (Out Of Kernel) stuff. You can make a fs specific call that serves as a general interface to marshall fs related operations in and out of the kernel. Then you can make a semantic-free user layer. It seems that a lot of NFS related work these days have to do with adding state. I was looking at this a few months ago after John H. released his layering code. It also seems that Poul and John Dyson have started cleaning up some fs related interface and memory issues, but I haven't had time to examine all the details. Regards, Mike Hancock > > 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-hackers Thu Oct 23 19:58:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA15785 for hackers-outgoing; Thu, 23 Oct 1997 19:58:13 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from bugs.us.dell.com (bugs.us.dell.com [143.166.169.147]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id TAA15724 for ; Thu, 23 Oct 1997 19:57:45 -0700 (PDT) (envelope-from tony@dell.com) Received: from moth.us.dell.com (moth.us.dell.com [143.166.169.152]) by bugs.us.dell.com (8.6.12/8.6.12) with SMTP id VAA10425 for ; Thu, 23 Oct 1997 21:57:06 -0500 Message-Id: <3.0.3.32.19971023215701.006dc4b0@bugs.us.dell.com> X-Sender: tony@bugs.us.dell.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Thu, 23 Oct 1997 21:57:01 -0500 To: hackers@FreeBSD.ORG From: Tony Overfield Subject: fixes for syscons.c and daemon_saver.c In-Reply-To: <199710221007.MAA01578@curry.mchp.siemens.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk While playing with the Dancin' Daemon screen saver, I noticed three minor problems. 1. On some video cards (S3 Trio64 based ones at least), there is a continuous, but brief, video glitch that mars the beauty of the screen saver. It is caused by continuously updating the border color, which briefly (for several pixel clocks) sets the pixel data to the border color. This should be a black glitch, but for some reason, it's producing a short blue glitch on the Trio64 based cards. One possible fix (in set_border() (syscons.c)): Change this: outb(ATC, 0x11); outb(ATC, color); inb(crtc_addr + 6); /* reset flip-flop */ outb(ATC, 0x20); /* enable Palette */ to this: outb(ATC, 0x31); outb(ATC, color); This keeps valid pixel data from being replaced by the contents of the overscan register. Alternate (or additional) fix (in daemon_saver() (daemon_saver.c)): Change code to call set_border(0) only once, like this: if (blank) { if (scrn_blanked == 0) set_border(0); if (scrn_blanked++ < 2) return; fillw( .... ); /* set_border(0); */ 2. Switching video modes from VGA_80x50 to VGA_80x25 (and etc.) can allow the Daemon and the hostname strings to wander far off the edge of the screen, crashing the kernel after a short time. This happens because the dimensions of the screen can change after the static position variables have been moved outside the new screen dimensions. Suggested fix: Change the code (in daemon_saver() (daemon_saver.c)) to make inequality boundary crossing checks, like this: if (dxpos >= scp->xsize - DAEMON_MAX_WIDTH) instead of: if (dxpos == scp->xsize - DAEMON_MAX_WIDTH) (repeat this 7 more times) The code should also force the txpos, typos, dxpos, dypos variables to all be in range, though this change will get them back in range fairly quickly. The draw_string(... message ...) stuff doesn't work right when the message string is longer than the width of the screen, which is easy to do in VGA_40x25 mode. The fix above doesn't fix this, but it prevents it from trashing the system. 3. syscons.c does not maintain the border color correctly when switching virtual terminals. Suggested fix (in exchange_scr() (syscons.c)): Add: set_border(new_scp->border); - Tony From owner-freebsd-hackers Thu Oct 23 20:35:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA17650 for hackers-outgoing; Thu, 23 Oct 1997 20:35:56 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from dcarmich.pr.mcs.net (dcarmich.pr.mcs.net [204.95.63.202]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA17642 for ; Thu, 23 Oct 1997 20:35:48 -0700 (PDT) (envelope-from dcarmich@dcarmich.pr.mcs.net) Received: (from dcarmich@localhost) by dcarmich.pr.mcs.net (8.8.5/8.8.5) id WAA00691; Thu, 23 Oct 1997 22:39:29 -0500 (CDT) Message-ID: <19971023223929.43563@dcarmich.pr.mcs.net> Date: Thu, 23 Oct 1997 22:39:29 -0500 From: Douglas Carmichael To: freebsd-hackers@freebsd.org Subject: Text-based sysinstall and serial console for installation? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74e Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk A text-based sysinstall utility would be good for: 1) Blind users using a speech synthesizer and/or Braille terminal 2) Sighted users with systems w/low memory 3) Physically challenged users using alternate terminals/input devices that can only display text with no cursor addressability. Also, maybe incorporate the use of a serial port console to the boot.flp? (One reason to do that is that so a blind user can hook up a serial cable from the system they want to install FreeBSD on to their existing system that is running a screen reader and/or Braille terminal driver). From owner-freebsd-hackers Thu Oct 23 21:37:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA21139 for hackers-outgoing; Thu, 23 Oct 1997 21:37:14 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from netroplex.com (ns1.netroplex.com [206.171.95.130]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA21134 for ; Thu, 23 Oct 1997 21:37:09 -0700 (PDT) (envelope-from info@pagecreators.com) Received: from awd (hahaha@max008-49.netroplex.com [207.212.27.49]) by netroplex.com (8.8.5/8.8.2) with ESMTP id VAA05686; Thu, 23 Oct 1997 21:38:32 -0700 (PDT) Message-ID: <345024A9.78F0254D@pagecreators.com> Date: Thu, 23 Oct 1997 21:31:38 -0700 From: Rod Ebrahimi X-Mailer: Mozilla 4.01 [en] (Win95; I) MIME-Version: 1.0 To: Fred Gilham , hackers@freebsd.org Subject: Re: Upgrade X-Priority: 3 (Normal) References: <199710231755.KAA16764@japonica.csl.sri.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Thank you... Also is there any fix files that can fix some of the problems fixed from 2.2.2 to 2.2.5 stability without doing a full upgrade? Thank you, Rod Fred Gilham wrote: > You wrote: > ---------------------------------------- > I have read the install notes and still am unclear on the best > method of upgrading from 2.2.2 to 2.2.5 with little change of our > source > configuration. Any help would be greatly appreciated. > ---------------------------------------- > > What I do is to get just the source, install it, and do a `make world' > > in /usr/src. I can do this on a system that's in service. It takes > about 4 hours on a P-166. Once this finishes, I re-make the kernel > with our kernel configuration file (I've set it up so I use the same > one on all our machines) and reboot and I'm up with an upgraded > system. I just did this yesterday on one of our systems. > > Once this is known to work, you can remote-mount the /usr/src and > /usr/obj file systems on different machines and do `make reinstall' on > > those machines. That way you only have to compile once. > > I've been upgrading this way for a long time and it seems the most > transparent to me. The only problem I have is when they add new files > > to /etc (such as login.conf) or change the group file or something. I > > have to fix this stuff by hand. > > -Fred From owner-freebsd-hackers Thu Oct 23 22:02:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA22690 for hackers-outgoing; Thu, 23 Oct 1997 22:02:31 -0700 (PDT) (envelope-from owner-freebsd-hackers) 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 WAA22682 for ; Thu, 23 Oct 1997 22:02:28 -0700 (PDT) (envelope-from jkh@time.cdrom.com) 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 WAA07930; Thu, 23 Oct 1997 22:03:03 -0700 (PDT) To: Douglas Carmichael cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Text-based sysinstall and serial console for installation? In-reply-to: Your message of "Thu, 23 Oct 1997 22:39:29 CDT." <19971023223929.43563@dcarmich.pr.mcs.net> Date: Thu, 23 Oct 1997 22:03:03 -0700 Message-ID: <7927.877669383@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > A text-based sysinstall utility would be good for: > 1) Blind users using a speech synthesizer and/or Braille terminal > 2) Sighted users with systems w/low memory > 3) Physically challenged users using alternate terminals/input devices that > can only display text with no cursor addressability. Well, if you supply me with a boot.flp image which implements all of this, I'll be happy to put it in the floppies/ directory of the next release. I've always encouraged the idea of alternative installers. Jordan From owner-freebsd-hackers Thu Oct 23 23:09:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA26224 for hackers-outgoing; Thu, 23 Oct 1997 23:09:39 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from safeconcept.utimaco.co.at (mail-gw.utimaco.co.at [195.96.28.162]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA26212 for ; Thu, 23 Oct 1997 23:09:33 -0700 (PDT) (envelope-from Michael.Schuster@utimaco.co.at) Received: (from uucp@localhost) by safeconcept.utimaco.co.at (8.8.5/8.8.5) id HAA22777 for ; Fri, 24 Oct 1997 07:57:59 +0200 (CEST) Received: from wshpux.utimaco.co.at(10.0.0.18) by safeconcept via smap (V2.0) id xma022772; Fri, 24 Oct 97 07:57:34 +0200 Message-ID: <34503B08.16D941F7@utimaco.co.at> Date: Fri, 24 Oct 1997 08:07:04 +0200 From: Michael Schuster Organization: Utimaco Safe Concept GmbH., Linz, Austria X-Mailer: Mozilla 4.03 [de] (X11; I; HP-UX B.10.01 9000/715) MIME-Version: 1.0 To: "hackers@FreeBSD.ORG" Subject: .zip vs. .tar.gz [was: zipfs filesystem anyone ? ] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Mike Smith wrote: >You are correct; gzipped tarfiles are organised the wrong way around >(metadata inside the compressed envelope), while zipfiles keep the >metadata outside. If you like, you can first compress all your files and then tar them, doing something like (not tested, just FTTOMH (from the top of my head:-)) find . -type f | xargs gzip tar cf . This is of course not as elegant as saying tar ....; gzip tarfile The whole difference obviously comes from different approaches: Zip does compression and archiving in one, whereas tar and gzip build on the typical UNIX way of doing things: one tool for one purpose. That way, your tools will be good, and you can upgrade one without having to touch the other. cheers Michael -- Michael Schuster Utimaco Safe Concept GmbH. | Tel: +43 732 655755 41 Europaplatz 6 | Fax: +43 732 655755 5 A-4020 Linz Austria | email: Michael.Schuster@utimaco.co.at From owner-freebsd-hackers Fri Oct 24 00:00:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA28407 for hackers-outgoing; Fri, 24 Oct 1997 00:00:59 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (word.smith.net.au [202.0.75.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA28348 for ; Fri, 24 Oct 1997 00:00:07 -0700 (PDT) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id QAA01921; Fri, 24 Oct 1997 16:26:40 +0930 (CST) Message-Id: <199710240656.QAA01921@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Michael Schuster cc: "hackers@FreeBSD.ORG" Subject: Re: .zip vs. .tar.gz [was: zipfs filesystem anyone ? ] In-reply-to: Your message of "Fri, 24 Oct 1997 08:07:04 +0200." <34503B08.16D941F7@utimaco.co.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 24 Oct 1997 16:26:35 +0930 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Mike Smith wrote: > > >You are correct; gzipped tarfiles are organised the wrong way around > >(metadata inside the compressed envelope), while zipfiles keep the > >metadata outside. > > If you like, you can first compress all your files and then tar them, > doing something like (not tested, just FTTOMH (from the top of my > head:-)) > > find . -type f | xargs gzip > tar cf . This leaves me with a tree full of compressed files, and when I unpack the tarball I have to uncompress them. And if the tarball contains files that are meant to be compressed, they'll get uncompressed, which I don't want either. > The whole difference obviously comes from different approaches: Zip does > compression and archiving in one, whereas tar and gzip build on the > typical UNIX way of doing things: one tool for one purpose. That way, > your tools will be good, and you can upgrade one without having to touch > the other. If tar was smart, it would use the external compression tool to compress the data for each file as it read it, rather than compressing the output stream. You would still lose, as the tar format does not have a central directory. mike From owner-freebsd-hackers Fri Oct 24 00:40:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA00342 for hackers-outgoing; Fri, 24 Oct 1997 00:40:29 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from shell.futuresouth.com (shell.futuresouth.com [207.141.254.20]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA00336 for ; Fri, 24 Oct 1997 00:40:27 -0700 (PDT) (envelope-from fullermd@futuresouth.com) Received: from shell.futuresouth.com (mail.futuresouth.com [207.141.254.21]) by shell.futuresouth.com (8.8.5/8.8.5) with SMTP id CAA25607; Fri, 24 Oct 1997 02:40:00 -0500 (CDT) Date: Fri, 24 Oct 1997 02:40:00 -0500 (CDT) From: "Matthew D. Fuller" To: Mike Smith cc: Michael Schuster , "hackers@FreeBSD.ORG" Subject: Re: .zip vs. .tar.gz [was: zipfs filesystem anyone ? ] In-Reply-To: <199710240656.QAA01921@word.smith.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 24 Oct 1997, Mike Smith wrote: > If tar was smart, it would use the external compression tool to > compress the data for each file as it read it, rather than compressing > the output stream. You would still lose, as the tar format does not > have a central directory. I have to disagree with this. it's much more efficient space-wise to compress a tarball than it is to tar a bunch of compressed files. and tar isn't meant to be a random-access archive method; tar and gzip are meant to save space and preserve directrory/file layout. And they're perfectly suited for this task. They don't do what you're discussing too well, no, but they aren't MEANT to. tar is smart for what tis' doing. > > mike > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* | FreeBSD; the way computers were meant to be | * "The only reason I'm burning my candle at both ends, is * | that I haven't figured out how to light the middle yet."| * fullermd@futuresouth.com :-} MAtthew Fuller * | http://keystone.westminster.edu/~fullermd | *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* From owner-freebsd-hackers Fri Oct 24 01:09:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA01753 for hackers-outgoing; Fri, 24 Oct 1997 01:09:08 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from mail.san.rr.com (san.rr.com [204.210.0.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA01747 for ; Fri, 24 Oct 1997 01:09:06 -0700 (PDT) (envelope-from studded@san.rr.com) Received: (from studded@localhost) by mail.san.rr.com (8.8.7/8.8.7) id BAA01837; Fri, 24 Oct 1997 01:07:47 -0700 (PDT) Message-Id: <199710240807.BAA01837@mail.san.rr.com> From: "Studded" To: "Mike Smith" Cc: "hackers@FreeBSD.ORG" Date: Fri, 24 Oct 97 01:07:38 -0700 Reply-To: "Studded" Priority: Normal X-Mailer: PMMail 1.95a For OS/2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: .zip vs. .tar.gz [was: zipfs filesystem anyone ? ] Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 24 Oct 1997 16:26:35 +0930, Mike Smith wrote: >If tar was smart, it would use the external compression tool to >compress the data for each file as it read it, rather than compressing >the output stream. You would still lose, as the tar format does not >have a central directory. I've never understood why InfoZip didn't catch on more in the Unix world. It is a very useful tool, which does almost everything on the list of requests that you and others are asking for. :) If you want more info, http://www.cdrom.com/pub/infozip/ Doug *** Proud operator, designer and maintainer of the world's largest *** Internet Relay Chat server. 4,168 clients and still growing. :-) *** Try spider.dal.net on ports 6662-4 (Powered by FreeBSD) *** Part of the DALnet IRC network *** From owner-freebsd-hackers Fri Oct 24 01:26:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA02472 for hackers-outgoing; Fri, 24 Oct 1997 01:26:04 -0700 (PDT) (envelope-from owner-freebsd-hackers) 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 BAA02456 for ; Fri, 24 Oct 1997 01:26:00 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id BAA21279; Fri, 24 Oct 1997 01:25:53 -0700 (PDT) Message-ID: <19971024012553.49295@hydrogen.nike.efn.org> Date: Fri, 24 Oct 1997 01:25:53 -0700 From: John-Mark Gurney To: Studded Cc: "hackers@FreeBSD.ORG" Subject: Re: .zip vs. .tar.gz [was: zipfs filesystem anyone ? ] References: <199710240807.BAA01837@mail.san.rr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199710240807.BAA01837@mail.san.rr.com>; from Studded on Fri, Oct 24, 1997 at 01:07:38AM -0700 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-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Studded scribbled this message on Oct 24: > On Fri, 24 Oct 1997 16:26:35 +0930, Mike Smith wrote: > > >If tar was smart, it would use the external compression tool to > >compress the data for each file as it read it, rather than compressing > >the output stream. You would still lose, as the tar format does not > >have a central directory. > > I've never understood why InfoZip didn't catch on more in the > Unix world. It is a very useful tool, which does almost everything on > the list of requests that you and others are asking for. :) If you > want more info, http://www.cdrom.com/pub/infozip/ well.. personally it's because you can't compress/decompress with the same program and the output is noisy... nothing nicer than doing: tar -czf file.tar.gz file and know that it's exactly what you wanted... no output, nothing... :) plus you get much better compression rates as you merge the whole group of files into one big one... meaning your dictionary will be larger we you compress most of the files... and really... how slow is it to extract a few hundredk now days? if you want infozip.. just install the package/port... -- 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-hackers Fri Oct 24 05:34:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA14931 for hackers-outgoing; Fri, 24 Oct 1997 05:34:31 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from pluto.senet.com.au (root@pluto.senet.com.au [203.11.90.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA14911 for ; Fri, 24 Oct 1997 05:34:25 -0700 (PDT) (envelope-from darius@holly.rd.net) Received: from holly.rd.net (c4-p24.senet.com.au [203.56.237.217]) by pluto.senet.com.au (8.8.7/8.8.7) with ESMTP id WAA07372 for ; Fri, 24 Oct 1997 22:04:19 +0930 Received: from holly.rd.net (localhost.rd.net [127.0.0.1]) by holly.rd.net (8.8.5/8.8.5) with ESMTP id WAA04548 for ; Fri, 24 Oct 1997 22:06:36 +0930 (CST) Message-Id: <199710241236.WAA04548@holly.rd.net> X-Mailer: exmh version 2.0zeta 7/24/97 To: freebsd-hackers@freebsd.org Subject: Re: zipfs filesystem anyone ? In-reply-to: Your message of "Thu, 23 Oct 1997 16:11:28 CST." <199710232211.QAA17154@rocky.mt.sri.com> Reply-to: doconnor@ist.flinders.edu.au Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 24 Oct 1997 22:06:35 +0930 From: "Daniel J. O'Connor" Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > > The VFS interface is not reflexive. > > No, it's a term from computer science, not medicine. > Never heard it in any of my classes. Well actually, its from mathematics... Do Logic and Graphs, and it will all be explained :) Although I don't really see how the term applies here.. Maybe he means reentrant.. Or something like it --------------- Daniel O'Connor 3rd Year Computer Science at Flinders University http://www.geocities.com.au/CapeCanaveral/7200 From owner-freebsd-hackers Fri Oct 24 09:23:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA01304 for hackers-outgoing; Fri, 24 Oct 1997 09:23:02 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from kcmain-int.SKW-Inc.Com ([208.132.78.205]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA01294 for ; Fri, 24 Oct 1997 09:22:53 -0700 (PDT) (envelope-from root@kcmain-int.SKW-Inc.Com) Received: (from root@localhost) by kcmain-int.SKW-Inc.Com (8.8.7/8.8.7) id LAA00247 for hackers@freebsd.org; Sat, 25 Oct 1997 11:22:24 -0500 (CDT) Date: Sat, 25 Oct 1997 11:22:24 -0500 (CDT) From: Charlie Root Message-Id: <199710251622.LAA00247@kcmain-int.SKW-Inc.Com> To: hackers@freebsd.org Subject: XFree86 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Greetings, I have a new PC with a Trident 9680 chipset in it. When I try to start Xwindows, it switches graphics mode, goes to all black and stops. If I do a CTRL-ALT-BS, it comes back to my prompt. I thought this had something to do with the Linear Frame Buffer being mis-aligned. I tried using the config parameter to disable the frame buffer and it did not help. When I start X I get: SVGA: PCI: Trident TGUI 9660/9680/9682 rev 211, Memory @ 0xe0000000, 0xe0400000 Trident chipset version: 0xd3 (TGUI96xx) SVGA: Detected a Trident 9680 SVGA: Revision 1 SVGA: Using Trident programmable clocks SVGA: chipset: tgui96xx SVGA: videoram: 1024k SVGA: Using 8bpp, Depth 8, Color weight: 666 SVGA: Maximum allowed dot-clock: 135.000 MHz From owner-freebsd-hackers Fri Oct 24 10:15:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA04749 for hackers-outgoing; Fri, 24 Oct 1997 10:15:31 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA04738 for ; Fri, 24 Oct 1997 10:15:15 -0700 (PDT) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.7/8.8.7) id KAA21497; Fri, 24 Oct 1997 10:15:10 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp04.primenet.com, id smtpd021483; Fri Oct 24 10:15:06 1997 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id KAA13208; Fri, 24 Oct 1997 10:15:02 -0700 (MST) From: Terry Lambert Message-Id: <199710241715.KAA13208@usr08.primenet.com> Subject: Re: zipfs filesystem anyone ? To: michaelh@cet.co.jp (Michael Hancock) Date: Fri, 24 Oct 1997 17:15:02 +0000 (GMT) Cc: tlambert@primenet.com, luigi@labinfo.iet.unipi.it, hackers@FreeBSD.ORG In-Reply-To: from "Michael Hancock" at Oct 24, 97 11:25:59 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > You could do one, but you will have to externalize a hell of a lot > > of code, and provide proxy allocation and freeing mechanisms for > > every place that is non-reflexive. > > Wouldn't you have to externalize a lot of stuff anyway? We'd need some > extra syscalls along the lines of John Heidemann's ook* (Out Of Kernel) > stuff. You can make a fs specific call that serves as a general interface > to marshall fs related operations in and out of the kernel. No. The "ook" stuff is kind of a kludge having to do with the fact that the VM interface consumed by local file systems is not encapsulated by a VFS layer: in other words, for local file systems, the top and bottom of the FS are different. This is actualy broken implementation more than anything else, IMO. Really, you need a clone top/bottom device, best case, or a paired top/bottom device (ala pty's, which should be clone themselves) at worst. The only real pain is extending the number of VOP's, should you need to... and that's going to bite you no matter how you approach it because the BSD VFS init code is broken (it counts the number of VOP's in the statically linked UFS instead of using the struct vnops descriptor count, with placeholders for some "reasonable number" of new VOPs). > Then you can make a semantic-free user layer. Well, you know my opinion: they should all be semantic free, and all implied state should be registered in a graph with all but the final Warshall pass complete, and the graph should be used to implement soft update semantics for all FS layers, everywhere. 8-). > It seems that a lot of NFS related work these days have to do with > adding state. Yes. This has me alarmed. It seems to me that NFS is becoming one kludge on top of another, with things getting tweaked until they appear to work, with no one really looking at the big picture. That's the same objection I have to stuffing VM glue into supposedly null function bodies in nullfs, unionfs, etc. 8-(. > I was looking at this a few months ago after John H. released his layering > code. ??? John H's code has been available since before the 4.4-Lite release; I was playing with it under 4.3 (FreeBSD 1.05)... > It also seems that Poul and John Dyson have started cleaning up some fs > related interface and memory issues, but I haven't had time to examine all > the details. I think John has been addressing real issues, and to be fair, I haven't unpacked my machines yet, so I haven't been able to look at Poul's stuff (the reduction of VOP calls seems sound in principle, but I can't comment for real until I actually look at it). I think the excitement over nullfs "working" has overshadowed a number of important design considerations; but you know that from my posts, so I don't need to repeat them. I don't know how much of the recent twiddling has been "make it work at any cost" as oppossed to real cleanup. I really think the VFS needs to be "dekludgeified" before more new stuff is added. If you make something parallel to something crooked, you end up with two crooked things. There needs to be someone in there with a "T-square" before an entire crooked house is built. 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-hackers Fri Oct 24 10:38:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA06364 for hackers-outgoing; Fri, 24 Oct 1997 10:38:26 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from super-g.inch.com (super-g.com [207.240.140.161]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA06357 for ; Fri, 24 Oct 1997 10:38:23 -0700 (PDT) (envelope-from spork@super-g.com) Received: from localhost (spork@localhost) by super-g.inch.com (8.8.7/8.8.5) with SMTP id NAA23663 for ; Fri, 24 Oct 1997 13:35:57 -0400 (EDT) Date: Fri, 24 Oct 1997 13:35:56 -0400 (EDT) From: spork X-Sender: spork@super-g.inch.com To: freebsd-hackers@FreeBSD.ORG Subject: Re: Possible SERIOUS bug in open()? (Big time bug) In-Reply-To: <19971024002450.UZ51487@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk J"org, Is there any chance of you back-porting this fix to RELENG_2_1_0? I can't really figure out how to do it, and a diff from then to now is radically different to the point that it doesn't even look like it would compile. Please? Charles On Fri, 24 Oct 1997, J Wunsch wrote: > As Jamil J. Weatherbee wrote: > > > No, the user open() should return error for somebody trying to open for > > not read and not write. > > It does (now). Why the h*ck are you both still arguing about it? For > me (being in MET DST timezone), it's already a matter of yesterday... > > -- > 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-hackers Fri Oct 24 10:42:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA06598 for hackers-outgoing; Fri, 24 Oct 1997 10:42:36 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA06593 for ; Fri, 24 Oct 1997 10:42:34 -0700 (PDT) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.7/8.8.7) id KAA17693; Fri, 24 Oct 1997 10:42:00 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp03.primenet.com, id smtpd017661; Fri Oct 24 10:41:50 1997 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id KAA14255; Fri, 24 Oct 1997 10:41:40 -0700 (MST) From: Terry Lambert Message-Id: <199710241741.KAA14255@usr08.primenet.com> Subject: Re: Possible SERIOUS bug in open()? (Big time bug) To: jamil@trojanhorse.ml.org (Jamil J. Weatherbee) Date: Fri, 24 Oct 1997 17:41:40 +0000 (GMT) Cc: tlambert@primenet.com, thorpej@nas.nasa.gov, joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Jamil J. Weatherbee" at Oct 23, 97 03:06:23 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > No, the user open() should return error for somebody trying to open for > not read and not write. /dev/io gives the process IOPL on the basis that > it is able to open /dev/io, not do operations on it. This is an implied interface. > I think it is perfectly reasonable for the driver to expect its open > method called only if the user has permissions on the file. Permission dictate whether the user may read the file or write the file; the open method specific to the file dictates wheher the user can open the file. There aren't permission bits associated with "openable", only "readable" and "writeable". For /dev/io, where opening has side effects that it wouldn't if people were required to use ioctl()'s instead of inb/outb, or where the port range was always trapped and proxied after trap instead of untrapped, this wouldn't be a side effect. Generally, /dev/io exists because there isn't a DDX in the console code like there should be, and a couple of other similar uses. > When you start putting the responsibility on the driver for maintaining > the security of the system and not the kernel then your'e just asking > for trouble. A device must dictate the policy for its use in all implementations. The original thread where the OR'ed flags resulted in an (unexpected to the user) flags value of '3' was an issue of a device specific policy prohibiting simultaneous readability and writeability for the device. How would the kernel enforce security policy for a simplex audio device which could not be used bidirectionally? Device flags indicating its simplex nature? This seems to me to be an enforcement issue for the audio driver, not for the kernel. /dev/io is unique in that it depends, rightly or wrongly, on side effects instead of explicit action. I think /dev/io is poorly designed compared to the Linux I/O port mapping mechanism in this regard (for example). > Much like most drivers do not check to see if the device > being passed is valid once it is opened because it should always be > valid (under most circumstances). There's no accounting for programmers who don't know how to code for hot pluggability... 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-hackers Fri Oct 24 10:47:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA06888 for hackers-outgoing; Fri, 24 Oct 1997 10:47:02 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA06877 for ; Fri, 24 Oct 1997 10:46:56 -0700 (PDT) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.7/8.8.7) id KAA18352; Fri, 24 Oct 1997 10:46:49 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp03.primenet.com, id smtpd018345; Fri Oct 24 10:46:46 1997 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id KAA14398; Fri, 24 Oct 1997 10:46:42 -0700 (MST) From: Terry Lambert Message-Id: <199710241746.KAA14398@usr08.primenet.com> Subject: Re: zipfs filesystem anyone ? To: nate@mt.sri.com (Nate Williams) Date: Fri, 24 Oct 1997 17:46:42 +0000 (GMT) Cc: tlambert@primenet.com, nate@mt.sri.com, luigi@labinfo.iet.unipi.it, hackers@freebsd.org In-Reply-To: <199710232211.QAA17154@rocky.mt.sri.com> from "Nate Williams" at Oct 23, 97 04:11:28 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > It means that there are side effects to the interface, and that the > > caller is dependent on the side effects. > > Kind of like strdup(3)? *grin* More like a program using: pwe = getpwnam( "bob"); /*deal with bob...*/ ... pwe ... ... pwe ... (void)getpwnam( "tom"); /*deal with tom...*/ ... pwe ... ... pwe ... With the idea that it knows that getpwnam returns a pointer to a static data area, so it's OK to only set the pointer to that area once. 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-hackers Fri Oct 24 10:48:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA07001 for hackers-outgoing; Fri, 24 Oct 1997 10:48:32 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA06985 for ; Fri, 24 Oct 1997 10:48:23 -0700 (PDT) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.7/8.8.7) id KAA23876 for ; Fri, 24 Oct 1997 10:48:15 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp04.primenet.com, id smtpd023853; Fri Oct 24 10:48:11 1997 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id KAA14447 for freebsd-hackers@FreeBSD.ORG; Fri, 24 Oct 1997 10:48:11 -0700 (MST) From: Terry Lambert Message-Id: <199710241748.KAA14447@usr08.primenet.com> Subject: Re: Possible SERIOUS bug in open()? (Big time bug) To: freebsd-hackers@FreeBSD.ORG Date: Fri, 24 Oct 1997 17:48:10 +0000 (GMT) In-Reply-To: <19971024002450.UZ51487@uriah.heep.sax.de> from "J Wunsch" at Oct 24, 97 00:24:50 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > No, the user open() should return error for somebody trying to open for > > not read and not write. > > It does (now). Why the h*ck are you both still arguing about it? For > me (being in MET DST timezone), it's already a matter of yesterday... Because I think the "fix" should be backed out because the side effect is useful, and he thinks it shouldn't because he doesn't want to have to code device drivers with security policy in mind. 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-hackers Fri Oct 24 10:54:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA07457 for hackers-outgoing; Fri, 24 Oct 1997 10:54:57 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA07450 for ; Fri, 24 Oct 1997 10:54:52 -0700 (PDT) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.7/8.8.7) id KAA19414; Fri, 24 Oct 1997 10:54:51 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp03.primenet.com, id smtpd019385; Fri Oct 24 10:54:41 1997 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id KAA14740; Fri, 24 Oct 1997 10:54:39 -0700 (MST) From: Terry Lambert Message-Id: <199710241754.KAA14740@usr08.primenet.com> Subject: Re: zipfs filesystem anyone ? To: doconnor@ist.flinders.edu.au Date: Fri, 24 Oct 1997 17:54:39 +0000 (GMT) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <199710241236.WAA04548@holly.rd.net> from "Daniel J. O'Connor" at Oct 24, 97 10:06:35 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > > > The VFS interface is not reflexive. > > > No, it's a term from computer science, not medicine. > > Never heard it in any of my classes. > > Well actually, its from mathematics... > Do Logic and Graphs, and it will all be explained :) > Although I don't really see how the term applies here.. > Maybe he means reentrant.. Or something like it "Principles of Object Oriented Design" Sorry, I ,don't have an ISBN handy. In absolutely dumbest terms, it means: 1) If *I* allocate it, it's *my* responsibility to free it 2) If I have to call a function to do something, I have to call a function to undo it 3) If I have to access data, I'll call a function to do it. 4) Everything is data opaque (no "promiscuous" knowledge) 5) All operations are reversible 6) Etc. ...all sorts of good things. 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-hackers Fri Oct 24 10:58:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA07667 for hackers-outgoing; Fri, 24 Oct 1997 10:58:00 -0700 (PDT) (envelope-from owner-freebsd-hackers) 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 KAA07651 for ; Fri, 24 Oct 1997 10:57:52 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id KAA26349; Fri, 24 Oct 1997 10:57:35 -0700 (PDT) Message-ID: <19971024105734.33600@hydrogen.nike.efn.org> Date: Fri, 24 Oct 1997 10:57:34 -0700 From: John-Mark Gurney To: Terry Lambert Cc: Michael Hancock , luigi@labinfo.iet.unipi.it, hackers@FreeBSD.ORG Subject: Re: zipfs filesystem anyone ? References: <199710241715.KAA13208@usr08.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199710241715.KAA13208@usr08.primenet.com>; from Terry Lambert on Fri, Oct 24, 1997 at 05:15:02PM +0000 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-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Terry Lambert scribbled this message on Oct 24: > The only real pain is extending the number of VOP's, should you need to... > and that's going to bite you no matter how you approach it because the > BSD VFS init code is broken (it counts the number of VOP's in the > statically linked UFS instead of using the struct vnops descriptor count, > with placeholders for some "reasonable number" of new VOPs). are you really sure about this? by my reading of the code in vfs_init.c (and I've sent enough time looking at the code reciently), the size of the opv table is vfs_opv_numops = sizeof(vfs_op_desc)/ sizeof(struct vnodeop_desc*) -1... shouldn't this be enough? or am I completely missreading the code? wouldn't simply increasing the allocated vfs_opv_numops a constant value, then keeping track of this information be enough? or are you looking at something more? [...] > I don't know how much of the recent twiddling has been "make it work at > any cost" as oppossed to real cleanup. I really think the VFS needs to > be "dekludgeified" before more new stuff is added. If you make something > parallel to something crooked, you end up with two crooked things. There > needs to be someone in there with a "T-square" before an entire crooked > house is built. yep... I know what you mean... and that is why I'm not writing any code for my bus/device design until I'm satisfied with it longer than a week.. (actually, the rate I've been going, more like a month) :) -- 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-hackers Fri Oct 24 11:24:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA09433 for hackers-outgoing; Fri, 24 Oct 1997 11:24:47 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA09423 for ; Fri, 24 Oct 1997 11:24:40 -0700 (PDT) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.7/8.8.7) id LAA25397; Fri, 24 Oct 1997 11:24:16 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp04.primenet.com, id smtpd025394; Fri Oct 24 11:24:10 1997 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id LAA16384; Fri, 24 Oct 1997 11:24:05 -0700 (MST) From: Terry Lambert Message-Id: <199710241824.LAA16384@usr08.primenet.com> Subject: Re: zipfs filesystem anyone ? To: gurney_j@resnet.uoregon.edu Date: Fri, 24 Oct 1997 18:24:05 +0000 (GMT) Cc: tlambert@primenet.com, michaelh@cet.co.jp, luigi@labinfo.iet.unipi.it, hackers@FreeBSD.ORG In-Reply-To: <19971024105734.33600@hydrogen.nike.efn.org> from "John-Mark Gurney" at Oct 24, 97 10:57:34 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > The only real pain is extending the number of VOP's, should you need to... > > and that's going to bite you no matter how you approach it because the > > BSD VFS init code is broken (it counts the number of VOP's in the > > statically linked UFS instead of using the struct vnops descriptor count, > > with placeholders for some "reasonable number" of new VOPs). > > are you really sure about this? by my reading of the code in vfs_init.c > (and I've sent enough time looking at the code reciently), the size of the > opv table is vfs_opv_numops = sizeof(vfs_op_desc)/ > sizeof(struct vnodeop_desc*) -1... shouldn't this be enough? or am I > completely missreading the code? I haven't seen this; my home machine has been packed in a box on a truck and is still in the box, only now in my livingroom. This is, in fact, one of my VFS patches! Yea, team! If it's in there, then this is an important first step. The next step would be to add a special placeholder descriptor that can be replaced in vfs_op_desc for several slots. This would make it so you didn't have to rebuild all of vnode_if.c and vnode_if.h to add new descriptors: you can overwrite the placeholders instead. Actually, that particular change (not using FFS to size the table) is the first change in a chain that lets you boot a machine without a file system at all (my original purpose). 8-) 8-). 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-hackers Fri Oct 24 11:43:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA10677 for hackers-outgoing; Fri, 24 Oct 1997 11:43:07 -0700 (PDT) (envelope-from owner-freebsd-hackers) 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 LAA10671 for ; Fri, 24 Oct 1997 11:43:03 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id LAA26509; Fri, 24 Oct 1997 11:42:44 -0700 (PDT) Message-ID: <19971024114243.36902@hydrogen.nike.efn.org> Date: Fri, 24 Oct 1997 11:42:43 -0700 From: John-Mark Gurney To: Terry Lambert Cc: michaelh@cet.co.jp, luigi@labinfo.iet.unipi.it, hackers@FreeBSD.ORG Subject: Re: zipfs filesystem anyone ? References: <19971024105734.33600@hydrogen.nike.efn.org> <199710241824.LAA16384@usr08.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199710241824.LAA16384@usr08.primenet.com>; from Terry Lambert on Fri, Oct 24, 1997 at 06:24:05PM +0000 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-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Terry Lambert scribbled this message on Oct 24: > > > The only real pain is extending the number of VOP's, should you need to... > > > and that's going to bite you no matter how you approach it because the > > > BSD VFS init code is broken (it counts the number of VOP's in the > > > statically linked UFS instead of using the struct vnops descriptor count, > > > with placeholders for some "reasonable number" of new VOPs). > > > > are you really sure about this? by my reading of the code in vfs_init.c > > (and I've sent enough time looking at the code reciently), the size of the > > opv table is vfs_opv_numops = sizeof(vfs_op_desc)/ > > sizeof(struct vnodeop_desc*) -1... shouldn't this be enough? or am I > > completely missreading the code? > > I haven't seen this; my home machine has been packed in a box on a truck > and is still in the box, only now in my livingroom. > > This is, in fact, one of my VFS patches! > > Yea, team! actually.. the change wasn't very massive.. just 3 lines of code and some comment updates... as a quick question.. now that we use vfs_opv_numops, should we get ride of the dummy NULL entry? > If it's in there, then this is an important first step. The next step > would be to add a special placeholder descriptor that can be replaced > in vfs_op_desc for several slots. This would make it so you didn't > have to rebuild all of vnode_if.c and vnode_if.h to add new descriptors: > you can overwrite the placeholders instead. or should we simply use the dummy NULL entry (and add some) for the place holder? personally, a possible define that declares I want a possible X extra vop vectors... and then have a couple variables that tell you the maximum number, and the current last offset... this shouldn't be hard to do... > Actually, that particular change (not using FFS to size the table) > is the first change in a chain that lets you boot a machine without > a file system at all (my original purpose). 8-) 8-). kool.... are you on -current? I guess I should of announced my vfsinit patches to hackers instead... basicly, to get ride of LKM's and prepare for kld modules, I needed to change the vfs system to initalize on a permodule basis instead of a initalize all staticly compiled module idea... http://freefall.freebsd.org/~jmg/vfs.patch -- 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-hackers Fri Oct 24 13:02:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA15829 for hackers-outgoing; Fri, 24 Oct 1997 13:02:24 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from gatekeeper.ray.com (gatekeeper.ray.com [138.125.162.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA15562 for ; Fri, 24 Oct 1997 13:00:00 -0700 (PDT) (envelope-from Gregory_D_Moncreaff@res.raytheon.com) Received: (mailer@localhost) by gatekeeper.ray.com (8.8.7/8.8.7) id PAA25554 for ; Fri, 24 Oct 1997 15:57:19 -0400 Received: from notes.res.ray.com/138.125.97.35() by gatekeeper.ray.com id sma029710; Fri Oct 24 15:55:30 1997 X-SMAP-TO: Received: by notes.res.ray.com(Lotus SMTP MTA v1.1 (385.6 5-6-1997)) id 8525653A.006D6E52 ; Fri, 24 Oct 1997 15:55:16 -0400 X-Lotus-FromDomain: RES From: "Gregory D Moncreaff" To: hackers@FreeBSD.org Message-ID: <8525653A.006CE9C5.00@notes.res.ray.com> Date: Fri, 24 Oct 1997 14:59:15 -0400 Subject: man recvmsg and soreceive Mime-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk With respect to connection oriented protocols PR_CONNREQUIRED (are there any in 2.2.5?) kern/uipc_socket.c:soreceive() will perform PDU_RCVD (which can have effect of implicitly confirming connection) when called ONLY to get control data unless flags has MSG_PEEK Need to update man page to say that you must call recvmsg with MSG_PEEK to avoid implicitly confirming connection ===================================================================== Gregory D. Moncreaff Phone 1-508-490-2048 Raytheon Electronic Systems Fax 1-508-490-2086 Gregory_D_Moncreaff@res.raytheon.com Home moncrg@ma.ultranet.com --------------------------------------------------------------------- From owner-freebsd-hackers Fri Oct 24 13:12:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA16413 for hackers-outgoing; Fri, 24 Oct 1997 13:12:07 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from cyber1.servtech.com (root@cyber1.servtech.com [199.1.22.8]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA16407 for ; Fri, 24 Oct 1997 13:12:02 -0700 (PDT) (envelope-from housley@pr-comm.com) Received: from pr-comm.com (root@prcomm.roc.servtech.com [204.181.3.14]) by cyber1.servtech.com (8.8.6/8.8.5) with ESMTP id QAA05516 for ; Fri, 24 Oct 1997 16:11:52 -0400 (EDT) Received: from pr-comm.com (housley@localhost [127.0.0.1]) by pr-comm.com (8.8.7/8.8.7) with ESMTP id QAA00853 for ; Fri, 24 Oct 1997 16:09:26 -0400 (EDT) (envelope-from housley@pr-comm.com) Message-ID: <34510029.193E7316@pr-comm.com> Date: Fri, 24 Oct 1997 16:08:09 -0400 From: "James E. Housley" Organization: PR Communications, Inc. X-Mailer: Mozilla 4.03b8 [en] (X11; I; FreeBSD 2.2.5-RELEASE i386) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Anti-spam in hub.mc Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I think I am missing something important here. I was using an older anti-spam rule set for sendmail. I started using the new set that is in hub.mc . My question is that mail from a site that is blocked has a message/reply with #blocked.contact postmaster@pr-comm.com (for me, was postmaster@FreeBSD.ORG). My question is how will they actually contact the postmaster if mail from that site is blocked????? Am I missing something? I understand a very little of how the rules work, but not much. I don't see anything that allows mail to postmaster mail through. Jim. -- -------------------------------------------+------------------------- James E. Housley | PGP: 1024/03983B4D PR Communications, Inc. | 2C 3F 3A 0D A8 D8 C3 13 www.servtech.com/public/pr-comm | 7C F0 B5 BF 27 8B 92 FE From owner-freebsd-hackers Fri Oct 24 13:46:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA19096 for hackers-outgoing; Fri, 24 Oct 1997 13:46:32 -0700 (PDT) (envelope-from owner-freebsd-hackers) 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 NAA19091 for ; Fri, 24 Oct 1997 13:46:30 -0700 (PDT) (envelope-from gdonl@tsc.tdk.com) 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 NAA09415; Fri, 24 Oct 1997 13:45:35 -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 NAA22945; Fri, 24 Oct 1997 13:45:20 -0700 (PDT) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id NAA18723; Fri, 24 Oct 1997 13:45:08 -0700 (PDT) From: Don Lewis Message-Id: <199710242045.NAA18723@salsa.gv.tsc.tdk.com> Date: Fri, 24 Oct 1997 13:45:02 -0700 In-Reply-To: Terry Lambert "Re: Possible SERIOUS bug in open()? (Big time bug)" (Oct 24, 5:41pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Terry Lambert , jamil@trojanhorse.ml.org (Jamil J. Weatherbee) Subject: Re: Possible SERIOUS bug in open()? (Big time bug) Cc: thorpej@nas.nasa.gov, joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Oct 24, 5:41pm, Terry Lambert wrote: } Subject: Re: Possible SERIOUS bug in open()? (Big time bug) } Permission dictate whether the user may read the file or write the file; } the open method specific to the file dictates wheher the user can open } the file. There aren't permission bits associated with "openable", only } "readable" and "writeable". } } For /dev/io, where opening has side effects Opening files has side effects, too. For instance, space isn't recovered if a file is unlinked if the file is open. There is also the issue of O_EXLOCK and O_SHLOCK. I don't want another user to have the ability to do either with my mode 0600 files. From owner-freebsd-hackers Fri Oct 24 13:55:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA19555 for hackers-outgoing; Fri, 24 Oct 1997 13:55:57 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from elvis.mu.org (elvis.mu.org [206.156.231.253]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA19532 for ; Fri, 24 Oct 1997 13:55:53 -0700 (PDT) (envelope-from paul@elvis.mu.org) Received: (from paul@localhost) by elvis.mu.org (8.8.7/8.8.7) id PAA08603 for freebsd-hackers@freebsd.org; Fri, 24 Oct 1997 15:55:45 -0500 (CDT) (envelope-from paul) From: Paul Saab Message-Id: <199710242055.PAA08603@elvis.mu.org> Subject: netstat: kvm_read: Bad address To: freebsd-hackers@freebsd.org Date: Fri, 24 Oct 1997 15:55:45 -0500 (CDT) X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I am trying to figure out why my machine has not been behaving recently after running bug free for months. Wednesday I had a kernel panic and Joerg has put me in the right direction to try and find the bug. Now today I got this while doing a netstat on another machine with exactly the same hardware configuration as the one which had the kernel panic but it is running 2.2.5-RELEASE. The machines are PPRO 200's with 2940UW's, 128MB of ram, and with 3c905 ethernet cards. My question is what does the following mean and how should I fix it. Active Internet connections Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp 0 0 themaneater.com.http 204.184.83.7.1976 ESTABLISHED tcp 0 8398 themaneater.com.http 204.184.83.7.1975 ESTABLISHED tcp 0 5650 themaneater.com.http 204.184.83.7.1974 ESTABLISHED tcp 0 0 themaneater.com.http 208.196.245.66.2658 ESTABLISHED tcp 0 0 themaneater.com.http 208.196.245.66.2657 ESTABLISHED tcp 0 0 themaneater.com.ftp-da Mizzou-AS6-17.mi.1232 TIME_WAIT tcp 361 -266160568 themaneater.com.http 16.211.65.241.2656 -264201400 tcp 0 -264546048 128.204.64.241.16625 144.105.65.241.39147 CLOSED netstat: kvm_read: Bad address ??? udp 0 0 elvis.4724 elvis.domain udp 0 0 localhost.domain *.* udp 0 0 elvis.domain *.* Thanks a bunch, Paul From owner-freebsd-hackers Fri Oct 24 14:14:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA20574 for hackers-outgoing; Fri, 24 Oct 1997 14:14:44 -0700 (PDT) (envelope-from owner-freebsd-hackers) 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 OAA20567 for ; Fri, 24 Oct 1997 14:14:34 -0700 (PDT) (envelope-from rivers@dignus.com) 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 RAA28779; Fri, 24 Oct 1997 17:14:23 -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 PAA29719; Fri, 24 Oct 1997 15:39:31 -0400 (EDT) Received: (from rivers@localhost) by lakes.dignus.com (8.8.5/8.6.9) id PAA13405; Fri, 24 Oct 1997 15:28:49 -0400 (EDT) Date: Fri, 24 Oct 1997 15:28:49 -0400 (EDT) From: Thomas David Rivers Message-Id: <199710241928.PAA13405@lakes.dignus.com> To: hackers@FreeBSD.ORG, root@kcmain-int.SKW-Inc.Com Subject: Re: XFree86 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Greetings, > > I have a new PC with a Trident 9680 chipset in it. When I try to start > Xwindows, it switches graphics mode, goes to all black and stops. If I do a > CTRL-ALT-BS, it comes back to my prompt. I thought this had something to do > with the Linear Frame Buffer being mis-aligned. I tried using the config > parameter to disable the frame buffer and it did not help. > > When I start X I get: > > SVGA: PCI: Trident TGUI 9660/9680/9682 rev 211, Memory @ 0xe0000000, 0xe0400000 > Trident chipset version: 0xd3 (TGUI96xx) > SVGA: Detected a Trident 9680 > SVGA: Revision 1 > SVGA: Using Trident programmable clocks > SVGA: chipset: tgui96xx > SVGA: videoram: 1024k > SVGA: Using 8bpp, Depth 8, Color weight: 666 > SVGA: Maximum allowed dot-clock: 135.000 MHz > Just F.Y.I - I use a Trident 9680-based board in my machine (not the best, by far, but certainly cheap...) First - it's probably worthwhile to go ahead and splurge for another 1024k of RAM - the video won't be worthwhile without it... Here's my XF86Config file. - Dave Rivers - # XF86Config auto-generated by XF86Setup # # Copyright (c) 1996 by The XFree86 Project, Inc. # # Permission is hereby granted, free of charge, to any person obtaining a # copy of this software and associated documentation files (the "Software"), # to deal in the Software without restriction, including without limitation # the rights to use, copy, modify, merge, publish, distribute, sublicense, # and/or sell copies of the Software, and to permit persons to whom the # Software is furnished to do so, subject to the following conditions: # # The above copyright notice and this permission notice shall be included in # all copies or substantial portions of the Software. # # THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR # IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, # FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL # THE XFREE86 PROJECT BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, # WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF # OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE # SOFTWARE. # # Except as contained in this notice, the name of the XFree86 Project shall # not be used in advertising or otherwise to promote the sale, use or other # dealings in this Software without prior written authorization from the # XFree86 Project. # # See 'man XF86Config' for info on the format of this file Section "Files" RgbPath "/usr/X11R6/lib/X11/rgb" FontPath "/usr/X11R6/lib/X11/fonts/misc:unscaled" FontPath "/usr/X11R6/lib/X11/fonts/75dpi:unscaled" FontPath "/usr/X11R6/lib/X11/fonts/100dpi:unscaled" FontPath "/usr/X11R6/lib/X11/fonts/Type1" FontPath "/usr/X11R6/lib/X11/fonts/Speedo" FontPath "/usr/X11R6/lib/X11/fonts/misc" FontPath "/usr/X11R6/lib/X11/fonts/75dpi" FontPath "/usr/X11R6/lib/X11/fonts/100dpi" EndSection Section "ServerFlags" EndSection Section "Keyboard" Protocol "Standard" XkbRules "xfree86" XkbModel "pc101" XkbLayout "us" EndSection Section "Pointer" Protocol "Microsoft" Device "/dev/cuaa0" BaudRate 1200 EndSection Section "Monitor" Identifier "Primary Monitor" VendorName "Unknown" ModelName "Unknown" HorizSync 31.5-69 VertRefresh 55-120 Modeline "1152x864" 65.00 1152 1200 1416 1480 864 893 903 973 interlace Modeline "1024x768" 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync Modeline "800x600" 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync Modeline "640x480" 31.50 640 680 720 864 480 488 491 521 Modeline "640x400" 25.18 640 664 760 800 400 409 411 450 Modeline "480x300" 29.95 480 504 584 624 300 319 322 333 doublescan Modeline "400x300" 25.00 400 424 488 520 300 319 322 333 doublescan Modeline "320x240" 15.75 320 336 384 400 240 244 246 262 doublescan Modeline "320x200" 12.59 320 336 384 400 200 204 205 225 doublescan EndSection Section "Device" Identifier "Primary Card" VendorName "Unknown" BoardName "Trident TGUI9680 (generic)" Option "med_dram" # Option "tgui_pci_read_off" # Turn off PCI burst read mode. Option "tgui_pci_write_off" # Turn off PCI burst write mode. EndSection Section "Screen" Driver "SVGA" Device "Primary Card" Monitor "Primary Monitor" SubSection "Display" Depth 8 Modes "1152x864" "1024x768" "800x600" "640x480" "640x400" "480x300" "400x300" "320x240" "320x200" EndSubSection SubSection "Display" Depth 15 Modes "1152x864" "1024x768" "800x600" "640x480" "640x400" "480x300" "400x300" "320x240" "320x200" EndSubSection SubSection "Display" Depth 16 Modes "1152x864" "1024x768" "800x600" "640x480" "640x400" "480x300" "400x300" "320x240" "320x200" EndSubSection SubSection "Display" Depth 24 Modes "1152x864" "1024x768" "800x600" "640x480" "640x400" "480x300" "400x300" "320x240" "320x200" EndSubSection SubSection "Display" Depth 32 Modes "1152x864" "1024x768" "800x600" "640x480" "640x400" "480x300" "400x300" "320x240" "320x200" EndSubSection EndSection From owner-freebsd-hackers Fri Oct 24 14:24:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA21196 for hackers-outgoing; Fri, 24 Oct 1997 14:24:55 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id OAA21190 for ; Fri, 24 Oct 1997 14:24:51 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id XAA01007; Fri, 24 Oct 1997 23:24:49 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id XAA10790; Fri, 24 Oct 1997 23:02:20 +0200 (MET DST) Message-ID: <19971024230220.VY14522@uriah.heep.sax.de> Date: Fri, 24 Oct 1997 23:02:20 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Cc: root@kcmain-int.SKW-Inc.Com (Charlie Root) Subject: Re: XFree86 References: <199710251622.LAA00247@kcmain-int.SKW-Inc.Com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199710251622.LAA00247@kcmain-int.SKW-Inc.Com>; from Charlie Root on Oct 25, 1997 11:22:24 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Charlie Root wrote: > I have a new PC with a Trident 9680 chipset in it. When I try to start > Xwindows, it switches graphics mode, goes to all black and stops. If I do a > CTRL-ALT-BS, it comes back to my prompt. I thought this had something to do > with the Linear Frame Buffer being mis-aligned. I tried using the config > parameter to disable the frame buffer and it did not help. That's probably something you'd better report to the XFree86 folks (although i'm aware that David Dawes is reading this list as well). Also, i think the TGUI support has been developed a lot lately, so make sure to not use an outdated Xserver for your tests. -- 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-hackers Fri Oct 24 14:31:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA21704 for hackers-outgoing; Fri, 24 Oct 1997 14:31:47 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from cedb.dpcsys.com (cedb.dpcsys.com [206.16.184.4]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA21695 for ; Fri, 24 Oct 1997 14:31:41 -0700 (PDT) (envelope-from dan@dpcsys.com) Received: from localhost (dan@localhost) by cedb.dpcsys.com (8.8.5/8.8.2) with SMTP id VAA10970; Fri, 24 Oct 1997 21:30:21 GMT Date: Fri, 24 Oct 1997 14:30:21 -0700 (PDT) From: Dan Busarow To: "James E. Housley" cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Anti-spam in hub.mc In-Reply-To: <34510029.193E7316@pr-comm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 24 Oct 1997, James E. Housley wrote: > I think I am missing something important here. I was using an older anti-spam > rule set for sendmail. I started using the new set that is in hub.mc . My > question is that mail from a site that is blocked has a message/reply with > #blocked.contact postmaster@pr-comm.com (for me, was postmaster@FreeBSD.ORG). > My question is how will they actually contact the postmaster if mail from that > site is blocked????? By telephone. Seriously, if you've blocked someone by mistake they can either get your phone number from whois (you do keep your contact information up to date, right) or send mail from an account at a non-blocked site. Personally I wouldn't bother with the contact ... message, our message is "Access denied". Dan -- Dan Busarow 714 443 4172 DPC Systems / Beach.Net dan@dpcsys.com Dana Point, California 83 09 EF 59 E0 11 89 B4 8D 09 DB FD E1 DD 0C 82 From owner-freebsd-hackers Fri Oct 24 14:44:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA22582 for hackers-outgoing; Fri, 24 Oct 1997 14:44:22 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from opus.cts.cwu.edu (skynyrd@opus.cts.cwu.edu [198.104.92.71]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA22577 for ; Fri, 24 Oct 1997 14:44:19 -0700 (PDT) (envelope-from skynyrd@opus.cts.cwu.edu) Received: from localhost (skynyrd@localhost) by opus.cts.cwu.edu (8.8.7/8.8.7) with SMTP id OAA08852; Fri, 24 Oct 1997 14:44:13 -0700 (PDT) (envelope-from skynyrd@opus.cts.cwu.edu) Date: Fri, 24 Oct 1997 14:44:12 -0700 (PDT) From: Chris Timmons To: Paul Saab cc: freebsd-hackers@FreeBSD.ORG Subject: Re: netstat: kvm_read: Bad address In-Reply-To: <199710242055.PAA08603@elvis.mu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk You might cvsup 2.2-STABLE and rebuild your kernel; David Greenman recently committed a fix for a problem that sounds similar to yours. -Chris From owner-freebsd-hackers Fri Oct 24 14:47:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA22760 for hackers-outgoing; Fri, 24 Oct 1997 14:47:43 -0700 (PDT) (envelope-from owner-freebsd-hackers) 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 OAA22755 for ; Fri, 24 Oct 1997 14:47:40 -0700 (PDT) (envelope-from jkh@time.cdrom.com) 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 OAA24975 for ; Fri, 24 Oct 1997 14:47:40 -0700 (PDT) To: hackers@freebsd.org Subject: Something which 2.2.5 upgraders might find handy. Date: Fri, 24 Oct 1997 14:47:39 -0700 Message-ID: <24971.877729659@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In ftp://freebsd.org/pub/jkh/225upgrade.tgz is a small package, simply saying: pkg_add ftp://freebsd.org/pub/jkh/225upgrade.tgz to launch the 2.2.5 upgrade on your machine. The key thing this package does is upgrade your /stand to 2.2.5 first so that the sysinstall upgrade code you run is the latest (and upgrade's been changed a bit for 2.2.5). All you should need to do is select your media type, the distributions you want to upgrade and you should be off and running. Let me know how well it works in actual practice. :) Jordan From owner-freebsd-hackers Fri Oct 24 15:11:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA24017 for hackers-outgoing; Fri, 24 Oct 1997 15:11:55 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from localhost.zilker.net (jump-x2-1021.jumpnet.com [207.8.67.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA24012 for ; Fri, 24 Oct 1997 15:11:51 -0700 (PDT) (envelope-from marquard@zilker.net) Received: (from marquard@localhost) by localhost.zilker.net (8.8.7/8.8.3) id RAA10335; Fri, 24 Oct 1997 17:11:40 -0500 (CDT) To: freebsd-hackers@freebsd.org Subject: Re: netstat: kvm_read: Bad address References: <199710242055.PAA08603@elvis.mu.org> From: Dave Marquardt Date: 24 Oct 1997 17:11:09 -0500 In-Reply-To: Paul Saab's message of "Fri, 24 Oct 1997 15:55:45 -0500 (CDT)" Message-ID: <85zpnyerr6.fsf@localhost.zilker.net> Lines: 28 X-Mailer: Gnus v5.5/XEmacs 19.15 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Paul Saab writes: > and find the bug. Now today I got this while doing a netstat on > another machine with exactly the same hardware configuration as > the one which had the kernel panic but it is running 2.2.5-RELEASE. > > > Active Internet connections > Proto Recv-Q Send-Q Local Address Foreign Address (state) > tcp 0 0 themaneater.com.http 204.184.83.7.1976 ESTABLISHED > tcp 0 8398 themaneater.com.http 204.184.83.7.1975 ESTABLISHED > tcp 0 5650 themaneater.com.http 204.184.83.7.1974 ESTABLISHED > tcp 0 0 themaneater.com.http 208.196.245.66.2658 ESTABLISHED > tcp 0 0 themaneater.com.http 208.196.245.66.2657 ESTABLISHED > tcp 0 0 themaneater.com.ftp-da Mizzou-AS6-17.mi.1232 TIME_WAIT > tcp 361 -266160568 themaneater.com.http 16.211.65.241.2656 -264201400 > tcp 0 -264546048 128.204.64.241.16625 144.105.65.241.39147 CLOSED > netstat: kvm_read: Bad address > ??? > udp 0 0 elvis.4724 elvis.domain > udp 0 0 localhost.domain *.* > udp 0 0 elvis.domain *.* You'll see this on lots of BSD-based systems. netstat reads the items on the tcb (TCP PCB) list one at a time from kernel memory, and the list has changed while you were reading it. No big deal, just a little annoying. To fix it would be painful, I think. -Dave From owner-freebsd-hackers Fri Oct 24 15:17:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA24521 for hackers-outgoing; Fri, 24 Oct 1997 15:17:04 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA24509 for ; Fri, 24 Oct 1997 15:17:00 -0700 (PDT) (envelope-from jamil@trojanhorse.ml.org) Received: from localhost (jamil@localhost) by trojanhorse.ml.org (8.8.7/8.8.5) with SMTP id PAA01238 for ; Fri, 24 Oct 1997 15:12:48 -0700 (PDT) Date: Fri, 24 Oct 1997 15:12:48 -0700 (PDT) From: "Jamil J. Weatherbee" To: freebsd-hackers@freebsd.org Subject: ioctl() base command groups Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Are the groups used in the _IO* macros, which are usually a single character supposed to have some systematic system of assignment? From owner-freebsd-hackers Fri Oct 24 17:34:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA01334 for hackers-outgoing; Fri, 24 Oct 1997 17:34:53 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from mail.calweb.com (mail.calweb.com [208.131.56.11]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA01325 for ; Fri, 24 Oct 1997 17:34:51 -0700 (PDT) (envelope-from jflists@mail.calweb.com) Received: by mail.calweb.com (8.8.6/8.8.6) with SMTP id RAA18786; Fri, 24 Oct 1997 17:31:57 -0700 (PDT) X-SMTP: hello devnull from jflists@pop.calweb.com server @devnull.calweb.com ip 207.173.135.51 Message-Id: <3.0.3.32.19971024173016.0099a1a0@pop.calweb.com> Warning: Unsolicited Commercial Email (UCE) will be returned to send in bulk X-Sender: jflists@pop.calweb.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 24 Oct 1997 17:30:16 -0700 To: Dan Busarow , "James E. Housley" From: "jfesler@calweb.com" Subject: Re: Anti-spam in hub.mc Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: References: <34510029.193E7316@pr-comm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The filter I use At 02:30 PM 10/24/97 -0700, Dan Busarow quoted and added in.. >> My question is how will they actually contact the postmaster if mail from that >> site is blocked????? > >By telephone. Seriously, if you've blocked someone by mistake they >can either get your phone number from whois (you do keep your contact Personally, mail to "postmaster" is *always* accepted over here. Period. Regardless of other filters that are in place. Most of the time, the error message I give out says to contact Postmaster, as in may cases domain names are being used without consent of their owners. -- Jason Fesler jfesler@calweb.com 'whois jf319' | When the chips are down Admin, CalWeb Internet Services www.calweb.com | The buffalo's empty Junk email returned in bulk; 1 cc to your postmaster | Junk mail probs? http://www.gigo.com/junkmail.htm | :-) From owner-freebsd-hackers Fri Oct 24 18:14:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA02835 for hackers-outgoing; Fri, 24 Oct 1997 18:14:13 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA02828 for ; Fri, 24 Oct 1997 18:14:04 -0700 (PDT) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.7/8.8.7) id SAA07130; Fri, 24 Oct 1997 18:14:02 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp03.primenet.com, id smtpd007124; Fri Oct 24 18:13:52 1997 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id SAA10113; Fri, 24 Oct 1997 18:13:43 -0700 (MST) From: Terry Lambert Message-Id: <199710250113.SAA10113@usr08.primenet.com> Subject: Re: zipfs filesystem anyone ? To: gurney_j@resnet.uoregon.edu Date: Sat, 25 Oct 1997 01:13:43 +0000 (GMT) Cc: tlambert@primenet.com, michaelh@cet.co.jp, luigi@labinfo.iet.unipi.it, hackers@FreeBSD.ORG In-Reply-To: <19971024114243.36902@hydrogen.nike.efn.org> from "John-Mark Gurney" at Oct 24, 97 11:42:43 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > If it's in there, then this is an important first step. The next step > > would be to add a special placeholder descriptor that can be replaced > > in vfs_op_desc for several slots. This would make it so you didn't > > have to rebuild all of vnode_if.c and vnode_if.h to add new descriptors: > > you can overwrite the placeholders instead. > > or should we simply use the dummy NULL entry (and add some) for the place > holder? The list terminator is still necessary for the population pass, where the vectors get populated. The VOP_REPLACEME needs to be seperate. > personally, a possible define that declares I want a possible X extra > vop vectors... and then have a couple variables that tell you the > maximum number, and the current last offset... this shouldn't be hard > to do... They kind of need to be static, unless the vector list becomes a linker set. This can't happen until the linker set can be agregated between linker uses. Basically, if you want to be able to pull it back out later, you have to be able to distinguish it. My plan was to use a seperate ELF section for each modules contribution to global linker sets. This lets you use an ELF image archiver to "permanently" add modules into the kernel (no difference between kld modules and normal kernel components, except the image file that backs them). > > Actually, that particular change (not using FFS to size the table) > > is the first change in a chain that lets you boot a machine without > > a file system at all (my original purpose). 8-) 8-). > > kool.... are you on -current? Yes. > I guess I should of announced my vfsinit > patches to hackers instead... basicly, to get ride of LKM's and prepare > for kld modules, I needed to change the vfs system to initalize on a > permodule basis instead of a initalize all staticly compiled module > idea... Be very careful here. I did this code under Windows 95. It turns out that you need to sort the *total* descriptor list, or you will end up with order of reference problems. I loaded the UFS, then I loaded the FFS, and initialized them in that order. This includes the NULL ops that you normally leave of tf the end, and llow to be set in the population pass (referred to above). Sorting the list also allows you to reference by index instead of by descriptor. If you think about it, you won't have a descriptor for a new VOP, if you dynamically load it, in vnode_if.h. This loses the little glue function. To fix this, you have to kill the glue functions. And you can do it if you can indext into the op vector and get the right function. 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-hackers Fri Oct 24 18:17:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA02975 for hackers-outgoing; Fri, 24 Oct 1997 18:17:06 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA02967 for ; Fri, 24 Oct 1997 18:17:03 -0700 (PDT) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.7/8.8.7) id SAA17899; Fri, 24 Oct 1997 18:16:54 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp04.primenet.com, id smtpd017880; Fri Oct 24 18:16:52 1997 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id SAA10298; Fri, 24 Oct 1997 18:16:48 -0700 (MST) From: Terry Lambert Message-Id: <199710250116.SAA10298@usr08.primenet.com> Subject: Re: Anti-spam in hub.mc To: jflists@calweb.com Date: Sat, 25 Oct 1997 01:16:48 +0000 (GMT) Cc: dan@dpcsys.com, housley@pr-comm.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: <3.0.3.32.19971024173016.0099a1a0@pop.calweb.com> from "jfesler@calweb.com" at Oct 24, 97 05:30:16 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >> My question is how will they actually contact the postmaster if mail > >> from that site is blocked????? > > Personally, mail to "postmaster" is *always* accepted over here. > Period. Regardless of other filters that are in place. Most of the > time, the error message I give out says to contact Postmaster, as > in may cases domain names are being used without consent of their owners. This is actually required, unconditionally, even if you are blocking other mail from that site. 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-hackers Fri Oct 24 18:20:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA03180 for hackers-outgoing; Fri, 24 Oct 1997 18:20:58 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA03175 for ; Fri, 24 Oct 1997 18:20:54 -0700 (PDT) (envelope-from karpen@ocean.campus.luth.se) Received: (from karpen@localhost) by ocean.campus.luth.se (8.8.5/8.8.5) id DAA11603; Sat, 25 Oct 1997 03:29:08 +0200 (CEST) From: Mikael Karpberg Message-Id: <199710250129.DAA11603@ocean.campus.luth.se> Subject: Re: Anti-spam in hub.mc In-Reply-To: <3.0.3.32.19971024173016.0099a1a0@pop.calweb.com> from "jfesler@calweb.com" at "Oct 24, 97 05:30:16 pm" To: jflists@calweb.com Date: Sat, 25 Oct 1997 03:29:08 +0200 (CEST) Cc: freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to jfesler@calweb.com: > The filter I use > > At 02:30 PM 10/24/97 -0700, Dan Busarow quoted and added in.. > >> My question is how will they actually contact the postmaster if mail > >> from that site is blocked????? Er... the filter, if I'm correct, will only block non-exiting domain names, and the sender can, therefor, by simply NOT trying to fake his domain, but instead using his normal mail system, mail postmaster. /Mikael From owner-freebsd-hackers Fri Oct 24 18:25:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA03304 for hackers-outgoing; Fri, 24 Oct 1997 18:25:12 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA03299 for ; Fri, 24 Oct 1997 18:25:07 -0700 (PDT) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.7/8.8.7) id SAA07520; Fri, 24 Oct 1997 18:25:02 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp03.primenet.com, id smtpd007514; Fri Oct 24 18:24:57 1997 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id SAA10641; Fri, 24 Oct 1997 18:24:47 -0700 (MST) From: Terry Lambert Message-Id: <199710250124.SAA10641@usr08.primenet.com> Subject: Re: Possible SERIOUS bug in open()? (Big time bug) To: Don.Lewis@tsc.tdk.com (Don Lewis) Date: Sat, 25 Oct 1997 01:24:47 +0000 (GMT) Cc: tlambert@primenet.com, jamil@trojanhorse.ml.org, thorpej@nas.nasa.gov, joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199710242045.NAA18723@salsa.gv.tsc.tdk.com> from "Don Lewis" at Oct 24, 97 01:45:02 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Opening files has side effects, too. For instance, space isn't > recovered if a file is unlinked if the file is open. There is > also the issue of O_EXLOCK and O_SHLOCK. I don't want another > user to have the ability to do either with my mode 0600 files. Clearly, normal files would enforce read or write permision for open. But say you have a processor emulator that gets invoked by an execution class loader so that it can mmap a foreign binary in its address space, and then run it. ,------------------. ,------------------. | DEC Alpha binary | | DEC Alpha binary | | regular process | | emulator process | | | | ,--------------. | | | | | x86 image | | | | | | (Netscape) | | | | | `--------------' | `------------------' `------------------' You need to be able to open something with just "x" access to map it so that a proces you own can "run" it. So you also want to allow an open if you have execute access. Does having only execute access keep you from reading a file? No. You can make it core. 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-hackers Fri Oct 24 18:46:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA04174 for hackers-outgoing; Fri, 24 Oct 1997 18:46:40 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA04166 for ; Fri, 24 Oct 1997 18:46:37 -0700 (PDT) (envelope-from michaelh@cet.co.jp) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.5/CET-v2.1) with SMTP id BAA24648; Sat, 25 Oct 1997 01:44:30 GMT Date: Sat, 25 Oct 1997 10:44:29 +0900 (JST) From: Michael Hancock To: John-Mark Gurney cc: Terry Lambert , luigi@labinfo.iet.unipi.it, hackers@FreeBSD.ORG Subject: Re: zipfs filesystem anyone ? In-Reply-To: <19971024114243.36902@hydrogen.nike.efn.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 24 Oct 1997, John-Mark Gurney wrote: > actually.. the change wasn't very massive.. just 3 lines of code and some > comment updates... > Sheez, Terry, first you give us mega-commits and now you give us tiny pointless ones. When are you going to get this right? ;-) Mike Hancock From owner-freebsd-hackers Fri Oct 24 18:49:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA04333 for hackers-outgoing; Fri, 24 Oct 1997 18:49:39 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from server.local.sunyit.edu (A-T34.rh.sunyit.edu [150.156.210.241]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA04317 for ; Fri, 24 Oct 1997 18:49:20 -0700 (PDT) (envelope-from perlsta@cs.sunyit.edu) Received: from localhost (perlsta@localhost) by server.local.sunyit.edu (8.8.7/8.8.5) with SMTP id VAA06304; Fri, 24 Oct 1997 21:54:11 -0500 (EST) X-Authentication-Warning: server.local.sunyit.edu: perlsta owned process doing -bs Date: Fri, 24 Oct 1997 21:54:11 -0500 (EST) From: Alfred Perlstein X-Sender: perlsta@server.local.sunyit.edu To: "Jordan K. Hubbard" cc: hackers@FreeBSD.ORG Subject: why is freebsd distributed like this? In-Reply-To: <24971.877729659@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I understand most of the FreeBSD release system, however i have a problem with it that i feel should be addressed. Why are there releases floating around with security holes in them? certain 'fixes' that are trivial but nessesary like the procfs patch should be applied all around the source tree as soon as possible. I understand that that is what the -stable releases are for... but it's almost being too much of a purist to let that stuff continue to be in freebsd. .________________________________________________________________________ __ _ |Alfred Perlstein - Programming & SysAdmin --"Have you seen my FreeBSD tatoo?" |perlsta@sunyit.edu --"who was that masked admin?" |http://www.cs.sunyit.edu/~perlsta : ' From owner-freebsd-hackers Fri Oct 24 18:55:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA04618 for hackers-outgoing; Fri, 24 Oct 1997 18:55:28 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from ren.dtir.qld.gov.au (firewall-user@ns.dtir.qld.gov.au [203.108.138.66]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA04613 for ; Fri, 24 Oct 1997 18:55:25 -0700 (PDT) (envelope-from syssgm@dtir.qld.gov.au) Received: by ren.dtir.qld.gov.au; id MAA07244; Sat, 25 Oct 1997 12:07:18 +1000 (EST) Received: from ogre.dtir.qld.gov.au(167.123.8.3) by ren.dtir.qld.gov.au via smap (3.2) id xma007242; Sat, 25 Oct 97 12:07:04 +1000 Received: from troll.dtir.qld.gov.au (troll.dtir.qld.gov.au [167.123.8.1]) by ogre.dtir.qld.gov.au (8.8.7/8.8.7) with ESMTP id LAA24320; Sat, 25 Oct 1997 11:54:15 +1000 (EST) Received: from localhost (syssgm@localhost) by troll.dtir.qld.gov.au (8.8.5/8.8.5) with SMTP id LAA02018; Sat, 25 Oct 1997 11:54:11 +1000 (EST) Message-Id: <199710250154.LAA02018@troll.dtir.qld.gov.au> X-Authentication-Warning: troll.dtir.qld.gov.au: syssgm@localhost didn't use HELO protocol To: Charles Henrich cc: freebsd-hackers@freebsd.org, syssgm@dtir.qld.gov.au Subject: Perils of login.conf (Was: fsck (2.2.5-RELEASE) large filesystems broken) References: <19971023004136.21792@crh.cl.msu.edu> <199710240723.RAA15535@ogre.dtir.qld.gov.au> <19971024083642.18571@crh.cl.msu.edu> In-Reply-To: <19971024083642.18571@crh.cl.msu.edu> from Charles Henrich at "Fri, 24 Oct 1997 08:36:42 -0400" Date: Sat, 25 Oct 1997 11:54:11 +1000 From: Stephen McKay Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [Moved from -bugs to -hackers for a bit of debate] On Friday, 24th October 1997, Charles Henrich wrote: >On the subject of Re: fsck (2.2.5-RELEASE) large filesystems broken, Stephen McKay stated: > >> I'd guess that you are being bitten by /etc/login.conf. The comments in it >> claim that 'daemon' is used by /etc/rc and 'daemon' has "datasize=32M". Try >> bumping this to 64M. > >Yes, that was it. I'd like to take an assault rifle to the fellow who decided >the defaults for FreeBSD is so limited, especially considering in most cases >FreeBSD is installed as a one or two use system. Ahem! Well, I wouldn't be using anything more dangerous than Nerf bats myself, but I have been inconvenienced a couple times by login.conf. There are some people who are very keen on it, and presumably it does wonderful things for them. However, after some pain and a bit of reflection, I think the defaults for everything should be pushed way up, like the maximum that FreeBSD can take for all these knobs, and let those that support hundreds or thousands of users wind them back to whatever limits they wish to impose. If this was the case then regular users would have one less thing to worry about and magazine reviewers who benchmark "out of the box" would get sensible results. Those who really use login.conf to impose carefully selected limits would be unaffected. Stephen. From owner-freebsd-hackers Fri Oct 24 19:03:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA05147 for hackers-outgoing; Fri, 24 Oct 1997 19:03:47 -0700 (PDT) (envelope-from owner-freebsd-hackers) 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 TAA05142 for ; Fri, 24 Oct 1997 19:03:45 -0700 (PDT) (envelope-from jkh@time.cdrom.com) 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 TAA13382; Fri, 24 Oct 1997 19:03:09 -0700 (PDT) To: Alfred Perlstein cc: hackers@FreeBSD.ORG Subject: Re: why is freebsd distributed like this? In-reply-to: Your message of "Fri, 24 Oct 1997 21:54:11 CDT." Date: Fri, 24 Oct 1997 19:03:09 -0700 Message-ID: <13379.877744989@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Why are there releases floating around with security holes in them? > certain 'fixes' that are trivial but nessesary like the procfs patch > should be applied all around the source tree as soon as possible. 1. We can't change what's already been released, at least not without causing serious confusion. 2. If you know of a specific security hole still in -current or -stable then the thing to do is NOT to whine here about it, the thing to do is to submit a PR if you're actually interested in seeing it fixed. And it's as simple as that. Jordan From owner-freebsd-hackers Fri Oct 24 19:11:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA05580 for hackers-outgoing; Fri, 24 Oct 1997 19:11:49 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from cedb.dpcsys.com (cedb.dpcsys.com [206.16.184.4]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA05574 for ; Fri, 24 Oct 1997 19:11:48 -0700 (PDT) (envelope-from dan@dpcsys.com) Received: from localhost (dan@localhost) by cedb.dpcsys.com (8.8.5/8.8.2) with SMTP id CAA13215; Sat, 25 Oct 1997 02:11:34 GMT Date: Fri, 24 Oct 1997 19:11:34 -0700 (PDT) From: Dan Busarow To: Terry Lambert cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Anti-spam in hub.mc In-Reply-To: <199710250116.SAA10298@usr08.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 25 Oct 1997, Terry Lambert wrote: > > >> My question is how will they actually contact the postmaster if mail > > >> from that site is blocked????? > > > This is actually required, unconditionally, even if you are blocking > other mail from that site. What was that RFC number? I do have a postmater mailbox and it is usable by 99.9995% of the Internet. (rough estimate) I see nothing in in RFC1123 that says I MUST accept mail to postmaster from every host on the Net, just that my MTA MUST support the postmaster mailbox, which it does, filters and all. Requiring postmaster to go through would also rule out check_mail filters which are certainly allowed by the RFCs. (quoting RFC821) "*if accepted*, the receiver-SMTP returns a 250 OK reply." Emphasis mine. RFC lawyering aside, care to share the IOS filter that checks for recipient if the packet is for port 25 but from a blocked source address? Dan -- Dan Busarow 714 443 4172 DPC Systems / Beach.Net dan@dpcsys.com Dana Point, California 83 09 EF 59 E0 11 89 B4 8D 09 DB FD E1 DD 0C 82 From owner-freebsd-hackers Fri Oct 24 19:20:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA05956 for hackers-outgoing; Fri, 24 Oct 1997 19:20:17 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id TAA05949 for ; Fri, 24 Oct 1997 19:20:07 -0700 (PDT) (envelope-from tom@sdf.com) Received: from tom by misery.sdf.com with smtp (Exim 1.73 #1) id 0xOvnj-0005K6-00; Fri, 24 Oct 1997 19:18:07 -0700 Date: Fri, 24 Oct 1997 19:18:04 -0700 (PDT) From: Tom To: Alfred Perlstein cc: hackers@freebsd.org Subject: Re: why is freebsd distributed like this? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 24 Oct 1997, Alfred Perlstein wrote: > I understand most of the FreeBSD release system, however i have a problem > with it that i feel should be addressed. > > Why are there releases floating around with security holes in them? > certain 'fixes' that are trivial but nessesary like the procfs patch > should be applied all around the source tree as soon as possible. > > I understand that that is what the -stable releases are for... but it's > almost being too much of a purist to let that stuff continue to be in > freebsd. If you are talking about older releases, then you shouldn't be using older releases. By deleting older releases, you can't deny they ever existed. If you change an older release, it is becomes something different. Also, there aren't any "stable releases". There are 2.1-stable and 2.2-stable branches, which releases have been made from at certain points in time. I don't really see a problem here, but again, I also have an archive of 1.1.5.1 around still. > .________________________________________________________________________ __ _ > |Alfred Perlstein - Programming & SysAdmin --"Have you seen my FreeBSD tatoo?" > |perlsta@sunyit.edu --"who was that masked admin?" > |http://www.cs.sunyit.edu/~perlsta > : > ' Tom From owner-freebsd-hackers Fri Oct 24 19:20:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA05972 for hackers-outgoing; Fri, 24 Oct 1997 19:20:22 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from cedb.dpcsys.com (cedb.dpcsys.com [206.16.184.4]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA05967 for ; Fri, 24 Oct 1997 19:20:21 -0700 (PDT) (envelope-from dan@dpcsys.com) Received: from localhost (dan@localhost) by cedb.dpcsys.com (8.8.5/8.8.2) with SMTP id CAA13232; Sat, 25 Oct 1997 02:20:14 GMT Date: Fri, 24 Oct 1997 19:20:13 -0700 (PDT) From: Dan Busarow To: "jfesler@calweb.com" cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Anti-spam in hub.mc In-Reply-To: <3.0.3.32.19971024173016.0099a1a0@pop.calweb.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 24 Oct 1997, jfesler@calweb.com wrote: > Personally, mail to "postmaster" is *always* accepted over here. > Period. Regardless of other filters that are in place. Most of the > time, the error message I give out says to contact Postmaster, as > in may cases domain names are being used without consent of their owners. A domain or IP block only makes it into our filters after the postmaster there has made it clear that they don't care if someone sends spam from their site. (saying we can't do anything about spam amounts to don't care) I haven't blocked a relay site yet but I do have some candidates. Dan -- Dan Busarow 714 443 4172 DPC Systems / Beach.Net dan@dpcsys.com Dana Point, California 83 09 EF 59 E0 11 89 B4 8D 09 DB FD E1 DD 0C 82 From owner-freebsd-hackers Fri Oct 24 20:40:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA09530 for hackers-outgoing; Fri, 24 Oct 1997 20:40:27 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from fly.HiWAAY.net (root@fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA09518 for ; Fri, 24 Oct 1997 20:40:24 -0700 (PDT) (envelope-from dkelly@nospam.hiwaay.net) Received: from nospam.hiwaay.net (tnt1-221.HiWAAY.net [208.147.147.221]) by fly.HiWAAY.net (8.8.7/8.8.6) with ESMTP id WAA06035 for ; Fri, 24 Oct 1997 22:40:20 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by nospam.hiwaay.net (8.8.7/8.8.4) with ESMTP id WAA04114 for ; Fri, 24 Oct 1997 22:40:18 -0500 (CDT) Message-Id: <199710250340.WAA04114@nospam.hiwaay.net> X-Mailer: exmh version 2.0zeta 7/24/97 To: hackers@FreeBSD.ORG From: dkelly@hiwaay.net Subject: Re: why is freebsd distributed like this? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 24 Oct 1997 22:40:18 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Why are there releases floating around with security holes in them? Who is going to go around and take them away from people? :-) I think its a good idea for Walnut Creek to keep older releases online for a while. Sometimes its handy to be able to go back to older software just to have a look. And for some, pulling it out of CVS might be too much. Its really inconvienent when a port's master site decides to update their code and delete the exact version a port relies on. As for security holes? That's what the -security list is for. Can't do much for people who don't care to help themselves. -- David Kelly N4HHE, dkelly@hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. From owner-freebsd-hackers Fri Oct 24 20:40:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA09572 for hackers-outgoing; Fri, 24 Oct 1997 20:40:55 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA09565 for ; Fri, 24 Oct 1997 20:40:51 -0700 (PDT) (envelope-from nate@rocky.mt.sri.com) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id VAA23053; Fri, 24 Oct 1997 21:40:46 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id VAA22910; Fri, 24 Oct 1997 21:40:43 -0600 (MDT) Date: Fri, 24 Oct 1997 21:40:43 -0600 (MDT) Message-Id: <199710250340.VAA22910@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alfred Perlstein Cc: "Jordan K. Hubbard" , hackers@freebsd.org Subject: Re: why is freebsd distributed like this? In-Reply-To: References: <24971.877729659@time.cdrom.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Why are there releases floating around with security holes in them? > certain 'fixes' that are trivial but nessesary like the procfs patch > should be applied all around the source tree as soon as possible. Umm, they were? But, it's really hard to delete releases from CD's. All security bugs are 'fixed' in the trees as soon as possible. But, new bugs/problems are found, and you can't go change bits already set in stone. If people aren't watching the security mailing list, then there's nothing we can do about it. And, the fact of the matter is that it costs too much money for WC to burn all the CD's and build new ones for every security bug that crops up. If people aren't willing to 'keep up' with their vendor (ie; us) and find out about bugs, then there's nothing we can do given the current resources. Even Sun doesn't let it's users know about security violations 'on their own' and we pay them 10's of thousands of dollars a year. Nate From owner-freebsd-hackers Sat Oct 25 00:46:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA20163 for hackers-outgoing; Sat, 25 Oct 1997 00:46:06 -0700 (PDT) (envelope-from owner-freebsd-hackers) 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 AAA20152 for ; Sat, 25 Oct 1997 00:46:01 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id AAA02976; Sat, 25 Oct 1997 00:45:45 -0700 (PDT) Message-ID: <19971025004544.21378@hydrogen.nike.efn.org> Date: Sat, 25 Oct 1997 00:45:44 -0700 From: John-Mark Gurney To: Terry Lambert Cc: michaelh@cet.co.jp, luigi@labinfo.iet.unipi.it, hackers@FreeBSD.ORG Subject: Re: zipfs filesystem anyone ? References: <19971024114243.36902@hydrogen.nike.efn.org> <199710250113.SAA10113@usr08.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199710250113.SAA10113@usr08.primenet.com>; from Terry Lambert on Sat, Oct 25, 1997 at 01:13:43AM +0000 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-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Terry Lambert scribbled this message on Oct 25: > > > If it's in there, then this is an important first step. The next step > > > would be to add a special placeholder descriptor that can be replaced > > > in vfs_op_desc for several slots. This would make it so you didn't > > > have to rebuild all of vnode_if.c and vnode_if.h to add new descriptors: > > > you can overwrite the placeholders instead. > > > > or should we simply use the dummy NULL entry (and add some) for the place > > holder? > > The list terminator is still necessary for the population pass, where > the vectors get populated. The VOP_REPLACEME needs to be seperate. I can see on the vnodeopv_desc of the vfs layer, but why does the NULL entry on the array of the vnodeop_desc array in vnode_if.c need the last NULL, that is what vfs_opv_numops is for... (which the population code uses)... so what I'm saying is we make two vars, maxvfs_opv_numops in which we allocate all the memory for that many ops... then as a new op is added we simply increase vfs_opv_numops to keep track of were we add the next op.. when it's equal to (or greater) then we simply disallow adding any new ops... the code to add this will be very minor... while your box is off line you can use http://www.freebsd.org/cgi/cvsweb.cgi to browse the source... > > personally, a possible define that declares I want a possible X extra > > vop vectors... and then have a couple variables that tell you the > > maximum number, and the current last offset... this shouldn't be hard > > to do... > > They kind of need to be static, unless the vector list becomes a linker > set. This can't happen until the linker set can be agregated between I was talking about the size of the list being variable, but that ther be an options like: options "EXTRA_VNODEOPS=5" then we simply do: int maxvfs_opv_numops = (sizeof(vfs_op_descs)/sizeof(struct vnodeop_desc *)) + EXTRA_VNODEOPS; and then the define is like: struct vnodeop_desc *vfs_op_descs[num] = { }; and we simply modify the awk script to properly generate num... which isn't hard... > linker uses. Basically, if you want to be able to pull it back out > later, you have to be able to distinguish it. My plan was to use a > seperate ELF section for each modules contribution to global linker > sets. This lets you use an ELF image archiver to "permanently" add > modules into the kernel (no difference between kld modules and normal > kernel components, except the image file that backs them). ok.. good to hear... > > I guess I should of announced my vfsinit > > patches to hackers instead... basicly, to get ride of LKM's and prepare > > for kld modules, I needed to change the vfs system to initalize on a > > permodule basis instead of a initalize all staticly compiled module > > idea... > > Be very careful here. I did this code under Windows 95. It turns out > that you need to sort the *total* descriptor list, or you will end up > with order of reference problems. I loaded the UFS, then I loaded the > FFS, and initialized them in that order. This includes the NULL ops > that you normally leave of tf the end, and llow to be set in the > population pass (referred to above). arg, I see what you mean.. ffs depends upon some of ufs's functions.. (arg, I was assuming that each module was independant)... right now the only way I can think of preventhing this from being a problem is to add the MOUNT_xxx to the declaration of the vnodeops, and then including in the ffs a dependancy of ufs... > Sorting the list also allows you to reference by index instead of by > descriptor. If you think about it, you won't have a descriptor for > a new VOP, if you dynamically load it, in vnode_if.h. This loses the > little glue function. To fix this, you have to kill the glue functions. > And you can do it if you can indext into the op vector and get the right > function. umm... isn't this already what is done? from vfs_opv_init: opv_desc_vector[opve_descp->opve_op->vdesc_offset] = opve_descp->opve_impl; the above line will set the appropriate vector by the vdesc_offset.. comment from vdesc_offset: /* offset in vector--first for speed */ then at the end, there is a second pass to fill in the remaining entries with the entry from VOFFSET(vop_default) of it's own vector.. hmm... looks like we need to remove this comment: /* * Finally, go back and replace unfilled routines * with their default. (Sigh, an O(n^3) algorithm. I * could make it better, but that'd be work, and n is small.) */ as right now the final routine runs in n as far as I can tell... :) ttyl.. -- 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-hackers Sat Oct 25 01:03:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA20838 for hackers-outgoing; Sat, 25 Oct 1997 01:03:31 -0700 (PDT) (envelope-from owner-freebsd-hackers) 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 BAA20828 for ; Sat, 25 Oct 1997 01:03:27 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id BAA03032; Sat, 25 Oct 1997 01:03:26 -0700 (PDT) Message-ID: <19971025010326.61185@hydrogen.nike.efn.org> Date: Sat, 25 Oct 1997 01:03:26 -0700 From: John-Mark Gurney To: FreeBSD Hackers Subject: ld and kld dependancies... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk well.. I was working on getting kld dependancies... and right now my only problem is that when I'm creating the kld module with ld, it will store the dependancy as but when making sure that it exists on the machine, it will search for lib.a... so, as far as I can see, we have a couple options: a) hack ld to understand either raw names passed to -l, or our own little idea of a kld module, like .kld b) get the kld code to do the conversion from to lib.a, and just keep ld the same... I'm leaning towards option a... perhaps a -Bkld which will turn on -Bshareable and searching of .kld? of course then there is the matter of the search path... right now the search path of the kernel kld code is limited to the same directory that the original file was located... I don't see that as much of a problem... -- 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-hackers Sat Oct 25 01:08:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA21041 for hackers-outgoing; Sat, 25 Oct 1997 01:08:55 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (ppp20.portal.net.au [202.12.71.120]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA21035 for ; Sat, 25 Oct 1997 01:08:50 -0700 (PDT) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (localhost [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id RAA00531; Sat, 25 Oct 1997 17:35:31 +0930 (CST) Message-Id: <199710250805.RAA00531@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: "Jamil J. Weatherbee" cc: freebsd-hackers@FreeBSD.ORG Subject: Re: ioctl() base command groups In-reply-to: Your message of "Fri, 24 Oct 1997 15:12:48 MST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 25 Oct 1997 17:35:29 +0930 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Are the groups used in the _IO* macros, which are usually a single > character supposed to have some systematic system of assignment? No, not really. They combine with the other attributes of the ioctl to help make the code unique, but there's nothing magic about them. mike From owner-freebsd-hackers Sat Oct 25 01:29:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA22126 for hackers-outgoing; Sat, 25 Oct 1997 01:29:16 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from dcarmich.pr.mcs.net (dcarmich.pr.mcs.net [204.95.63.202]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA22109; Sat, 25 Oct 1997 01:29:08 -0700 (PDT) (envelope-from dcarmich@dcarmich.pr.mcs.net) Received: (from dcarmich@localhost) by dcarmich.pr.mcs.net (8.8.7/8.8.7) id DAA00245; Sat, 25 Oct 1997 03:28:38 -0500 (CDT) (envelope-from dcarmich) From: Douglas Carmichael Message-Id: <199710250828.DAA00245@dcarmich.pr.mcs.net> Subject: 2.2.5-RELEASE installs fine, but can't detect TI PCI-1130 CardBus controller To: freebsd-hackers@freebsd.org, freebsd-mobile@freebsd.org Date: Sat, 25 Oct 1997 03:28:37 -0500 (CDT) X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I installed the 2.2.5-RELEASE bindist and srcdist from ftp2.freebsd.org and they installed fine over my existing 2.2.2-RELEASE/PAO-970616 system, but 2.2.5-RELEASE does not detect my NEC Versa 6050MH laptop's TI PCI-1130 CardBus PCMCIA controller when 2.2.2-RELEASE correctly detected it. Here's my kernel configuration file: # My new kernel configuration (10/3/97) machine "i386" cpu "I586_CPU" ident NECVERSA maxusers 60 options INET #InterNETworking options FFS #Berkeley Fast Filesystem options MFS #Memory Filesystem options PROCFS #Process filesystem options "COMPAT_43" #Compatible with BSD 4.3 [KEEP THIS!] options UCONSOLE #Allow users to grab the console options SYSVSHM options SYSVSEM options SYSVMSG # kernel tracing options KTRACE # laptop-specific configuration options LAPTOP # If your laptop have not had Windoze95-Ready BIOS, please update it. # Such old BIOS'es sometimes have critical bugs at 32-bit protected # mode APM BIOS interface (which have not used by Windoze 3.1). # PC-card suspend/resume support (experimental) options APM_PCCARD_RESUME options PCIC_RESUME_RESET # Keep power for serial cards when the system suspends # (If your machine hangs up when you try to suspend the system with # FAX/Modem PCMCIA card, uncomment this option). #options SIO_SUSP_KEEP_PWR # Detach SCSI devices when the SCSI card is removed options SCSI_DETACH # Don't suspend the system immediately before the system is resumed # from suspended mode (Default 3 seconds) options "APM_NOSUSPEND_IMMEDIATE=3" config kernel root on wd0 controller isa0 controller pci0 controller crd0 device pcic0 at crd? device pcic1 at crd? controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr disk fd0 at fdc0 drive 0 controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr disk wd0 at wdc0 drive 0 flags 0x80ff options ATAPI #Enable ATAPI support for IDE bus options ATAPI_STATIC #Don't do it as an LKM device wcd0 #IDE CD-ROM device sc0 at isa? port "IO_KBD" tty irq 1 vector scintr device npx0 at isa? port "IO_NPX" irq 13 vector npxintr # # Laptop support (see LINT for more options) # device apm0 at isa? # Advanced Power Management options APM_BROKEN_STATCLOCK # Workaround some buggy APM BIOS device sio0 at isa? port "IO_COM1" tty irq 4 vector siointr device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr device sio2 at isa? port "IO_COM3" tty irq 9 vector siointr device lpt0 at isa? port? tty irq 7 vector lptintr device psm0 at isa? port "IO_KBD" conflicts tty irq 12 vector psmintr # Sound devices controller snd0 device sb0 at isa? port 0x220 irq 5 drq 1 vector sbintr options SBC_IRQ=5 device sbxvi0 at isa? drq 5 device sbmidi0 at isa? port 0x330 device opl0 at isa? port 0x388 # Order is important here due to intrusive probes, do *not* alphabetize # this list of network interfaces until the probes have been fixed. # Right now it appears that the ie0 must be probed before ep0. See # revision 1.20 of this file. pseudo-device loop pseudo-device speaker pseudo-device tun 2 pseudo-device pty 16 pseudo-device gzip # Exec gzipped a.out's pseudo-device vn #Vnode driver (turns a file into a device) And dmesg output: 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.5-RELEASE #0: Sat Oct 25 02:07:45 CDT 1997 dcarmich@dcarmich.pr.mcs.net:/usr/src/sys/compile/NECVERSA CPU: Pentium (150.85-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x544 Stepping=4 Features=0x8001bf real memory = 50331648 (49152K bytes) avail memory = 47636480 (46520K bytes) Probing for devices on PCI bus 0: chip0 rev 2 on pci0:0 chip1 rev 3 on pci0:1 vga0 rev 69 on pci0:2 chip2 rev 4 int a irq ?? on pci0:3:0 chip3 rev 4 int b irq ?? on pci0:3:1 Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> pccard driver sio added sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A sio2 at 0x3e8-0x3ef irq 9 on isa sio2: type 16550A lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface psm0 at 0x60-0x64 irq 12 on motherboard psm0: device ID 0 fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in wdc0 at 0x1f0-0x1f7 irq 14 on isa wdc0: unit 0 (wd0): , 32-bit, multi-block-16 wd0: 1376MB (2818368 sectors), 2796 cyls, 16 heads, 63 S/T, 512 B/S npx0 on motherboard npx0: INT 16 interface apm0 on isa apm: found APM BIOS version 1.1 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: PC-Card VLSI 82C146 (5 mem & 2 I/O windows) pcic: controller irq 10 What could be causing the problem? Is there a later PAO that I can use? A prompt response would be appreciated. From owner-freebsd-hackers Sat Oct 25 03:03:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA25325 for hackers-outgoing; Sat, 25 Oct 1997 03:03:45 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from server.local.sunyit.edu (A-T34.rh.sunyit.edu [150.156.210.241]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA25320 for ; Sat, 25 Oct 1997 03:03:41 -0700 (PDT) (envelope-from perlsta@cs.sunyit.edu) Received: from localhost (perlsta@localhost) by server.local.sunyit.edu (8.8.7/8.8.5) with SMTP id GAA00595 for ; Sat, 25 Oct 1997 06:08:36 -0500 (EST) X-Authentication-Warning: server.local.sunyit.edu: perlsta owned process doing -bs Date: Sat, 25 Oct 1997 06:08:36 -0500 (EST) From: Alfred Perlstein X-Sender: perlsta@server.local.sunyit.edu To: hackers@FreeBSD.org Subject: help with buildworld 2.2-stable? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk i've been just cvs-up'd to the latest 2.2-stable from a -stable from a month or so ago, i've been trying: make -j8 buildworld but it keeps bombing out with the error: --- lstReplace.o --- --- lstSucc.o --- --- realinstall --- --- lstReplace.o --- cc -O -I/usr/src/usr.bin/make -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/usr.bin/make/lst.lib/lstReplace.c --- lstSucc.o --- cc -O -I/usr/src/usr.bin/make -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/usr.bin/make/lst.lib/lstSucc.c --- realinstall --- install -c -s -o bin -g bin -m 555 make /usr/obj/usr/src/tmp/usr/bin install: make: No such file or directory *** Error code 71 1 error *** Error code 2 1 error several questions: 1) am i doing the right thing to upgrade to a 2.2.5'ish system? 2) why does the compile fail? it seems to be make'ing "make" when this happens observation: 1) if i go into /usr/src/usr.bin/make and type 'make' then 'make install' it seems to go off without a hitch... please excuse my poor knowledge of make file structure if the problem seems obvious... thank you, .________________________________________________________________________ __ _ |Alfred Perlstein - Programming & SysAdmin --"Have you seen my FreeBSD tatoo?" |perlsta@sunyit.edu --"who was that masked admin?" |http://www.cs.sunyit.edu/~perlsta : ' From owner-freebsd-hackers Sat Oct 25 04:04:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA29091 for hackers-outgoing; Sat, 25 Oct 1997 04:04:36 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA29082; Sat, 25 Oct 1997 04:04:11 -0700 (PDT) (envelope-from se@X14.MI.Uni-Koeln.DE) Received: from x14.mi.uni-koeln.de ([134.95.219.124]) by Octopussy.MI.Uni-Koeln.DE (8.8.7/8.8.7) with ESMTP id NAA14764; Sat, 25 Oct 1997 13:04:08 +0200 (MET DST) Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.7/8.6.9) id AAA01511; Fri, 24 Oct 1997 00:02:29 +0200 (CEST) X-Face: " Date: Fri, 24 Oct 1997 00:02:29 +0200 From: Stefan Esser To: Joerg Wunsch Cc: freebsd-hackers@FreeBSD.ORG, Stefan Esser Subject: Re: 2.2.2-RELEASE '875 SCSI won't negotiage References: <19971021081759.TH50130@uriah.heep.sax.de> <199710220009.TAA18051@nospam.hiwaay.net> <19971022080341.HR59190@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: <19971022080341.HR59190@uriah.heep.sax.de>; from J Wunsch on Wed, Oct 22, 1997 at 08:03:41AM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On 1997-10-22 08:03 +0200, J Wunsch wrote: > As dkelly@hiwaay.net wrote: > > > Went back and RTFM'ed my Asus SC875 manual and obsverved on page 11 > > the default Synchronous Transfer Rate (MS/Sec) (sic) is 20. So is this MB/ > > sec or MHz? > > MHz. Together with the 16-bit bus, it makes a theoretical maximum of > 40 MB/s (minus transaction overhead which is, as Stefan mentioned, not > neglicible). The theoretical maximum is 40,000,000 bytes per second, or 38.1 * 1024*1024 bytes per second (== 38.1 MB/s). This would still allow for some 600 transfers of 64KB each. Fast drives offer a command overhead of some 50us with a fast controller. If the bus is to be saturated, and the maximum transfer length is 64KB, then the overhead is at least some 30ms per second, or 3%. We get a maximum net data rate of some 36.9MB/s, under those assumptions. Regards, STefan From owner-freebsd-hackers Sat Oct 25 04:05:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA29141 for hackers-outgoing; Sat, 25 Oct 1997 04:05:09 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA29131 for ; Sat, 25 Oct 1997 04:05:05 -0700 (PDT) (envelope-from se@X14.MI.Uni-Koeln.DE) Received: from x14.mi.uni-koeln.de ([134.95.219.124]) by Octopussy.MI.Uni-Koeln.DE (8.8.7/8.8.7) with ESMTP id NAA14784 for ; Sat, 25 Oct 1997 13:05:02 +0200 (MET DST) Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.7/8.6.9) id KAA00722; Sat, 25 Oct 1997 10:35:22 +0200 (CEST) X-Face: " Date: Sat, 25 Oct 1997 10:35:22 +0200 From: Stefan Esser To: Don Lewis Cc: Joerg Wunsch , freebsd-hackers@FreeBSD.ORG Subject: Re: 2.2.2-RELEASE '875 SCSI won't negotiage References: <199710212347.QAA09208@salsa.gv.tsc.tdk.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: <199710212347.QAA09208@salsa.gv.tsc.tdk.com>; from Don Lewis on Tue, Oct 21, 1997 at 04:47:42PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On 1997-10-21 16:47 -0700, Don Lewis wrote: > On Oct 22, 12:13am, Stefan Esser wrote: > } > > > sd0(ncr0:0:0): WIDE SCSI (16 bit) enabled > } > > > sd0(ncr0:0:0): 20.0 MB/s (100 ns, offset 16) > } If 40MB/s is reported, you still won't be able to get > } more than some 37MB/s moved, actually, but well, it is > } the number claimed by the drive and controller vendors, > } and so it can't be wrong to report it :) > > But isn't this misleading if it's only connected to narrow devices? Sure, it was, if that number was printed for a narrow device. But it of course isn't: This is a per device message, and a narrow device would have 20MB/s in its attach message (while actually being limited to some 18.5MB/s). Regards, STefan From owner-freebsd-hackers Sat Oct 25 04:05:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA29177 for hackers-outgoing; Sat, 25 Oct 1997 04:05:43 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA29171 for ; Sat, 25 Oct 1997 04:05:39 -0700 (PDT) (envelope-from se@X14.MI.Uni-Koeln.DE) Received: from x14.mi.uni-koeln.de ([134.95.219.124]) by Octopussy.MI.Uni-Koeln.DE (8.8.7/8.8.7) with ESMTP id NAA14757; Sat, 25 Oct 1997 13:04:04 +0200 (MET DST) Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.7/8.6.9) id LAA00954; Sat, 25 Oct 1997 11:15:40 +0200 (CEST) X-Face: " Date: Sat, 25 Oct 1997 11:15:40 +0200 From: Stefan Esser To: dkelly@hiwaay.net Cc: Joe McGuckin , freebsd-hackers@FreeBSD.ORG Subject: Re: 2.2.2-RELEASE '875 SCSI won't negotiage References: <199710210124.UAA14405@nospam.hiwaay.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: <199710210124.UAA14405@nospam.hiwaay.net>; from dkelly@hiwaay.net on Mon, Oct 20, 1997 at 08:24:34PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On 1997-10-20 20:24 -0500, dkelly@hiwaay.net wrote: > ncr0 rev 3 int a irq 11 on pci0:11 > ncr0 waiting for scsi devices to settle > (ncr0:0:0): WIDE SCSI (16 bit) enabled(ncr0:0:0): 10.0 MB/s (200 ns, offset 15) > (ncr0:0:0): "IBM OEM DCHS09W 2222" type 0 fixed SCSI 2 > sd1(ncr0:0:0): Direct-Access > sd1(ncr0:0:0): WIDE SCSI (16 bit) enabled > sd1(ncr0:0:0): 20.0 MB/s (100 ns, offset 15) > 8689MB (17796077 512 byte sectors) This is correct for the non-Ultra version of the NCR driver (as of 2.2-stable before September 8, 1997). > Am mildly concerned about the 10.0 MB/s message that starts it off. And I'm No reason to worry! The IBM drives have certain specific features, and their active request for negotiation of a synchronous data rate is one of them. The driver does not know anything about the drive, when it initiates the negotiation, and will not go beyond 5MHz, at that stage. After the INQUIRY returned the drive name and features, and after the quirks code had a chance to limit what the driver will agree on, the driver initiates a negotiation and the final synchronous transfer parameters are agreed on. > thinking about the whole issue because I'm not certian my performance is up > to snuff. Using bonnie: > > IBM OEM DCHS09W on Asus SC875, new & empty 2.4G filesystem at end of disk: > -------Sequential Output-------- ---Sequential Input-- --Random-- > -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- > MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU > 100 3972 41.8 3986 14.6 2234 7.5 6700 76.3 8228 16.4 108.4 2.6 > ^^^^ this seems low This IS low! Seems your drive does not signal early command completion on writes, even if tags are used (or did you disable tags ?) What's the state of the WCE bit in mode page 8 ? # scsi -f /dev/sd0 -m 8 WCE: 1 [ ... having read further down, I see you DTRT WRT WCE ... ] But your other Bonnie numbers seem odd, too. Or was there much other activity on that system at the time of the test ? The "per char" input rate should only be limited by available CPU cycles, or the data rate should be no lower than in the "block" input case. Having the file system at the end of the disk does of course affect performance. > SEAGATE ST32550N on Adaptec 2940 (AIC-7870) old 86% full 1.8G fs > -------Sequential Output-------- ---Sequential Input-- --Random-- > -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- > MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU > 100 3980 43.2 4402 13.9 1774 5.0 4260 48.3 3759 5.7 71.5 1.5 > > System is an Asus P6NP5 PPro-166/512k 32M RAM. > > # scsi -f /dev/rsd1c -m 8 -P 3 > WCE: 0 > Observed the Seagate had the WCE set (Write Cache Enable) so I did the same > for the IBM. > > Flipped the WCE bit from 0 to 1 and got this on the IBM (last fs): > -------Sequential Output-------- ---Sequential Input-- --Random-- > -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- > MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU > 100 7402 76.5 7927 31.0 2311 7.8 6587 75.2 8207 16.2 110.3 2.5 > ^^^^ ^^^^ both of these are *much* better. With an assumed data rate of near 8MB/s and a 64KB transfer, you wrote 64KB in 8ms. Since Bonnie could not issue the next command in time, one revolution of the media (8.3ms) was lost, and the actual peformance was near 64KB/16ms or 4MB/s. > After enabling the write cache, this drive is comparable to the new Seagate > 4.3G Barracuda on an Adaptec 2940AU (AIC-7860) and P-133 I'm playing with > at work: > -------Sequential Output-------- ---Sequential Input-- --Random-- > -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- > MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU > 100 3653 75.6 8523 36.4 2293 15.9 3595 70.6 9183 38.4 92.2 4.3 This is obviously a file system on the outer tracks (or only a few hundred MB offset from the start of the disk). > It really bugged me that my UW HD on PentiumPro was being beat by a P-133 > with narrow SCSI. Then I began to wonder if there was a difference between Well, I beat most people's Bonnie results with my 486/133 and a 2GB Quantum Atlas connected to a NCR 53c810 for quite a while :) > inner and outer tracks. This fs starts about 200M past block 0, while the > above (up 2, the IBM) starts 2.4G from the end of the disk: > -------Sequential Output-------- ---Sequential Input-- --Random-- > -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- > MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU > 100 8098 79.7 9385 38.3 2758 9.2 6426 74.0 9772 20.1 111.2 2.5 > > ...and that's more like it! Yes, it definitely is ... ;) Regards, STefan From owner-freebsd-hackers Sat Oct 25 07:22:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA04845 for hackers-outgoing; Sat, 25 Oct 1997 07:22:43 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA04840 for ; Sat, 25 Oct 1997 07:22:39 -0700 (PDT) (envelope-from se@X14.MI.Uni-Koeln.DE) Received: from x14.mi.uni-koeln.de ([134.95.219.124]) by Octopussy.MI.Uni-Koeln.DE (8.8.7/8.8.7) with ESMTP id QAA15923; Sat, 25 Oct 1997 16:22:33 +0200 (MET DST) Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.7/8.6.9) id OAA01064; Sat, 25 Oct 1997 14:03:01 +0200 (CEST) X-Face: " Date: Sat, 25 Oct 1997 14:03:01 +0200 From: Stefan Esser To: Neil Ludban Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: ncr53c875j under FreeBSD-2.2.2 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On 1997-10-19 22:58 -0400, Neil Ludban wrote: > Hello, > > I've ruled out everything I could think of on this problem, and what's > left points to a question about the ncr driver for -hackers. > > I'm trying to get FreeBSD 2.2.2-RELEASE to recognize a Diamond FirePort40 > SCSI adapter, which uses the NCR 53c875j chip. A borrowed Asus PCI-SC875 > is recognized correctly on the same system (53c875 chip, no j). I looked > through the ncr code and found the identification numbers for different > chip numbers, but didn't see anything about the 875j or even different > revisions of other chips. Sorry, Symbios used a different PCI chip ID for the J version of the 875, for reasons I do not really understand, but did not mention this in the 875 data book. The driver was fixed to accept both chip IDs (there is no difference between the two, as far as the NCR driver is concerned). But this was too late for 2.2.2 ... > Can anyone tell me if this should already work (I got a bad card, or a > messed up BIOS), or explain where to start to add support? According to > Symbios' web site, the j suffix means it "supports JTAG boundary scan for > onboard testing." I assume that if the current driver were to recognize > it, it would act like a plain 875, which would be good enough for me. It does and it is :) > A possibly related problem is that having both SCSI cards installed at > once, or the Asus with a PCI NIC (ed2, RealTek 8029) causes the boot to > hang after the imasks line. The next thing should have been the BIOS > disk geometries. FWIW, the geometry of the SCSI disk is correct for > either controller. Hmmm, that's strange. I'm using two NCR SCSI chips and a RealTek 8029 based Ethernet card in my system, too ... My guess is, that there is an IRQ conflict between PCI and ISA. Could verify, that none of the IRQs printed for the PCI cards is configured for one of your ISA cards, too. I do not know anything about your PCI BIOS (whether it dynamically assigns interrupts to PCI slots, for example), but assume some kind of configuration problem exists. > pci0:12: NCR/Symbios, device=0x008f, class=storage (scsi) int a irq 11 > [no driver assigned] Just replace the line reading: #define NCR_875_ID (0x000f1000ul) by: #define NCR_875_ID (0x008f1000ul) and rebuild your kernel. But this will make the driver ignore the non-J version of the 875. The drivers in 2.2-stable and -current have been fixed to accept both PCI IDs for quite some time, so you may want to upgrade, if you need one kernel that supports both at a time. Regards, STefan From owner-freebsd-hackers Sat Oct 25 09:08:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA08702 for hackers-outgoing; Sat, 25 Oct 1997 09:08:25 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from burka.carrier.kiev.ua (root@burka.carrier.kiev.ua [193.193.193.107]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA08638 for ; Sat, 25 Oct 1997 09:07:54 -0700 (PDT) (envelope-from archer@grape.carrier.kiev.ua) Received: from sivka.carrier.kiev.ua (root@sivka.carrier.kiev.ua [193.193.193.101]) by burka.carrier.kiev.ua (8.8.6/8.8.6) with ESMTP id TAA18815 for ; Sat, 25 Oct 1997 19:07:24 +0300 (EEST) Received: (from uucp@localhost) by sivka.carrier.kiev.ua (8.8.7/8.8.7) with UUCP id TAA26527 for hackers@freebsd.org; Sat, 25 Oct 1997 19:02:50 +0300 (EEST) Received: (from archer@localhost) by grape.carrier.kiev.ua (8.8.7/8.8.7) id SAA11255; Sat, 25 Oct 1997 18:49:23 +0300 (EEST) Date: Sat, 25 Oct 1997 18:49:23 +0300 (EEST) From: Alexander Litvin Message-Id: <199710251549.SAA11255@grape.carrier.kiev.ua> To: hackers@freebsd.org Subject: Re: de0 errors In-Reply-To: <199710230955.CAA13696@salsa.gv.tsc.tdk.com> <19971023112105.56949@crh.cl.msu.edu> X-Newsreader: TIN [UNIX 1.3 unoff BETA 970424; i386 FreeBSD 2.2.5-971010-BETA] Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I experience the same. No problem it would be, but with that card the box also seems to lockup after a while :( It is our proxy server, quite busy (about 30000 requests per hour), and I don't have opportunity to investigate it in details, but after installation of DE it locked up two times during one hour, so I decided to put back PCI ed. All that on 2.2.5, 266MHz P-II, Intel LX chipset. In article <19971023112105.56949@crh.cl.msu.edu> you wrote: > On the subject of Re: de0 errors, Don Lewis stated: > > packets will be sent, but your card may not be operating as efficiently > > as possible. > > > > What speed is your network (10Mb or 100Mb)? What speed does the de driver > > think it's running at? What kind of card do you have? > Its a 100mbit network, the card thinks its a 100mbit network. > de0 rev 18 int a irq 9 on pci0:20 > de0: SMC 9332DST 21140 [10-100Mb/s] pass 1.2 > de0: address 00:00:c0:9e:ba:c7 > de0: enabling 100baseTX port > de0: flags=8843 mtu 1500 > inet 35.8.2.20 netmask 0xfff80000 broadcast 35.15.255.255 > ether 00:00:c0:9e:ba:c7 > media: 100baseTX status: active > -Crh > Charles Henrich Michigan State University henrich@msu.edu > http://pilot.msu.edu/~henrich -- Litvin Alexander "Real Programs dump Core" From owner-freebsd-hackers Sat Oct 25 10:35:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA12460 for hackers-outgoing; Sat, 25 Oct 1997 10:35:50 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA12440; Sat, 25 Oct 1997 10:35:44 -0700 (PDT) (envelope-from nate@rocky.mt.sri.com) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id LAA28680; Sat, 25 Oct 1997 11:35:42 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id LAA24441; Sat, 25 Oct 1997 11:35:41 -0600 (MDT) Date: Sat, 25 Oct 1997 11:35:41 -0600 (MDT) Message-Id: <199710251735.LAA24441@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Douglas Carmichael Cc: freebsd-hackers@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: 2.2.5-RELEASE installs fine, but can't detect TI PCI-1130 CardBus controller In-Reply-To: <199710250828.DAA00245@dcarmich.pr.mcs.net> References: <199710250828.DAA00245@dcarmich.pr.mcs.net> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I installed the 2.2.5-RELEASE bindist and srcdist from > ftp2.freebsd.org and they installed fine over my existing > 2.2.2-RELEASE/PAO-970616 system, but 2.2.5-RELEASE does not detect my > NEC Versa 6050MH laptop's TI PCI-1130 CardBus PCMCIA controller when > 2.2.2-RELEASE correctly detected it. ^^^^^^^^^^^^^ There have been *NO* changes from 2.2.2 -> 2.2.5 in the pccard code, so I'm pretty sure that 2.2.2 never detected your controller w/out the PAO patches. And, there isn't (yet?) a PAO release for 2.2.5, so you'll have to wait until one is made, or port the patches from PAO to 2.2.5. But, I'm confused: > And dmesg output: > 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.5-RELEASE #0: Sat Oct 25 02:07:45 CDT 1997 > dcarmich@dcarmich.pr.mcs.net:/usr/src/sys/compile/NECVERSA ... > PC-Card VLSI 82C146 (5 mem & 2 I/O windows) > pcic: controller irq 10 It certainly looks like your controller is found to me. Nate From owner-freebsd-hackers Sat Oct 25 11:56:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA16076 for hackers-outgoing; Sat, 25 Oct 1997 11:56:17 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA16071 for ; Sat, 25 Oct 1997 11:56:14 -0700 (PDT) (envelope-from jamil@trojanhorse.ml.org) Received: from localhost (jamil@localhost) by trojanhorse.ml.org (8.8.7/8.8.5) with SMTP id LAA00178 for ; Sat, 25 Oct 1997 11:55:34 -0700 (PDT) Date: Sat, 25 Oct 1997 11:55:34 -0700 (PDT) From: "Jamil J. Weatherbee" To: freebsd-hackers@freebsd.org Subject: Parity Ram Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Can someone fill me in on when you would want to use parity ram as opposed to non-parity ram these days? If there was some anomaly in memory how would freebsd handle it (is there a trap for parity error?) From owner-freebsd-hackers Sat Oct 25 12:33:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA17653 for hackers-outgoing; Sat, 25 Oct 1997 12:33:49 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from isgate.is (isgate.is [193.4.58.51]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA17642 for ; Sat, 25 Oct 1997 12:33:45 -0700 (PDT) (envelope-from totii@est.is) Received: from eh.est.is (eh.est.is [194.144.208.34]) by isgate.is (8.7.5-M/) with ESMTP id TAA29704; Sat, 25 Oct 1997 19:32:23 GMT Received: from didda.est.is (totii@ppp-22.est.is [194.144.208.122]) by eh.est.is (8.8.5/8.8.5) with SMTP id TAA20876; Sat, 25 Oct 1997 19:30:53 GMT Message-ID: <34524948.41C67EA6@est.is> Date: Sat, 25 Oct 1997 19:32:24 +0000 From: =?iso-8859-1?Q?=DEor=F0ur?= Ivarsson X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386) MIME-Version: 1.0 To: "Jamil J. Weatherbee" CC: freebsd-hackers@FreeBSD.ORG Subject: Re: Parity Ram References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jamil J. Weatherbee wrote: > > Can someone fill me in on when you would want to use parity ram as opposed > to non-parity ram these days? If there was some anomaly in memory how > would freebsd handle it (is there a trap for parity error?) As far as I know, the 'parity check fail' is connected to NMI of CPU. In most cases the BIOS rutines accept this and halt the computer with no information on where or why , only something like 'NMI detected, system halted' or 'Memory parity fail - NMI generated , system halted'. The only reason for this might be giving you some warning of failed memory rather than failed software. This has helped me several times when I was suspecting broken memory in the old days (90-93) :-) Thordur Ivarsson From owner-freebsd-hackers Sat Oct 25 12:43:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA18150 for hackers-outgoing; Sat, 25 Oct 1997 12:43:09 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from fly.HiWAAY.net (root@fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA18133; Sat, 25 Oct 1997 12:42:57 -0700 (PDT) (envelope-from dkelly@nospam.hiwaay.net) Received: from nospam.hiwaay.net (max7-198.HiWAAY.net [208.147.145.198]) by fly.HiWAAY.net (8.8.7/8.8.6) with ESMTP id OAA29225; Sat, 25 Oct 1997 14:42:51 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by nospam.hiwaay.net (8.8.7/8.8.4) with ESMTP id NAA08387; Sat, 25 Oct 1997 13:31:47 -0500 (CDT) Message-Id: <199710251831.NAA08387@nospam.hiwaay.net> X-Mailer: exmh version 2.0zeta 7/24/97 To: Stefan Esser cc: freebsd-hackers@FreeBSD.ORG From: dkelly@HiWAAY.net Subject: Re: ncr53c875j under FreeBSD-2.2.2 In-reply-to: Message from Stefan Esser of "Sat, 25 Oct 1997 14:03:01 +0200." <19971025140301.61013@mi.uni-koeln.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 25 Oct 1997 13:31:46 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Stefan Esser said: > > My guess is, that there is an IRQ conflict between PCI and ISA. Could > verify, that none of the IRQs printed for the PCI cards is configured > for one of your ISA cards, too. I do not know anything about your PCI > BIOS (whether it dynamically assigns interrupts to PCI slots, for > example), but assume some kind of configuration problem exists. Is it OK for PCI cards to share the same IRQ? I was thinking my Asus SC875 and IBM DCHS-39100 were not performing up to par and found it on IRQ 9, also the 2940 and Mach32 were all on IRQ 9. Now the performance is up to expectations after I discovered write buffering was not enabled on the DCHS. -- David Kelly N4HHE, dkelly@hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. From owner-freebsd-hackers Sat Oct 25 13:06:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA19053 for hackers-outgoing; Sat, 25 Oct 1997 13:06:04 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from ns2.cetlink.net (root@ns2.cetlink.net [209.54.54.20]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA19043 for ; Sat, 25 Oct 1997 13:05:59 -0700 (PDT) (envelope-from jak@cetlink.net) Received: from ts1-cltnc-30-s19.cetlink.net (ts1-cltnc-30-s19.cetlink.net [209.54.58.30]) by ns2.cetlink.net (8.8.5/8.8.5) with SMTP id QAA29372; Sat, 25 Oct 1997 16:05:37 -0400 (EDT) From: jak@cetlink.net (John Kelly) To: dwhite@resnet.uoregon.edu To: hackers@FreeBSD.ORG Subject: Re: 48 meg double fault moved to 64 meg in 2.2.5 Date: Sat, 25 Oct 1997 14:24:29 -0400 Message-ID: In-Reply-To: Lines: 77 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Doug White wrote: >> I have extra parts to build a third machine identical to the >> configuration which shows the problem. >Keep us posted. If you find anything consistent, you should send >it using send-pr and maybe followup to hackers@freebsd.org. The problem does occur with no SCSI present -- just the motherboard and a video card. When testing it this way, I had to use the floppy controller on the motherboard instead of the faster one on the Buslogic SCSI card. That seems to rule out either floppy controller as a cause of the problem. I found a CMOS option called "DRAM Hole for UNIX(64MB)" which I enabled to see what would happen. With 64 meg and 2.2.5, the problem disappeared. But with 48 meg and 2.2.2 it had no effect, and the double fault still occurred. I'm guessing that's because the BIOS does not try to create that DRAM hole unless you fill the board with 64 meg of memory -- as they do say in parentheses "(64MB)." Unfortunately, I can't keep the "DRAM hole" enabled, because after a reboot the memory test fails, and the only cure is the hardware reset button. Even if I could leave it enabled, it's of no help at all with 48 meg and the 2.2.2 boot floppy. The memory test failure after a reboot may happen because this motherboard does not have address line 26 wired to the chipset, and thus anything over 64 meg cannot be addressed properly. Presumably, to create the "DRAM hole," the BIOS remaps some memory from below the 64 meg line to above 64 meg, and once it's put there, it can no longer be seen, since A26 is unusable -- at least not by the chipset (although A26 is wired between the CPU and the local bus). I learned about the A26 problem on this motherboard when I tried using the linear addressing feature of XFree86 with my Cirrus 5430 video card. Although the video card tries to use the A26 line to remap its memory above the 64 meg line, the motherboard could not handle it. The XFree docs have a good explanation of this situation in X11R6/lib/X11/doc/README.cirrus. But as for the motherboard and the boot floppy problem, I don't understand the purpose of the "DRAM hole for UNIX," although it clearly does have a positive effect on the boot floppy problem when it's activated with 64 meg in the machine. Is it true that this problem only occurs with the boot floppy? The last good message I see with the 2.2.2 boot floppy and 48 meg is "changing root device to fd0c," and then immediately the "panic: double fault" appears. Since floppy controllers use DMA, perhaps DMA and the bounce buffers are an issue? Addressing memory remapped above 64 meg may also be part of the problem, at least on this motherboard. I did find an interesting tidbit in Messmer's "Indispensable PC Hardware Book" (second edition). On page 621 he says: "DMA transfer is not a trivial job, especially when paging is enabled, even for the operating system ... as the DMA controller overwrites the physical memory contents mercilessly without any care for the protection mechanisms of the protected mode ... an incorrectly initialized DMA chip may ... crash ... the complete computer system." Hmmm... sounds familiar. Oh well, I've reached the limits of my knowledge in these areas. I hope my report is of some help to the experts. John From owner-freebsd-hackers Sat Oct 25 13:17:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA19850 for hackers-outgoing; Sat, 25 Oct 1997 13:17:52 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from earth.mat.net (root@earth.mat.net [206.246.122.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA19845 for ; Sat, 25 Oct 1997 13:17:49 -0700 (PDT) (envelope-from chuckr@glue.umd.edu) Received: from picnic.mat.net (picnic.mat.net [206.246.122.117]) by earth.mat.net (8.8.7/8.6.12) with SMTP id QAA29210; Sat, 25 Oct 1997 16:17:07 -0400 (EDT) Date: Sat, 25 Oct 1997 15:16:26 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@picnic.mat.net To: =?iso-8859-1?Q?=DEor=F0ur?= Ivarsson cc: "Jamil J. Weatherbee" , freebsd-hackers@FreeBSD.ORG Subject: Re: Parity Ram In-Reply-To: <34524948.41C67EA6@est.is> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.freebsd.org id NAA19846 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 25 Oct 1997, Žoršur Ivarsson wrote: > Jamil J. Weatherbee wrote: > > > > Can someone fill me in on when you would want to use parity ram as opposed > > to non-parity ram these days? If there was some anomaly in memory how > > would freebsd handle it (is there a trap for parity error?) > > As far as I know, the 'parity check fail' is connected to NMI of CPU. > In most cases the BIOS rutines accept this and halt the computer with no > information on where or why , only something like 'NMI detected, system > halted' or > 'Memory parity fail - NMI generated , system halted'. Huh ? BIOS routines? What's that got to do with FreeBSD? We don't use the BIOS routines, they don't get called at all, right? If there's a parity violation, if that's wired to NMI, then the NMI get's called, but what that does is determined by FreeBSD, not your BIOS. > > The only reason for this might be giving you some warning of failed > memory rather > than failed software. > > This has helped me several times when I was suspecting broken memory in > the old days (90-93) :-) > > Thordur Ivarsson > > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-hackers Sat Oct 25 13:28:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA20576 for hackers-outgoing; Sat, 25 Oct 1997 13:28:10 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from verdi.nethelp.no (verdi.nethelp.no [195.1.171.130]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id NAA20565 for ; Sat, 25 Oct 1997 13:28:06 -0700 (PDT) (envelope-from sthaug@nethelp.no) From: sthaug@nethelp.no Received: (qmail 23834 invoked by uid 1001); 25 Oct 1997 20:28:01 +0000 (GMT) To: jamil@trojanhorse.ml.org Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Parity Ram In-Reply-To: Your message of "Sat, 25 Oct 1997 11:55:34 -0700 (PDT)" References: X-Mailer: Mew version 1.05+ on Emacs 19.28.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Sat, 25 Oct 1997 22:28:01 +0200 Message-ID: <23832.877811281@verdi.nethelp.no> Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Can someone fill me in on when you would want to use parity ram as opposed > to non-parity ram these days? To avoid silently corrupting your data? > If there was some anomaly in memory how > would freebsd handle it (is there a trap for parity error?) If you have a decent chipset (eg. 430HX, 440FX) parity memory can actually give you single bit error correction, and double bit error detection. This is actually quite a bit better than straight parity. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-hackers Sat Oct 25 13:31:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA20844 for hackers-outgoing; Sat, 25 Oct 1997 13:31:02 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from fallout.campusview.indiana.edu (fallout.campusview.indiana.edu [149.159.1.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA20838 for ; Sat, 25 Oct 1997 13:30:59 -0700 (PDT) (envelope-from jfieber@indiana.edu) Received: from localhost (jfieber@localhost) by fallout.campusview.indiana.edu (8.8.7/8.8.7) with SMTP id PAA18625; Sat, 25 Oct 1997 15:30:57 -0500 (EST) Date: Sat, 25 Oct 1997 15:30:57 -0500 (EST) From: John Fieber To: "Jamil J. Weatherbee" cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Parity Ram In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 25 Oct 1997, Jamil J. Weatherbee wrote: > Can someone fill me in on when you would want to use parity ram as opposed > to non-parity ram these days? So when your memory fails, you know it was a memory failure rather than an irreproducable software bug. Also, with appropriate BIOS support, you can get not only error detection, but some error correction capability. My question is why would anybody want to use non-parity ram? -john From owner-freebsd-hackers Sat Oct 25 13:59:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA23218 for hackers-outgoing; Sat, 25 Oct 1997 13:59:10 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id NAA23206 for ; Sat, 25 Oct 1997 13:59:06 -0700 (PDT) (envelope-from tom@sdf.com) Received: from tom by misery.sdf.com with smtp (Exim 1.73 #1) id 0xPDH4-0006F2-00; Sat, 25 Oct 1997 13:57:35 -0700 Date: Sat, 25 Oct 1997 13:57:34 -0700 (PDT) From: Tom To: freebsd-hackers@freebsd.org Subject: Re: Parity Ram In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 25 Oct 1997, Jamil J. Weatherbee wrote: > Can someone fill me in on when you would want to use parity ram as opposed Why? To discover memory problems before they corrupt data, and cause random panics, core dumps, hangs, or file system corruption. Personally, I use ECC capable motherboards that can actually use parity to fix some errors. > to non-parity ram these days? If there was some anomaly in memory how > would freebsd handle it (is there a trap for parity error?) These days? RAM can fail. Nothing has changed in the last 10 years. I've bought about a gig of RAM in the last couple of months, a good percentage of SIMMs still arrive DOA. FreeBSD systems simple reboot upon parity errors. This is pretty safe thing to do. Much better than what a non-parity system would at this point (ex. corrupt your filesystems). A smarter thing to do, might be to simple stop the process owning the memory that failed, and flag the area as unusable (NT does this). Doesn't help much if kernel is in the bad memory area though. Tom From owner-freebsd-hackers Sat Oct 25 14:00:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA23360 for hackers-outgoing; Sat, 25 Oct 1997 14:00:13 -0700 (PDT) (envelope-from owner-freebsd-hackers) 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 OAA23353 for ; Sat, 25 Oct 1997 14:00:08 -0700 (PDT) (envelope-from jkh@time.cdrom.com) 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 NAA18149; Sat, 25 Oct 1997 13:59:50 -0700 (PDT) To: jak@cetlink.net (John Kelly) cc: dwhite@resnet.uoregon.edu, hackers@FreeBSD.ORG Subject: Re: 48 meg double fault moved to 64 meg in 2.2.5 In-reply-to: Your message of "Sat, 25 Oct 1997 14:24:29 EDT." Date: Sat, 25 Oct 1997 13:59:50 -0700 Message-ID: <18145.877813190@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > With 64 meg and 2.2.5, the problem disappeared. But with 48 meg > and 2.2.2 it had no effect, and the double fault still occurred. > I'm guessing that's because the BIOS does not try to create that > DRAM hole unless you fill the board with 64 meg of memory -- as > they do say in parentheses "(64MB)." Hmmm. Bizarre. Ick. > The memory test failure after a reboot may happen because this > motherboard does not have address line 26 wired to the chipset, > and thus anything over 64 meg cannot be addressed properly. You know, christmas is coming up and a new Tyan motherboard would probably not be that expensive. ;-) > Is it true that this problem only occurs with the boot floppy? Correct. > The last good message I see with the 2.2.2 boot floppy and 48 > meg is "changing root device to fd0c," and then immediately the > "panic: double fault" appears. Yep, that sounds like the problem we've seen alright. Never did find it in 2.2.2 and, now that it's mysteriously moved itself, are going to have Even More Fun(tm) trying to track it down in 2.2-stable. I'm sure that it's going to turn out to be something in the D'OH! category when found. > Since floppy controllers use DMA, perhaps DMA and the bounce > buffers are an issue? Addressing memory remapped above 64 meg > may also be part of the problem, at least on this motherboard. I suppose I could always build you a boot floppy without bounce buffering, just to see what effect it has, but that wouldn't do your Buslogic controller any good at all during an actual installation. ;-) Jordan From owner-freebsd-hackers Sat Oct 25 14:09:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA23853 for hackers-outgoing; Sat, 25 Oct 1997 14:09:34 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA23848 for ; Sat, 25 Oct 1997 14:09:31 -0700 (PDT) (envelope-from se@X14.MI.Uni-Koeln.DE) Received: from x14.mi.uni-koeln.de ([134.95.219.124]) by Octopussy.MI.Uni-Koeln.DE (8.8.7/8.8.7) with ESMTP id XAA18070; Sat, 25 Oct 1997 23:09:28 +0200 (MET DST) Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.7/8.6.9) id XAA03524; Sat, 25 Oct 1997 23:09:34 +0200 (CEST) X-Face: " Date: Sat, 25 Oct 1997 23:09:32 +0200 From: Stefan Esser To: dkelly@hiwaay.net Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: ncr53c875j under FreeBSD-2.2.2 References: <199710251831.NAA08387@nospam.hiwaay.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: <199710251831.NAA08387@nospam.hiwaay.net>; from dkelly@HiWAAY.net on Sat, Oct 25, 1997 at 01:31:46PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On 1997-10-25 13:31 -0500, dkelly@HiWAAY.net wrote: > Stefan Esser said: > > > > My guess is, that there is an IRQ conflict between PCI and ISA. Could > > verify, that none of the IRQs printed for the PCI cards is configured > > for one of your ISA cards, too. I do not know anything about your PCI > > BIOS (whether it dynamically assigns interrupts to PCI slots, for > > example), but assume some kind of configuration problem exists. > > Is it OK for PCI cards to share the same IRQ? I was thinking my Asus > SC875 and IBM DCHS-39100 were not performing up to par and found it on > IRQ 9, also the 2940 and Mach32 were all on IRQ 9. Now the performance > is up to expectations after I discovered write buffering was not > enabled on the DCHS. PCI requires all cards to support shared interrupts, while PCI chips wired onto a motherboard need not. The interrupt code in FreeBSD knows how to deal with shared interrupts, but there is some (low) additional overhead, since all cards that share an interrupt have to be polled to find the real interrupt source. If anybody observes performance problems which depend on shared interrupts, I'd like to hear about them. On one occasion, going from shared to exclusive IRQs helped performance a lot, but there may have been some configuration or setup problem. I have tried shared interrupts on my system (which does require manual assignment of IRQs to PCI slots), and found no measurable difference in performance with 2 NCR SCSI cards and one PCI NE2000 clone all using the same IRQ. Regards, STefan From owner-freebsd-hackers Sat Oct 25 14:11:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA23968 for hackers-outgoing; Sat, 25 Oct 1997 14:11:02 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from dfw-ix12.ix.netcom.com (dfw-ix12.ix.netcom.com [206.214.98.12]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA23960 for ; Sat, 25 Oct 1997 14:11:00 -0700 (PDT) (envelope-from wghhicks@ix.netcom.com) Received: (from smap@localhost) by dfw-ix12.ix.netcom.com (8.8.4/8.8.4) id QAA22095 for ; Sat, 25 Oct 1997 16:10:27 -0500 (CDT) Received: from atl-ga17-14.ix.netcom.com(204.32.174.174) by dfw-ix12.ix.netcom.com via smap (V1.3) id rma022079; Sat Oct 25 16:09:57 1997 Message-ID: <34525F3B.1137B612@ix.netcom.com> Date: Sat, 25 Oct 1997 17:06:03 -0400 From: Jerry Hicks Reply-To: wghhicks@ix.netcom.com Organization: TerraEarth X-Mailer: Mozilla 4.03b8 [en] (X11; I; FreeBSD 2.2-STABLE i386) MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.ORG Subject: Re: Parity Ram References: <34524948.41C67EA6@est.is> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Žoršur Ivarsson wrote: > > This has helped me several times when I was suspecting broken memory in > the old days (90-93) :-) > > Thordur Ivarsson ECC Memory was marginally useful for this years ago when were using NMOS RAM. Lately, most memory failures I've seen are catastrophic, taking out a whole device or better. I'm not a hardware specialist; Does 'Parity RAM' employ a conventional parity scheme, a la asynch serial communications? Didn't Richard Hamming show these to -cause- more problems than they solve? It seems I recall a number like 256K (bits/bytes/words?) as being the threshold in a proof he presented. Jerry Hicks jerry_hicks@bigfoot.com From owner-freebsd-hackers Sat Oct 25 14:30:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA24640 for hackers-outgoing; Sat, 25 Oct 1997 14:30:51 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from out2.ibm.net (out2.ibm.net [165.87.194.229]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA24634 for ; Sat, 25 Oct 1997 14:30:49 -0700 (PDT) (envelope-from SimsS@IBM.Net) Received: from Elvis.RatsNest.VaBeach.Va.Us (slip166-72-229-67.va.us.ibm.net [166.72.229.67]) by out2.ibm.net (8.8.5/8.6.9) with SMTP id VAA49340; Sat, 25 Oct 1997 21:30:43 GMT Received: by localhost with Microsoft MAPI; Sat, 25 Oct 1997 17:30:46 -0400 Message-ID: <01BCE16B.BA31AFE0.SimsS@IBM.Net> From: Steve Sims Reply-To: "SimsS@IBM.Net" To: "'Jordan K. Hubbard'" Cc: "'hackers@freebsd.org'" Subject: RE: Something which 2.2.5 upgraders might find handy. Date: Sat, 25 Oct 1997 17:19:46 -0400 X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4128 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Blew chunks for me on my stove-stock 2.2.2-RELEASE install. (This system was installed two days ago from the latest CD) It started to go well - pkg_add pulled the package from your directory. It backed up /etc to /usr/tmp/etc (so I was protected). I selected "Kernel Developer" and told it to use all of the existing network configuration. I selected FTP as the media. (NB: My default route on the laptop is via ep0 to my desktop running iij-ppp -auto) I couldn't get connected to ftp.freebsd.org. A curse on those SlackWare folks pulling down 'their' latest cut ;-) It attempted to gracefully recover, so I selected ftp4.freebsd.org (since it's closer to me). Segmentation fault. :-( Spilled core and gave me a prompt. The system was sufficiently hosed at this point that I went back to the CD, did a clean install. Restored /usr/tmp/etc/* back to /etc and I was in business again. Under 2.2.2-RELEASE. Oh well. I'll try again later tonight. ...sjs... On Friday, October 24, 1997 5:48 PM, Jordan K. Hubbard [SMTP:jkh@time.cdrom.com] wrote: > In ftp://freebsd.org/pub/jkh/225upgrade.tgz is a small package, simply > saying: > pkg_add ftp://freebsd.org/pub/jkh/225upgrade.tgz > > to launch the 2.2.5 upgrade on your machine. The key thing this > package does is upgrade your /stand to 2.2.5 first so that the > sysinstall upgrade code you run is the latest (and upgrade's been > changed a bit for 2.2.5). All you should need to do is select your > media type, the distributions you want to upgrade and you should be > off and running. > > Let me know how well it works in actual practice. :) > > Jordan > From owner-freebsd-hackers Sat Oct 25 14:37:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA24922 for hackers-outgoing; Sat, 25 Oct 1997 14:37:41 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id OAA24917 for ; Sat, 25 Oct 1997 14:37:38 -0700 (PDT) (envelope-from tom@sdf.com) Received: from tom by misery.sdf.com with smtp (Exim 1.73 #1) id 0xPDsG-0006GR-00; Sat, 25 Oct 1997 14:36:00 -0700 Date: Sat, 25 Oct 1997 14:35:56 -0700 (PDT) From: Tom To: Jerry Hicks cc: freebsd-hackers@freebsd.org Subject: Re: Parity Ram In-Reply-To: <34525F3B.1137B612@ix.netcom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.freebsd.org id OAA24918 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 25 Oct 1997, Jerry Hicks wrote: > Žoršur Ivarsson wrote: > > > > This has helped me several times when I was suspecting broken memory in > > the old days (90-93) :-) > > > > Thordur Ivarsson > > ECC Memory was marginally useful for this years ago when were using NMOS > RAM. Lately, most memory failures I've seen are catastrophic, taking out > a whole device or better. > > I'm not a hardware specialist; Does 'Parity RAM' employ a conventional > parity scheme, a la asynch serial communications? Most do, except for ECC schemes. > Didn't Richard Hamming show these to -cause- more problems than they > solve? It seems I recall a number like 256K (bits/bytes/words?) as being > the threshold in a proof he presented. Huh? I don't understand. How does it cause problems to determine that a memory location is corrupted? > Jerry Hicks > jerry_hicks@bigfoot.com > > Tom From owner-freebsd-hackers Sat Oct 25 14:42:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA25189 for hackers-outgoing; Sat, 25 Oct 1997 14:42:30 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from isgate.is (isgate.is [193.4.58.51]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA25180 for ; Sat, 25 Oct 1997 14:42:27 -0700 (PDT) (envelope-from totii@est.is) Received: from eh.est.is (eh.est.is [194.144.208.34]) by isgate.is (8.7.5-M/) with ESMTP id VAA01372; Sat, 25 Oct 1997 21:42:21 GMT Received: from didda.est.is (totii@ppp-22.est.is [194.144.208.122]) by eh.est.is (8.8.5/8.8.5) with SMTP id VAA24878; Sat, 25 Oct 1997 21:40:51 GMT Message-ID: <345267BF.167EB0E7@est.is> Date: Sat, 25 Oct 1997 21:42:23 +0000 From: =?iso-8859-1?Q?=DEor=F0ur?= Ivarsson X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386) MIME-Version: 1.0 To: wghhicks@ix.netcom.com CC: freebsd-hackers@FreeBSD.ORG Subject: Re: Parity Ram References: <34524948.41C67EA6@est.is> <34525F3B.1137B612@ix.netcom.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id OAA25185 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jerry Hicks wrote: > > Žoršur Ivarsson wrote: > > > > This has helped me several times when I was suspecting broken memory in > > the old days (90-93) :-) > > > > Thordur Ivarsson > > ECC Memory was marginally useful for this years ago when were using NMOS > RAM. Lately, most memory failures I've seen are catastrophic, taking out > a whole device or better. > > I'm not a hardware specialist; Does 'Parity RAM' employ a conventional > parity scheme, a la asynch serial communications? > > Didn't Richard Hamming show these to -cause- more problems than they > solve? It seems I recall a number like 256K (bits/bytes/words?) as being > the threshold in a proof he presented. > > Jerry Hicks > jerry_hicks@bigfoot.com In the old days 8088, 8086, 80186, 80286 and 80386 it was just plain odd or even parity like in serial communications but later on came better algorithm that could really fix wrong bits Thordur Ivarsson From owner-freebsd-hackers Sat Oct 25 14:46:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA25415 for hackers-outgoing; Sat, 25 Oct 1997 14:46:56 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from florence.pavilion.net (florence.pavilion.net [194.242.128.25]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA25407 for ; Sat, 25 Oct 1997 14:46:49 -0700 (PDT) (envelope-from joe@florence.pavilion.net) Received: (from joe@localhost) by florence.pavilion.net (8.8.7/8.8.7) id WAA01411; Sat, 25 Oct 1997 22:45:35 +0100 (BST) Message-ID: <19971025224535.22610@pavilion.net> Date: Sat, 25 Oct 1997 22:45:35 +0100 From: Josef Karthauser To: Douglas Carmichael Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD for digital recording w/PCI multitrack in/out cards? References: <199710082310.SAA21519@Jupiter.Mcs.Net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81 In-Reply-To: <199710082310.SAA21519@Jupiter.Mcs.Net>; from Douglas Carmichael on Wed, Oct 08, 1997 at 06:10:11PM -0500 X-NCC-RegID: uk.pavilion Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > What multitrack recording software exists for FreeBSD? If someone could write a silicon graphics emulation we could all run cubase and dump our pcs :) (Now _that_ would be a nice christmas present.) Joe -- Josef Karthauser Technical Manager Email: joe@pavilion.net Pavilion Internet plc. [Tel: +44 1273 607072 Fax: +44 1273 607073] From owner-freebsd-hackers Sat Oct 25 14:49:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA25524 for hackers-outgoing; Sat, 25 Oct 1997 14:49:15 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from isgate.is (isgate.is [193.4.58.51]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA25515 for ; Sat, 25 Oct 1997 14:49:06 -0700 (PDT) (envelope-from totii@est.is) Received: from eh.est.is (eh.est.is [194.144.208.34]) by isgate.is (8.7.5-M/) with ESMTP id VAA01439; Sat, 25 Oct 1997 21:48:55 GMT Received: from didda.est.is (totii@ppp-22.est.is [194.144.208.122]) by eh.est.is (8.8.5/8.8.5) with SMTP id VAA25196; Sat, 25 Oct 1997 21:47:25 GMT Message-ID: <34526949.2781E494@est.is> Date: Sat, 25 Oct 1997 21:48:57 +0000 From: =?iso-8859-1?Q?=DEor=F0ur?= Ivarsson X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386) MIME-Version: 1.0 To: John Fieber CC: freebsd-hackers@FreeBSD.ORG Subject: Re: Parity Ram References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk John Fieber wrote: > > On Sat, 25 Oct 1997, Jamil J. Weatherbee wrote: > > > Can someone fill me in on when you would want to use parity ram as opposed > > to non-parity ram these days? > > So when your memory fails, you know it was a memory failure > rather than an irreproducable software bug. Also, with > appropriate BIOS support, you can get not only error detection, > but some error correction capability. > > My question is why would anybody want to use non-parity ram? > > -john lot of memory without parity has been sold in low-end computers to cut the price but when you have to work on fix of broken computer it can take long time if you are not going to 'Just replace all the simms'. Very often you will have to run the computer hour after hour to find the broken one if you have parity-less memory. Thordur Ivarsson From owner-freebsd-hackers Sat Oct 25 14:51:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA25702 for hackers-outgoing; Sat, 25 Oct 1997 14:51:57 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from isgate.is (isgate.is [193.4.58.51]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA25694 for ; Sat, 25 Oct 1997 14:51:51 -0700 (PDT) (envelope-from totii@est.is) Received: from eh.est.is (eh.est.is [194.144.208.34]) by isgate.is (8.7.5-M/) with ESMTP id VAA01467; Sat, 25 Oct 1997 21:51:42 GMT Received: from didda.est.is (totii@ppp-22.est.is [194.144.208.122]) by eh.est.is (8.8.5/8.8.5) with SMTP id VAA25240; Sat, 25 Oct 1997 21:50:13 GMT Message-ID: <345269F0.446B9B3D@est.is> Date: Sat, 25 Oct 1997 21:51:44 +0000 From: =?iso-8859-1?Q?=DEor=F0ur?= Ivarsson X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386) MIME-Version: 1.0 To: Tom CC: freebsd-hackers@FreeBSD.ORG Subject: Re: Parity Ram References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Tom wrote: > > On Sat, 25 Oct 1997, Jamil J. Weatherbee wrote: > > > Can someone fill me in on when you would want to use parity ram as opposed > > Why? To discover memory problems before they corrupt data, and cause > random panics, core dumps, hangs, or file system corruption. Personally, > I use ECC capable motherboards that can actually use parity to fix some > errors. You need EDO ram I think for this to work, You need some memory to keep information of what is in your memory before. > > to non-parity ram these days? If there was some anomaly in memory how > > would freebsd handle it (is there a trap for parity error?) > > These days? RAM can fail. Nothing has changed in the last 10 years. > I've bought about a gig of RAM in the last couple of months, a good > percentage of SIMMs still arrive DOA. > > FreeBSD systems simple reboot upon parity errors. This is pretty safe > thing to do. Much better than what a non-parity system would at this > point (ex. corrupt your filesystems). A smarter thing to do, might be to > simple stop the process owning the memory that failed, and flag the area > as unusable (NT does this). Doesn't help much if kernel is in the bad > memory area though. > > Tom From owner-freebsd-hackers Sat Oct 25 14:54:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA25841 for hackers-outgoing; Sat, 25 Oct 1997 14:54:15 -0700 (PDT) (envelope-from owner-freebsd-hackers) 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 OAA25834 for ; Sat, 25 Oct 1997 14:54:12 -0700 (PDT) (envelope-from jkh@time.cdrom.com) 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 OAA18532; Sat, 25 Oct 1997 14:54:13 -0700 (PDT) To: "SimsS@IBM.Net" cc: "'hackers@freebsd.org'" Subject: Re: Something which 2.2.5 upgraders might find handy. In-reply-to: Your message of "Sat, 25 Oct 1997 17:19:46 EDT." <01BCE16B.BA31AFE0.SimsS@IBM.Net> Date: Sat, 25 Oct 1997 14:54:13 -0700 Message-ID: <18528.877816453@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I couldn't get connected to ftp.freebsd.org. A curse on those SlackWare > folks pulling down 'their' latest cut ;-) Actually, the machine was down for most of yesterday on an aborted 1GB upgrade (looks like one of the SIMMs was bad). Looks like the graceful recovery isn't so graceful, though. :-) Thanks, I'll try and reproduce that one. Jordan From owner-freebsd-hackers Sat Oct 25 14:59:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA26088 for hackers-outgoing; Sat, 25 Oct 1997 14:59:34 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from isgate.is (isgate.is [193.4.58.51]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA26080 for ; Sat, 25 Oct 1997 14:59:26 -0700 (PDT) (envelope-from totii@est.is) Received: from eh.est.is (eh.est.is [194.144.208.34]) by isgate.is (8.7.5-M/) with ESMTP id VAA01526; Sat, 25 Oct 1997 21:55:36 GMT Received: from didda.est.is (totii@ppp-22.est.is [194.144.208.122]) by eh.est.is (8.8.5/8.8.5) with SMTP id VAA25532; Sat, 25 Oct 1997 21:54:05 GMT Message-ID: <34526AD7.794BDF32@est.is> Date: Sat, 25 Oct 1997 21:55:35 +0000 From: =?iso-8859-1?Q?=DEor=F0ur?= Ivarsson X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386) MIME-Version: 1.0 To: Chuck Robey CC: "Jamil J. Weatherbee" , freebsd-hackers@FreeBSD.ORG Subject: Re: Parity Ram References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id OAA26084 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Chuck Robey wrote: > > On Sat, 25 Oct 1997, Žoršur Ivarsson wrote: > > > Jamil J. Weatherbee wrote: > > > > > > Can someone fill me in on when you would want to use parity ram as opposed > > > to non-parity ram these days? If there was some anomaly in memory how > > > would freebsd handle it (is there a trap for parity error?) > > > > As far as I know, the 'parity check fail' is connected to NMI of CPU. > > In most cases the BIOS rutines accept this and halt the computer with no > > information on where or why , only something like 'NMI detected, system > > halted' or > > 'Memory parity fail - NMI generated , system halted'. > > Huh ? BIOS routines? What's that got to do with FreeBSD? We don't use > the BIOS routines, they don't get called at all, right? If there's a > parity violation, if that's wired to NMI, then the NMI get's called, but > what that does is determined by FreeBSD, not your BIOS. > > > > > The only reason for this might be giving you some warning of failed > > memory rather > > than failed software. > > > > This has helped me several times when I was suspecting broken memory in > > the old days (90-93) :-) > > > > Thordur Ivarsson Ok, most of the old software and OSes did not fiddle with the NMI entry point so you did always get to the BIOS, but I don't know what happen in FreeBSD it self. Thordur Ivarsson From owner-freebsd-hackers Sat Oct 25 15:19:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA26874 for hackers-outgoing; Sat, 25 Oct 1997 15:19:07 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from dfw-ix1.ix.netcom.com (dfw-ix1.ix.netcom.com [206.214.98.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA26869 for ; Sat, 25 Oct 1997 15:19:05 -0700 (PDT) (envelope-from wghhicks@ix.netcom.com) Received: (from smap@localhost) by dfw-ix1.ix.netcom.com (8.8.4/8.8.4) id RAA20593; Sat, 25 Oct 1997 17:17:19 -0500 (CDT) Received: from atl-ga20-15.ix.netcom.com(205.186.178.79) by dfw-ix1.ix.netcom.com via smap (V1.3) id rma020575; Sat Oct 25 17:16:42 1997 Message-ID: <34526EE2.64DE0BA6@ix.netcom.com> Date: Sat, 25 Oct 1997 18:12:50 -0400 From: Jerry Hicks Reply-To: wghhicks@ix.netcom.com Organization: TerraEarth X-Mailer: Mozilla 4.03b8 [en] (X11; I; FreeBSD 2.2-STABLE i386) MIME-Version: 1.0 To: "Žoršur Ivarsson" CC: freebsd-hackers@FreeBSD.ORG Subject: Re: Parity Ram References: <34524948.41C67EA6@est.is> <34525F3B.1137B612@ix.netcom.com> <345267BF.167EB0E7@est.is> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Yeah, but when you go to buy memory they have ECC *OR* parity types available. ECC generally costs more than parity... i understand the way ECC works, the minicomputer systems i've worked with in days past held 3 bits for every 8. Just wondering what parity RAM *really* means (these daze). WRT the reason parity could be worse, most of the schemes i'm familiar with use only a single bit per eight bit quantity. Parity bits can be bad too, that is why most ECC schemes are considered superior (to me anyway). Off to find Hamming's proof... Cheers! Jerry Hicks, jerry_hicks@bigfoot.com Žoršur Ivarsson wrote: > > Jerry Hicks wrote: > > > > Žoršur Ivarsson wrote: > > > > > > This has helped me several times when I was suspecting broken memory in > > > the old days (90-93) :-) > > > > > > Thordur Ivarsson > > > > ECC Memory was marginally useful for this years ago when were using NMOS > > RAM. Lately, most memory failures I've seen are catastrophic, taking out > > a whole device or better. > > > > I'm not a hardware specialist; Does 'Parity RAM' employ a conventional > > parity scheme, a la asynch serial communications? > > > > Didn't Richard Hamming show these to -cause- more problems than they > > solve? It seems I recall a number like 256K (bits/bytes/words?) as being > > the threshold in a proof he presented. > > > > Jerry Hicks > > jerry_hicks@bigfoot.com > > In the old days 8088, 8086, 80186, 80286 and 80386 it was just plain odd > or even > parity like in serial communications but later on came better algorithm > that could > really fix wrong bits > > Thordur Ivarsson From owner-freebsd-hackers Sat Oct 25 15:30:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA27480 for hackers-outgoing; Sat, 25 Oct 1997 15:30:49 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id PAA27472 for ; Sat, 25 Oct 1997 15:30:45 -0700 (PDT) (envelope-from tom@sdf.com) Received: from tom by misery.sdf.com with smtp (Exim 1.73 #1) id 0xPEhd-0006IQ-00; Sat, 25 Oct 1997 15:29:06 -0700 Date: Sat, 25 Oct 1997 15:29:02 -0700 (PDT) From: Tom To: =?iso-8859-1?Q?=DEor=F0ur?= Ivarsson cc: freebsd-hackers@freebsd.org Subject: Re: Parity Ram In-Reply-To: <345269F0.446B9B3D@est.is> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.freebsd.org id PAA27474 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 25 Oct 1997, [iso-8859-1] Žoršur Ivarsson wrote: > Tom wrote: > > > > On Sat, 25 Oct 1997, Jamil J. Weatherbee wrote: > > > > > Can someone fill me in on when you would want to use parity ram as opposed > > > > Why? To discover memory problems before they corrupt data, and cause > > random panics, core dumps, hangs, or file system corruption. Personally, > > I use ECC capable motherboards that can actually use parity to fix some > > errors. > > You need EDO ram I think for this to work, You need some memory to keep > information of what is in your memory before. No. EDO is just like regular DRAM, except the timing is different (faster). ECC uses the parity bits in regular parity RAM. Tom From owner-freebsd-hackers Sat Oct 25 15:57:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA28601 for hackers-outgoing; Sat, 25 Oct 1997 15:57:21 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from out2.ibm.net (out2.ibm.net [165.87.194.229]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA28594 for ; Sat, 25 Oct 1997 15:57:18 -0700 (PDT) (envelope-from mouth@ibm.net) Received: from slip129-37-53-68.ca.us.ibm.net (slip129-37-53-68.ca.us.ibm.net [129.37.53.68]) by out2.ibm.net (8.8.5/8.6.9) with SMTP id WAA76996 for ; Sat, 25 Oct 1997 22:57:10 GMT From: mouth@ibm.net (John Kelly) To: freebsd-hackers@FreeBSD.ORG Subject: Re: Parity Ram Date: Sat, 25 Oct 1997 22:58:33 GMT Message-ID: <34536bc3.4216043@smtp-gw01.ny.us.ibm.net> References: <34524948.41C67EA6@est.is> <34525F3B.1137B612@ix.netcom.com> In-Reply-To: <34525F3B.1137B612@ix.netcom.com> X-Mailer: Forte Agent 1.01/16.397 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id PAA28595 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 25 Oct 1997 17:06:03 -0400, Jerry Hicks wrote: >Didn't Richard Hamming show these to -cause- more problems than they >solve? It seems I recall a number like 256K (bits/bytes/words?) as being >the threshold in a proof he presented. Even if he's correct that additional bits needed for parity increase the overall frequency of bit errors, when a one-bit error does occur on a parity SIMM, at least you are notified of that fact. On the other hand, any bit errors occurring on a non-parity SIMM will be unreported. You will have corrupted memory, which could be as trivial as a reversed bit in a graphic image, or a serious data error. The fact that you can change one bit in a graphic image without dire consequences is why printers don't need parity memory. But on the other hand, most banks use mainframes with ECC memory. Would you be a satisfied customer if they kept your account balance on a PC with non-parity memory and every once in a while subtracted $16,384 from your account because they had a bit error in memory which went undetected? So it depends on the application. Non-parity memory has its place, but not on any computer where data integrity is important. Intel published a white paper which claimed that with modern memory manufacturing techniques, bit errors due to gamma radiation and other disturbances are no more likely than once every 20 years or so for a DRAM chip. But that's just for one chip --- multiply the number of SIMMs and individual chips found in a machine and the likelihood increases. A great shame upon the computer industry is that chip makers like Intel have foisted non-parity chipsets like the 430FX upon an unsuspecting and uninformed public who imagine their PCs operate reliably as any other appliance. With so many non-parity chipsets and memory in use, running bug-ridden Microsoft products, I'm amazed the American economy hasn't collapsed entirely. John From owner-freebsd-hackers Sat Oct 25 16:00:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA28741 for hackers-outgoing; Sat, 25 Oct 1997 16:00:33 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA28736 for ; Sat, 25 Oct 1997 16:00:29 -0700 (PDT) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.7/8.8.7) id QAA10940; Sat, 25 Oct 1997 16:00:23 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp04.primenet.com, id smtpd010927; Sat Oct 25 16:00:14 1997 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id QAA03495; Sat, 25 Oct 1997 16:00:09 -0700 (MST) From: Terry Lambert Message-Id: <199710252300.QAA03495@usr09.primenet.com> Subject: Re: zipfs filesystem anyone ? To: michaelh@cet.co.jp (Michael Hancock) Date: Sat, 25 Oct 1997 23:00:09 +0000 (GMT) Cc: gurney_j@resnet.uoregon.edu, tlambert@primenet.com, luigi@labinfo.iet.unipi.it, hackers@FreeBSD.ORG In-Reply-To: from "Michael Hancock" at Oct 25, 97 10:44:29 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > actually.. the change wasn't very massive.. just 3 lines of code and some > > comment updates... > > Sheez, Terry, first you give us mega-commits and now you give us tiny > pointless ones. When are you going to get this right? ;-) That change was part of my original VFS "megacommit". It was also seperated out as part of a smaller set of commits (just namei, just vfs_init, etc.) when the "megacommit" was rejected. 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-hackers Sat Oct 25 16:45:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA00116 for hackers-outgoing; Sat, 25 Oct 1997 16:45:01 -0700 (PDT) (envelope-from owner-freebsd-hackers) 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 QAA29991; Sat, 25 Oct 1997 16:44:49 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id QAA11993; Sat, 25 Oct 1997 16:44:47 -0700 (PDT) Message-ID: <19971025164446.39994@hydrogen.nike.efn.org> Date: Sat, 25 Oct 1997 16:44:46 -0700 From: John-Mark Gurney To: FreeBSD Hackers Cc: Peter Wemm Subject: bsd.libnames.mk problems... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk well.. Jonathan Mini pointed out that src/usr.bin/doscmd/Makefile used a src reference to crt0.o... so I simply changed it to ${LIBCRT0} but then the build failed... upon further examination, it seems that bsd.libnames.mk is only included from bsd.prog.mk if BINFORMAT != aout... why isn't it? it happens to also break the other dependancy on ${LIBC}... this change was introduced by peter in rev1.55 of bsd.prog.mk... -- 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-hackers Sat Oct 25 16:58:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA00559 for hackers-outgoing; Sat, 25 Oct 1997 16:58:12 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from ns2.cetlink.net (root@ns2.cetlink.net [209.54.54.20]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA00554 for ; Sat, 25 Oct 1997 16:58:09 -0700 (PDT) (envelope-from jak@cetlink.net) Received: from ts1-cltnc-23-s12.cetlink.net (ts1-cltnc-23-s12.cetlink.net [209.54.58.23]) by ns2.cetlink.net (8.8.5/8.8.5) with SMTP id TAA11728 for ; Sat, 25 Oct 1997 19:57:27 -0400 (EDT) From: jak@cetlink.net (John Kelly) To: hackers@FreeBSD.ORG Subject: Re: 48 meg double fault moved to 64 meg in 2.2.5 Date: Sat, 25 Oct 1997 19:08:48 -0400 Message-ID: In-Reply-To: <18145.877813190@time.cdrom.com> Lines: 34 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk "Jordan K. Hubbard" wrote: >You know, christmas is coming up and a new Tyan motherboard would >probably not be that expensive. ;-) Heh. I've got one of those too. Dual P-133s which I would like to try out on FreeBSD 3.0 one of these days. If I get much more computer stuff it's going to start falling out the windows. At auction for an incredible price, I bought over a hundred SMC Ultra ethernet cards to connect this stuff with. Old McDonald had a web farm, E-I-E I/O. >I suppose I could always build you a boot floppy without bounce >buffering, just to see what effect it has, but that wouldn't do your >Buslogic controller any good at all during an actual installation. ;-) Hmmm. I thought I read that bounce buffers were only needed for ISA busmastering and boards with "broken" VLB controllers unable to handle addresses above 16MB. Even though my motherboard does not properly implement the A26 line (addresses 64 meg and above), since the Buslogic 32-bit busmastering controller is only trying to address memory below 64 meg (the motherboard maximum memory is 64 meg), it works well. And although it's a seemingly obsolete 486DX4-100, the 32-bit VLB SCSI and a Seagate 7200rpm Barracuda make it pretty quick. But in any case, if you create a boot floppy without the bounce buffers, let me know. I'll spin it up to see if that change has any effect on the boot floppy 48 meg problem. John From owner-freebsd-hackers Sat Oct 25 18:06:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA04106 for hackers-outgoing; Sat, 25 Oct 1997 18:06:48 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA04078 for ; Sat, 25 Oct 1997 18:06:39 -0700 (PDT) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.7/8.8.7) id SAA16040; Sat, 25 Oct 1997 18:06:37 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp04.primenet.com, id smtpd016033; Sat Oct 25 18:06:29 1997 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id SAA15742; Sat, 25 Oct 1997 18:06:25 -0700 (MST) From: Terry Lambert Message-Id: <199710260106.SAA15742@usr04.primenet.com> Subject: Re: zipfs filesystem anyone ? To: gurney_j@resnet.uoregon.edu Date: Sun, 26 Oct 1997 01:06:25 +0000 (GMT) Cc: tlambert@primenet.com, michaelh@cet.co.jp, luigi@labinfo.iet.unipi.it, hackers@FreeBSD.ORG In-Reply-To: <19971025004544.21378@hydrogen.nike.efn.org> from "John-Mark Gurney" at Oct 25, 97 00:45:44 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > The list terminator is still necessary for the population pass, where > > the vectors get populated. The VOP_REPLACEME needs to be seperate. > > I can see on the vnodeopv_desc of the vfs layer, but why does the NULL > entry on the array of the vnodeop_desc array in vnode_if.c need the > last NULL, that is what vfs_opv_numops is for... (which the population > code uses)... OK. This code is not obvious. I will have to refer to the original kern/vfs_init.c code for this. In vfs_opv_init(), there is a MALLOC() where the dynamic vectors are allocated. The purpose of this is that the per FS descriptor list for the VOP's defined for a given VFS layer is sparse. If you look further down in vfs_opv_init(), you will see: /* * Finally, go back and replace unfilled routines * with their default. (Sigh, an O(n^3) algorithm. I * could make it better, but that'd be work, and n is small.) */ So basically, it takes a list like: { A, D, F, J, NULL } And changes it to: { A, b, c, D, e, F, g, h, i, J, k, l } The point being that it knows the end of the per FS descriptor list by the NULL. This actually bears *directly* on my sorting recommendation: if the descriptor list is sparse, you will not have a baseline for a sort of a new descriptor entry that isn't also in the globally declared descriptor array, because only the descriptors defined in vnode_if.c will have known offsets. > so what I'm saying is we make two vars, maxvfs_opv_numops in which we > allocate all the memory for that many ops... then as a new op is added > we simply increase vfs_opv_numops to keep track of were we add the next > op.. when it's equal to (or greater) then we simply disallow adding any > new ops... Yes, this is just housekeeping, and it doesn't matter how it is accomplished so long as it doesn't preclude some future use we haven't thought of yet. It's a "don't care" state. > > > personally, a possible define that declares I want a possible X extra > > > vop vectors... and then have a couple variables that tell you the > > > maximum number, and the current last offset... this shouldn't be hard > > > to do... > > > > They kind of need to be static, unless the vector list becomes a linker > > set. This can't happen until the linker set can be agregated between > > I was talking about the size of the list being variable, but that ther > be an options like: > options "EXTRA_VNODEOPS=5" > > then we simply do: > int maxvfs_opv_numops = (sizeof(vfs_op_descs)/sizeof(struct vnodeop_desc *)) + > EXTRA_VNODEOPS; > > and then the define is like: > struct vnodeop_desc *vfs_op_descs[num] = { > }; > > and we simply modify the awk script to properly generate num... which > isn't hard... See above. The descriptors have to be unique at the time vnode_if.c is compiled; different indices pointing to the same address won't cut it. Probably you will need to have a special tag value, or you will need to have a duplicate array containing only the replacement descriptor entries portion of the vfs_op_descs table. Or you will need to save them one behind when you add the descriptor, and remove them one behind. I would caution *againt* saving them one behind, though. I could easily see a new VOP being used by two loadable FS's. To make the thing work, you would need to keep a reference count -- and that implies some place to keep it. I would suggest in a structure with the VOP descriptors you replace. Really, the output (populated) per FS structure with all entries filled in for the defaults should be possible to dereference directly -- *IFF* it's sorted. This gets rid of the function stubs for the VOP_* calls, and saves a lot of call overhead. Think about it, anyway... > arg, I see what you mean.. ffs depends upon some of ufs's functions.. > (arg, I was assuming that each module was independant)... Yes. This kind of screws up the BSDI plans for Soft Updates, since it mean the soft updates capable UFS will not be able to be shared with MFS, LFS, etc.. > right now the only way I can think of preventhing this from being a > problem is to add the MOUNT_xxx to the declaration of the vnodeops, > and then including in the ffs a dependancy of ufs... No. If the entries are sorted, and you have a reference, then an init routine can reference the previously defined loaded module (the symbol table is cumulative). This at least gets you an address to pass into the modified vfs_opv_init() function so you can convert the UFS descriptor list to a set of function pointers. The trick is to know beforehand that the populated descriptor lists are in the same order in the UFS and the FFS, and just use the offset so you don't have to reference every function by symbol. Hence the sort. It can be a simple bubble sort (that's what I used), since you can sort it in place in the populated vector (dynamic vector is a bad name for this in the code, IMO). > > Sorting the list also allows you to reference by index instead of by > > descriptor. If you think about it, you won't have a descriptor for > > a new VOP, if you dynamically load it, in vnode_if.h. This loses the > > little glue function. To fix this, you have to kill the glue functions. > > And you can do it if you can indext into the op vector and get the right > > function. > > umm... isn't this already what is done? from vfs_opv_init: > opv_desc_vector[opve_descp->opve_op->vdesc_offset] = > opve_descp->opve_impl; > the above line will set the appropriate vector by the vdesc_offset.. No. This requires that the symbol set for the descriptor set be complete; if you are adding a new VOP, then it won't be (unless you have ELF linker set agregation across distinct per kld sections working). Even then, the VOP entry may be duplicated, which I don't know how the linker set could handle correctly. It really needs a reference count for each FS that's using the new VOP. It becomes a can of worms quickly unless you reduce the decriptor list to a set of indices into an array of VOP functions. So again, doing the physical sort is the right way to go. Note that if you ad a VOP, you have to go back and repopulate the dynamic entry wheere the new VOP came in, if there is a default behaviour specified. 8-(. You can make the sort part of the vfs_opv_init(). Since the vfs_opv_init() "knows" the descriptor list, this works. > then at the end, there is a second pass to fill in the remaining entries > with the entry from VOFFSET(vop_default) of it's own vector.. > > hmm... looks like we need to remove this comment: > /* > * Finally, go back and replace unfilled routines > * with their default. (Sigh, an O(n^3) algorithm. I > * could make it better, but that'd be work, and n is small.) > */ > as right now the final routine runs in n as far as I can tell... :) The O(n^3) is wrong, unlesss you consider the whole thing, and you consider it in light of how the UFS is referenced by the FFS. For that specific case, O(n^3) is correct. This is because there is a seperate "dynamic vector" for each reference instance of a "non-dynamic vector". This is also not very obvious from the code. You need to look at the array declarations themselves, and the specfs ops, etc., in context to see this. The part of the comment that says "replace unfilled routines" is correct, but, again, it's descriptor based, which breaks truly dynamic loading of intermediate VFS's as opposed to complete-to-bottom stacks. The problem is in telling "NULL" entries from "uninitialized" entries. You need to know this because you want to collapse the first defined entry to the top of the stack so that you have the minimum possible call overhead for any individual stacked VOP. You can *almost* see how this is supposed to work in the "FFS stacked on UFS" case. It's kind of obfuscated by the "struct fileops" crap, and the fact that the vnode handling is from a global free pool, instead of the vnode objects being subelements in the per FS object structure (for UFS, struct inode for the in core inode). If you ignore that code and pretend the references are direct instead of indirect, it's a lot easier to visualize (one of the reasons I think the code should be changed to make it match the conceptual design). Right now, there is no real "collapse" taking place. Mostly because things with NULL entries are broken and getting more broken the more people stuff VM code into them. If you look at the "UFS in FFS VOP structure" entries, you can see how the vnode pointer is supposed to be an abstract type in each FS. The per FS macro for "VTOI" and "ITOV" are supposed to be the only gates where a vnode is not treated as an opaque type (and that goes back to the global pool implementation; you *could* use pointer math to make it *truly* opaque if the vnode were a subelement). It's all very complicated, but you can see it if you take enough time. Unfortunately, not very many people have taken enough time, since it's a lot more convoluted than it should be (ideally and IMO, anyway). But to ascend out of the fourth ring of hell, you first have to visit the fourth ring of hell... otherwise you can't get there from here. ;-). Once enough people understand the code so that a code review is possible and people can get the warm fuzzies about the new code, it should be possible to fix all of it to make it easier for people to get their brains around. Then it picks up speed as it rolls downhill. 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-hackers Sat Oct 25 18:13:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA04872 for hackers-outgoing; Sat, 25 Oct 1997 18:13:18 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA04849 for ; Sat, 25 Oct 1997 18:13:07 -0700 (PDT) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.7/8.8.7) id SAA16242; Sat, 25 Oct 1997 18:13:07 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp04.primenet.com, id smtpd016235; Sat Oct 25 18:13:00 1997 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id SAA15989; Sat, 25 Oct 1997 18:12:57 -0700 (MST) From: Terry Lambert Message-Id: <199710260112.SAA15989@usr04.primenet.com> Subject: Re: FreeBSD for digital recording w/PCI multitrack in/out cards? To: joe@pavilion.net (Josef Karthauser) Date: Sun, 26 Oct 1997 01:12:57 +0000 (GMT) Cc: dcarmich@mcs.net, freebsd-hackers@FreeBSD.ORG In-Reply-To: <19971025224535.22610@pavilion.net> from "Josef Karthauser" at Oct 25, 97 10:45:35 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > What multitrack recording software exists for FreeBSD? > > If someone could write a silicon graphics emulation we could all run > cubase and dump our pcs :) > (Now _that_ would be a nice christmas present.) Processor emulation for SGI would require a MIPS emulation package, an execution class loader, and the ability to open files that were executable but not readable or writeable in order to map them into the emulator's address space. You can download a MIPS emulator (SPIM) from the net. I would be happy to help get an emulation running, but you'd probrably have to start with NetBSD MIPS binaries and work your way up... 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-hackers Sat Oct 25 19:24:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA10121 for hackers-outgoing; Sat, 25 Oct 1997 19:24:22 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (ppp20.portal.net.au [202.12.71.120]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA10113 for ; Sat, 25 Oct 1997 19:24:15 -0700 (PDT) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (localhost [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id LAA00510; Sun, 26 Oct 1997 11:50:11 +1030 (CST) Message-Id: <199710260120.LAA00510@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Josef Karthauser cc: Douglas Carmichael , freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD for digital recording w/PCI multitrack in/out cards? In-reply-to: Your message of "Sat, 25 Oct 1997 22:45:35 BST." <19971025224535.22610@pavilion.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 26 Oct 1997 11:50:09 +1030 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > What multitrack recording software exists for FreeBSD? > > If someone could write a silicon graphics emulation we could all run > cubase and dump our pcs :) > (Now _that_ would be a nice christmas present.) You could just buy an old Atari and run it on the original platform 8) (or hack STonX to make it run there...) mike From owner-freebsd-hackers Sat Oct 25 20:16:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA13835 for hackers-outgoing; Sat, 25 Oct 1997 20:16:46 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from dfw-ix3.ix.netcom.com (dfw-ix3.ix.netcom.com [206.214.98.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA13829 for ; Sat, 25 Oct 1997 20:16:42 -0700 (PDT) (envelope-from wghhicks@ix.netcom.com) Received: (from smap@localhost) by dfw-ix3.ix.netcom.com (8.8.4/8.8.4) id WAA25933; Sat, 25 Oct 1997 22:15:12 -0500 (CDT) Received: from atl-ga15-14.ix.netcom.com(204.32.174.110) by dfw-ix3.ix.netcom.com via smap (V1.3) id rma025876; Sat Oct 25 22:14:41 1997 Message-ID: <3452B4B9.8A4510A9@ix.netcom.com> Date: Sat, 25 Oct 1997 23:10:49 -0400 From: Jerry Hicks Reply-To: wghhicks@ix.netcom.com Organization: TerraEarth X-Mailer: Mozilla 4.03b8 [en] (X11; I; FreeBSD 2.2-STABLE i386) MIME-Version: 1.0 To: Mike Smith CC: freebsd-hackers@freebsd.org Subject: Re: Parity Ram References: <199710260126.LAA00539@word.smith.net.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Mike Smith wrote: > > > Yeah, but when you go to buy memory they have ECC *OR* parity types > > available. ECC generally costs more than parity... > > Crap. In the case of 72-pin parts, parity and ECC are both x36. 30-pin > parts are either x8 (no parity) or x9 (parity, or ECC in groups of 4). > > mike Hi Mike, i understood that they're referred to as ECC vs PARITY because of the memory controller interface. True, the same number of bits are found in devices labeled both ways. Some ECC controllers must have special requirements of the interface to the memory (timing, interleaving ?) A quick AltaVista search on ECC found this link: http://www1.ibmlink.ibm.com/HTML/SPEC/6062ipme.html#pari (IBM, ugh) In this example they are pretty explicit that parity memory is different from ECC-EDO devices. i'll bet the prices are different too. i'm really just trying to understand all this myself; i'm not a hardware type. (heck, i'm not that much of a software type either ;) Do you know anything of Richard Hamming's assertion that parity memory (the old fashioned even/odd type) is-a-bad -thing in large configurations? this is bound to be a FAQ... Thanks, Jerry Hicks jerry_hicks@bigfoot.com From owner-freebsd-hackers Sat Oct 25 21:05:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA15535 for hackers-outgoing; Sat, 25 Oct 1997 21:05:05 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA15526 for ; Sat, 25 Oct 1997 21:05:00 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id OAA11964; Sun, 26 Oct 1997 14:34:56 +1030 (CST) Message-ID: <19971026143455.13913@lemis.com> Date: Sun, 26 Oct 1997 14:34:55 +1030 From: Greg Lehey To: FreeBSD Hackers Subject: When login class? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Am I correct in believing that the current login class concept was introduced in 4.4BSD? Otherwise, where did it come from? Greg From owner-freebsd-hackers Sat Oct 25 23:53:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA21287 for hackers-outgoing; Sat, 25 Oct 1997 23:53:49 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from verdi.nethelp.no (verdi.nethelp.no [195.1.171.130]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA21282 for ; Sat, 25 Oct 1997 23:53:45 -0700 (PDT) (envelope-from sthaug@nethelp.no) From: sthaug@nethelp.no Received: (qmail 26799 invoked by uid 1001); 26 Oct 1997 06:53:38 +0000 (GMT) To: wghhicks@ix.netcom.com Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Parity Ram In-Reply-To: Your message of "Sat, 25 Oct 1997 18:12:50 -0400" References: <34526EE2.64DE0BA6@ix.netcom.com> X-Mailer: Mew version 1.05+ on Emacs 19.28.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Sun, 26 Oct 1997 07:53:37 +0100 Message-ID: <26797.877848817@verdi.nethelp.no> Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > i understand the way ECC works, the minicomputer systems i've worked > with in days past held 3 bits for every 8. Just wondering what parity > RAM *really* means (these daze). > > WRT the reason parity could be worse, most of the schemes i'm familiar > with use only a single bit per eight bit quantity. Parity bits can be > bad too, that is why most ECC schemes are considered superior (to me > anyway). Hardware based on the Intel 430HX and 440FX chipsets (probably 440LX also) can use a single parity bit per byte to get you ECC. The trick is that memory is read and written in units of 64 bits (ie. 72 bits with the parity info). 72 bits per 64 bit of information is enough to get you single bit correction and double bit detection. Steinar Haug, Nethelp consulting, sthaug@nethelp.no