From owner-freebsd-hackers Sun Jan 26 00:05:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA25806 for hackers-outgoing; Sun, 26 Jan 1997 00:05:51 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA25800 for ; Sun, 26 Jan 1997 00:05:46 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id TAA22463; Sun, 26 Jan 1997 19:05:31 +1100 Date: Sun, 26 Jan 1997 19:05:31 +1100 From: Bruce Evans Message-Id: <199701260805.TAA22463@godzilla.zeta.org.au> To: j@uriah.heep.sax.de, jmz@cabri.obs-besancon.fr Subject: Re: fdisk headache Cc: freebsd-hackers@FreeBSD.org Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >> The real problem is then when I want to label the disk: I get >> >> ioctl DIOCWLABEL: Operation not supported by device >> sd4s4: type 0xa5, start 1, end = 6265199, size 6265199 >> sd4s4: C/H/S end 666/5/55 (220109) != end 6265199: invalid > >The slice code knows about various BIOS problems. It assumes a few >bogus geometry values (including the 1024 cylinders one). However, >the total number of sectors in the BSD slice must still match the `c' >partition value -- 6265199. There is one fatal error here and one warning. The fatal DIOCWLABEL error is probably caused by attempting to label a device that doesn't support labeling. Surprise :-). /dev/rsd4 does not support labeling. /dev/rsd4s4c (or its alias /dev/rsd4s4, or if s4 is the first BSD slice, its alias /dev/rsd4c) supports labeling. The fatal error may mask another fatal error. The disk size and the `c' partition size in the label should both match the size of the slice -- 6265199 (it may work to use a smaller size at least for the `c' partition, but there is normally no reason to). The warning about the slice size mismatch is printed to help diagnose errors like this. Unfortunately, it is only printed if the `bootverbose' flag is set (it is normally set by booting with -v), and the warning about the invalid BIOS geometry is also printed. (The BIOS geometry is irrelevant here. It is probably caused by the installer not rounding the slice size to a cylinder boundary.) Bruce From owner-freebsd-hackers Sun Jan 26 00:24:15 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA26435 for hackers-outgoing; Sun, 26 Jan 1997 00:24:15 -0800 (PST) Received: from csd.cs.technion.ac.il (csd.cs.technion.ac.il [132.68.32.8]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id AAA26424 for ; Sun, 26 Jan 1997 00:24:10 -0800 (PST) Received: from localhost (nadav@localhost) by csd.cs.technion.ac.il (8.6.11/8.6.10) with SMTP id KAA29628; Sun, 26 Jan 1997 10:19:55 +0200 X-Authentication-Warning: csd.cs.technion.ac.il: nadav owned process doing -bs Date: Sun, 26 Jan 1997 10:19:55 +0200 (IST) From: Nadav Eiron X-Sender: nadav@csd To: Terry Lambert cc: Tom Samplonius , garman@phs.k12.ar.us, freebsd-hackers@freebsd.org Subject: Re: CMD640b ide controller bug workarounds? In-Reply-To: <199701252030.NAA00669@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 25 Jan 1997, Terry Lambert wrote: > > > L*nux has an option `hda=serialize' to do this. Is there any chance > > > FreeBSD could have an CMD640B_SUCKS_ROCKS_SERIALIZE_REQUESTS option in the > > > kernel config file? > > > > Considering that a perfectly good, brand new EIDE controller with > >primary and secondary, and dual 16550 UARTs, and printer for $50, why > > bother? > > So that FreeBSD will run on hardware as it comes from the manufacturer > so that people who want to run FreeBSD can be pure computer users > instead of a combination of computer user, petty cash drawer, and > hardware hacker? And another reason: I (for one) have a machine with a built-in CMD640 and no free PCI slots... > > > Regards, > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. > Nadav From owner-freebsd-hackers Sun Jan 26 00:35:58 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA26871 for hackers-outgoing; Sun, 26 Jan 1997 00:35:58 -0800 (PST) Received: from seagull.rtd.com (seagull.rtd.com [198.102.68.2]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA26858 for ; Sun, 26 Jan 1997 00:35:56 -0800 (PST) Received: (from dgy@localhost) by seagull.rtd.com (8.7.5/8.7.3) id BAA01692; Sun, 26 Jan 1997 01:35:51 -0700 (MST) From: Don Yuniskis Message-Id: <199701260835.BAA01692@seagull.rtd.com> Subject: Re: suggestion for kernel printk() ? To: bde@zeta.org.au (Bruce Evans) Date: Sun, 26 Jan 1997 01:35:50 -0700 (MST) Cc: bde@zeta.org.au, dgy@rtd.com, freebsd-hackers@freefall.freebsd.org In-Reply-To: <199701260649.RAA20345@godzilla.zeta.org.au> from "Bruce Evans" at Jan 26, 97 05:49:48 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >> I use a serial console and `terminalprogram | tee foo' to capture > >> the output. > > > >Yes, but I would have had to have built the kernel with COMCONSOLE > >(which I didn't). > > COMCONSOLE hasn't been necessary for 2 years in -current (just boot > with -h) but is still necessary in -stable. Sigh. Hmmm... this is a 2.1R box. I'll have to check next time I reboot... > >However, is it worthwhile for the mechanism that printk() ?? uses to > >observe some kind of flow control? It did not recognize scroll_lock, > >pause, ^S, etc. This would have at least enabled me to read some > >(i.e. one screen full) of the messages to see what the kernel was > >complaining about. > > Scroll lock and scrollback don't work until interrupts are enabled after Yes, that's what I had suspected. > probing all the devices. printf() doesn't have any flow control. It > can't afford to pause once the system is up because that would freeze > the whole system. Freezing for 1 msec per character to for output at > 9600 bps is bad enough. But would it actually *break* anything? Perhaps I'll hack in a two line patch next time I rebuild a kernel and see what happens... Thx! --don From owner-freebsd-hackers Sun Jan 26 01:02:39 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA27680 for hackers-outgoing; Sun, 26 Jan 1997 01:02:39 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA27675 for ; Sun, 26 Jan 1997 01:02:35 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id TAA23790; Sun, 26 Jan 1997 19:56:20 +1100 Date: Sun, 26 Jan 1997 19:56:20 +1100 From: Bruce Evans Message-Id: <199701260856.TAA23790@godzilla.zeta.org.au> To: bde@zeta.org.au, dgy@rtd.com Subject: Re: suggestion for kernel printk() ? Cc: freebsd-hackers@freefall.freebsd.org Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> probing all the devices. printf() doesn't have any flow control. It >> can't afford to pause once the system is up because that would freeze >> the whole system. Freezing for 1 msec per character to for output at >> 9600 bps is bad enough. > >But would it actually *break* anything? Perhaps I'll hack in a two line >patch next time I rebuild a kernel and see what happens... Yes, it would steal characters from the foreground console unless the keyboard is dedicated to low-level console input. Bruce From owner-freebsd-hackers Sun Jan 26 01:22:18 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA28584 for hackers-outgoing; Sun, 26 Jan 1997 01:22:18 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id BAA28579 for ; Sun, 26 Jan 1997 01:22:15 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id KAA15968; Sun, 26 Jan 1997 10:22:08 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id KAA27732; Sun, 26 Jan 1997 10:20:27 +0100 (MET) Message-ID: Date: Sun, 26 Jan 1997 10:20:27 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@freebsd.org (FreeBSD hackers) Cc: garman@phs.k12.ar.us, tom@sdf.com, freebsd-hackers@freebsd.org Subject: Re: CMD640b ide controller bug workarounds? References: <199701260222.VAA14109@dyson.iquest.net> X-Mailer: Mutt 0.55-PL10 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: <199701260222.VAA14109@dyson.iquest.net>; from John S. Dyson on Jan 25, 1997 21:22:53 -0500 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As John S. Dyson wrote: > I can 'fix' the problem but am overloaded with work this weekend. We > haven't encountered this problem very often, and any solution to the > problem is a bit of a 'wart.' If you are willing to wait for approx > 1-2wks, I might be able to hack the wd driver. (In fact, it might > be a good kernel initiation project for YOU :-)). :-) If anybody starts it, please don't make it an option, but a controller flag. This way, it can be manipulated from boot -c. -- 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 Jan 26 01:38:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA29252 for hackers-outgoing; Sun, 26 Jan 1997 01:38:49 -0800 (PST) Received: from seagull.rtd.com (seagull.rtd.com [198.102.68.2]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA29246 for ; Sun, 26 Jan 1997 01:38:46 -0800 (PST) Received: (from dgy@localhost) by seagull.rtd.com (8.7.5/8.7.3) id CAA07377; Sun, 26 Jan 1997 02:38:38 -0700 (MST) From: Don Yuniskis Message-Id: <199701260938.CAA07377@seagull.rtd.com> Subject: Re: suggestion for kernel printk() ? To: bde@zeta.org.au (Bruce Evans) Date: Sun, 26 Jan 1997 02:38:37 -0700 (MST) Cc: bde@zeta.org.au, dgy@rtd.com, freebsd-hackers@freefall.freebsd.org In-Reply-To: <199701260856.TAA23790@godzilla.zeta.org.au> from "Bruce Evans" at Jan 26, 97 07:56:20 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >> probing all the devices. printf() doesn't have any flow control. It > >> can't afford to pause once the system is up because that would freeze > >> the whole system. Freezing for 1 msec per character to for output at > >> 9600 bps is bad enough. > > > >But would it actually *break* anything? Perhaps I'll hack in a two line > >patch next time I rebuild a kernel and see what happens... > > Yes, it would steal characters from the foreground console unless the > keyboard is dedicated to low-level console input. I guess a single character pushback isn't supported at that level? --don From owner-freebsd-hackers Sun Jan 26 01:50:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA29661 for hackers-outgoing; Sun, 26 Jan 1997 01:50:49 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id BAA29656 for ; Sun, 26 Jan 1997 01:50:46 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id KAA16398 for freebsd-hackers@FreeBSD.ORG; Sun, 26 Jan 1997 10:50:39 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id KAA27916; Sun, 26 Jan 1997 10:46:01 +0100 (MET) Message-ID: Date: Sun, 26 Jan 1997 10:46:01 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG Subject: Re: fdisk headache References: <199701260706.SAA20817@godzilla.zeta.org.au> X-Mailer: Mutt 0.55-PL10 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: <199701260706.SAA20817@godzilla.zeta.org.au>; from Bruce Evans on Jan 26, 1997 18:06:48 +1100 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Bruce Evans wrote: > >> I think it is bad form to do this.. > > > >Mmmaybe. > > >Of course, there's one thing that won't work with this method: > >nextboot. > Boot selectors won't work either. Since there's nothing to select from. ;-) Right now, there are three reasons to still call it ``dangerously dedicated'': . Since the MBR is identical to the BSD bootstrap, there's no room for things like `nextboot' after the MBR, and you can't replace the MBR by fancy things like a boot selector. Hence, in a system that is not FreeBSD-only, you could at best make drives != #0 ``DD'', and you won't be able to boot select away from that drive once you switched there. (Normally, booteasy allows to wander around back and forth through all the drives.) . Some known rogues like Win95 will happily clobber the dummy fdisk table (and thus the BSD bootstrap) when they first visit the drive -- of course, without asking the operator, since they interpret the term ``Plug and play'' this way. . Some operating systems might choke on that fdisk table afterwards, so if you are going to install something else on such a drive later, it's best do do a ``dd if=/dev/zero of=/dev/rXXX count=100'' before recycling the drive to another task. (The fourth reason has been fixed since: disklabel -B used to clobber sysinstall's fdisk table, and thus invalidated the sliced device names sysinstall leaves in /etc/fstab.) The plus side is: . It's the simplest way to setup a drive at all, since you can use the total number of blocks of the drive for FreeBSD. The drives are run in a mode that is basically the same as workstation and minicomputer Unices used to do for years. . The number of BIOS geometry constraints to care for reduces drastic- ally, so you can usually (*) ignore any geometry issues. (*) I.e., the BIOS's geometry idea involves at least 15 sectors per track, 4 heads, and the root file system is not larger than 30 MB. To summarize: this mode is intended for those who only want to run FreeBSD, and nothing else. I never advised people with mixed configurations to use it. Those who don't spend the slightest idea into using their machine with other operating systems can however simplify their life by using it. -- 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 Jan 26 01:51:11 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA29709 for hackers-outgoing; Sun, 26 Jan 1997 01:51:11 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id BAA29702 for ; Sun, 26 Jan 1997 01:51:08 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id KAA16410; Sun, 26 Jan 1997 10:51:03 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id KAA27928; Sun, 26 Jan 1997 10:48:09 +0100 (MET) Message-ID: Date: Sun, 26 Jan 1997 10:48:09 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: ponds!rivers@dg-rtp.dg.com (Thomas David Rivers) Cc: freebsd-hackers@freebsd.org (FreeBSD hackers) Subject: Re: 3.0-970124-SNAP on ftp.freebsd.org References: <199701260133.UAA15694@lakes.water.net> X-Mailer: Mutt 0.55-PL10 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: <199701260133.UAA15694@lakes.water.net>; from Thomas David Rivers on Jan 25, 1997 20:33:32 -0500 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Thomas David Rivers wrote: > Is there a 2.2 boot/fixit with Justin's SCSI changes (I'm assuming > there the ones 2.2 is waiting on.) That's why we want to make a 2.2-GAMMA. > Or, would it be as meaningful to run my test on the 3.0 snap? Well, give it a try if the 2 MB traffic for the boot + fixit floppy don't hurt you. -- 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 Jan 26 02:02:15 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA00215 for hackers-outgoing; Sun, 26 Jan 1997 02:02:15 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA00210 for ; Sun, 26 Jan 1997 02:02:12 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id UAA25500; Sun, 26 Jan 1997 20:59:33 +1100 Date: Sun, 26 Jan 1997 20:59:33 +1100 From: Bruce Evans Message-Id: <199701260959.UAA25500@godzilla.zeta.org.au> To: bde@zeta.org.au, dgy@rtd.com Subject: Re: suggestion for kernel printk() ? Cc: freebsd-hackers@freefall.freebsd.org Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> Yes, it would steal characters from the foreground console unless the >> keyboard is dedicated to low-level console input. > >I guess a single character pushback isn't supported at that level? >--don Right. The low level console driver is very primitive. It does no buffering. Doing anything in it would have reentrancy problems, since it may be called from interrupt handlers. BTW, there _are_ reentrancy problems in the syscons and pcvt output routines. Don't use /dev/ttyv0 in syscons if you want the system to stay up forever. Bruce From owner-freebsd-hackers Sun Jan 26 02:15:53 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA00751 for hackers-outgoing; Sun, 26 Jan 1997 02:15:53 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA00738 for ; Sun, 26 Jan 1997 02:15:46 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id VAA25791; Sun, 26 Jan 1997 21:11:30 +1100 Date: Sun, 26 Jan 1997 21:11:30 +1100 From: Bruce Evans Message-Id: <199701261011.VAA25791@godzilla.zeta.org.au> To: freebsd-hackers@FreeBSD.org, j@uriah.heep.sax.de Subject: Re: CMD640b ide controller bug workarounds? Cc: garman@phs.k12.ar.us, tom@sdf.com Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >If anybody starts it, please don't make it an option, but a controller >flag. This way, it can be manipulated from boot -c. This is barely possible. There are only 4 controller flags to spare, because 28 bits are misused for drive flags. Bruce From owner-freebsd-hackers Sun Jan 26 02:58:43 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA01837 for hackers-outgoing; Sun, 26 Jan 1997 02:58:43 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA01832 for ; Sun, 26 Jan 1997 02:58:40 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id VAA26848; Sun, 26 Jan 1997 21:51:12 +1100 Date: Sun, 26 Jan 1997 21:51:12 +1100 From: Bruce Evans Message-Id: <199701261051.VAA26848@godzilla.zeta.org.au> To: freebsd-hackers@FreeBSD.ORG, j@uriah.heep.sax.de Subject: Re: fdisk headache Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> Boot selectors won't work either. > >Since there's nothing to select from. ;-) >Right now, there are three reasons to still call it ``dangerously >dedicated'': > >. Since the MBR is identical to the BSD bootstrap, there's no room for > things like `nextboot' after the MBR, and you can't replace the MBR > by fancy things like a boot selector. Hence, in a system that is > not FreeBSD-only, you could at best make drives != #0 ``DD'', and > you won't be able to boot select away from that drive once you > switched there. (Normally, booteasy allows to wander around back > and forth through all the drives.) There may be 512(*) sd drives, 512 od drives, 16 cd drives and a small number of wd and fd drives :-). That's a lot to select from. (*) Actually at most 128(**) floppy drives and 128(**) hard drives altogether (because of the BIOS interface limit). (**) Your BIOS may vary. >. Some operating systems might choke on that fdisk table afterwards, > so if you are going to install something else on such a drive later, > it's best do do a ``dd if=/dev/zero of=/dev/rXXX count=100'' before ^^^^^^^^^ > recycling the drive to another task. Should be count=1. If 1 won't work, then 100 may not be enough either, and you'd better know what you are doing. E.g., if there is a FreeBSD slice at offset 100000, then there will be a BSD label at offset 100001, and it should be zeroed to prevent it being resurrected if a BSD slice is created at offset 100000 a year later and the label hasn't been changed. >The plus side is: >... >. The number of BIOS geometry constraints to care for reduces drastic- > ally, so you can usually (*) ignore any geometry issues. > > (*) I.e., the BIOS's geometry idea involves at least 15 sectors per > track, 4 heads, and the root file system is not larger than 30 MB. Actually if the root file system is below cylinder 1024 in the BIOS translation mode. I think the 15 sectors/track limit only applies for floppies. Bruce From owner-freebsd-hackers Sun Jan 26 03:17:03 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA02206 for hackers-outgoing; Sun, 26 Jan 1997 03:17:03 -0800 (PST) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id DAA02201 for ; Sun, 26 Jan 1997 03:17:00 -0800 (PST) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id LAA27794 for hackers@freebsd.org; Sun, 26 Jan 1997 11:35:10 +0100 From: Luigi Rizzo Message-Id: <199701261035.LAA27794@labinfo.iet.unipi.it> Subject: help for a floppy boot sector To: hackers@freebsd.org Date: Sun, 26 Jan 1997 11:35:10 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I am looking for some floppy boot code which allows you to build a bootable floppy which can start a .COM file without the need for MSDOS. Two applications: netboot (which produces a .COM file) for people who cannot burn an eprom, and my bridge code (available from my home page, based on netboot), same problem. Ideally I would do something like cat bootcode nb8390.com | dd of=/dev/fd0a to produce a bootable floppy. I figure out I could perhaps use the standard boot sectors for an a.out executable, but patching them to handle .COM file is probably more trouble than necessary. Maybe the bootcode in use for PCEMU can do the job ? Thanks 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 Sun Jan 26 03:24:43 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA02480 for hackers-outgoing; Sun, 26 Jan 1997 03:24:43 -0800 (PST) Received: from ravenock.cybercity.dk (ravenock.cybercity.dk [194.16.57.32]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA02472 for ; Sun, 26 Jan 1997 03:24:37 -0800 (PST) Received: (from sos@localhost) by ravenock.cybercity.dk (8.8.4/8.7.3) id MAA05236; Sun, 26 Jan 1997 12:25:55 +0100 (MET) From: Søren Schmidt Message-Id: <199701261125.MAA05236@ravenock.cybercity.dk> Subject: Re: suggestion for kernel printk() ? In-Reply-To: <199701260959.UAA25500@godzilla.zeta.org.au> from Bruce Evans at "Jan 26, 97 08:59:33 pm" To: bde@zeta.org.au (Bruce Evans) Date: Sun, 26 Jan 1997 12:25:46 +0100 (MET) Cc: bde@zeta.org.au, dgy@rtd.com, freebsd-hackers@freefall.freebsd.org 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-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In reply to Bruce Evans who wrote: > >> Yes, it would steal characters from the foreground console unless the > >> keyboard is dedicated to low-level console input. > > > >I guess a single character pushback isn't supported at that level? > >--don > > Right. The low level console driver is very primitive. It does no > buffering. Doing anything in it would have reentrancy problems, since > it may be called from interrupt handlers. BTW, there _are_ reentrancy > problems in the syscons and pcvt output routines. Don't use /dev/ttyv0 > in syscons if you want the system to stay up forever. Erhm, why ?? I've not seen any problems and ttyv0 is the only tty I use on my WS (its used almost only under X otherwise) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-hackers Sun Jan 26 03:37:42 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA02826 for hackers-outgoing; Sun, 26 Jan 1997 03:37:42 -0800 (PST) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA02821 for ; Sun, 26 Jan 1997 03:37:40 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.3/CET-v2.1) with SMTP id LAA21972; Sun, 26 Jan 1997 11:36:44 GMT Date: Sun, 26 Jan 1997 20:36:44 +0900 (JST) From: Michael Hancock To: proff@suburbia.net cc: hackers@freebsd.org Subject: Re: SLAB stuff, and applications to current net code (fwd) In-Reply-To: <19970126042316.10096.qmail@suburbia.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 26 Jan 1997 proff@suburbia.net wrote: > Can anyone inform me what a SLAB allocator is, and if so, would freebsd > benefit from one? > It's a chunk of memory that you put multiple kernel objects of the same type into. We have a modified mach zone allocator. They're both type stable memory allocators. Maybe John or David will explain how our allocator differs from the original zone allocator in 4.4BSD borrowed from Mach. I not sure how much benefit the SLAB allocator would offer over what we have. There's some extra overhead in maintaining a SLAB. BTW, SLAB is used in Solaris. Regards, Mike Hancock From owner-freebsd-hackers Sun Jan 26 03:40:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA02934 for hackers-outgoing; Sun, 26 Jan 1997 03:40:59 -0800 (PST) Received: from haldjas.folklore.ee (Haldjas.folklore.ee [193.40.6.121]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA02929; Sun, 26 Jan 1997 03:40:42 -0800 (PST) Received: from localhost (narvi@localhost) by haldjas.folklore.ee (8.8.4/8.8.4) with SMTP id NAA12413; Sun, 26 Jan 1997 13:38:28 +0200 (EET) Date: Sun, 26 Jan 1997 13:38:28 +0200 (EET) From: Narvi To: Terry Lambert cc: Jake Hamby , hasty@rah.star-gate.com, multimedia@freebsd.org, hackers@freebsd.org Subject: Re: New Bt848 Video capture driver for FreeBSD In-Reply-To: <199701252133.OAA00739@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 25 Jan 1997, Terry Lambert wrote: > > For the record, somebody wrote a bt848 driver for BeOS, and there's a demo > > of the new 3DKit which allows you to drop live video and/or QuickTime > > movies onto the faces of a 3D object (cube, sphere, pulsing thing, book > > pages), and spin it around in realtime. It looks _real_ sweet playing > > about 6 QT movies simultaneously on a PowerMac 8500, all texture-mapped > > onto various 3D objects, but a live video feed is even cooler. Man, I'd > > love to have the source code to that! > > I bet you $1 that they are only transferring data for the one, two, or > three visible faces of the cube. What do you think of them being fools? Everybody knows most things just drop a lot of frames when displaying video on the screen. Dropping a (at the current point of time) invisible video stream is not cheating, I even wouldn't consider using a hack that did not do so. But they still need to move the reference to the current frame in the six other movies. > > You could easily render a projection matrix to do this: > > o Start with a cube showing one face (ie: the vector from > your viewpoint through the center of the cube is perpendicular > to the plane of the face). > [snip - I don't care about checking the validity at the moment] Sander > > o For more complex rotations, you will rotate the cube center > as if it were attached to an axis with a fixed center by > moving the cube center relative. This is topologically > equivalent to rotating the cube about any point. You will > need to make another matrix for perspective, since if you > rotate about a point other than the body center, the average > distance to the body center will get farther (the cube will > "get smaller") or closer (the cube will "get larger"). > > > 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 Sun Jan 26 03:52:35 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA03334 for hackers-outgoing; Sun, 26 Jan 1997 03:52:35 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id DAA03328 for ; Sun, 26 Jan 1997 03:52:31 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id MAA18608; Sun, 26 Jan 1997 12:52:21 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id MAA05258; Sun, 26 Jan 1997 12:33:44 +0100 (MET) Message-ID: Date: Sun, 26 Jan 1997 12:33:44 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Cc: hackers@freebsd.org Subject: Re: help for a floppy boot sector References: <199701261035.LAA27794@labinfo.iet.unipi.it> X-Mailer: Mutt 0.55-PL10 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: <199701261035.LAA27794@labinfo.iet.unipi.it>; from Luigi Rizzo on Jan 26, 1997 11:35:10 +0100 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Luigi Rizzo wrote: > Maybe the bootcode in use for PCEMU can do the job ? Probably. Well, no. It doesn't provide for any DOS functions, it just uses the BIOS only. But you should be able to use the loader 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 Sun Jan 26 04:36:04 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA05281 for hackers-outgoing; Sun, 26 Jan 1997 04:36:04 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA05276 for ; Sun, 26 Jan 1997 04:36:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id EAA06772; Sun, 26 Jan 1997 04:35:36 -0800 (PST) Message-Id: <199701261235.EAA06772@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Michael Hancock cc: proff@suburbia.net, hackers@FreeBSD.ORG Subject: Re: SLAB stuff, and applications to current net code (fwd) In-reply-to: Your message of "Sun, 26 Jan 1997 20:36:44 +0900." From: David Greenman Reply-To: dg@root.com Date: Sun, 26 Jan 1997 04:35:36 -0800 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >On Sun, 26 Jan 1997 proff@suburbia.net wrote: > >> Can anyone inform me what a SLAB allocator is, and if so, would freebsd >> benefit from one? >> > >It's a chunk of memory that you put multiple kernel objects of the same >type into. We have a modified mach zone allocator. They're both type >stable memory allocators. The memory allocator in BSD is *not* type-stable. >Maybe John or David will explain how our allocator differs from the >original zone allocator in 4.4BSD borrowed from Mach. There isn't a lot of difference. Just some performance improvements. >I not sure how much benefit the SLAB allocator would offer over what we >have. There's some extra overhead in maintaining a SLAB. > >BTW, SLAB is used in Solaris. The allocator in BSD is designed to be as fast as possible and trades space efficiency for performance. I'm very skeptical that a SLAB allocator would be any faster than the current allocation algorithm, although it would likely be more space efficient. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Sun Jan 26 04:58:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA06543 for hackers-outgoing; Sun, 26 Jan 1997 04:58:09 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA06537 for ; Sun, 26 Jan 1997 04:58:07 -0800 (PST) From: proff@suburbia.net Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with SMTP id EAA23753 for ; Sun, 26 Jan 1997 04:59:21 -0800 (PST) Received: (qmail 19510 invoked by uid 110); 26 Jan 1997 12:57:47 -0000 Message-ID: <19970126125747.19508.qmail@suburbia.net> Subject: Re: SLAB stuff, and applications to current net code (fwd) In-Reply-To: <199701261235.EAA06772@root.com> from David Greenman at "Jan 26, 97 04:35:36 am" To: dg@root.com Date: Sun, 26 Jan 1997 23:57:47 +1100 (EST) Cc: 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >I not sure how much benefit the SLAB allocator would offer over what we > >have. There's some extra overhead in maintaining a SLAB. > > > >BTW, SLAB is used in Solaris. > > The allocator in BSD is designed to be as fast as possible and trades > space efficiency for performance. I'm very skeptical that a SLAB allocator > would be any faster than the current allocation algorithm, although it > would likely be more space efficient. > > -DG > > David Greenman > Core-team/Principal Architect, The FreeBSD Project > I presume the idea is that the cache efficiency of small allocations would be substantially improved? Cheers, Julian From owner-freebsd-hackers Sun Jan 26 05:40:52 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA09170 for hackers-outgoing; Sun, 26 Jan 1997 05:40:52 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA09165 for ; Sun, 26 Jan 1997 05:40:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id FAA06943; Sun, 26 Jan 1997 05:40:21 -0800 (PST) Message-Id: <199701261340.FAA06943@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: proff@suburbia.net cc: hackers@freebsd.org Subject: Re: SLAB stuff, and applications to current net code (fwd) In-reply-to: Your message of "Sun, 26 Jan 1997 23:57:47 +1100." <19970126125747.19508.qmail@suburbia.net> From: David Greenman Reply-To: dg@root.com Date: Sun, 26 Jan 1997 05:40:21 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> >I not sure how much benefit the SLAB allocator would offer over what we >> >have. There's some extra overhead in maintaining a SLAB. >> > >> >BTW, SLAB is used in Solaris. >> >> The allocator in BSD is designed to be as fast as possible and trades >> space efficiency for performance. I'm very skeptical that a SLAB allocator >> would be any faster than the current allocation algorithm, although it >> would likely be more space efficient. ... >I presume the idea is that the cache efficiency of small allocations >would be substantially improved? We already order the allocations to take advantage of the cache by putting freed chunks at the head of the list within the bucket (thus making them the first candidates for re-allocation). This isn't perfect, of course, but it does get you most of the way there. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Sun Jan 26 05:59:16 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA09649 for hackers-outgoing; Sun, 26 Jan 1997 05:59:16 -0800 (PST) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id FAA09644; Sun, 26 Jan 1997 05:59:10 -0800 (PST) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id OAA28121; Sun, 26 Jan 1997 14:17:13 +0100 From: Luigi Rizzo Message-Id: <199701261317.OAA28121@labinfo.iet.unipi.it> Subject: Re: exec bug To: dg@root.com, dyson@freebsd.org Date: Sun, 26 Jan 1997 14:17:12 +0100 (MET) Cc: hackers@freebsd.org In-Reply-To: <199701261336.FAA06928@root.com> from "David Greenman" at Jan 26, 97 05:35:44 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >> In the case of NFS, the read should block indefinately. I'm not sure what > >> will happen if the NFS is mounted "soft", however. > > > >that would be a major problem then! > > Not any more so than any other read blocking indefinately. I was referring to the soft case. the blocking read only leaves the process hung, and possibly not dying at shutdown. But an nfs 'soft' read timing out with a failure, isn't it a time-bomb ? > > Wouldn't it be possible to track > >the exact reason of the fault inside the handler and avoid panicing ? > >After all there are no performance problems at that point.. > > ...and just how do you tell the exec code that a page fault that occured > while it was accessing the image header was "fatal"? The only mechanism we you mean "was not fatal" dont you ? > have for this is signals, and that doesn't work when you're executing in the > kernel like this. I don't know the "big picture" so this could be totally nonsense, but how about creating a "page_probe()" function, cooperating with the fault handler, which tries to access the page, returning 1 if any page fault occur in the kernel address space while running ? Then exec_aout_imgact() (or any other critical function) could first page_probe() the required page, then either continue or fail. There shouldn't be much penalty in doing this since at most the page gets paged in, something that would be necessary anyways. 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 Sun Jan 26 06:46:23 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA10778 for hackers-outgoing; Sun, 26 Jan 1997 06:46:23 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA10773 for ; Sun, 26 Jan 1997 06:46:20 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id BAA00334; Mon, 27 Jan 1997 01:43:47 +1100 Date: Mon, 27 Jan 1997 01:43:47 +1100 From: Bruce Evans Message-Id: <199701261443.BAA00334@godzilla.zeta.org.au> To: bde@zeta.org.au, sos@ravenock.cybercity.dk Subject: Re: suggestion for kernel printk() ? Cc: dgy@rtd.com, freebsd-hackers@freefall.freebsd.org Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> it may be called from interrupt handlers. BTW, there _are_ reentrancy >> problems in the syscons and pcvt output routines. Don't use /dev/ttyv0 >> in syscons if you want the system to stay up forever. > >Erhm, why ?? I've not seen any problems and ttyv0 is the only tty I >use on my WS (its used almost only under X otherwise) Syscons is not reentrant and doesn't mask interrupts at all while it is doing output, so there must be races when it is reentered. This problem can't be fixed by masking interrupts, because it is important that kernel messages get printed no matter what, and in any case the the console driver is used for unmaskable traps (mainly debugger traps) and NMIs. Here's an LKM to demonstrate the problem. It just prints a "*" every 100 msec in its timeout interrupt handler. Running it together with `hd /* >/dev/ttyv0' usually causes a panic in 10-20 seconds on a 486/33. Use `make; make load' to run it. Reduce the timeout to panic faster. I often use ttyv0 and rarely use X and haven't seen the problem either. Kernel printfs are rare, but 10-20 seconds worth of printfs at 10/sec isn't many either. There are obviously more problems at line and page boundaries; perhaps the problems are rarer for kernel messages because most messages are newline-terminated. Bruce #! /bin/sh # This is a shell archive. Remove anything before this line, then unpack # it by saving it into a file and typing "sh file". To overwrite existing # files, type "sh file -c". You can also feed this as standard input via # unshar, or by typing "sh 'Makefile' <<'END_OF_FILE' XBINDIR= /tmp XSRCS= foo.c XKMOD= foo_mod XNOMAN= none X XCLEANFILES+= ${KMOD} X X.include END_OF_FILE if test 97 -ne `wc -c <'Makefile'`; then echo shar: \"'Makefile'\" unpacked with wrong size! fi # end of 'Makefile' fi if test -f 'foo.c' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'foo.c'\" else echo shar: Extracting \"'foo.c'\" \(725 characters\) sed "s/^X//" >'foo.c' <<'END_OF_FILE' X#include X#include X#include X#include X#include X XMOD_MISC(foo); X Xstatic void Xfoo(void *arg) X{ X#if 0 X sccnputc(0, '*'); X timeout(foo, NULL, 1); X#else X /* X * Fills up log if done every tick so only do it every 10 ticks and X * wait a bit longer for races. X */ X printf("*"); X timeout(foo, NULL, 10); X#endif X} X Xint Xfoo_mod(struct lkm_table *lkmtp, int cmd, int ver) X{ X DISPATCH(lkmtp, cmd, ver, foo_load, foo_unload, lkm_nullcmd); X} X Xstatic int Xfoo_load(struct lkm_table *lkmtp, int cmd) X{ X timeout(foo, NULL, 1); X return 0; X} X Xstatic int Xfoo_unload(struct lkm_table *lkmtp, int cmd) X{ X int s; X X s = splsoftclock(); X untimeout(foo, NULL); X splx(s); X return 0; X} END_OF_FILE if test 725 -ne `wc -c <'foo.c'`; then echo shar: \"'foo.c'\" unpacked with wrong size! fi # end of 'foo.c' fi echo shar: End of shell archive. exit 0 From owner-freebsd-hackers Sun Jan 26 07:09:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA11603 for hackers-outgoing; Sun, 26 Jan 1997 07:09:01 -0800 (PST) Received: from diablo.ppp.de (diablo.ppp.de [193.141.101.34]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id HAA11598 for ; Sun, 26 Jan 1997 07:08:58 -0800 (PST) Received: from freebie.lemis.de by diablo.ppp.de with smtp (Smail3.1.28.1 #1) id m0voWCV-000Qa4C; Sun, 26 Jan 97 16:08 MET Received: (grog@localhost) by freebie.lemis.de (8.8.4/8.6.12) id PAA04577; Sun, 26 Jan 1997 15:59:09 +0100 (MET) From: grog@lemis.de Message-Id: <199701261459.PAA04577@freebie.lemis.de> Subject: Re: bisdn In-Reply-To: <23118.853940980@time.cdrom.com> from "Jordan K. Hubbard" at "Jan 22, 97 05:49:40 am" To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Sun, 26 Jan 1997 15:59:08 +0100 (MET) Cc: hackers@freebsd.org (FreeBSD Hackers), isdn@muc.ditec.de (FreeBSD ISDN Distribution List) Organisation: LEMIS, Schellnhausen 2, 36325 Feldatal, Germany Phone: +49-6637-919123 Fax: +49-6637-919122 Reply-to: grog@lemis.de (Greg Lehey) 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Jordan K. Hubbard writes: >> and greatly appreciated, too ! Several people will be working on getting >> this integrated into -current (aka 3.0). > > Really? Awesome! I'd just about given up! :-) What's the problem? I've been running bisdn on 2.2-CURRENT and 3.0-CURRENT since last May. Greg From owner-freebsd-hackers Sun Jan 26 08:21:25 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA13718 for hackers-outgoing; Sun, 26 Jan 1997 08:21:25 -0800 (PST) Received: from feephi.phofarm.com ([206.21.77.129]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA13703 for ; Sun, 26 Jan 1997 08:20:49 -0800 (PST) Received: from feephi.phofarm.com (feephi.phofarm.com [206.21.77.130]) by feephi.phofarm.com (8.8.4/8.7.3) with SMTP id LAA00348; Sun, 26 Jan 1997 11:17:50 -0500 (EST) Message-ID: <32EB83A7.41C67EA6@phofarm.com> Date: Sun, 26 Jan 1997 11:17:43 -0500 From: "Danny J. Zerkel" Organization: Photon Farmers X-Mailer: Mozilla 3.01 (X11; I; FreeBSD 3.0-CURRENT i386) MIME-Version: 1.0 To: hackers@freefall.freebsd.org CC: toor@dyson.iquest.net Subject: Re: CMD640b ide controller bug workarounds? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I can 'fix' the problem but am overloaded with work this weekend. We > haven't encountered this problem very often, and any solution to the > problem is a bit of a 'wart.' If you are willing to wait for approx > 1-2wks, I might be able to hack the wd driver. (In fact, it might > be a good kernel initiation project for YOU :-)). > > John > dyson@freebsd.org If he's not interested, I am. I have one of these controllers on my motherboard (Micronics). I would also like to access the PCI side of this controller, instead of the ISA side. I only have one disk hanging off this controller, just a 540 that I use for Windows95 (when forced at gun point). I also use it as a secondary boot partition for FreeBSD if I need to mess with the boot partitions on my SCSI disks. Danny J. Zerkel Photon Farmers dzerkel@phofarm.com. From owner-freebsd-hackers Sun Jan 26 09:55:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA16795 for hackers-outgoing; Sun, 26 Jan 1997 09:55:49 -0800 (PST) Received: from risc6.unisa.ac.za (risc6.unisa.ac.za [163.200.97.6]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA16787 for ; Sun, 26 Jan 1997 09:55:44 -0800 (PST) Received: by risc6.unisa.ac.za (AIX 4.1/UCB 5.64/4.03) id AA27426; Sun, 26 Jan 1997 19:44:14 +0200 From: radova@risc6.unisa.ac.za (A. Radovanovic) Message-Id: <9701261744.AA27426@risc6.unisa.ac.za> Subject: Help - can't login To: hackers@freebsd.org Date: Sun, 26 Jan 1997 19:44:13 +0200 (USAST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk My freebsd ran out of disk space in /. Unfortunately I rebooted the system and now I can't get in - no username or password are accepted. If I boot in a single user mode, the file system is mounted as a read only and I can't do anything with the passwd file. Is there any way to get in and repair the damage? Alex From owner-freebsd-hackers Sun Jan 26 10:22:18 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA17664 for hackers-outgoing; Sun, 26 Jan 1997 10:22:18 -0800 (PST) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA17659 for ; Sun, 26 Jan 1997 10:22:15 -0800 (PST) Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.2-biteme) with ESMTP id MAA15107; Sun, 26 Jan 1997 12:22:03 -0600 (CST) Received: from Mercury.mcs.net (Mercury.mcs.com [192.160.127.80]) by Mailbox.mcs.com (8.8.5/8.8.2) with ESMTP id MAA24555; Sun, 26 Jan 1997 12:22:02 -0600 (CST) Received: (from karl@localhost) by Mercury.mcs.net (8.8.5/8.8.2) id MAA01165; Sun, 26 Jan 1997 12:21:58 -0600 (CST) From: Karl Denninger Message-Id: <199701261821.MAA01165@Mercury.mcs.net> Subject: Re: Help - can't login To: radova@risc6.unisa.ac.za (A. Radovanovic) Date: Sun, 26 Jan 1997 12:21:58 -0600 (CST) Cc: hackers@freebsd.org In-Reply-To: <9701261744.AA27426@risc6.unisa.ac.za> from "A. Radovanovic" at Jan 26, 97 07:44:13 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > My freebsd ran out of disk space in /. Unfortunately I rebooted the > system and now I can't get in - no username or password are accepted. > If I boot in a single user mode, the file system is mounted as a read > only and I can't do anything with the passwd file. > > Is there any way to get in and repair the damage? > > Alex > Boot single-user. Type "fsck -p" Wait. IF AND ONLY IF ALL FILESYSTEMS CHECK CLEAN: mount -vat ufs This should mount all filesystems on local disks, including remounting root as read/write. Then you should be able to have at it. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 99 Analog numbers, 77 ISDN, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal From owner-freebsd-hackers Sun Jan 26 11:25:23 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA19833 for hackers-outgoing; Sun, 26 Jan 1997 11:25:23 -0800 (PST) Received: from spoon.beta.com (root@[199.165.180.33]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA19827 for ; Sun, 26 Jan 1997 11:25:18 -0800 (PST) Received: from spoon.beta.com (mcgovern@localhost [127.0.0.1]) by spoon.beta.com (8.8.4/8.6.9) with ESMTP id OAA00337; Sun, 26 Jan 1997 14:24:58 -0500 (EST) Message-Id: <199701261924.OAA00337@spoon.beta.com> To: Andrew.Gordon@net-tel.co.uk cc: mcgovern@spoon.beta.com, hackers@FreeBSD.org, mcgovern@spoon.beta.com Subject: Re: Overdrive question... In-reply-to: Your message of "Sun, 26 Jan 1997 02:40:12 GMT." <"6af-970126023959-804F*/G=Andrew/S=Gordon/O=NET-TEL Computer Systems Ltd/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"@MHS> Date: Sun, 26 Jan 1997 14:24:58 -0500 From: "Brian J. McGovern" Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Thanks for the heads up. I tinkered with it quite a bit more (rougly 20+ times what the manual says it should take), and I'm getting reasonable performance out of it. Turns out they don't like my ATI wonder card (16 bit SVGA w/1MB of ram), and my S3 Trio VLB VGA card. After 10 or so hours now, I've gotten both machines running reasonably. My next stop is to see if I can find a 50 Mhz crystal for one of my machines, so I can wring every bit of processing speed out of it. -Brian From owner-freebsd-hackers Sun Jan 26 11:25:55 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA19880 for hackers-outgoing; Sun, 26 Jan 1997 11:25:55 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id LAA19866 for ; Sun, 26 Jan 1997 11:25:52 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA02101; Sun, 26 Jan 1997 12:07:40 -0700 From: Terry Lambert Message-Id: <199701261907.MAA02101@phaeton.artisoft.com> Subject: Re: CMD640b ide controller bug workarounds? To: tom@sdf.com (Tom Samplonius) Date: Sun, 26 Jan 1997 12:07:40 -0700 (MST) Cc: terry@lambert.org, garman@phs.k12.ar.us, freebsd-hackers@freebsd.org In-Reply-To: from "Tom Samplonius" at Jan 25, 97 06:26:52 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > So that FreeBSD will run on hardware as it comes from the manufacturer > > so that people who want to run FreeBSD can be pure computer users > > instead of a combination of computer user, petty cash drawer, and > > hardware hacker? > > You're dreaming. As long as hw manufactures make crap, computer usage > will never be "pure". Even the Linux solution requires the user to > diagnose the problem as hw, and add the "hda=serialize" option. It's possible to diagnose the chipset and automatically invoke the workaround. Linux has fallen down. See the test program on www.intel.com for the controller bug. 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 Sun Jan 26 12:16:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA21577 for hackers-outgoing; Sun, 26 Jan 1997 12:16:49 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA21565 for ; Sun, 26 Jan 1997 12:16:44 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA02186; Sun, 26 Jan 1997 12:58:33 -0700 From: Terry Lambert Message-Id: <199701261958.MAA02186@phaeton.artisoft.com> Subject: Re: CMD640b ide controller bug workarounds? To: garman@phs.k12.ar.us Date: Sun, 26 Jan 1997 12:58:33 -0700 (MST) Cc: tom@sdf.com, freebsd-hackers@freebsd.org In-Reply-To: from "Jason Garman" at Jan 25, 97 07:44:48 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I realize that this is a hardware flaw, but the computer manufacturer is > completely unresponsive to any requests (besides this machine is not > under warranty any more anyhow. If anyone has any suggestions as to how > to deal with the manufacturer, I'd love to hear those too) > > Their stock response is to have the OS `vendor' fix the `problem' in their > software. Sigh. Do they have a FAX machine? Fax them the chip specs. and ask again. The specs imply both channels can be active at the same time. Also, correct them: "fix the 'problem'" should be "work around the 'problem'", since the problem will still exist. Point out to them that you are objecting to the problem existing, not to the fact that it can be worked around in software. Ask them for an example of the software workaround for your OS. In general, be vocal and annoying until they do something in response to the irritation (even if they encapsulate you in pearl by replacing your motherboard, like an oyster would do, your problem will be solved). > Btw- an interesting side note... the `checkide' program that intel is > peddling to check the problem freezes my machine. Heh. Sad part is that > Intel refuses to even fix their program because my motherboard isn't an > Intel one. There are two check programs. You need to search for "+IDE +CMD640" on AltaVista. 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 Sun Jan 26 12:41:07 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA22669 for hackers-outgoing; Sun, 26 Jan 1997 12:41:07 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA22664 for ; Sun, 26 Jan 1997 12:41:05 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA02217; Sun, 26 Jan 1997 13:24:13 -0700 From: Terry Lambert Message-Id: <199701262024.NAA02217@phaeton.artisoft.com> Subject: Re: cvs commit: src/sys/kern kern_lockf.c To: michaelh@cet.co.jp Date: Sun, 26 Jan 1997 13:24:13 -0700 (MST) Cc: bde@freefall.freebsd.org, Hackers@FreeBSD.ORG In-Reply-To: from "Michael Hancock" at Jan 26, 97 01:15:56 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > All of the argument checking seems out of place here. The call trace is > like this: > > fcntl => VOP_ADVLOCK => lf_advlock > > or > > open => VOP_ADVLOCK => lf_advlock > > Garbage input should be stopped at the source and lf_advlock should be > completely free from arg checking. The original coder wanted to factor > error checking into lf_advlock, but it seems incorrect to allow garbage to > come in so far. > > A consistent division of arg checking responsibilities would make it > easier for people to decide where to do the checks. We would need some > comments or preconditions specified in lf_advlock to communicate what was > expected so that we would know what to do in fcntl and open. > > Any comments? Yes. The syntactic checking should be in the system call layer, and the grammatic checking should be in the lf_advlock layer, which should be called from the system call layer. A system call interface is a consumer of VFS services, just as an NFS or NetWare or SMB or Lantastic or AppleTalk server may be a consumer of VFS services without being a consumer of the system call layer. This is one of the things I am always on about. The call trace should be: fcntl(lock) <- check call syntax here lf_advlock(lock) <- check arg values here if( !VOP_ADVLOCK(lock)) lf_advlock(unlock) And the FS specific VOP_ADVLOCK should simply return 0 in all cases for most FS's. For fan-out layers (like union mount, where 1 VOP_ADVLOCK needs to apply to potentially more than one underlying stack), union.VOP_ADVLOCK(lock) if( rv = lf_advlock(lock)) <- underlying vnode 1 return( rv); <- FAIL if( underlying1.VOP_ADVLOCK(lock)) { lf_advlock(unlock); <- underlying vnode 1 return( 1); <- FAIL } if( rv = lf_advlock(lock)) { <- underlying vnode 2 underlying1.VOP_ADVLOCK(unlock); lf_advlock(unlock); <- underlying vnode 1 return( rv); <-- FAIL } if( underlying2.VOP_ADVLOCK(lock)) { lf_advlock(unlock); <- underlying vnode 2 underlying1.VOP_ADVLOCK(unlock); lf_advlock(unlock); <- underlying vnode 1 return( 1); <- FAIL } return( 0); With unwind in case the locking really needs to do something. Probably the easiest way to do this would be a list + recursion, and let a union only union 2 FS's (union does this, but make it a rule for others). Clearly, this would benefit from negative logic to enable a single point of exit from the unionfs code. It's as shown to make control flow obvious, but negative logic is best for SMP and kernel reentrancy of the routine to enable clean tracking of entry/exit lock state. All functions should be single-entry/single-exit, if possible, so as to not damage the ability to later implement SMP reentrancy and kernel multithreading as quickly and error-free as humanly possible. The veto architecture is needed to make union FS's not accidently lf_advlock() the same vnode twice. For example, say I have a quota and a non-quota "view" onto the same FS. The quota implementation is a stacking layer so that all FS's can have quotas. The vnode is passed through the quota layer, because all the quota layer does is a name space incursion to subtract out the quota file on the FS root. A lock on the quota vnode and the non-quota vnode would be a lock on the same vnode. For NFS, nfs.VOP_ADVLOCK(lock) #ifdef NFS_CLIENT_LOCKING return( nfs_client_lock(lock)); #else /* !NFS_CLIENT_LOCKING*/ return( 0); /* always succeed; current implementation*/ #endif /* !NFS_CLIENT_LOCKING*/ This has the advantage of a local lock on the same file failing before NFS has to hit actually the wire. The place for the checking is either fcntl + open, or lf_advlock, depending on who pulls the arguments in. The Lite2 locking implementation is slightly different, but can be handled the same way, since it's just a lock manager issue, not a hierarchy issue. 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 Sun Jan 26 12:49:16 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA23026 for hackers-outgoing; Sun, 26 Jan 1997 12:49:16 -0800 (PST) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA23016 for ; Sun, 26 Jan 1997 12:49:12 -0800 (PST) Received: from misery.sdf.com [204.244.213.33] by misery.sdf.com with smtp (Exim 1.59 #1) id 0voTme-0006VY-00; Sun, 26 Jan 1997 04:34:04 -0800 Date: Sun, 26 Jan 1997 04:34:04 -0800 (PST) From: Tom Samplonius To: Terry Lambert cc: garman@phs.k12.ar.us, freebsd-hackers@freebsd.org Subject: Re: CMD640b ide controller bug workarounds? In-Reply-To: <199701261907.MAA02101@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 26 Jan 1997, Terry Lambert wrote: > > > So that FreeBSD will run on hardware as it comes from the manufacturer > > > so that people who want to run FreeBSD can be pure computer users > > > instead of a combination of computer user, petty cash drawer, and > > > hardware hacker? > > > > You're dreaming. As long as hw manufactures make crap, computer usage > > will never be "pure". Even the Linux solution requires the user to > > diagnose the problem as hw, and add the "hda=serialize" option. > > It's possible to diagnose the chipset and automatically invoke the > workaround. Linux has fallen down. > > See the test program on www.intel.com for the controller bug. I've been told by the user in question, that the ide check program from Intel hangs on his system. Not too useful. "Pure computer usage" will not be possible until a "pure computer" exists. As it stands, sw people need to keep "adapting" to new hw bugs. > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. Tom From owner-freebsd-hackers Sun Jan 26 12:52:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA23236 for hackers-outgoing; Sun, 26 Jan 1997 12:52:47 -0800 (PST) Received: from pegasus.my.domain (capt-39.ppp.hooked.net [206.80.9.167]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA23231 for ; Sun, 26 Jan 1997 12:52:43 -0800 (PST) Received: from pegasus.my.domain (localhost [127.0.0.1]) by pegasus.my.domain (8.7.6/8.7.3) with SMTP id MAA12067 for ; Sun, 26 Jan 1997 12:53:09 -0800 Message-ID: <32EBC435.63297F3E@hooked.net> Date: Sun, 26 Jan 1997 12:53:09 -0800 From: RHS Linux User X-Mailer: Mozilla 3.01Gold (X11; I; Linux 2.0.27 i686) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: What to do about the 2.0 GNU libc? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I must appologize for my past posts to this mail list. I now see that freebsd is the way it is for a reason. Also the handling of ppp connections in linux and most other OS's really sucks. FreeBSD has the best implimentation I have ever seen. I am curious about the up and comming GNU 2.0 libc. Since the BSD's have their own libc will you be replacing yours with the GNU one? Not that I like GNU to much (it seams to be becomming the Microsoft of the free software world) but it would save a lot of developement time if you didn't have to worry about your own library. Since this the GNU libc will be used by Linux it would be hard to go wrong. FreeBSD would be using the same libc are it's chief competitor. FreeBSD would then only have the userland commands to deal with, since Linux of course has GNU maintaining those. I hate GNU binutils. The next question is. Is the GNU libc 2.0 being ported? I saw that someone was doing a port for BSDI2.0, is this not the same as FreeBSD? I am very interested the GNU libc 2.0 for its posix threads and the fact that it is rentrant (which it has to be of course for threads). What is the status of kernel-threads in FreeBSD? I heard that you where getting there. Since you have linux compatibility (except for clone() right?) would it not be possible to just use the GNU libc 2.0 the way it is? Does it ever have to be ported? I am sure Linux will always have presidence with GNU anyway. This of course looks really bad since eventually freebsd will have linux's kernel calls. But think about it. It is only externel, just as the GNU libc is externel. Is FreeBSD BSD without the BSD libc? Good question. I have many more questions.... Thanks... From owner-freebsd-hackers Sun Jan 26 13:01:19 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA24013 for hackers-outgoing; Sun, 26 Jan 1997 13:01:19 -0800 (PST) Received: from pegasus.my.domain (capt-39.ppp.hooked.net [206.80.9.167]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA24008 for ; Sun, 26 Jan 1997 13:01:15 -0800 (PST) Received: from pegasus.my.domain (localhost [127.0.0.1]) by pegasus.my.domain (8.7.6/8.7.3) with SMTP id NAA12098 for ; Sun, 26 Jan 1997 13:01:41 -0800 Message-ID: <32EBC635.4F86F1D5@hooked.net> Date: Sun, 26 Jan 1997 13:01:41 -0800 From: RHS Linux User X-Mailer: Mozilla 3.01Gold (X11; I; Linux 2.0.27 i686) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: What is the default for async in /etc/fstab? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I am having trouble determining the disk IO performace of FreeBSD vs. Linux. I recently ran a test on FreeBSD and the write performance wasn't so great. However, I didn't think to see if async was set in the /etc/fstab file. I installed from a 2.1 CDROM initially and then cvsuped different versions. So what is the default for async in the 2.1 /etc/fstab? Have other people tested ufs vs. ext2? The only docs I could find where for ext2. A comparison with FreeBSD 2.0 I think, although it could have been older. This was for some old Linux 1.xx. Hardware. Adapt. 2940UW, and Quantum 4.3gig Atlas, 7200rpm. 8.5ms. Thanks. From owner-freebsd-hackers Sun Jan 26 13:23:44 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA25041 for hackers-outgoing; Sun, 26 Jan 1997 13:23:44 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA25036 for ; Sun, 26 Jan 1997 13:23:41 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA02273; Sun, 26 Jan 1997 14:05:45 -0700 From: Terry Lambert Message-Id: <199701262105.OAA02273@phaeton.artisoft.com> Subject: Re: SLAB stuff, and applications to current net code (fwd) To: proff@suburbia.net Date: Sun, 26 Jan 1997 14:05:45 -0700 (MST) Cc: hackers@freebsd.org In-Reply-To: <19970126042316.10096.qmail@suburbia.net> from "proff@suburbia.net" at Jan 26, 97 03:23:16 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I'm going to try feveriously to get the SLAB allocator integrated into > > Linus's sources over the next two days. For the most part my > > incentive is so that people think about it when they design memory > > object allocation subsystems. > > > > For example, even right now, look at the way struct sock's are indeed > > allocated. Alan's recent change to add sock_init_data() and the fact > > that my sources already use SLAB for struct sock sparked this idea. > > > > We could in this case just make sock_init_data() the constructor > > routine for the sock SLAB. So for a warm SLAB cache this code never > > gets run as long as users of sock's are not forgetful and leave a sock > > in a reasonable state when they free them. (ie. don't leave crap on > > the receive queue etc.) > > Can anyone inform me what a SLAB allocator is, and if so, would freebsd > benefit from one? In simple terms, it allocates "slabs" of memory for memory pools of a particular type, generally in units of pages. It is basically a variant of the zone allocator (per MACH). You can implement memory zoning, per MACH, to tag object persistance within a SLAB allocator. Assuming you allocate the kernel space itself with the SLAB allocator, and the kernel image is assembled on SLAB boundries, you can even do things like zone discard, which let you throw away initialization code once the system is up, and reclaim the memory for reuse by the system. One of the reasons I want ELF is to allow zone discard. Technically, FreeBSD already does SLAB allocation, or at least its interface looks like it does. The sys/malloc.h values M_MBUF, M_SOCKET, M_NAMEI, etc. used by the kernel malloc, are all SLAB identifiers. --- In a kernel multithreading or SMP environment, you don't *want* a SLAB allocator... at least, not a pure one, as the base level for allocation. You want a global page-pool allocator instead, and then you will implement your allocator on top of the page pool. There are even reasons you might want to have this on a simple UP system. Because the kernel is reeentrant, you can reenter the allocator on a SLAB id. FreeBSD currently copes with this (badly) on its fault/interrupt reentrancy case... for example, allocating an mbuf at interrupt level requires that the mbuf SLAB be guarded against reentrancy by running the allocation to completion at high SPL so that it is never really reentered while the data structure is in an indeterminate state. This adds to processing latency in the kernel. In reality, each context wants its own set of SLABs. This may be overkill for exception reentrancy, actually. The way Microsoft does this in Windows95 and NT is dividing the interrupt service routines into "upper" and "lower", with "lower" running at interrupt mode, and "upper" running in non-interrupt mode. In Windows95 and NT, you do not do memory allocation at interrupt level; you must preallocate the memory at driver init, and allocate it again in "upper" code if the preallocated object is consumed by the "lower" code. If you don't want to make this restriction on the use of allocators (there are several places where the preallocation overhead would be exhorbitant, like FDDI or ATM with large card buffers), then you must provide a seperate set of SLABs for a context. In terms of context SLABs, you *do* want seperate SLABs for each processor context in SMP. The reason you want this is that using a global SLAB pool, like in SVR4 or Solaris, you must line up all your processors behind the IPI in order to synchronize access to the SLAB control object for the object type you are allocating. The correct method, first demonstrated in Sequent Dynix, is to have per processor page pools. The synchronization is not required unless you need to refill the page pool from (low water mark) or drain the page pool to (high watermark) the global system page pool. This method is documented in: "UNIX Internals: The New Frontiers" Uresh Vahalia, _Prentice Hall_ ISBN 0-13-101908-2 Chapter 12 _Kernel Memory Allocation_ Section 12.9 _A Hierarchical Allocator for Multiprocessors Sequent failed to implement SLAB allocation on top of this page pool abstraction, and so Vahalia's Analysis is rather harsh, compared to his analysis of SLAB allocation (covered Section 12.10). But it is incorrect to call the SLAB allocation itself superior. Vahalia cites a paper: "Efficient Kernel Memory Allocation on Shared Memory Multiprocessors" McKenney, P.E. and Slingwine, J. Proceedings of USENIX, Winter, 1993 Which shows the sequent code to be faster than the McKusick-Karels algorithm by a factor of three to five on a UP, and a factor of one hundred to one thousand on a 25 processor system. Clearly, if we considered contexts as owning pools instead of CPU's, we should expect a three to nine times improvement for UP BSD from having seperate contexts for interrupt vs. exception vs. normal allocations (in place of running the allocations to completion at high SPL). This might not have more than a 10% scaled effect on a heavily interrupting FreeBSD system, but a 10% improvement is an improvement. There are a number of issues, like object garbage collection, which you would do using cache invalidation at IPI synchronization time to determine if a low water mark hit is real or not. For instance, I may allocate an mbuf on CPU 1 and pass it's address to CPU 2 for use by a user process context entered in the TCP code. If the CPU 2 process then deallocates the MBUF, the cache line indicating the allocation will not have been invalidated. Effectively, this means that there must be an allocation map with each object, and that it must be dynamically scoped. This lets CPU2 mark the map entry as invalid, even though CPU1 did the allocating. CPU1 would sync his picture to that of the global picture at low water mark, reclaiming released buffers at that time. In reality, it's probably better to have a message interface per SLAB per CPU to propagate deallocation messages... if you didn't do that, then a deallocation on CPU1 or CPU3 could cause a corrupt cache line to be written. Rather than fighting between CPU's and being careful at the cache line level, the IPI synchronization should allow message delivery at IPI; this will generally be very fast, since the memory can be preallocated with page attributes so the que pointer ownership is toggled at IPI time. We can go into this in detail if anyone wants to, but the SMP list is probably a better forum for these issues. 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 Sun Jan 26 13:25:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA25104 for hackers-outgoing; Sun, 26 Jan 1997 13:25:32 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA25096; Sun, 26 Jan 1997 13:25:29 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA02284; Sun, 26 Jan 1997 14:08:43 -0700 From: Terry Lambert Message-Id: <199701262108.OAA02284@phaeton.artisoft.com> Subject: Re: Possible projects? To: hsu@freefall.freebsd.org (Jeffrey Hsu) Date: Sun, 26 Jan 1997 14:08:43 -0700 (MST) Cc: kneel@ishiboo.com, hackers@freefall.freebsd.org In-Reply-To: <199701260732.XAA23320@freefall.freebsd.org> from "Jeffrey Hsu" at Jan 25, 97 11:32:57 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > You could try converting the kernel memory allocator to a slab > allocator. See the Unix Frontiers books for more details and > ideas for other projects. Please see my other posting. I know it isn't a pure SLAB allocator, but the interface is we use is a SLAB interface. Also, there are many cases where a pure SLAB allocator is a very, very bad idea. Using an impure allocator could win 1.1 times performance over a SLAB allocator in the up case, and 100 to 1000 time performance in the MP case. 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 Sun Jan 26 13:30:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA25427 for hackers-outgoing; Sun, 26 Jan 1997 13:30:47 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA25422; Sun, 26 Jan 1997 13:30:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id NAA08138; Sun, 26 Jan 1997 13:30:26 -0800 (PST) Message-Id: <199701262130.NAA08138@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Luigi Rizzo cc: dyson@freebsd.org, hackers@freebsd.org Subject: Re: exec bug In-reply-to: Your message of "Sun, 26 Jan 1997 14:17:12 +0100." <199701261317.OAA28121@labinfo.iet.unipi.it> From: David Greenman Reply-To: dg@root.com Date: Sun, 26 Jan 1997 13:30:26 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> >> In the case of NFS, the read should block indefinately. I'm not sure what >> >> will happen if the NFS is mounted "soft", however. >> > >> >that would be a major problem then! >> >> Not any more so than any other read blocking indefinately. > >I was referring to the soft case. the blocking read only leaves >the process hung, and possibly not dying at shutdown. But an nfs >'soft' read timing out with a failure, isn't it a time-bomb ? Like I said, I'm not sure what will happen. The system might just leave a zeroed page in memory which would cause execve() to return a exec format failure to the process. On the other hand, it probably will return a fault failure and cause a panic...I just don't know for sure. In any case, using 'soft' mounts for executables is a bad idea no matter how you slice it...it shouldn't kill the system, however. >> > Wouldn't it be possible to track >> >the exact reason of the fault inside the handler and avoid panicing ? >> >After all there are no performance problems at that point.. >> >> ...and just how do you tell the exec code that a page fault that occured >> while it was accessing the image header was "fatal"? The only mechanism we > >you mean "was not fatal" dont you ? No, I mean that you only take special action in the failure case, so that is the case you want to know about. >> have for this is signals, and that doesn't work when you're executing in the >> kernel like this. > >I don't know the "big picture" so this could be totally nonsense, >but how about creating a "page_probe()" function, cooperating with >the fault handler, which tries to access the page, returning 1 if >any page fault occur in the kernel address space while running ? >Then exec_aout_imgact() (or any other critical function) could >first page_probe() the required page, then either continue or fail. >There shouldn't be much penalty in doing this since at most the >page gets paged in, something that would be necessary anyways. See my last reply to Bruce. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Sun Jan 26 13:33:04 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA25587 for hackers-outgoing; Sun, 26 Jan 1997 13:33:04 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA25581 for ; Sun, 26 Jan 1997 13:33:01 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA02297; Sun, 26 Jan 1997 14:14:46 -0700 From: Terry Lambert Message-Id: <199701262114.OAA02297@phaeton.artisoft.com> Subject: Re: fdisk headache To: joerg_wunsch@uriah.heep.sax.de Date: Sun, 26 Jan 1997 14:14:45 -0700 (MST) Cc: freebsd-hackers@freebsd.org In-Reply-To: from "J Wunsch" at Jan 26, 97 10:46:01 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Boot selectors won't work either. > > Since there's nothing to select from. ;-) > > Right now, there are three reasons to still call it ``dangerously > dedicated'': > > . Since the MBR is identical to the BSD bootstrap, there's no room for > things like `nextboot' after the MBR, and you can't replace the MBR > by fancy things like a boot selector. Hence, in a system that is > not FreeBSD-only, you could at best make drives != #0 ``DD'', and > you won't be able to boot select away from that drive once you > switched there. (Normally, booteasy allows to wander around back > and forth through all the drives.) This is evil. The purpose of the DOS MBR and partition table is to make BIOS happy and to allow multiboot. We don't do ourselves any favors by sabotoging that for other OS's. > The plus side is: [ ... ] > . The number of BIOS geometry constraints to care for reduces drastic- > ally, so you can usually (*) ignore any geometry issues. > > (*) I.e., the BIOS's geometry idea involves at least 15 sectors per > track, 4 heads, and the root file system is not larger than 30 MB. This is a bogus argument based on the assumption that we wouldn't put an absolute sector address in the partition entry like we should so a sector-offset based driver (BSD) could still use the partition table entry without multiplying out C/H/S values. Note that we should put the entry there for our parttition: we should not rely on a DOS tool to do it correctly for us. 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 Sun Jan 26 13:33:16 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA25602 for hackers-outgoing; Sun, 26 Jan 1997 13:33:16 -0800 (PST) Received: from jason.garman.net (pm106-02.dialip.mich.net [192.195.231.204]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA25597 for ; Sun, 26 Jan 1997 13:33:11 -0800 (PST) Received: (qmail 917 invoked by uid 1000); 26 Jan 1997 21:33:04 -0000 Message-ID: Date: Sun, 26 Jan 1997 16:33:04 -0500 From: garman@jason.garman.net (Jason Garman) To: terry@lambert.org (Terry Lambert) Cc: freebsd-hackers@freebsd.org Subject: Re: CMD640b ide controller bug workarounds? References: <199701261958.MAA02186@phaeton.artisoft.com> X-Mailer: Mutt 0.58 Mime-Version: 1.0 Reply-To: garman@phs.k12.ar.us X-Phase-Of-Moon: The Moon is Waning Gibbous (92% of Full) X-Operating-System: FreeBSD/i386 2.1.5-RELEASE In-Reply-To: <199701261958.MAA02186@phaeton.artisoft.com>; from Terry Lambert on Jan 26, 1997 12:58:33 -0700 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Terry Lambert writes: > Fax them the chip specs. and ask again. The specs imply both channels > can be active at the same time. > I have the specs sitting right in front of me (it's available in pdf format from their ftp server). Not that any tech drone I'm going to get on the phone is going to understand these specs...and why they imply that both channels can be active simultaneously. > Also, correct them: "fix the 'problem'" should be "work around the > 'problem'", since the problem will still exist. Point out to them > that you are objecting to the problem existing, not to the fact that > it can be worked around in software. > Good point. Thanks for the tip. > In general, be vocal and annoying until they do something in response > to the irritation (even if they encapsulate you in pearl by replacing > your motherboard, like an oyster would do, your problem will be solved). > I've done this type of thing before (with packard bell of all companies-- and actually got results...), so I guess I can try again. The last time I called they were `overloaded with holiday orders and tech questions' (yeah right) and would hand you off to an automated answering machine where you could leave your name and number. Needless to say, they never called back. The company is Zenon Technology, 818-935-1828. They also have an 800 number but I don't have that sitting in front of me right now... > There are two check programs. You need to search for "+IDE +CMD640" on > AltaVista. > EIDEtest you mean? I just grabbed it. Going to try it in a sec. for anyone else who's interested. Enjoy, -- Jason Garman http://www.nesc.k12.ar.us/~garman/ Student, Eleanor Roosevelt High School garman@phs.k12.ar.us From owner-freebsd-hackers Sun Jan 26 13:35:44 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA25804 for hackers-outgoing; Sun, 26 Jan 1997 13:35:44 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA25793 for ; Sun, 26 Jan 1997 13:35:42 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA02314; Sun, 26 Jan 1997 14:16:41 -0700 From: Terry Lambert Message-Id: <199701262116.OAA02314@phaeton.artisoft.com> Subject: Re: SLAB stuff, and applications to current net code (fwd) To: michaelh@cet.co.jp (Michael Hancock) Date: Sun, 26 Jan 1997 14:16:41 -0700 (MST) Cc: proff@suburbia.net, hackers@FreeBSD.ORG In-Reply-To: from "Michael Hancock" at Jan 26, 97 08:36:44 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Can anyone inform me what a SLAB allocator is, and if so, would freebsd > > benefit from one? > > It's a chunk of memory that you put multiple kernel objects of the same > type into. We have a modified mach zone allocator. They're both type > stable memory allocators. A SLAB allocator is also a modified MACH zone allocator. > I not sure how much benefit the SLAB allocator would offer over what we > have. There's some extra overhead in maintaining a SLAB. There is significant cache benefit. See Vahalia. > BTW, SLAB is used in Solaris. Yes, "pure SLAB"... and it handicaps their SMP something fierce. 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 Sun Jan 26 13:38:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA26060 for hackers-outgoing; Sun, 26 Jan 1997 13:38:32 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA26055 for ; Sun, 26 Jan 1997 13:38:29 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA02324; Sun, 26 Jan 1997 14:18:45 -0700 From: Terry Lambert Message-Id: <199701262118.OAA02324@phaeton.artisoft.com> Subject: Re: SLAB stuff, and applications to current net code (fwd) To: dg@root.com Date: Sun, 26 Jan 1997 14:18:45 -0700 (MST) Cc: michaelh@cet.co.jp, proff@suburbia.net, hackers@FreeBSD.ORG In-Reply-To: <199701261235.EAA06772@root.com> from "David Greenman" at Jan 26, 97 04:35:36 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > The allocator in BSD is designed to be as fast as possible and trades > space efficiency for performance. I'm very skeptical that a SLAB allocator > would be any faster than the current allocation algorithm, although it > would likely be more space efficient. Are you looking at the TLB overhead for SLAB? Technically, the FreeBSD allocator meets the interface criteria for SLAB, though it's not SLAB (as you point out, it's not type-stable). 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 Sun Jan 26 13:49:17 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA26673 for hackers-outgoing; Sun, 26 Jan 1997 13:49:17 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA26655 for ; Sun, 26 Jan 1997 13:49:11 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA02357; Sun, 26 Jan 1997 14:29:38 -0700 From: Terry Lambert Message-Id: <199701262129.OAA02357@phaeton.artisoft.com> Subject: Re: CMD640b ide controller bug workarounds? To: tom@sdf.com (Tom Samplonius) Date: Sun, 26 Jan 1997 14:29:38 -0700 (MST) Cc: terry@lambert.org, garman@phs.k12.ar.us, freebsd-hackers@FreeBSD.org In-Reply-To: from "Tom Samplonius" at Jan 26, 97 04:34:04 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > See the test program on www.intel.com for the controller bug. > > I've been told by the user in question, that the ide check program from > Intel hangs on his system. Not too useful. There are two programs. I pointed at the wrong one. I posted an AltaVista search string that will find the other. > "Pure computer usage" will not be possible until a "pure computer" > exists. As it stands, sw people need to keep "adapting" to new hw bugs. Yes. And this is a case where they have not adapted, such that the user can't assume the sw platform is reliable on any hardware. I'm seperating the idea of a sw platform user from a sw user on that platform -- maybe that's the confusion? 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 Sun Jan 26 13:58:16 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA27031 for hackers-outgoing; Sun, 26 Jan 1997 13:58:16 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA27026 for ; Sun, 26 Jan 1997 13:58:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id NAA08258; Sun, 26 Jan 1997 13:56:14 -0800 (PST) Message-Id: <199701262156.NAA08258@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Terry Lambert cc: michaelh@cet.co.jp, bde@freefall.freebsd.org, Hackers@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern kern_lockf.c In-reply-to: Your message of "Sun, 26 Jan 1997 13:24:13 MST." <199701262024.NAA02217@phaeton.artisoft.com> From: David Greenman Reply-To: dg@root.com Date: Sun, 26 Jan 1997 13:56:14 -0800 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >This is one of the things I am always on about. > > >The call trace should be: > > fcntl(lock) <- check call syntax here > lf_advlock(lock) <- check arg values here > if( !VOP_ADVLOCK(lock)) > lf_advlock(unlock) > >And the FS specific VOP_ADVLOCK should simply return 0 in all cases for >most FS's. I disagree. The call trace should be: fcntl(lock) VOP_ADVLOCK(lock) lf_advlock(lock) This works properly with unusual filesystem stacking and is more flexible. >The veto architecture is needed to make union FS's not accidently >lf_advlock() the same vnode twice. For example, say I have a quota >and a non-quota "view" onto the same FS. The quota implementation >is a stacking layer so that all FS's can have quotas. The vnode >is passed through the quota layer, because all the quota layer does >is a name space incursion to subtract out the quota file on the FS >root. A lock on the quota vnode and the non-quota vnode would be >a lock on the same vnode. Only leaf filesystems should call lf_advlock(), so upper layers don't matter. union_advlock should just be a pass-through. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Sun Jan 26 14:01:40 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA27228 for hackers-outgoing; Sun, 26 Jan 1997 14:01:40 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA27220 for ; Sun, 26 Jan 1997 14:01:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id OAA08317; Sun, 26 Jan 1997 14:01:12 -0800 (PST) Message-Id: <199701262201.OAA08317@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: RHS Linux User cc: freebsd-hackers@freebsd.org Subject: Re: What to do about the 2.0 GNU libc? In-reply-to: Your message of "Sun, 26 Jan 1997 12:53:09 PST." <32EBC435.63297F3E@hooked.net> From: David Greenman Reply-To: dg@root.com Date: Sun, 26 Jan 1997 14:01:12 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >I must appologize for my past posts to this mail list. I now see that >freebsd is the way it is for a reason. Also the handling of ppp >connections in linux and most other OS's really sucks. FreeBSD has the >best implimentation I have ever seen. > >I am curious about the up and comming GNU 2.0 libc. Since the BSD's have >their own libc will you be replacing yours with the GNU one? Not that I >like GNU to much (it seams to be becomming the Microsoft of the free >software world) but it would save a lot of developement time if you >didn't have to worry about your own library. Since this the GNU libc >will be used by Linux it would be hard to go wrong. FreeBSD would be >using the same libc are it's chief competitor. FreeBSD would then only >have the userland commands to deal with, since Linux of course has GNU >maintaining those. I hate GNU binutils. No, the GNU libc is GPL'd which would cause distribution restrictions for everything that is linked with it. Unlike GNU, we actually encourage commercial re-use of FreeBSD code (in embedded systems, for example). -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Sun Jan 26 14:10:03 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA27554 for hackers-outgoing; Sun, 26 Jan 1997 14:10:03 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA27538 for ; Sun, 26 Jan 1997 14:09:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id OAA08360; Sun, 26 Jan 1997 14:07:28 -0800 (PST) Message-Id: <199701262207.OAA08360@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Terry Lambert cc: michaelh@cet.co.jp, proff@suburbia.net, hackers@FreeBSD.ORG Subject: Re: SLAB stuff, and applications to current net code (fwd) In-reply-to: Your message of "Sun, 26 Jan 1997 14:18:45 MST." <199701262118.OAA02324@phaeton.artisoft.com> From: David Greenman Reply-To: dg@root.com Date: Sun, 26 Jan 1997 14:07:28 -0800 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> The allocator in BSD is designed to be as fast as possible and trades >> space efficiency for performance. I'm very skeptical that a SLAB allocator >> would be any faster than the current allocation algorithm, although it >> would likely be more space efficient. > >Are you looking at the TLB overhead for SLAB? See my other reply regarding ordering of allocations. Memory that was recently freed is re-used before memory that was freed long ago, which should have both better cache effects and less TLB overhead (than the original BSD allocator). This should compare well to the slab allocator, but it would perhaps be interesting to actually do a formal comparison. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Sun Jan 26 14:16:46 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA27945 for hackers-outgoing; Sun, 26 Jan 1997 14:16:46 -0800 (PST) Received: from jason.garman.net (pm106-09.dialip.mich.net [192.195.231.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id OAA27931 for ; Sun, 26 Jan 1997 14:16:32 -0800 (PST) Received: (qmail 363 invoked by uid 1000); 26 Jan 1997 22:16:25 -0000 Message-ID: Date: Sun, 26 Jan 1997 17:16:25 -0500 From: garman@jason.garman.net (Jason Garman) To: terry@lambert.org (Terry Lambert) Cc: freebsd-hackers@freebsd.org Subject: Re: CMD640b ide controller bug workarounds? References: <199701261958.MAA02186@phaeton.artisoft.com> X-Mailer: Mutt 0.58 Mime-Version: 1.0 Reply-To: garman@phs.k12.ar.us X-Phase-Of-Moon: The Moon is Waning Gibbous (91% of Full) X-Operating-System: FreeBSD/i386 2.1.5-RELEASE In-Reply-To: <199701261958.MAA02186@phaeton.artisoft.com>; from Terry Lambert on Jan 26, 1997 12:58:33 -0700 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Terry Lambert writes: > There are two check programs. You need to search for "+IDE +CMD640" on > AltaVista. > EIDEtest (if that's the other one you're referring to) simply asks you to do background I/O operations on, say, the second interface drives while the program does I/O on the first interface... since that causes the machine to freeze, the same would happen here. The old rztest program that Intel put out at the beginning of all this mess didn't even test for this particular flaw, because it doesn't exist in the RZ1000 chip that it checked for. Regarding automatic detection mechanisms- FreeBSD already notices that I have the flawed chip: ... *** pci0:12: CMD, device=0x0640, class=storage (ide) int a irq 14 [no driver assigned] ... wdc0 at 0x1f0-0x1f7 irq 14 on isa wdc0: unit 0 (wd0): wd0: 696MB (1427328 sectors), 1416 cyls, 16 heads, 63 S/T, 512 B/S wdc0: unit 1 (atapi): , removable, accel, dma, iordy wcd0: 344Kb/sec, 256Kb cache, audio play, 256 volume levels, ejectable tray wcd0: medium type unknown, unlocked wdc1 at 0x170-0x177 irq 15 on isa wdc1: unit 0 (wd2): wd2: 1916MB (3924144 sectors), 3893 cyls, 16 heads, 63 S/T, 512 B/S And as for L*nux, looking through AltaVista's search results for the query you gave me, it seems that L*nux _does_ automatically and non-destructively detect and work around the CMD 640b bugs. (no hda=serialize needed after all, apparently) Detecting a VLB board using this chip would be harder (is it even possible)? Enjoy, -- Jason Garman http://www.nesc.k12.ar.us/~garman/ Student, Eleanor Roosevelt High School garman@phs.k12.ar.us From owner-freebsd-hackers Sun Jan 26 14:28:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA28552 for hackers-outgoing; Sun, 26 Jan 1997 14:28:01 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA28540 for ; Sun, 26 Jan 1997 14:27:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id OAA08492; Sun, 26 Jan 1997 14:25:45 -0800 (PST) Message-Id: <199701262225.OAA08492@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Terry Lambert cc: proff@suburbia.net, hackers@FreeBSD.ORG Subject: Re: SLAB stuff, and applications to current net code (fwd) In-reply-to: Your message of "Sun, 26 Jan 1997 14:05:45 MST." <199701262105.OAA02273@phaeton.artisoft.com> From: David Greenman Reply-To: dg@root.com Date: Sun, 26 Jan 1997 14:25:45 -0800 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Vahalia cites a paper: > "Efficient Kernel Memory Allocation on Shared Memory > Multiprocessors" > McKenney, P.E. and Slingwine, J. > Proceedings of USENIX, Winter, 1993 > >Which shows the sequent code to be faster than the McKusick-Karels >algorithm by a factor of three to five on a UP, and a factor of >one hundred to one thousand on a 25 processor system. I haven't read that paper, but I suspect that the numbers are wrong due to spl* having high overhead back then. Since Bruce's "fast interrupt" code, spl* is almost free, and this changes things greatly. The situation might change slightly in MP systems, but the total time inside of malloc is so small that I really doubt that synchronization/serialization will ever be a significant problem. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Sun Jan 26 14:44:07 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA29537 for hackers-outgoing; Sun, 26 Jan 1997 14:44:07 -0800 (PST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA29508 for ; Sun, 26 Jan 1997 14:44:02 -0800 (PST) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.4/8.8.4) with SMTP id OAA17789; Sun, 26 Jan 1997 14:37:51 -0800 (PST) Message-ID: <32EBDC19.794BDF32@whistle.com> Date: Sun, 26 Jan 1997 14:35:05 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: proff@suburbia.net CC: dg@root.com, hackers@freebsd.org, alan.cox@linux.org Subject: Re: SLAB stuff, and applications to current net code (fwd) References: <19970126125747.19508.qmail@suburbia.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk proff@suburbia.net wrote: > > > >I not sure how much benefit the SLAB allocator would offer over what we > > >have. There's some extra overhead in maintaining a SLAB. > > > > > >BTW, SLAB is used in Solaris. > > > > The allocator in BSD is designed to be as fast as possible and trades > > space efficiency for performance. I'm very skeptical that a SLAB allocator > > would be any faster than the current allocation algorithm, although it > > would likely be more space efficient. > > > > -DG > > > > David Greenman > > Core-team/Principal Architect, The FreeBSD Project > > > > I presume the idea is that the cache efficiency of small allocations > would be substantially improved? > > Cheers, > Julian I talked with alan about this at the USENIX conf. He told me that originally he looked at using a BSD style allocator, but that small allocations of mbufs etc all hit the same cache lines as they were always on powers of two. (obviously) especially when working on the headers of large packets. he saw a noticable problem with cache overwrites. I didn't get it all but probably he could tell us more.. I've CC'd him. He seems very knowledgable about BSD internals and not at all the screaming fanatic that we sometimes see in the linux camp so I really enjoyed the conversation.. julian From owner-freebsd-hackers Sun Jan 26 15:02:02 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA00470 for hackers-outgoing; Sun, 26 Jan 1997 15:02:02 -0800 (PST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA00465 for ; Sun, 26 Jan 1997 15:01:59 -0800 (PST) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.4/8.8.4) with SMTP id OAA18010; Sun, 26 Jan 1997 14:57:15 -0800 (PST) Message-ID: <32EBE0A4.3F54BC7E@whistle.com> Date: Sun, 26 Jan 1997 14:54:28 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: dg@root.com CC: RHS Linux User , freebsd-hackers@FreeBSD.ORG Subject: Re: What to do about the 2.0 GNU libc? References: <199701262201.OAA08317@root.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk David Greenman wrote: > > >I must appologize for my past posts to this mail list. I now see that > >freebsd is the way it is for a reason. Also the handling of ppp > >connections in linux and most other OS's really sucks. FreeBSD has the > >best implimentation I have ever seen. > > > >I am curious about the up and comming GNU 2.0 libc. Since the BSD's have > >their own libc will you be replacing yours with the GNU one? Not that I > >like GNU to much (it seams to be becomming the Microsoft of the free > >software world) but it would save a lot of developement time if you > >didn't have to worry about your own library. Since this the GNU libc > >will be used by Linux it would be hard to go wrong. FreeBSD would be > >using the same libc are it's chief competitor. FreeBSD would then only > >have the userland commands to deal with, since Linux of course has GNU > >maintaining those. I hate GNU binutils. > > No, the GNU libc is GPL'd which would cause distribution restrictions > for everything that is linked with it. Unlike GNU, we actually encourage > commercial re-use of FreeBSD code (in embedded systems, for example). > Gnu libc is LGPL'd of course, which has much lighter restrictions.. (dont ha ve to do all the source redistribution stuff for linked binaries etc.) > -DG > > David Greenman > Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Sun Jan 26 15:27:28 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA01529 for hackers-outgoing; Sun, 26 Jan 1997 15:27:28 -0800 (PST) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA01524 for ; Sun, 26 Jan 1997 15:27:24 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.3/CET-v2.1) with SMTP id XAA25209; Sun, 26 Jan 1997 23:26:48 GMT Date: Mon, 27 Jan 1997 08:26:48 +0900 (JST) From: Michael Hancock To: David Greenman cc: proff@suburbia.net, hackers@FreeBSD.ORG Subject: Re: SLAB stuff, and applications to current net code (fwd) In-Reply-To: <199701261235.EAA06772@root.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 26 Jan 1997, David Greenman wrote: > >On Sun, 26 Jan 1997 proff@suburbia.net wrote: > > > >> Can anyone inform me what a SLAB allocator is, and if so, would freebsd > >> benefit from one? > >> > > > >It's a chunk of memory that you put multiple kernel objects of the same > >type into. We have a modified mach zone allocator. They're both type > >stable memory allocators. > > The memory allocator in BSD is *not* type-stable. For SMP it might more make sense to create typed global pools to allocate objects per zone, than putting effort into a SLAB allocator. > The allocator in BSD is designed to be as fast as possible and trades > space efficiency for performance. I'm very skeptical that a SLAB allocator > would be any faster than the current allocation algorithm, although it > would likely be more space efficient. It did seem easier to color the cache with the SLAB implementation. I don't remember the results of John's page coloring work to distribute hits in the cache. > -DG > > David Greenman > Core-team/Principal Architect, The FreeBSD Project > From owner-freebsd-hackers Sun Jan 26 15:41:52 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA02310 for hackers-outgoing; Sun, 26 Jan 1997 15:41:52 -0800 (PST) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA02305 for ; Sun, 26 Jan 1997 15:41:49 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.3/CET-v2.1) with SMTP id XAA25270; Sun, 26 Jan 1997 23:40:49 GMT Date: Mon, 27 Jan 1997 08:40:49 +0900 (JST) From: Michael Hancock Reply-To: Michael Hancock To: Terry Lambert cc: bde@freefall.freebsd.org, FreeBSD Hackers Subject: Re: cvs commit: src/sys/kern kern_lockf.c In-Reply-To: <199701262024.NAA02217@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 26 Jan 1997, Terry Lambert wrote: > > All of the argument checking seems out of place here. The call trace is > > like this: > > > > fcntl => VOP_ADVLOCK => lf_advlock > > > > or > > > > open => VOP_ADVLOCK => lf_advlock > > > > Garbage input should be stopped at the source and lf_advlock should be > > completely free from arg checking. The original coder wanted to factor > > error checking into lf_advlock, but it seems incorrect to allow garbage to > > come in so far. > > > > A consistent division of arg checking responsibilities would make it > > easier for people to decide where to do the checks. We would need some > > comments or preconditions specified in lf_advlock to communicate what was > > expected so that we would know what to do in fcntl and open. > > > > Any comments? > > Yes. The syntactic checking should be in the system call layer, and > the grammatic checking should be in the lf_advlock layer, which should > be called from the system call layer. [..] > The call trace should be: > > fcntl(lock) <- check call syntax here > lf_advlock(lock) <- check arg values here > if( !VOP_ADVLOCK(lock)) > lf_advlock(unlock) > [..] > The place for the checking is either fcntl + open, or lf_advlock, > depending on who pulls the arguments in. Taking the preposterous lengths checking example, checking isn't necessary in open case since it is initialized to zero in the body of open. The cases you need to check are directly triggered externally in fcntl by user programs. This is why I think arg values should be checked at the system call level in this case. Regards, Mike From owner-freebsd-hackers Sun Jan 26 15:42:00 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA02337 for hackers-outgoing; Sun, 26 Jan 1997 15:42:00 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA02329 for ; Sun, 26 Jan 1997 15:41:56 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.4/8.6.9) with ESMTP id PAA09975; Sun, 26 Jan 1997 15:41:53 -0800 (PST) To: grog@lemis.de (Greg Lehey) cc: hackers@freebsd.org (FreeBSD Hackers), isdn@muc.ditec.de (FreeBSD ISDN Distribution List) Subject: Re: bisdn In-reply-to: Your message of "Sun, 26 Jan 1997 15:59:08 +0100." <199701261459.PAA04577@freebie.lemis.de> Date: Sun, 26 Jan 1997 15:41:53 -0800 Message-ID: <9971.854322113@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I don't think that the problems are technical so much as political, something which generally sucks given that the last thing the free software community needs to be doing is shooting its feet off and generally handing the boys at microsoft an even more overwhelming advantage ("you can't crush us! hah! we plan to commit suicide through sheer stupidity and ego way before we'll let that happen!" :-) Oh well. Sigh! :-) Jordan > Jordan K. Hubbard writes: > >> and greatly appreciated, too ! Several people will be working on getting > >> this integrated into -current (aka 3.0). > > > > Really? Awesome! I'd just about given up! :-) > > What's the problem? I've been running bisdn on 2.2-CURRENT and > 3.0-CURRENT since last May. > > Greg > From owner-freebsd-hackers Sun Jan 26 15:50:48 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA02827 for hackers-outgoing; Sun, 26 Jan 1997 15:50:48 -0800 (PST) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id PAA02818 for ; Sun, 26 Jan 1997 15:50:45 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA24199; Sun, 26 Jan 1997 18:50:13 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Sun, 26 Jan 1997 18:50 EST Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.8.3/8.7.3) with ESMTP id PAA01530 for ; Sun, 26 Jan 1997 15:29:05 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.8.3/8.6.9) id PAA00352 for freebsd-hackers@freefall.cdrom.com; Sun, 26 Jan 1997 15:33:00 -0500 (EST) Date: Sun, 26 Jan 1997 15:33:00 -0500 (EST) From: Thomas David Rivers Message-Id: <199701262033.PAA00352@lakes.water.net> To: ponds!freefall.cdrom.com!freebsd-hackers Subject: Problems bootin 3.0 SNAP-970124. Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Just a quick problem report. I found that I was unable to boot the SNAP without disabling ed1. I have a different setup- ed0 is in irq 9 (2), at port 0x300. So, the default probe doesn't find it; and the probe for ed1 will "find" it - but it's irq will be wrong. Apparently, this causes the ed1 probe to lock up.... - Dave Rivers - From owner-freebsd-hackers Sun Jan 26 16:50:52 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA07951 for hackers-outgoing; Sun, 26 Jan 1997 16:50:52 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA07946 for ; Sun, 26 Jan 1997 16:50:49 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id BAA14004 for freebsd-hackers@FreeBSD.ORG; Mon, 27 Jan 1997 01:50:47 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id BAA08259; Mon, 27 Jan 1997 01:27:04 +0100 (MET) Message-ID: Date: Mon, 27 Jan 1997 01:27:03 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG Subject: Re: fdisk headache References: <199701262114.OAA02297@phaeton.artisoft.com> X-Mailer: Mutt 0.55-PL10 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: <199701262114.OAA02297@phaeton.artisoft.com>; from Terry Lambert on Jan 26, 1997 14:14:45 -0700 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Terry Lambert wrote: > > Right now, there are three reasons to still call it ``dangerously > > dedicated'': > > > > . Since the MBR is identical to the BSD bootstrap, there's no room for > > things like `nextboot' after the MBR, and you can't replace the MBR > > by fancy things like a boot selector. > This is evil. You consider it evil -- some (many?) others don't. See the first sentence above: it's called ``dangerously'' dedicated mode. It's just for those who want and love this way. Those who prefer fighting against braindead 1024-cylinder or foobar megabyte limits are free to do so, and we even do them the favour to make these struggles (i.e., the DOS-compatible way) the default variant. -- 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 Jan 26 16:51:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA07975 for hackers-outgoing; Sun, 26 Jan 1997 16:51:01 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA07970 for ; Sun, 26 Jan 1997 16:50:59 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id BAA14006 for freebsd-hackers@freebsd.org; Mon, 27 Jan 1997 01:50:51 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id BAA08268; Mon, 27 Jan 1997 01:29:18 +0100 (MET) Message-ID: Date: Mon, 27 Jan 1997 01:29:17 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@freebsd.org Subject: Re: fdisk headache References: <199701262114.OAA02297@phaeton.artisoft.com> X-Mailer: Mutt 0.55-PL10 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: <199701262114.OAA02297@phaeton.artisoft.com>; from Terry Lambert on Jan 26, 1997 14:14:45 -0700 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Terry Lambert wrote: > > . The number of BIOS geometry constraints to care for reduces drastic- > > ally, so you can usually (*) ignore any geometry issues. > This is a bogus argument based on the assumption that we wouldn't put > an absolute sector address in the partition entry like we should so > a sector-offset based driver (BSD) could still use the partition > table entry without multiplying out C/H/S values. > > Note that we should put the entry there for our parttition: we should > not rely on a DOS tool to do it correctly for us. p.s.: You apparently don't understand what i'm writing about. There's no DOS tool ever involved in DD mode (and little red daemons will jump out of the disk if you ever come close to those disks with some DOS tool at all :-). -- 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 Jan 26 16:51:16 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA08012 for hackers-outgoing; Sun, 26 Jan 1997 16:51:16 -0800 (PST) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA08002 for ; Sun, 26 Jan 1997 16:51:13 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.8.4/8.6.9) id TAA20481; Sun, 26 Jan 1997 19:51:03 -0500 (EST) From: "John S. Dyson" Message-Id: <199701270051.TAA20481@dyson.iquest.net> Subject: Re: What is the default for async in /etc/fstab? To: dicen@hooked.net (RHS Linux User) Date: Sun, 26 Jan 1997 19:51:03 -0500 (EST) Cc: freebsd-hackers@freebsd.org In-Reply-To: <32EBC635.4F86F1D5@hooked.net> from "RHS Linux User" at Jan 26, 97 01:01:41 pm X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Have other people tested ufs vs. ext2? The only docs I could find where > for ext2. A comparison with FreeBSD 2.0 I think, although it could have > been older. This was for some old Linux 1.xx. > The performance that I have measured (sequential -- IOZONE) is that FreeBSD is faster in both read/write. However, our metadata performance is slower (filecreates/deletes.) With -async, our metadata is still slower, but not by orders of magnitude. FreeBSD's cache perf is much faster (by factors of 3-4.) Much of it is due to the default block size (8K vs. 1K.) But the fragment size of an 8K UFS filesystem is the *same* as a 1K ext2fs. Both are very fast though. John From owner-freebsd-hackers Sun Jan 26 16:54:23 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA08245 for hackers-outgoing; Sun, 26 Jan 1997 16:54:23 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA08228 for ; Sun, 26 Jan 1997 16:54:18 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id BAA14101; Mon, 27 Jan 1997 01:54:13 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id BAA08470; Mon, 27 Jan 1997 01:46:40 +0100 (MET) Message-ID: Date: Mon, 27 Jan 1997 01:46:40 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: dicen@hooked.net (RHS Linux User) Cc: freebsd-hackers@freebsd.org Subject: Re: What is the default for async in /etc/fstab? References: <32EBC635.4F86F1D5@hooked.net> X-Mailer: Mutt 0.55-PL10 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: <32EBC635.4F86F1D5@hooked.net>; from RHS Linux User on Jan 26, 1997 13:01:41 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As RHS Linux User wrote: ^^^^^^^^^^^^^^ What a weird name. :-/ > So what is the default for async in the 2.1 > /etc/fstab? j@uriah 1204% fgrep async /etc/fstab /dev/sd1g /usr/release ufs rw,async 0 4 /dev/sd1h /tmp ufs rw,async 0 3 -- 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 Jan 26 17:35:34 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA10163 for hackers-outgoing; Sun, 26 Jan 1997 17:35:34 -0800 (PST) Received: from llaic.univ-bpclermont.fr (llaic.univ-bpclermont.fr [192.54.142.163]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id RAA10146 for ; Sun, 26 Jan 1997 17:35:22 -0800 (PST) Message-Id: <199701270135.RAA10146@freefall.freebsd.org> Received: by llaic.univ-bpclermont.fr (1.38.193.4/16.2) id AA28403; Mon, 27 Jan 1997 02:34:52 +0100 From: Roger Espel Llima Subject: Re: hackers-digest V3 #36 To: hackers@freefall.freebsd.org Date: Mon, 27 Jan 1997 02:34:51 +0100 (MET) In-Reply-To: <199701262133.NAA25596@freefall.freebsd.org> from "owner-hackers-digest@freefall.freebsd.org" at Jan 26, 97 01:33:06 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I am curious about the up and comming GNU 2.0 libc. Since the BSD's have > their own libc will you be replacing yours with the GNU one? Not that I > like GNU to much (it seams to be becomming the Microsoft of the free > software world) but it would save a lot of developement time if you > didn't have to worry about your own library. Since this the GNU libc > will be used by Linux it would be hard to go wrong. FreeBSD would be > using the same libc are it's chief competitor. FreeBSD would then only > have the userland commands to deal with, since Linux of course has GNU > maintaining those. Not only the userland commands -- what about the kernel? I don't really think FreeBSD should change to a completely different libc; the GNU libc has some very nice features (reentrancy...) but a system's libc is usually very closely tied to the kernel, so it's good that the same team (or almost...) develops both, as is the case with FreeBSD. > I hate GNU binutils. Really? GNU binutils are gcc, gas, ld and other related commands (nm, objdump...). Are you sure you don't mean GNU fileutils? (ls, cp, rm and all those). I personally like the GNU fileutils and their BSD equivalents pretty much the same. > The next question is. Is the GNU libc 2.0 being ported? I saw that > someone was doing a port for BSDI2.0, is this not the same as FreeBSD? A port for BSDi could probably be adapted very easily for FreeBSD. Even if it isn't used as the default libc, a port is always a good thing... > I am very interested the GNU libc 2.0 for its posix threads and the fact > that it is rentrant (which it has to be of course for threads). What is > the status of kernel-threads in FreeBSD? I heard that you where getting > there. Current kernels already support rfork(), which should be the basis for kernel threads just like clone() is under Linux. > Since you have linux compatibility (except for clone() right?) would it > not be possible to just use the GNU libc 2.0 the way it is? Does it ever > have to be ported? I am sure Linux will always have presidence with GNU > anyway. This of course looks really bad since eventually freebsd will > have linux's kernel calls. But think about it. It is only externel, just > as the GNU libc is externel. Is FreeBSD BSD without the BSD libc? Good > question. That just means that when Linux starts using GNU libc 2.0 (aka Linux libc 6.0), FreeBSD's linux compatibility libc will be changed to a copy of it. That isn't the one BSD commands use though, obviously. Roger -- e-mail: roger.espel.llima@ens.fr WWW page & PGP key: http://www.eleves.ens.fr:8080/home/espel/index.html From owner-freebsd-hackers Sun Jan 26 17:36:45 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA10284 for hackers-outgoing; Sun, 26 Jan 1997 17:36:45 -0800 (PST) Received: from notes.bookcase.com (root@notes.bookcase.com [207.22.115.2]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id RAA10269 for ; Sun, 26 Jan 1997 17:36:42 -0800 (PST) Received: from localhost (chadf@localhost) by notes.bookcase.com (8.6.12/8.6.12) with SMTP id TAA02200 for ; Sun, 26 Jan 1997 19:38:39 -0500 Date: Sun, 26 Jan 1997 20:38:38 -0400 (EDT) From: "Chad M. Fraleigh" X-Sender: chadf@notes To: freebsd-hackers@freebsd.org Subject: Re: Local X packages In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 21 Jan 1997, John Fieber wrote: > compile with X11R6, I don't ever want to see another imake file! The first time I saw Imakefiles I hated them. I mean for something that is suppose to make things more portable and easier, it seems to be very good at making things harder. > However, if someone can figure out how to do it, I'm sure many > would be *very* grateful; it takes me far longer to upgrade X > than it does the rest of FreeBSD, and something always gets > spammed in the process. Since I refuse to install most X packages in the /usr/X11R6 directory (I think xview was my only expection I've made). While doing this is sometimes a pain because I have to modify several files, for the most part it's trival. Adding these lines at the begining of the Imakefile (or .tmpl if there is one) file after doing the patches and before doing the configure will probably fix about 80-90% of them: BINDIR = $(PREFIX)/bin MANPATH = $(PREFIX)/man LIBDIR = $(PREFIX)/lib/X11 INCROOT = $(PREFIX)/include TOP_INCLUDES = -I$(PREFIX)/include -I/usr/X11R6/include -I/usr/local/include EXTRA_LIBRARIES = -L/usr/local/lib I don't see why this couldn't easily be added to the patches for each package. Of course to fully integrate this would reguire that it's don't to all the applications first, and then to the libraries (like xpm, xview, etc..). That way you don't break anything that expects them in /usr/X11R6 when they're in /usr/local. Since I'm using $(PREFIX) instead of /usr/local I need to do my makes with PREFIX=/usr/local to override it using /usr/X11R6 when USE_IMAKE is set. To impliment it for the real thing a new setting would be needed (perhaps IMAKE_PREFIX with a default of /usr/X11R6) that could be set in their environment. -Chad From owner-freebsd-hackers Sun Jan 26 17:45:53 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA10779 for hackers-outgoing; Sun, 26 Jan 1997 17:45:53 -0800 (PST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA10773 for ; Sun, 26 Jan 1997 17:45:48 -0800 (PST) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.4/8.8.4) with SMTP id RAA19636 for ; Sun, 26 Jan 1997 17:42:26 -0800 (PST) Message-ID: <32EC0752.446B9B3D@whistle.com> Date: Sun, 26 Jan 1997 17:39:30 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: hackers@freebsd.org Subject: Why is this not a kernel memory leak? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk in route.c in rtrequest() in the RTM_DELETE: clause. the clause ends with: /* * If the caller wants it, then it can have it, but it's * up to it to free the rtentry as we won't be doing it. */ if (ret_nrt) *ret_nrt = rt; else if (rt->rt_refcnt <= 0) { rt->rt_refcnt++; /* make a 1->0 transition */ rtfree(rt); } break; now in the case when (ret_nrt) is NULL, and the reference count is 1, we never call rtfree(rt). If we did, the count would go to 0 and the block would be freed, which, since we are trying to delete it would seem a reasonable thing.. why leave the eference count as 1? doesn't this defeat the whole point of reference counts? This smells of "kludge" to me.. I'm going to go hunting and hopefully I can find out what's going on enough to clean up the ref counts enough so that they become useful again.. julian From owner-freebsd-hackers Sun Jan 26 18:19:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA11695 for hackers-outgoing; Sun, 26 Jan 1997 18:19:37 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id SAA11655 for ; Sun, 26 Jan 1997 18:18:13 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id SAA02602; Sun, 26 Jan 1997 18:57:06 -0700 From: Terry Lambert Message-Id: <199701270157.SAA02602@phaeton.artisoft.com> Subject: Re: cvs commit: src/sys/kern kern_lockf.c To: dg@root.com Date: Sun, 26 Jan 1997 18:57:05 -0700 (MST) Cc: terry@lambert.org, michaelh@cet.co.jp, bde@freefall.freebsd.org, Hackers@freebsd.org In-Reply-To: <199701262156.NAA08258@root.com> from "David Greenman" at Jan 26, 97 01:56:14 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >This is one of the things I am always on about. > > > > > >The call trace should be: > > > > fcntl(lock) <- check call syntax here > > lf_advlock(lock) <- check arg values here > > if( !VOP_ADVLOCK(lock)) > > lf_advlock(unlock) > > > >And the FS specific VOP_ADVLOCK should simply return 0 in all cases for > >most FS's. > > I disagree. The call trace should be: > > fcntl(lock) > VOP_ADVLOCK(lock) > lf_advlock(lock) > > This works properly with unusual filesystem stacking and is more flexible. ??? How so? Can you give me a stacking situation example where this would be true? The Heidemann paper specifically references null function bodies in a layering design, and the Rosental paper specifically talks about "collapsing" call graphs for null function elements in layers. I can think of several layers where you would want to affect the data operands, but not the hierarchy operands: an encryption layer, etc.. I can also think of several situations where you would want ti affect the hiearchy operands instead of the data operands: a quota layer, an ACL layer, a UMSDOS attribution layer, etc.. I can think of no situation in which I would want to hit the wire for a network FS call, when the given operation will fail remotely and will also fail locally (ie: VOP_ADVLOCK). All you succeed in doing is increasing latency, for no good reason. We can discuss the race conditions using this same call-down type of implementation in VOP_LOCK for directory traversal in an MSDOSFS, and the possibility for error when each FS implementor is required to reimplement upcalls (violating the abstract interface definition) in an identical way. These are obvious, and the related PR's are long-standing. Further, we can identify issues of NFS export resulting from the same style of coding in the mount calls being expected to process the exposed mount points, and of root vs. non-root FS mouninting being valid in some FS's and not in others because of the absurd per FS reimplementation requirements. If even we accepted you as being correct, we could implement the toplogically equivalent arrangement in a veto architecture by mounting an "advisory locking implementation layer" immediately above the terminal layer, and have it make the lf_advlock calls instead. Finally, this neglects fan-out architectures in which there may be a pseudo-vnode as a container object for more than one underlying vnode: it is necessary to lock the container object as well, since a user can legally have a "view" onto any FS "root" in any stack of FS layers (indeed, this *must* happen for most of the existing FS's NFS export implementations). > Only leaf filesystems should call lf_advlock(), so upper layers don't > matter. union_advlock should just be a pass-through. This assumes that a leaf element is rigidly defined (ie: it assumes that the bottom end of the stack will directly access media via a system specific mechanism for doing raw I/O). In the Rosenthal paper, a design is discussed where the bottom end is the same interface as the top end, even for nodes that structure storage. You can think of the bottom ends layer being a layer with a flat name space (not imposing directory hierarchy) and the namespace as being numeric (this is one of the problems with the current "FS responsible for namei buffer deallocation" scheme -- it implies a buffer as opposed to some otherwise opaque layer specific statite). In reality, the bottom end system interface wants to be system specific, but the design of a VFS layer itself (even one like UFS) doesn't want to be system specific. Ie: the FFS module should operate the same way without regard to whether it's running in a Linux environment, or a BSD environment, or a Windows environment: it shouldn't matter. We can see the beginnings of this by looking at the existing FFS/UFS layering split, where the imposition of a directory hierarchy is done in a seperate stacking layer (UFS) from the imposition of a flat numeric name space layer (FFS inodes). It is eminently logical to extend this to the idea that a flat numeric namespace of groups of blocks (the inode layer) be implemented on a flat numeric namespace of blocks (that is, device access via VFS interface). We can either decide that the current UFS/FFS interface is wrong, or we can decide that the current FFS/VM interface is wrong. Since the former is more flexible, it's an easy choice to make. This is also why it's a mistake to make FFS/UFS specific code for the "soft updates" implementation: it seperates the UFS-with-soft-updates used by FFS from the UFS-without-soft-updates used by LFS, and is a move *away* from code reuse. 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 Sun Jan 26 18:58:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA12777 for hackers-outgoing; Sun, 26 Jan 1997 18:58:32 -0800 (PST) Received: from bugs.us.dell.com (bugs.us.dell.com [143.166.169.147]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id SAA12766 for ; Sun, 26 Jan 1997 18:57:53 -0800 (PST) Received: from ant.us.dell.com (ant.us.dell.com [198.64.66.34]) by bugs.us.dell.com (8.6.12/8.6.12) with SMTP id UAA20141; Sun, 26 Jan 1997 20:56:21 -0600 Message-Id: <3.0.1.32.19970126205619.00684ee4@bugs.us.dell.com> X-Sender: tony@bugs.us.dell.com X-Mailer: Windows Eudora Light Version 3.0.1 beta 7 (32) Date: Sun, 26 Jan 1997 20:56:19 -0600 To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch), graichen@rzpd.de (Thomas Graichen) From: Tony Overfield Subject: Re: magic of western digital disks ... ? Cc: tech@OpenBSD.org, hackers@FreeBSD.org In-Reply-To: References: <199701191244.NAA00878@prospero.at.home> <199701191244.NAA00878@prospero.at.home> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk J Wunsch wrote: >As Thomas Graichen wrote: >> ...on another machine i get errors like "hard error reading block >> ..." - but the disk is completely ok and works fine with FreeBSD - >> it also works fine if it is entered into the bios (... btw. after >> getting the "hard error ..." messages i was short before throwing >> the disk away - until i discovered that setting it in the bios >> helped :-) > >This sounds like an initialization problem. If you register it with >the BIOS, the BIOS does some initialization on the disk. Specifically, many IDE drives will not accept media (read/write) commands until a geometry has been specified using the INITIALIZE DEVICE PARAMETERS (0x91) command. A BIOS will always do this for drives that it recognizes. The FreeBSD driver issues this command, but perhaps the OpenBSD driver doesn't (I haven't looked at it). From owner-freebsd-hackers Sun Jan 26 19:48:19 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA14704 for hackers-outgoing; Sun, 26 Jan 1997 19:48:19 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id TAA14696 for ; Sun, 26 Jan 1997 19:48:17 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id UAA04555; Sun, 26 Jan 1997 20:31:08 -0700 From: Terry Lambert Message-Id: <199701270331.UAA04555@phaeton.artisoft.com> Subject: Re: CMD640b ide controller bug workarounds? To: garman@phs.k12.ar.us Date: Sun, 26 Jan 1997 20:31:08 -0700 (MST) Cc: terry@lambert.org, freebsd-hackers@freebsd.org In-Reply-To: from "Jason Garman" at Jan 26, 97 05:16:25 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > And as for L*nux, looking through AltaVista's search results for the query > you gave me, it seems that L*nux _does_ automatically and > non-destructively detect and work around the CMD 640b bugs. (no > hda=serialize needed after all, apparently) > > Detecting a VLB board using this chip would be harder (is it even > possible)? Well, for PCI, yes. For VLB, there's no slot identification data (which is why, like ISA, it sucks). If the Linux code is working around the hardware problem, it probably has code to detect it, which you could examine to determine their algorithm. 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 Sun Jan 26 20:37:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA16604 for hackers-outgoing; Sun, 26 Jan 1997 20:37:59 -0800 (PST) Received: from threadway.teeny.org (root@threadway.teeny.org [204.245.200.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA16597 for ; Sun, 26 Jan 1997 20:37:55 -0800 (PST) Received: from localhost (downsj@localhost.teeny.org [127.0.0.1]) by threadway.teeny.org (8.8.5/8.6.12) with ESMTP id UAA00246; Sun, 26 Jan 1997 20:36:21 -0800 (PST) Message-Id: <199701270436.UAA00246@threadway.teeny.org> To: Tony Overfield cc: Joerg Wunsch , Thomas Graichen , tech@openbsd.org, hackers@freebsd.org Subject: Re: magic of western digital disks ... ? In-reply-to: Your message of "Sun, 26 Jan 1997 20:56:19 CST." <3.0.1.32.19970126205619.00684ee4@bugs.us.dell.com> Date: Sun, 26 Jan 1997 20:36:19 -0800 From: Jason Downs Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <3.0.1.32.19970126205619.00684ee4@bugs.us.dell.com>, Tony Overfield writes: >J Wunsch wrote: >>As Thomas Graichen wrote: >>> ...on another machine i get errors like "hard error reading block >>> ..." - but the disk is completely ok and works fine with FreeBSD - >>> it also works fine if it is entered into the bios (... btw. after >>> getting the "hard error ..." messages i was short before throwing >>> the disk away - until i discovered that setting it in the bios >>> helped :-) >> >>This sounds like an initialization problem. If you register it with >>the BIOS, the BIOS does some initialization on the disk. > >Specifically, many IDE drives will not accept media (read/write) >commands until a geometry has been specified using the INITIALIZE >DEVICE PARAMETERS (0x91) command. A BIOS will always do this for >drives that it recognizes. The FreeBSD driver issues this command, >but perhaps the OpenBSD driver doesn't (I haven't looked at it). Yes, it does. It wouldn't exactly conform to specs if it didn't. The OpenBSD driver runs disks on things like Amigas, which in way have any sort of BIOS sending initialization commands. -- Jason Downs (503) 256-8535 -/- (503) 952-3749 downsj@teeny.org --> teeny.org: Free Software for a Free Internet <-- http://www.teeny.org/ Little. Yellow. Secure. http://www.openbsd.org/ From owner-freebsd-hackers Sun Jan 26 21:50:38 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA18301 for hackers-outgoing; Sun, 26 Jan 1997 21:50:38 -0800 (PST) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA18296 for ; Sun, 26 Jan 1997 21:50:35 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.3/CET-v2.1) with SMTP id FAA27728; Mon, 27 Jan 1997 05:49:42 GMT Date: Mon, 27 Jan 1997 14:49:41 +0900 (JST) From: Michael Hancock To: proff@suburbia.net cc: hackers@freebsd.org Subject: Re: SLAB stuff, and applications to current net code (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 26 Jan 1997, Michael Hancock wrote: > On Sun, 26 Jan 1997 proff@suburbia.net wrote: > > > Can anyone inform me what a SLAB allocator is, and if so, would freebsd > > benefit from one? > > > > It's a chunk of memory that you put multiple kernel objects of the same > type into. We have a modified mach zone allocator. They're both type > stable memory allocators. Oops, as David mentioned, I goofed. The major objects are mach zone and when freed can be allocated as another type later on. The way vnodes are allocated and deallocated is almost TSM, if it weren't for the special allocation case when more vnodes are needed than originally allocated at boot. I'll have to look into how Solaris' SLAB deallocates memory, it's probably not TSM either. Regards, Mike Hancock From owner-freebsd-hackers Sun Jan 26 21:56:27 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA18467 for hackers-outgoing; Sun, 26 Jan 1997 21:56:27 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA18462 for ; Sun, 26 Jan 1997 21:56:22 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id QAA25341; Mon, 27 Jan 1997 16:53:51 +1100 Date: Mon, 27 Jan 1997 16:53:51 +1100 From: Bruce Evans Message-Id: <199701270553.QAA25341@godzilla.zeta.org.au> To: dicen@hooked.net, toor@dyson.iquest.net Subject: Re: What is the default for async in /etc/fstab? Cc: freebsd-hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> Have other people tested ufs vs. ext2? The only docs I could find where >> ... >The performance that I have measured (sequential -- IOZONE) is that >FreeBSD is faster in both read/write. However, our metadata performance >is slower (filecreates/deletes.) With -async, our metadata is still >slower, but not by orders of magnitude. FreeBSD's cache perf is much >faster (by factors of 3-4.) Much of it is due to the default block >size (8K vs. 1K.) But the fragment size of an 8K UFS filesystem is >the *same* as a 1K ext2fs. In my tests, ext2fs is fastest for huge sequential i/o's when the block sizes are closer (8K vs 4K), but there was only a small difference (less than 10%) between the best and worst cases (best: ext2fs under FreeBSD, next: ext2fs under Linux, worst: ext2fs under Linux) except for rewrite, which was 66% faster under Linux than under FreeBSD. Cache performance also catches up (46MB/sec for FreeBSD-current-last-November, 41MB/sec for Linux-2.0.20). A 4K fragment size wastes space probably wastes time in most cases. Bruce From owner-freebsd-hackers Sun Jan 26 23:56:29 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA24793 for hackers-outgoing; Sun, 26 Jan 1997 23:56:29 -0800 (PST) Received: from weenix.guru.org (kmitch@unix.guru.org [198.82.200.65]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA24788 for ; Sun, 26 Jan 1997 23:56:25 -0800 (PST) Received: (from kmitch@localhost) by weenix.guru.org (8.8.4/8.8.4) id CAA03562 for hackers@freebsd.org; Mon, 27 Jan 1997 02:56:24 -0500 (EST) From: Keith Mitchell Message-Id: <199701270756.CAA03562@weenix.guru.org> Subject: DUMP problem To: hackers@freebsd.org Date: Mon, 27 Jan 1997 02:56:23 -0500 (EST) X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Every so often, I get dump errors from amanda: | DUMP: Date of this level 1 dump: Mon Jan 27 00:32:08 1997 | DUMP: Date of last level 0 dump: Sun Jan 26 16:15:36 1997 | DUMP: Dumping /dev/rsd2g (/var) to standard output | DUMP: mapping (Pass I) [regular files] | DUMP: mapping (Pass II) [directories] | DUMP: estimated 11763 tape blocks. | DUMP: too many slaves, 1 (recompile smaller): Resource temporarily unavailab le | DUMP: The ENTIRE dump is aborted. Does anyone know how to fix this too many slaves error condition that keeps popping up?? From owner-freebsd-hackers Mon Jan 27 00:08:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA25173 for hackers-outgoing; Mon, 27 Jan 1997 00:08:32 -0800 (PST) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA25096; Mon, 27 Jan 1997 00:05:14 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.3/CET-v2.1) with SMTP id IAA28518; Mon, 27 Jan 1997 08:05:07 GMT Date: Mon, 27 Jan 1997 17:05:07 +0900 (JST) From: Michael Hancock Reply-To: Michael Hancock To: David Greenman cc: FreeBSD Hackers , freebsd-smp@FreeBSD.ORG Subject: Re: SLAB stuff, and applications to current net code (fwd) In-Reply-To: <199701262225.OAA08492@root.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk [Added cc to smp] On Sun, 26 Jan 1997, David Greenman wrote: > >Vahalia cites a paper: > > "Efficient Kernel Memory Allocation on Shared Memory > > Multiprocessors" > > McKenney, P.E. and Slingwine, J. > > Proceedings of USENIX, Winter, 1993 > > > >Which shows the sequent code to be faster than the McKusick-Karels > >algorithm by a factor of three to five on a UP, and a factor of > >one hundred to one thousand on a 25 processor system. > > I haven't read that paper, but I suspect that the numbers are wrong due > to spl* having high overhead back then. Since Bruce's "fast interrupt" code, > spl* is almost free, and this changes things greatly. The situation might > change slightly in MP systems, but the total time inside of malloc is so small > that I really doubt that synchronization/serialization will ever be a > significant problem. > If subsystems used TSM it would be faster still at the expense of being even less space efficient. Objects would never be free'd in the malloc/free sense, but put on a typed free list. The operations of moving from list to list is even cheaper than malloc/free and synchronization/serialization is easier, even more so in MP environments. In this case, the performance of malloc/free would be largely irrelevant. However, the underlying allocator's ability to distribute hot objects across the processor cache might become more important. TSM probably wouldn't go over with those that want to run FBSD on systems with 8MB of RAM. It'd probably be the way to go for SMP systems though. BTW, SLAB isn't type stable either. There's an operation kmem_cache_reap() that returns a SLAB whose objects are all free to the page level allocator. TSM on top of a SLAB allocator might be interesting. It would negate the extra management overhead of the SLABs and be able to take advantage of processor cache coloring at the same time. Regards, Mike Hancock From owner-freebsd-hackers Mon Jan 27 00:09:26 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA25238 for hackers-outgoing; Mon, 27 Jan 1997 00:09:26 -0800 (PST) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA25233 for ; Mon, 27 Jan 1997 00:09:22 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.3/CET-v2.1) with SMTP id IAA28611; Mon, 27 Jan 1997 08:08:59 GMT Date: Mon, 27 Jan 1997 17:08:59 +0900 (JST) From: Michael Hancock To: Bruce Evans cc: dicen@hooked.net, freebsd-hackers@freebsd.org Subject: Re: What is the default for async in /etc/fstab? In-Reply-To: <199701270553.QAA25341@godzilla.zeta.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 27 Jan 1997, Bruce Evans wrote: > In my tests, ext2fs is fastest for huge sequential i/o's when the block > sizes are closer (8K vs 4K), but there was only a small difference (less > than 10%) between the best and worst cases (best: ext2fs under FreeBSD, > next: ext2fs under Linux, worst: ext2fs under Linux) except for rewrite, next: and worst: are the same here. ;-) From owner-freebsd-hackers Mon Jan 27 00:52:31 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA26456 for hackers-outgoing; Mon, 27 Jan 1997 00:52:31 -0800 (PST) Received: from pegasus.my.domain (sole-11.ppp.hooked.net [206.80.9.203]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA26451 for ; Mon, 27 Jan 1997 00:52:28 -0800 (PST) Received: from pegasus.my.domain (localhost [127.0.0.1]) by pegasus.my.domain (8.7.6/8.7.3) with SMTP id AAA00605 for ; Mon, 27 Jan 1997 00:52:53 -0800 Message-ID: <32EC6CE5.64E60DE1@hooked.net> Date: Mon, 27 Jan 1997 00:52:53 -0800 From: dicen X-Mailer: Mozilla 3.01Gold (X11; I; Linux 2.0.27 i686) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Performance of ufs vs. ext2. References: <199701270553.QAA25341@godzilla.zeta.org.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Bruce Evans wrote: > > >> Have other people tested ufs vs. ext2? The only docs I could find where > >> ... > >The performance that I have measured (sequential -- IOZONE) is that > >FreeBSD is faster in both read/write. However, our metadata performance > >is slower (filecreates/deletes.) With -async, our metadata is still > >slower, but not by orders of magnitude. FreeBSD's cache perf is much > >faster (by factors of 3-4.) Much of it is due to the default block > >size (8K vs. 1K.) But the fragment size of an 8K UFS filesystem is > >the *same* as a 1K ext2fs. > > In my tests, ext2fs is fastest for huge sequential i/o's when the block > sizes are closer (8K vs 4K), but there was only a small difference (less > than 10%) between the best and worst cases (best: ext2fs under FreeBSD, > next: ext2fs under Linux, worst: ext2fs under Linux) except for rewrite, > which was 66% faster under Linux than under FreeBSD. Cache performance > also catches up (46MB/sec for FreeBSD-current-last-November, 41MB/sec > for Linux-2.0.20). A 4K fragment size wastes space probably wastes time > in most cases. > > Bruce Okay cool some real numbers. When you speak of "rewrite" are you talking about the creation and deletion of files (Metadata)? There seams to be a significant speed difference between the creation and deletion of files on linux ext2 vs. Freebsd ufs. Linux ext2 is way faster. I suppose I could just run ext2 under FreeBSD right? It sure would make a "make world" faster. You know if someone were to setup a news server it would seam to make more sence to use ext2. From owner-freebsd-hackers Mon Jan 27 00:52:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA26494 for hackers-outgoing; Mon, 27 Jan 1997 00:52:47 -0800 (PST) Received: from mailserv.tversu.ac.ru (root@mailserv.tversu.ac.ru [193.233.128.3]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id AAA26476 for ; Mon, 27 Jan 1997 00:52:38 -0800 (PST) Received: from localhost (vadim@localhost) by mailserv.tversu.ac.ru (8.6.12/8.6.12) with SMTP id LAA15371 for ; Mon, 27 Jan 1997 11:53:57 +0300 Date: Mon, 27 Jan 1997 11:53:54 +0300 (MSK) From: Vadim Kolontsov To: hackers@freebsd.org Subject: in_rtqtimo Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello, what does this kernel message mean? /kernel: in_rtqtimo: adjusted rtq_reallyold to 2400 Best regards, Vadim. -------------------------------------------------------------------------- Vadim Kolontsov SysAdm/Programmer Tver Regional Center of New Information Technologies Networks Lab From owner-freebsd-hackers Mon Jan 27 01:10:03 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA27118 for hackers-outgoing; Mon, 27 Jan 1997 01:10:03 -0800 (PST) Received: from clipper.cs.kiev.ua (root@cs-demon.ua.net [193.124.48.251]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id BAA27085 for ; Mon, 27 Jan 1997 01:09:48 -0800 (PST) Received: from dog.farm.org by clipper.cs.kiev.ua with uucp id m0von18-000t3EC; Mon, 27 Jan 97 11:06 WET Received: (from dk@localhost) by dog.farm.org (8.7.5/dk#3) id AAA00505; Mon, 27 Jan 1997 00:57:34 -0800 (PST) Date: Mon, 27 Jan 1997 00:57:34 -0800 (PST) From: Dmitry Kohmanyuk Message-Id: <199701270857.AAA00505@dog.farm.org> To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Cc: freebsd-hackers@freebsd.org Subject: Re: help for a floppy boot sector Newsgroups: cs-monolit.gated.lists.freebsd.hackers Organization: FARM Computing Association Reply-To: dk+@ua.net X-Newsreader: TIN [version 1.2 PL2] Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199701261035.LAA27794@labinfo.iet.unipi.it> you wrote: > I am looking for some floppy boot code which allows you to build a > bootable floppy which can start a .COM file without the need for MSDOS. I have written just this thing for the same reason - a standalone .COM-file loader which is smart enough to read MSDOS FAT from a floppy and load a single file. It fits into 512 bytes. It's available (with source code) from: ftp://ftp.cs.kiev.ua/csrt/unix/dkbooter-1.0.zip [ I beleive I have announced this some time ago on -hackers. ] The source code uses DOS TASM, but rewrite to GAS should be easy. (ask me if you need it). > Ideally I would do something like > cat bootcode nb8390.com | dd of=/dev/fd0a > to produce a bootable floppy. oh, with my code, you have to do: ; mformat a: ; dd if=dkboot of=/dev/fd0a bs=1b ; mcopy nb8390.com a:loader.com p.s. because that site can be slow, I have uploaded a copy into ftp://ftp.freebsd.org/pub/FreeBSD/incoming/dkbooter-1.0.zip -- "I want to die peacefully in my sleep like my grandfather. Not screaming in terror like his passengers." From owner-freebsd-hackers Mon Jan 27 01:58:15 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA28632 for hackers-outgoing; Mon, 27 Jan 1997 01:58:15 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA28627 for ; Mon, 27 Jan 1997 01:58:12 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id UAA32722; Mon, 27 Jan 1997 20:52:47 +1100 Date: Mon, 27 Jan 1997 20:52:47 +1100 From: Bruce Evans Message-Id: <199701270952.UAA32722@godzilla.zeta.org.au> To: bde@zeta.org.au, michaelh@cet.co.jp Subject: Re: What is the default for async in /etc/fstab? Cc: dicen@hooked.net, freebsd-hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> In my tests, ext2fs is fastest for huge sequential i/o's when the block >> sizes are closer (8K vs 4K), but there was only a small difference (less >> than 10%) between the best and worst cases (best: ext2fs under FreeBSD, >> next: ext2fs under Linux, worst: ext2fs under Linux) except for rewrite, > >next: and worst: are the same here. ;-) Oops. worst: ufs under FreeBSD. Here is the data. Environment: - ASUS P5/133, 32MB, 2.1GB Quantum FireballTM IDE drive with identical configurations under FreeBSD and Linux (16 sectors/interrupt, 32-bit i/o, PIO mode 4). - all on the same empty partition (except mke2fs puts lost+found there) at offset about 320MB and size about 1024MB. - I thought I used the same block size of 4K in all cases, but some of my notes say that I used 8K for ufs. The ufs fragment size was certainly not 4K as it should have been to match the ext2fs fragment size. bonnie.ext2fs-under-freebsd-current (fs block size 4K) ----------------------------------- -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 512 3786 71.8 5220 18.7 1556 9.1 3904 70.7 5204 14.5 47.6 2.8 bonnie.ext2fs-under-linux-2.0.20 (fs block size 4K) -------------------------------- -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 512 3836 96.2 4517 25.0 2500 35.0 3488 91.2 5156 19.8 44.8 2.0 bonnie.ufs-under-freebsd-current (fs block/frag size 8K/1K or 4K/?) -------------------------------- -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 512 3543 70.9 4627 19.1 1459 8.1 3891 70.5 4875 13.4 45.0 2.6 Bruce From owner-freebsd-hackers Mon Jan 27 02:04:02 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA28943 for hackers-outgoing; Mon, 27 Jan 1997 02:04:02 -0800 (PST) Received: from profane.iq.org (profane.iq.org [203.4.184.217]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA28899 for ; Mon, 27 Jan 1997 02:03:06 -0800 (PST) Received: (from proff@localhost) by profane.iq.org (8.8.4/8.8.2) id VAA23833 for hackers@freebsd.org; Mon, 27 Jan 1997 21:03:19 +1100 (EST) From: Julian Assange Message-Id: <199701271003.VAA23833@profane.iq.org> Subject: gomoku To: hackers@freebsd.org Date: Mon, 27 Jan 1997 21:03:19 +1100 (EST) 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Is there any reason that gomoku from Lite2 is missing from /usr/src/games? Gomoku is a "connect 4" type game. -- Cheers, Julian. From owner-freebsd-hackers Mon Jan 27 02:11:14 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA29122 for hackers-outgoing; Mon, 27 Jan 1997 02:11:14 -0800 (PST) Received: from snowcrash.cymru.net (root@snowcrash.cymru.net [163.164.160.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA29117 for ; Mon, 27 Jan 1997 02:11:10 -0800 (PST) Received: (from alan@localhost) by snowcrash.cymru.net (8.7.1/8.7.1) id KAA26279; Mon, 27 Jan 1997 10:08:17 GMT From: Alan Cox Message-Id: <199701271008.KAA26279@snowcrash.cymru.net> Subject: Re: SLAB stuff, and applications to current net code (fwd) To: julian@whistle.com (Julian Elischer) Date: Mon, 27 Jan 1997 10:08:09 +0000 (GMT) Cc: proff@suburbia.net, dg@root.com, hackers@freebsd.org, alan.cox@linux.org In-Reply-To: <32EBDC19.794BDF32@whistle.com> from "Julian Elischer" at Jan 26, 97 02:35:05 pm Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > He told me that originally he looked at using a BSD style allocator, > but that small allocations of mbufs etc all hit the same cache > lines as they were always on powers of two. (obviously) > especially when working on the headers of large packets. > > he saw a noticable problem with cache overwrites. > > I didn't get it all but probably he could tell us more.. > I've CC'd him. He seems very knowledgable about BSD internals > and not at all the screaming fanatic that we sometimes see in the linux > camp so I really enjoyed the conversation.. I'm flattered 8) The problem occuring was one that seems to occur with a lot of allocators. Linux like most other OS's tends to do things of the form object=some_malloc(size_of_object) With the older Linux allocator and all the buddy based allocators object has the property that the lower bits are 0, and the next few bits are 0 with a passably higher probability. In other words the start of the object tends to be at something0000000000 and the 0000000000 tends to include the bits used to select an L1 cache line. Its pretty trivial to inspect the Linux and BSD code to see that almost all objects are of the form struct { most used field regularly used field buf[blah]; /* rarely accessed */ } [memory allocator slop - never used] In the end I pulled some messy tricks in Linux 2.0 to keep the cache a bit saner by building sk_buff's (mbufs to the BSD world) with the buffer structure at the tail of the object .. ie ptr=malloc(size+struct+15) struct=ptr-sizeof(struct) round_down(ptr,16); struct->data=ptr That combined with the fact most linux sk_buff's have the major headers on the 2nd and 3rd cache line into the buffer gave me a performance improvement I could benchmark. The right answer in current literature is undoubtedly a SLAB allocator and that is where we are going at the moment. Alan From owner-freebsd-hackers Mon Jan 27 02:12:38 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA29201 for hackers-outgoing; Mon, 27 Jan 1997 02:12:38 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA29186 for ; Mon, 27 Jan 1997 02:12:32 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id VAA00439; Mon, 27 Jan 1997 21:08:56 +1100 Date: Mon, 27 Jan 1997 21:08:56 +1100 From: Bruce Evans Message-Id: <199701271008.VAA00439@godzilla.zeta.org.au> To: dicen@hooked.net, freebsd-hackers@FreeBSD.ORG Subject: Re: Performance of ufs vs. ext2. Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Okay cool some real numbers. When you speak of "rewrite" are you talking >about the creation and deletion of files (Metadata)? There seams to be a It's whatever the bonnie benchmark does. Something like rewriting the data in an existing file using a too-small blocksize. The small blocksize forces blocks to be written to be pre-read unless the OS is very smart. It is normally at least twice as slow as an append with a too-small blocksize because it involves twice as much i/o. Under FreeBSD it is about 3 times as slow. Under Linux it is only twice as slow. >significant speed difference between the creation and deletion of files >on linux ext2 vs. Freebsd ufs. Linux ext2 is way faster. I suppose I This is caused mainly by a different default for synchronization of writes: FreeBSD: mount -o -noasync: usually safer but always slower. Linux: mount -o -async: usually less safe but always faster. >could just run ext2 under FreeBSD right? It sure would make a "make >world" faster. You know if someone were to setup a news server it would >seam to make more sence to use ext2. No, the file system has very little to do with the speed of create/delete. FreeBSD uses the same mount default for ext2fs and ufs. `mount -o async' speeds them up almost equally so that they are both slightly slower for create/delete than Linux. They are slower because Linux has better support for its default setting. Bruce From owner-freebsd-hackers Mon Jan 27 02:22:48 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA29510 for hackers-outgoing; Mon, 27 Jan 1997 02:22:48 -0800 (PST) Received: from zwei.siemens.at (zwei.siemens.at [193.81.246.12]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA29505 for ; Mon, 27 Jan 1997 02:22:40 -0800 (PST) Received: from sol1.gud.siemens.co.at ([10.1.143.100]) by zwei.siemens.at (8.7.5/8.7.3) with SMTP id LAA15874 for ; Mon, 27 Jan 1997 11:23:18 +0100 (MET) Received: from ws2301.gud.siemens.co.at by sol1.gud.siemens.co.at with smtp (Smail3.1.28.1 #7 for ) id m0vooBs-000211C; Mon, 27 Jan 97 11:21 MET Received: by ws2301.gud.siemens.co.at (1.37.109.16/1.37) id AA267670327; Mon, 27 Jan 1997 11:18:47 +0100 From: "Hr.Ladavac" Message-Id: <199701271018.AA267670327@ws2301.gud.siemens.co.at> Subject: Re: What is the default for async in /etc/fstab? To: dicen@hooked.net (RHS Linux User) Date: Mon, 27 Jan 1997 11:18:46 +0100 (MEZ) Cc: freebsd-hackers@freebsd.org In-Reply-To: <32EBC635.4F86F1D5@hooked.net> from "RHS Linux User" at Jan 26, 97 01:01:41 pm 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk E-mail message from RHS Linux User contained: > I am having trouble determining the disk IO performace of FreeBSD vs. > Linux. I recently ran a test on FreeBSD and the write performance wasn't > so great. However, I didn't think to see if async was set in the > /etc/fstab file. I installed from a 2.1 CDROM initially and then cvsuped > different versions. So what is the default for async in the 2.1 > /etc/fstab? Default is sync metadata, async file contents. If you set any value to your filesystem, and if it cannot be easily reproduced (i.e. you're not doing an initial installation or zero level restore,) I would advise very strongly against async metadata. Losing half a filesystem because fsck had to use heuristics to repair it and found a wrong consistent FS state is not my kind of fun. > > Have other people tested ufs vs. ext2? The only docs I could find where > for ext2. A comparison with FreeBSD 2.0 I think, although it could have > been older. This was for some old Linux 1.xx. Dunno. But you could try :) You seem to have both OS's. /Marino > > Hardware. Adapt. 2940UW, and Quantum 4.3gig Atlas, 7200rpm. 8.5ms. > > Thanks. > From owner-freebsd-hackers Mon Jan 27 04:45:48 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA04828 for hackers-outgoing; Mon, 27 Jan 1997 04:45:48 -0800 (PST) Received: from zwei.siemens.at (zwei.siemens.at [193.81.246.12]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA04820 for ; Mon, 27 Jan 1997 04:45:41 -0800 (PST) Received: from sol1.gud.siemens.co.at ([10.1.143.100]) by zwei.siemens.at (8.7.5/8.7.3) with SMTP id NAA19098 for ; Mon, 27 Jan 1997 13:46:24 +0100 (MET) Received: from ws2301.gud.siemens.co.at by sol1.gud.siemens.co.at with smtp (Smail3.1.28.1 #7 for ) id m0voqQL-000213C; Mon, 27 Jan 97 13:44 MET Received: by ws2301.gud.siemens.co.at (1.37.109.16/1.37) id AA114238913; Mon, 27 Jan 1997 13:41:53 +0100 From: "Hr.Ladavac" Message-Id: <199701271241.AA114238913@ws2301.gud.siemens.co.at> Subject: Re: Performance of ufs vs. ext2. To: dicen@hooked.net (dicen) Date: Mon, 27 Jan 1997 13:41:53 +0100 (MEZ) Cc: freebsd-hackers@freebsd.org In-Reply-To: <32EC6CE5.64E60DE1@hooked.net> from "dicen" at Jan 27, 97 00:52:53 am 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk E-mail message from dicen contained: > Bruce Evans wrote: > > > > >> Have other people tested ufs vs. ext2? The only docs I could find where > > >> ... > > >The performance that I have measured (sequential -- IOZONE) is that > > >FreeBSD is faster in both read/write. However, our metadata performance > > >is slower (filecreates/deletes.) With -async, our metadata is still > > >slower, but not by orders of magnitude. FreeBSD's cache perf is much > > >faster (by factors of 3-4.) Much of it is due to the default block > > >size (8K vs. 1K.) But the fragment size of an 8K UFS filesystem is > > >the *same* as a 1K ext2fs. > > > > In my tests, ext2fs is fastest for huge sequential i/o's when the block > > sizes are closer (8K vs 4K), but there was only a small difference (less > > than 10%) between the best and worst cases (best: ext2fs under FreeBSD, > > next: ext2fs under Linux, worst: ext2fs under Linux) except for rewrite, > > which was 66% faster under Linux than under FreeBSD. Cache performance > > also catches up (46MB/sec for FreeBSD-current-last-November, 41MB/sec > > for Linux-2.0.20). A 4K fragment size wastes space probably wastes time > > in most cases. > > > > Bruce > > Okay cool some real numbers. When you speak of "rewrite" are you talking > about the creation and deletion of files (Metadata)? There seams to be a > significant speed difference between the creation and deletion of files > on linux ext2 vs. Freebsd ufs. Linux ext2 is way faster. I suppose I > could just run ext2 under FreeBSD right? It sure would make a "make > world" faster. You know if someone were to setup a news server it would > seam to make more sence to use ext2. Doubt it. You could run FFS async (the way the Linuxers run ext2fs) and pray to Deity-of-your-choice not to lose the filesystem (the way the Linuxers who run ex2fs should do but do not, presumably out of ignorance). For a news server, you can run FFS noatime, and have a big win without endangering your data. Joe Greco made a series of posts on the matter. /Marino > From owner-freebsd-hackers Mon Jan 27 05:21:18 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA05875 for hackers-outgoing; Mon, 27 Jan 1997 05:21:18 -0800 (PST) Received: from terra.Sarnoff.COM (terra.sarnoff.com [130.33.11.203]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id FAA05870 for ; Mon, 27 Jan 1997 05:21:15 -0800 (PST) Received: (from rminnich@localhost) by terra.Sarnoff.COM (8.6.12/8.6.12) id IAA19691; Mon, 27 Jan 1997 08:20:14 -0500 Date: Mon, 27 Jan 1997 08:20:13 -0500 (EST) From: "Ron G. Minnich" X-Sender: rminnich@terra To: RHS Linux User cc: freebsd-hackers@FreeBSD.org Subject: Re: What to do about the 2.0 GNU libc? In-Reply-To: <32EBC435.63297F3E@hooked.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk I just wanted to mention that: rfork as it now exists on openbsd/freebsd does as much as clone does on my latest linux 2.x. Actually judging by the comments in my kernel source it is possible that rfork on freebsd is somewhat more useful than clone on linux. ron Ron Minnich |"Failure is not an option" -- Gene Kranz rminnich@sarnoff.com | -- except, of course, on Microsoft products (609)-734-3120 | ftp://ftp.sarnoff.com/pub/mnfs/www/docs/cluster.html From owner-freebsd-hackers Mon Jan 27 07:20:40 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA09733 for hackers-outgoing; Mon, 27 Jan 1997 07:20:40 -0800 (PST) Received: from itsdsv1.enc.edu (itsdsv1.enc.edu [207.95.42.241]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA09728 for ; Mon, 27 Jan 1997 07:20:37 -0800 (PST) Received: from dingo.its.enc.edu (dingo.its.enc.edu [207.95.222.250]) by itsdsv1.enc.edu (8.7.5/8.7.3) with SMTP id KAA01836; Mon, 27 Jan 1997 10:17:52 -0500 (EST) Date: Mon, 27 Jan 1997 10:26:23 -0500 (EST) From: Charles Owens X-Sender: owensc@dingo.its.enc.edu Reply-To: Charles Owens To: Julian Elischer cc: hackers list FreeBSD Subject: Re: [Fwd: LDAP object schema for NIS/UNIX/KERB ] Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > http://www.xedoc.com.au/~lukeh/ldap/schema.html > Julian, What's your interest in this area? I make heavy production use of FreeBSD NIS but am planning a move to LDAP. This is my next big project... I expect to spend a few months on it. One of the main goals is to provide generic directory services that Web applications can leverage, but I was planning on some sort of gateway to NIS to keep the user passwords in sync. From the URL above it seems that this NIS intergration is being seriously considered. I hope I can make use of their work. I read Bill Paul's reply about not having any time. If I make any progress that seems integratable into FreeBSD I will of course submit it to someone for consideration. Do you have any plans to work in this area? It would be nice to have some folks to bounce my stuff off of. Do you know what has been done by FreeBSD folks with LDAP in general? (other than the port of the umich package). Are there any official plans to make use of it in any real way? thanks, --- ------------------------------------------------------------------------- Charles N. Owens Email: owensc@enc.edu http://www.enc.edu/~owensc Network & Systems Administrator Information Technology Services "Outside of a dog, a book is man's Eastern Nazarene College best friend. Inside of a dog it's too dark to read." - Groucho Marx ------------------------------------------------------------------------- From owner-freebsd-hackers Mon Jan 27 08:01:48 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA11435 for hackers-outgoing; Mon, 27 Jan 1997 08:01:48 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA11429 for ; Mon, 27 Jan 1997 08:01:45 -0800 (PST) Received: from diablo.ppp.de (diablo.ppp.de [193.141.101.34]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id IAA25609 for ; Mon, 27 Jan 1997 08:01:44 -0800 (PST) From: Greg Lehey Received: from freebie.lemis.de by diablo.ppp.de with smtp (Smail3.1.28.1 #1) id m0votTg-000QaIC; Mon, 27 Jan 97 17:00 MET Received: (grog@localhost) by freebie.lemis.de (8.8.4/8.6.12) id PAA11832; Mon, 27 Jan 1997 15:42:05 +0100 (MET) Message-Id: <199701271442.PAA11832@freebie.lemis.de> Subject: Re: bisdn In-Reply-To: <9971.854322113@time.cdrom.com> from "Jordan K. Hubbard" at "Jan 26, 97 03:41:53 pm" To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Mon, 27 Jan 1997 15:42:04 +0100 (MET) Cc: isdn@muc.ditec.de (FreeBSD ISDN Distribution List), hackers@freebsd.org (FreeBSD Hackers) Organisation: LEMIS, Schellnhausen 2, 36325 Feldatal, Germany Phone: +49-6637-919123 Fax: +49-6637-919122 Reply-to: grog@lemis.de (Greg Lehey) 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Jordan K. Hubbard writes: > I don't think that the problems are technical so much as political, > something which generally sucks given that the last thing the free > software community needs to be doing is shooting its feet off and > generally handing the boys at microsoft an even more overwhelming > advantage ("you can't crush us! hah! we plan to commit suicide > through sheer stupidity and ego way before we'll let that happen!" :-) > > Oh well. Sigh! :-) Well, to be fair, Gary Jennejohn replied and told me that this related to ppp, which I don't use. I think the problem there is that not many people use ppp over here, so it's not surprising that it's taking a long time. In that connection, you may be interested to know that I finally succeeded in getting a Teles card to somebody in the US who plans to use it with FreeBSD. He's a device driver engineer who works for Tandem in Austin, and I won't mention his name until I have his permission to do so, but he's a member of a startup planning to build an intelligent ISDN router. I'd guess that he will also contribute to the FreeBSD effort, which should open it up to a wider audience. I'll ask him to announce himself if he wants. Greg From owner-freebsd-hackers Mon Jan 27 09:20:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA14573 for hackers-outgoing; Mon, 27 Jan 1997 09:20:49 -0800 (PST) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA14567 for ; Mon, 27 Jan 1997 09:20:46 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA19495; Mon, 27 Jan 1997 12:20:06 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Mon, 27 Jan 1997 12:20 EST Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.8.3/8.7.3) with ESMTP id JAA00421 for ; Mon, 27 Jan 1997 09:26:38 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.8.3/8.6.9) id JAA01879 for freebsd-hackers@freefall.cdrom.com; Mon, 27 Jan 1997 09:30:23 -0500 (EST) Date: Mon, 27 Jan 1997 09:30:23 -0500 (EST) From: Thomas David Rivers Message-Id: <199701271430.JAA01879@lakes.water.net> To: ponds!freefall.cdrom.com!freebsd-hackers Subject: 2.2-BETA and 1.2meg floppies? Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I'm not sure if Jordan had included this in the "4-meg won't be supported" announcement. But - I was just scrounging together a test-bed machine to let me try these things out ahead of time. Unfortunately, the only floppy drive I could cheaply (i.e. free) acquire is a 1.2 meg floppy. Now, the 2.2-BETA boot floppy, boot.flp, will fit - it's 1177088 bytes long. But, I don't believe the fixit floppy, fixit.flp will since it's 1474560 bytes. [A 5-1/4" floppy has 1228800 bytes.] total 5220 -rw-r--r-- 1 rivers wheel 153 Dec 25 21:52 CHECKSUM.MD5 -rw-r--r-- 1 rivers wheel 699 Dec 23 23:00 README.TXT -rw-r--r-- 1 rivers wheel 1177088 Dec 25 21:42 boot.flp -rw-r--r-- 1 rivers wheel 1474560 Dec 25 21:44 fixit.flp I understand; and agree with the arguments that 1.44 meg floppies are cheap (~$60) - but, I'm under serious austerity measures now and don't think I'll stumble into that $60 any time soon. [We're trying to pay off the house early, you know how it goes - and if not, read last Decemeber's Money Magazine.] So - I was wondering if we can produce a smaller "fixit.flp". Perhaps one without "vi" (just ed would be enough.) might bring it into the 1.2 meg range. I put this together with left-overs from previous projects and some other people's junk they were just going to throw away [cases, monitors, etc..] I was able to scrounge; at absolutely no additional cost was: 386dx-33, 12 meg memory. Aha 1542B, a 5-1/4" floppy, and an old 500 meg SCSI. Serial card with 16450's wired on-board. IDE controller and 40 meg IDE drive (which I saved for another day.) Hercules adapter and a nice Princeton monochrome monitor; plus a used "tilty" monitor stand. NE2000 clone card Ancient/dirty keyboard (switchable between XT/AT, with ESC in the wrong place.) Of course, some of these are parts I had purchased years ago; so I suppose you could say there was some cost; but that should be amatorized across about 6-7 years. - Dave Rivers - From owner-freebsd-hackers Mon Jan 27 09:44:17 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA15890 for hackers-outgoing; Mon, 27 Jan 1997 09:44:17 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA15881 for ; Mon, 27 Jan 1997 09:44:15 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA05718; Mon, 27 Jan 1997 10:26:54 -0700 From: Terry Lambert Message-Id: <199701271726.KAA05718@phaeton.artisoft.com> Subject: Re: What is the default for async in /etc/fstab? To: dicen@hooked.net (RHS Linux User) Date: Mon, 27 Jan 1997 10:26:53 -0700 (MST) Cc: freebsd-hackers@freebsd.org In-Reply-To: <32EBC635.4F86F1D5@hooked.net> from "RHS Linux User" at Jan 26, 97 01:01:41 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I am having trouble determining the disk IO performace of FreeBSD vs. > Linux. I recently ran a test on FreeBSD and the write performance wasn't > so great. However, I didn't think to see if async was set in the > /etc/fstab file. I installed from a 2.1 CDROM initially and then cvsuped > different versions. So what is the default for async in the 2.1 > /etc/fstab? Default is "reliable"... ie: off. > Have other people tested ufs vs. ext2? The only docs I could find where > for ext2. A comparison with FreeBSD 2.0 I think, although it could have > been older. This was for some old Linux 1.xx. Is there a FFS for Linux yet? I think you will only find BSD numbers. Comparing EXT2 on Linux to FFS on FreeBSD, you are more likely comparing Linux and FreeBSD, not the FS's themselves. 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 Mon Jan 27 09:47:43 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA16106 for hackers-outgoing; Mon, 27 Jan 1997 09:47:43 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA16088 for ; Mon, 27 Jan 1997 09:47:35 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA05738; Mon, 27 Jan 1997 10:30:13 -0700 From: Terry Lambert Message-Id: <199701271730.KAA05738@phaeton.artisoft.com> Subject: Re: CMD640b ide controller bug workarounds? To: terry@lambert.org (Terry Lambert) Date: Mon, 27 Jan 1997 10:30:13 -0700 (MST) Cc: garman@phs.k12.ar.us, terry@lambert.org, freebsd-hackers@freebsd.org In-Reply-To: <199701270331.UAA04555@phaeton.artisoft.com> from "Terry Lambert" at Jan 26, 97 08:31:08 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Well, for PCI, yes. For VLB, there's no slot identification data > (which is why, like ISA, it sucks). > > If the Linux code is working around the hardware problem, it probably > has code to detect it, which you could examine to determine their > algorithm. I now have it on good authority that Linux has working chip detection code. 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 Jan 27 09:50:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA16473 for hackers-outgoing; Mon, 27 Jan 1997 09:50:51 -0800 (PST) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA16464 for ; Mon, 27 Jan 1997 09:50:47 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA22832; Mon, 27 Jan 1997 12:50:15 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Mon, 27 Jan 1997 12:50 EST Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.8.3/8.7.3) with ESMTP id MAA08123 for ; Mon, 27 Jan 1997 12:32:56 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.8.3/8.6.9) id MAA02158 for freebsd-hackers@freefall.cdrom.com; Mon, 27 Jan 1997 12:36:55 -0500 (EST) Date: Mon, 27 Jan 1997 12:36:55 -0500 (EST) From: Thomas David Rivers Message-Id: <199701271736.MAA02158@lakes.water.net> To: ponds!freefall.cdrom.com!freebsd-hackers Subject: panic: ffs_valloc: dup alloc with 2.2-BETA. Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Ok - Here's the first fruit from my reliable reproduction of my "nightly" panics. I can now readily cause the problem with 2.2-BETA. This implies that whatever fixes were postulated during the 2.2 development don't address the problem, or weren't complete somehow. Anyway, I get a nice: panic: ffs_valloc: dup alloc during the install's newfs of my root file system. At this point; since I can readily reproduce the problem - and have a machine dedicated to that end... I'm in a position to try out anything anyone wants to try! My only limitation is a 5-1/4" floppy drive... - Dave Rivers - From owner-freebsd-hackers Mon Jan 27 09:51:12 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA16527 for hackers-outgoing; Mon, 27 Jan 1997 09:51:12 -0800 (PST) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA16516 for ; Mon, 27 Jan 1997 09:51:07 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA22711; Mon, 27 Jan 1997 12:50:04 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Mon, 27 Jan 1997 12:50 EST Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.8.3/8.7.3) with ESMTP id MAA07293 for ; Mon, 27 Jan 1997 12:06:40 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.8.3/8.6.9) id MAA02068 for freebsd-hackers@freefall.cdrom.com; Mon, 27 Jan 1997 12:10:38 -0500 (EST) Date: Mon, 27 Jan 1997 12:10:38 -0500 (EST) From: Thomas David Rivers Message-Id: <199701271710.MAA02068@lakes.water.net> To: ponds!freefall.cdrom.com!freebsd-hackers Subject: Reproduction of ffs_valloc: dup alloc (finally!) Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Finally, I have a reproduction of the ffs_valloc problem in 2.1.6.1. I can attempt to install 2.1.6.1 (from the Walnut Creek CDROM) on a particular machine and consistently get the dup alloc when the installation attempts to do the newfs of the file system. If I alter the newfs parameters; I don't get the problem. I'm going to try it with 2.2-BETA and see what happens.... - Dave Rivers - From owner-freebsd-hackers Mon Jan 27 09:52:14 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA16635 for hackers-outgoing; Mon, 27 Jan 1997 09:52:14 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA16618 for ; Mon, 27 Jan 1997 09:52:12 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA05765; Mon, 27 Jan 1997 10:34:30 -0700 From: Terry Lambert Message-Id: <199701271734.KAA05765@phaeton.artisoft.com> Subject: Re: bisdn To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Mon, 27 Jan 1997 10:34:30 -0700 (MST) Cc: grog@lemis.de, hackers@FreeBSD.ORG, isdn@muc.ditec.de In-Reply-To: <9971.854322113@time.cdrom.com> from "Jordan K. Hubbard" at Jan 26, 97 03:41:53 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > >> and greatly appreciated, too ! Several people will be working on getting > > >> this integrated into -current (aka 3.0). > > > > > > Really? Awesome! I'd just about given up! :-) > > > > What's the problem? I've been running bisdn on 2.2-CURRENT and > > 3.0-CURRENT since last May. > > I don't think that the problems are technical so much as political, > something which generally sucks given that the last thing the free > software community needs to be doing is shooting its feet off and > generally handing the boys at microsoft an even more overwhelming > advantage ("you can't crush us! hah! we plan to commit suicide > through sheer stupidity and ego way before we'll let that happen!" :-) > > Oh well. Sigh! :-) Clearly your process for adding committers and/or having committers do your code reviews has failed to keep up with the BISDN folk's ability to generate code. 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 Jan 27 09:56:48 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA16904 for hackers-outgoing; Mon, 27 Jan 1997 09:56:48 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA16887 for ; Mon, 27 Jan 1997 09:56:45 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA05784; Mon, 27 Jan 1997 10:39:04 -0700 From: Terry Lambert Message-Id: <199701271739.KAA05784@phaeton.artisoft.com> Subject: Re: fdisk headache To: joerg_wunsch@uriah.heep.sax.de Date: Mon, 27 Jan 1997 10:39:04 -0700 (MST) Cc: freebsd-hackers@freebsd.org In-Reply-To: from "J Wunsch" at Jan 27, 97 01:27:03 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > . Since the MBR is identical to the BSD bootstrap, there's no room for > > > things like `nextboot' after the MBR, and you can't replace the MBR > > > by fancy things like a boot selector. > > > This is evil. > > You consider it evil -- some (many?) others don't. See the first > sentence above: it's called ``dangerously'' dedicated mode. It's just > for those who want and love this way. Those who prefer fighting > against braindead 1024-cylinder or foobar megabyte limits are free to > do so, and we even do them the favour to make these struggles (i.e., > the DOS-compatible way) the default variant. "Fighting against the 1024 cylinder limit" is an irrelevant supposition. That limit is not present in LBA-aware MBR's, such as the OnTrack 7.x stuff which also happens to install a BIOS TSR that supplies the LBA BIOS entry points. The limit in that case, or in the case of native LBA support in the IDE controller BIOS, is the FreeBSD OS specific boot code. Again, removing the ability to install other OS's without reinstalling BSD is evil. I don't care if it's non-default or not. 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 Mon Jan 27 09:57:55 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA17014 for hackers-outgoing; Mon, 27 Jan 1997 09:57:55 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA17009 for ; Mon, 27 Jan 1997 09:57:52 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA05796; Mon, 27 Jan 1997 10:40:15 -0700 From: Terry Lambert Message-Id: <199701271740.KAA05796@phaeton.artisoft.com> Subject: Re: fdisk headache To: joerg_wunsch@uriah.heep.sax.de Date: Mon, 27 Jan 1997 10:40:15 -0700 (MST) Cc: freebsd-hackers@freebsd.org In-Reply-To: from "J Wunsch" at Jan 27, 97 01:29:17 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > . The number of BIOS geometry constraints to care for reduces drastic- > > > ally, so you can usually (*) ignore any geometry issues. > > > This is a bogus argument based on the assumption that we wouldn't put > > an absolute sector address in the partition entry like we should so > > a sector-offset based driver (BSD) could still use the partition > > table entry without multiplying out C/H/S values. > > > > Note that we should put the entry there for our parttition: we should > > not rely on a DOS tool to do it correctly for us. > > p.s.: You apparently don't understand what i'm writing about. There's > no DOS tool ever involved in DD mode (and little red daemons will jump > out of the disk if you ever come close to those disks with some DOS > tool at all :-). The BIOS real mode POST-based MBR load is a "DOS tool"... unless you are claiming you can make BIOS calls in protected mode? 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 Jan 27 10:12:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA17977 for hackers-outgoing; Mon, 27 Jan 1997 10:12:59 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA17971 for ; Mon, 27 Jan 1997 10:12:54 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA05820; Mon, 27 Jan 1997 10:53:52 -0700 From: Terry Lambert Message-Id: <199701271753.KAA05820@phaeton.artisoft.com> Subject: Re: SLAB stuff, and applications to current net code (fwd) To: alan@cymru.net (Alan Cox) Date: Mon, 27 Jan 1997 10:53:52 -0700 (MST) Cc: julian@whistle.com, proff@suburbia.net, dg@root.com, hackers@freebsd.org, alan.cox@linux.org In-Reply-To: <199701271008.KAA26279@snowcrash.cymru.net> from "Alan Cox" at Jan 27, 97 10:08:09 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > The right answer in current literature is undoubtedly a SLAB allocator and > that is where we are going at the moment. > > Alan Have you read Vahalia, 12.9, regarding per context page pooling? You can build a SLAB allocator on top of that, and the 12.10 analysis about SLAB vs. page pooling incorrectly bias toward SLAB because the page pooling had zone implemented on top of it (and zone is worse than SLAB). You will probably want to zone discard between contexts to allow freeing in one context after allocation in another. This is covered (a little) in "UNIX for Modern Architectures" for the SMP case, but applies to allocation at interrupt time and freeing at run time, and vice versa. This is important when you note that you could consider the two as seperate contexts, and you become worried about disabling interrupts during allocation (and potentially during page reclaimation to satisfy the request in the "BLOCK_OK" case). This is an issue of concurrency of operation, even in the UP case, if you do that. 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 Mon Jan 27 10:16:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA18145 for hackers-outgoing; Mon, 27 Jan 1997 10:16:09 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA18133 for ; Mon, 27 Jan 1997 10:16:03 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.4/8.6.9) with ESMTP id KAA12328; Mon, 27 Jan 1997 10:15:12 -0800 (PST) To: Terry Lambert cc: grog@lemis.de, hackers@FreeBSD.ORG, isdn@muc.ditec.de Subject: Re: bisdn In-reply-to: Your message of "Mon, 27 Jan 1997 10:34:30 MST." <199701271734.KAA05765@phaeton.artisoft.com> Date: Mon, 27 Jan 1997 10:15:11 -0800 Message-ID: <12324.854388911@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Clearly your process for adding committers and/or having committers do > your code reviews has failed to keep up with the BISDN folk's ability > to generate code. An excellent try, Terry. Here's a cookie. You're completely and utterly wrong as usual, but it was still a nice try. Actually, we've been waiting for many months for the BISDN code and if people over there could only stop threatening to sue one another if anything were ever actually released, I'm sure it would be much further ahead. Fortunately, I think and hope that this litigious phase has passed with the BISDN group and we may soon get something which can be released without getting anyone's noses out of joint. For details, please contact the isdn folks - I've just been the bystander watching events with dismay up to now. Jordan From owner-freebsd-hackers Mon Jan 27 10:53:06 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA21911 for hackers-outgoing; Mon, 27 Jan 1997 10:53:06 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA21904 for ; Mon, 27 Jan 1997 10:53:04 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA05959; Mon, 27 Jan 1997 11:35:23 -0700 From: Terry Lambert Message-Id: <199701271835.LAA05959@phaeton.artisoft.com> Subject: Re: bisdn To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Mon, 27 Jan 1997 11:35:23 -0700 (MST) Cc: terry@lambert.org, grog@lemis.de, hackers@freebsd.org, isdn@muc.ditec.de In-Reply-To: <12324.854388911@time.cdrom.com> from "Jordan K. Hubbard" at Jan 27, 97 10:15:11 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Actually, we've been waiting for many months for the BISDN code and if > people over there could only stop threatening to sue one another if > anything were ever actually released, I'm sure it would be much > further ahead. Fortunately, I think and hope that this litigious > phase has passed with the BISDN group and we may soon get something > which can be released without getting anyone's noses out of joint. > > For details, please contact the isdn folks - I've just been the > bystander watching events with dismay up to now. Ah. I misinterpreted your "shoot our own foot off" statement as containing a possessive "our". 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 Mon Jan 27 11:03:14 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA22570 for hackers-outgoing; Mon, 27 Jan 1997 11:03:14 -0800 (PST) Received: from vdp01.vailsystems.com (root@vdp01.vailsystems.com [207.152.98.18]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA22560 for ; Mon, 27 Jan 1997 11:03:12 -0800 (PST) Received: from crocodile.vale.com (crocodile [204.117.217.147]) by vdp01.vailsystems.com (8.8.3/8.7.3) with ESMTP id NAA00312 for ; Mon, 27 Jan 1997 13:03:06 -0600 (CST) Received: from jaguar (jaguar.vale.com [204.117.217.146]) by crocodile.vale.com (8.8.3/8.7.3) with SMTP id NAA21464 for ; Mon, 27 Jan 1997 13:03:05 -0600 (CST) Message-ID: <32ECFBE9.10E8@vailsys.com> Date: Mon, 27 Jan 1997 13:03:05 -0600 From: Hal Snyder Reply-To: hal@vailsys.com Organization: Vail Systems, Inc. X-Mailer: Mozilla 3.0 (WinNT; I) MIME-Version: 1.0 To: hackers@freebsd.org Subject: directory conventions Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I just got the following from Blair Zajac, who is working on the next release of amanda: > I'm working on Amanda 2.3.0.4 right this minute. It's got a lot of > patches included in it, but probably the biggest deal is that it now > uses automake and autoconf to build the sources. ... > Finally, since I've been converting this to automake, GNU has some standard > places where it likes to shove things. Right now Amanda 2.3.0.4 uses the > following distribution: > > $prefix/bin Amanda server side programs > $prefix/libexec Amanda backup client programs > $prefix/share/amanda Runtime configuration files > $prefix/share/amanda-index Directory for index of dumps > $prefix/var/amanda Directory for database & log files > > I figure that the configuration files and the indexing files can go under > share, since they are in a format that all OS'es can understand. However, > the log files and the database (curinfo) files may be OS dependent and should > go into another directory, say var. This is all customizable using the > options that configure provides to change the locations of where stuff gets > installed. Does anybody have any good ideas or comments on this? Prefix for BSD's is /usr/local. My guess is that config files should go to /usr/local/etc. What is the diff in purpose between /usr/local/libexec and /usr/local/bin? What is /usr/local/share for? Portable bits, as Blair suggests? And what of /usr/local/var? From owner-freebsd-hackers Mon Jan 27 17:06:44 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA01230 for hackers-outgoing; Mon, 27 Jan 1997 17:06:44 -0800 (PST) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA01224 for ; Mon, 27 Jan 1997 17:06:35 -0800 (PST) Received: from awfulhak.demon.co.uk (localhost.coverform.lan [127.0.0.1]) by awfulhak.demon.co.uk (8.8.4/8.7.3) with ESMTP id BAA19092; Tue, 28 Jan 1997 01:01:11 GMT Message-Id: <199701280101.BAA19092@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: fredriks@mcs.com cc: hackers@freebsd.org Subject: Re: Modifications to pppd to make it log connecton times In-reply-to: Your message of "Thu, 23 Jan 1997 00:59:29 CST." <32E70C51.41C67EA6@mcs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 28 Jan 1997 01:01:10 +0000 From: Brian Somers Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > This is a multi-part message in MIME format. > > --------------446B9B3D2781E494167EB0E7 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > Hi, > Here are context diffs to pppd that makes pppd log the total > time in minutes that it has been connected(similar to what ppp does). > I don't know if I have caught every way pppd can exit(it obviously > doesn't do this if it dumps core or the machine panics) to make sure > the data is printed out, but it does work for the normal cases for sure. [.....] I havn't got to look at these yet, but I'll give you a shout when I do. Thanks -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Mon Jan 27 17:19:39 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA01973 for hackers-outgoing; Mon, 27 Jan 1997 17:19:39 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA01940 for ; Mon, 27 Jan 1997 17:19:35 -0800 (PST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id QAA28209 for ; Mon, 27 Jan 1997 16:25:35 -0800 (PST) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.4/8.8.4) with SMTP id QAA10324 for ; Mon, 27 Jan 1997 16:17:59 -0800 (PST) Message-ID: <32ED4558.446B9B3D@whistle.com> Date: Mon, 27 Jan 1997 16:16:24 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: hackers@freebsd.org Subject: Network interfaces: removal of. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have a system with frame relay interfaces, and virtual circuits are reflected by virtual 'interfaces' e.g vc0, vc2 etc. the trouble is that there is no support in the kernel for REMOVING an interface! does anyone have any ideas on this? removal of an interface requires that the interface addresses be freed. this in turn requires that any routes that access that ifa (e.g in a TCP pcb) discover that it is invalid the next time they try use it, and try get a new rtentry/ifa. None of this happens at the moment. Add to that the fact that the linked list of interfaces has no support for removing entries, and that the interface array has no support for re-using entries. The reference counting on rtentries and IFAs is next to useless as so many places don't use them rigorously, which requires hacks to keep them allingned with anything even close to reality.. Is there anyone in the group who feels as though they understand the situation well enough to work with me in trying to clean this up a bit? I have the interest in doing it, but I need someone to guide me a bit as the routing table system still confuses me on a regular basis. julian From owner-freebsd-hackers Mon Jan 27 17:23:08 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA02924 for hackers-outgoing; Mon, 27 Jan 1997 17:23:08 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA02897 for ; Mon, 27 Jan 1997 17:23:03 -0800 (PST) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id OAA27491 for ; Mon, 27 Jan 1997 14:49:48 -0800 (PST) Received: from seagull.rtd.com by agora.rdrop.com with smtp (Smail3.1.29.1 #17) id m0vozqO-0008yFC; Mon, 27 Jan 97 14:48 PST Received: (from dgy@localhost) by seagull.rtd.com (8.7.5/8.7.3) id PAA15452; Mon, 27 Jan 1997 15:44:19 -0700 (MST) From: Don Yuniskis Message-Id: <199701272244.PAA15452@seagull.rtd.com> Subject: Re: suggestion for kernel printk() ? To: Shimon@i-Connect.Net (Simon Shapiro) Date: Mon, 27 Jan 1997 15:44:19 -0700 (MST) Cc: dgy@rtd.com, freebsd-hackers@freefall.freebsd.org, bde@zeta.org.au In-Reply-To: from "Simon Shapiro" at Jan 27, 97 02:23:10 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk It seems that Simon Shapiro said: > > > > I just spent some time fighting a kernel that died miserably > > > >on boot :-( I was inundated with an endless stream of kernel > > > >messages (in highlighted text) followed promptly by a hard reset. > > > >It was quite frustrating to find that there doesn't seem to be a > > > >mechanism to pause the display at this point! > > > > However, is it worthwhile for the mechanism that printk() ?? uses to > > observe some kind of flow control? It did not recognize scroll_lock, > > pause, ^S, etc. This would have at least enabled me to read some > > (i.e. one screen full) of the messages to see what the kernel was > > complaining about. > > I may be offbase here, but scroll-lock, etc. are INPUT, while printk is Yes. But all of those mechanisms tie in to provide flow control for regular console output functions. Apparently, however, this happens at a higher level than I had hoped/assumed (i.e. more stuff has to be functional before this mechanism works). > output. No? Maybe a (oops :-) SysV-like mechanism where print{kf} go to > a circular buffer andanother mechanism dumps it to ``the console''. > If you like ugly, (if memory serves), you can either pass an additional arg > to the output routine (A la Linux) or designate the first character in the > string to tell what to do, as in ~==console and buffer, !=bufferonly, etc. I was suggesting having printk() examine the keyboard buffer for a pending "pause" key and blocking in this event. However, it appears that the system couldn't handle that crude of an implementation... --don From owner-freebsd-hackers Mon Jan 27 17:23:19 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA02985 for hackers-outgoing; Mon, 27 Jan 1997 17:23:19 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA02946 for ; Mon, 27 Jan 1997 17:23:12 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id OAA27524 for ; Mon, 27 Jan 1997 14:54:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id OAA12253; Mon, 27 Jan 1997 14:52:37 -0800 (PST) Message-Id: <199701272252.OAA12253@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Jon Moldenhauer cc: freebsd-hackers@freebsd.org Subject: Re: Intel EtherExpress Pro 10B PCI In-reply-to: Your message of "Sat, 25 Jan 1997 20:22:58 PST." <199701260422.UAA15008@almond.elite.net> From: David Greenman Reply-To: dg@root.com Date: Mon, 27 Jan 1997 14:52:37 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Up till now, I hadn't seen anyone say they had gotten the 10B >card to work. Well, I did get it to work. Basically, the 10B >uses the same chip as the 100B (the i82557) and so the fxp >driver recognizes the card when FreeBSD boots. Unfortunately, >the fxp driver assumes the card is a 100B card which may not >always be the case. To remedy this, I hacked up the fxp >driver so it is possible to use the link0 and link1 flags to >ifconfig to tell the driver how to configure the card. For >users of the 100B card, nothing changes. For users of the 10B >card, you add 'link0 link1' to the ifconfig line for the card. > >The reason for two flags is this: link0 controls whether the >card is set up in nibble-wide (100Mbit) or bit-wide (10Mbit) >mode, and link1 controls whether the card is willing to do >full-duplex or will refuse to do full-duplex. Again, the >default settings of ifconfig are to work the way the driver >did before so you have to explicitly give the link0 flag to >put the card into bit-wide mode and explicitly give the link1 >flag to tell the card to refuse full-duplex mode. > >Anyway, thats probably more than anyone wants to know and >there must be a better way to tell the driver whether the >card is a 10B or 100B but since I don't have a 100B card I >couldn't figure out a reliable way (ethernet addresses >might work, but I would need to see some 100B ethernet >addresses to be sure). What you're saying above is all correct, and I agree that the flags isn't the right way to accomplish the 'mediatype' card setting - the driver needs to figure out what type of card you have. Unfortunately, I haven't found a way to easily do this, either, which is why the Pro/10 wasn't supported (the fact I don't _have_ a Pro/10 also has something to do with it :-)). Anyway, your investigation and patches are very useful in that they 1) will get people going right away, and more importantly, 2) show that this is all that is needed to get the driver working with the Pro/10. Probably the "right" solution to the probing will be to actually look at the PHY type and base the mediatype mode setting on the results of that. ...but I'll need to get a Pro/10 before I can write the code for this. Thanks! -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Mon Jan 27 17:24:07 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA03284 for hackers-outgoing; Mon, 27 Jan 1997 17:24:07 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA03237 for ; Mon, 27 Jan 1997 17:24:03 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id OAA27335 for ; Mon, 27 Jan 1997 14:24:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id OAA12114; Mon, 27 Jan 1997 14:23:00 -0800 (PST) Message-Id: <199701272223.OAA12114@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Vadim Kolontsov cc: hackers@freebsd.org Subject: Re: in_rtqtimo In-reply-to: Your message of "Mon, 27 Jan 1997 11:53:54 +0300." From: David Greenman Reply-To: dg@root.com Date: Mon, 27 Jan 1997 14:23:00 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Hello, > > what does this kernel message mean? > > /kernel: in_rtqtimo: adjusted rtq_reallyold to 2400 It means that your machine had a lot of clone routes and was adjusting the expiration time down a bit (to 2400 seconds). You can safely ignore it. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Mon Jan 27 17:24:22 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA03359 for hackers-outgoing; Mon, 27 Jan 1997 17:24:22 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA03325 for ; Mon, 27 Jan 1997 17:24:14 -0800 (PST) Received: from sendero.i-connect.net ([206.190.144.100]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id OAA27389 for ; Mon, 27 Jan 1997 14:32:04 -0800 (PST) Received: (qmail 3717 invoked by uid 1000); 27 Jan 1997 23:30:07 -0000 Message-ID: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199701252032.NAA20427@seagull.rtd.com> Date: Mon, 27 Jan 1997 14:23:10 -0800 (PST) Organization: iConnect Corp. From: Simon Shapiro To: Don Yuniskis Subject: Re: suggestion for kernel printk() ? Cc: freebsd-hackers@freefall.freebsd.org, (Bruce Evans) Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Don Yuniskis; On 25-Jan-97 you wrote: > It seems that Bruce Evans said: > > > > > I just spent some time fighting a kernel that died miserably > > >on boot :-( I was inundated with an endless stream of kernel > > >messages (in highlighted text) followed promptly by a hard reset. > > >It was quite frustrating to find that there doesn't seem to be a > > >mechanism to pause the display at this point! > > > > I use a serial console and `terminalprogram | tee foo' to capture > > the output. > > Yes, but I would have had to have built the kernel with COMCONSOLE > (which I didn't). > > > > OK, reboot from /kernel.old and look through the logs. Hmmm... > > >nothing here! Probably the filesystem wasn't even functional when > > >the boot ran into trouble. > > > > Boot messages are supposed to be preserved in the message buffer > > across reboots. However, many PC BIOSes and/or memory systems do > > something that invalidates the message buffer even for a soft reboot. > > Well, I wasn't observant enough to notice what type of restart the > PC went through (two different varieties here -- one of which actually > rampages through memory, etc.) but suspect this is the problem. > > However, is it worthwhile for the mechanism that printk() ?? uses to > observe some kind of flow control? It did not recognize scroll_lock, > pause, ^S, etc. This would have at least enabled me to read some > (i.e. one screen full) of the messages to see what the kernel was > complaining about. I may be offbase here, but scroll-lock, etc. are INPUT, while printk is output. No? Maybe a (oops :-) SysV-like mechanism where print{kf} go to a circular buffer andanother mechanism dumps it to ``the console''. If you like ugly, (if memory serves), you can either pass an additional arg to the output routine (A la Linux) or designate the first character in the string to tell what to do, as in ~==console and buffer, !=bufferonly, etc. Simon From owner-freebsd-hackers Mon Jan 27 17:24:29 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA03402 for hackers-outgoing; Mon, 27 Jan 1997 17:24:29 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA03377 for ; Mon, 27 Jan 1997 17:24:25 -0800 (PST) Received: from sendero.i-connect.net ([206.190.144.100]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id OAA27390 for ; Mon, 27 Jan 1997 14:32:04 -0800 (PST) Received: (qmail 3725 invoked by uid 1000); 27 Jan 1997 23:30:08 -0000 Message-ID: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Mon, 27 Jan 1997 14:27:12 -0800 (PST) Organization: iConnect Corp. From: Simon Shapiro To: (Joerg Wunsch) Subject: Re: fdisk headache Cc: freebsd-hackers@freebsd.org, (Jean-Marc Zucconi) , (J Wunsch) Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi J Wunsch; On 25-Jan-97 you wrote: > As Jean-Marc Zucconi wrote: > > > I try to add another disk, but it seems that something has changed > > since my last drive installation because fdisk doesnt want to write a > > correct information. > > Why are you using fdisk at all? You are running Unix, you aren't > running on a PC, you are not supposed to use fdisk (unless other > systems on your disk force you to this step). Slow down.... The gentleman has a valid point, methinks. If not, please show me how to build 120 filesystems on a disk that is 750GB large. Impossible/stupid numbers? not really when considering a large disk array with a very large database. >From what I have seen, FreeBSD gives me 6 partitions (slices) per device. not quite enough. I am running 22 filessystems on a 16GB ccd conglomerate and porting/qriting a driver for the DPT controller that allows, easily, 4 wide controllers, 3 busses each, 15 targets per drive, 15 LUNS per target. Shall I go on? > > :-) > > > My new drive is probed as: > > (ncr1:6:0): "QUANTUM FIREBALL_TM3200S 300N" type 0 fixed SCSI 2 > > sd4(ncr1:6:0): Direct-Access > > sd4(ncr1:6:0): 10.0 MB/s (100 ns, offset 8) > > 3067MB (6281856 512 byte sectors) > > sd4(ncr1:6:0): with 6810 cyls, 5 heads, and an average 184 > > sectors/track > > (why 6810*5*184 != 6281856 ???) > > So, if you don't understand it -- why do you boot with -v at all? We > deliberately took this line out of the default messages: > > sd4(ncr1:6:0): with 6810 cyls, 5 heads, and an average 184 > ^^^^^^^^^^^^^^ > > ...and this should be taken as a good indication that nobody claims > the equation C*H*S = should assumed to be > true. It's just the other way round: the SCSI drive can report about > its number of heads, cylinders, and total number of blocks. Since it > can't report about the number of sectors per track (and this number > would barely make sense at all), the boot message calculates that > average from the other three figures. > > > When I start fdisk it tells me that the drive has 19035cyl, 6heads, > > 55sec/trk. Wanting to change the values to 6810/5/184, I get > > You can't. You are limited by the BIOS constraints in an fdisk table. > The best you could do is changing it to 1024/x/y where x and y match > the emulation your BIOS is using. > > > The data for partition 3 is: > > sysid 165,(FreeBSD/NetBSD/386BSD) > > start 1, size 6265199 (3059 Meg), flag 80 > > beg: cyl 0/ sector 2/ head 0; > > end: cyl 666/ sector 55/ head 5 > > The last value is obviously wrong, but if try to change it to > > something more realistic, eg. 6810/5/183, fdisk interpret my values as > > 666/55/5 !!!!! > > Because it will be (silently) masked by 0x3ff. > > > The real problem is then when I want to label the disk: I get > > > > ioctl DIOCWLABEL: Operation not supported by device > > sd4s4: type 0xa5, start 1, end = 6265199, size 6265199 > > sd4s4: C/H/S end 666/5/55 (220109) != end 6265199: invalid > > The slice code knows about various BIOS problems. It assumes a few > bogus geometry values (including the 1024 cylinders one). However, > the total number of sectors in the BSD slice must still match the `c' > partition value -- 6265199. > > > Is there a solution? I don't care if the geometry is incorrect as long > > I can disklabel/newfs the drive and use the 3067 Mb!!! > > The simplest solution (assuming you only want FreeBSD there) is: > > . wipe out your junked fdisk table: dd if=/dev/zero of=/dev/rsd4 count=10 > . give the entire disk to FreeBSD: disklabel -Brw sd4 auto > . edit the partitions as you need: disklabel -e sd4 > > -- > 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 Jan 27 17:24:39 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA03459 for hackers-outgoing; Mon, 27 Jan 1997 17:24:39 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA03441 for ; Mon, 27 Jan 1997 17:24:35 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id PAA27716 for ; Mon, 27 Jan 1997 15:16:41 -0800 (PST) Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with SMTP id PAA24291 for ; Mon, 27 Jan 1997 15:16:33 -0800 (PST) Received: (qmail 3638 invoked by uid 110); 27 Jan 1997 23:14:54 -0000 MBOX-Line: From owner-netdev@roxanne.nuclecu.unam.mx Mon Jan 27 19:05:01 1997 remote from suburbia.net Delivered-To: proff@suburbia.net Received: (qmail 8369 invoked from network); 27 Jan 1997 19:04:55 -0000 Received: from roxanne.nuclecu.unam.mx (132.248.29.2) by suburbia.net with SMTP; 27 Jan 1997 19:04:55 -0000 Received: (from root@localhost) by roxanne.nuclecu.unam.mx (8.6.12/8.6.11) id MAA03684 for netdev-outgoing; Mon, 27 Jan 1997 12:46:36 -0600 Received: from athena.nuclecu.unam.mx (athena.nuclecu.unam.mx [132.248.29.9]) by roxanne.nuclecu.unam.mx (8.6.12/8.6.11) with ESMTP id MAA03679 for ; Mon, 27 Jan 1997 12:46:33 -0600 Received: (from miguel@localhost) by athena.nuclecu.unam.mx (8.6.12/8.6.11) id MAA08310; Mon, 27 Jan 1997 12:37:25 -0600 Date: Mon, 27 Jan 1997 12:37:25 -0600 Message-Id: <199701271837.MAA08310@athena.nuclecu.unam.mx> From: Miguel de Icaza To: netdev@roxanne.nuclecu.unam.mx, dah@pe.net CC: davem@jenolan.rutgers.edu In-reply-to: <199701261640.IAA18757@magnolia.pe.net> (message from David Heitmann on Sun, 26 Jan 1997 08:40:17 -0800) Subject: Re: SLAB stuff, and applications to current net code X-Lost: In case of doubt, make it sound convincing Reply-To: netdev@roxanne.nuclecu.unam.mx, Miguel de Icaza Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I'm going to try feveriously to get the SLAB allocator integrated into > > Linus's sources over the next two days. For the most part my > > incentive is so that people think about it when they design memory > > object allocation subsystems. > > Could someone post where to get more (detailed) information about > SLAB allocators? You can find a nice explanation on Uresh Vahalia's "Unix Internals: The New Frontiers". I have also placed the Postscript paper that I got from somewere on the net on my web page: http://luthien.nuclecu.unam.mx/~miguel Miguel. From owner-freebsd-hackers Mon Jan 27 17:27:02 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA04124 for hackers-outgoing; Mon, 27 Jan 1997 17:27:02 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA04102 for ; Mon, 27 Jan 1997 17:26:53 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id NAA26916 for ; Mon, 27 Jan 1997 13:26:50 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id WAA15384; Mon, 27 Jan 1997 22:25:08 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id WAA12677; Mon, 27 Jan 1997 22:08:45 +0100 (MET) Message-ID: Date: Mon, 27 Jan 1997 22:08:45 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: ponds!rivers@dg-rtp.dg.com (Thomas David Rivers) Cc: freebsd-hackers@freebsd.org (FreeBSD hackers) Subject: Re: 2.2-BETA and 1.2meg floppies? References: <199701271430.JAA01879@lakes.water.net> X-Mailer: Mutt 0.55-PL10 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: <199701271430.JAA01879@lakes.water.net>; from Thomas David Rivers on Jan 27, 1997 09:30:23 -0500 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Thomas David Rivers wrote: > I'm not sure if Jordan had included this in the "4-meg won't be > supported" announcement. Yes, he did. > Now, the 2.2-BETA boot floppy, boot.flp, will fit - it's 1177088 > bytes long. That's surprising. At least at one stage in the game, we ran out of space on the 1.2 MB floppies, and decided that we don't have the energy to deal any longer with this. (It's been a continous hunt for just a few bytes on the install floppy.) > So - I was wondering if we can produce a smaller "fixit.flp". It's not very difficult to do this. However, Julian didn't seem to be very interested in maintaining his floppy build submission that doesn't require an entire `make release' before, so it's currently a little orphaned. I'm not sure whether it will be possible for you to just create a fixit floppy without building an entire release... With a little Makefile tweaking, you should be able however. It's not much more than just some `crunchgen' stuff. Have a look into /usr/src/release/*. I could probably put up a fixit image without a vi, but this one will become outdated fairly soon. -- 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 Jan 27 17:27:10 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA04159 for hackers-outgoing; Mon, 27 Jan 1997 17:27:10 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA04122 for ; Mon, 27 Jan 1997 17:27:02 -0800 (PST) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id NAA26974 for ; Mon, 27 Jan 1997 13:34:51 -0800 (PST) Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.2-biteme) with ESMTP id PAA27780 for ; Mon, 27 Jan 1997 15:34:49 -0600 (CST) Received: from Venus.mcs.net (ljo@Venus.mcs.com [192.160.127.92]) by Mailbox.mcs.com (8.8.5/8.8.2) with ESMTP id PAA02541; Mon, 27 Jan 1997 15:34:39 -0600 (CST) Received: (from ljo@localhost) by Venus.mcs.net (8.8.5/8.8.2) id PAA10766; Mon, 27 Jan 1997 15:34:20 -0600 (CST) From: Lars Jonas Olsson Message-Id: <199701272134.PAA10766@Venus.mcs.net> Subject: de0 timeouts w 486 CPU To: hackers@freebsd.org Date: Mon, 27 Jan 1997 15:34:19 -0600 (CST) Cc: ljo@Mcs.Net X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have a 486DX4-100 system that is doing make worlds fine, but generates a lot of: de0: system error: master abort messages with a current kernel. With a 2.1R kernel it was generating illegal interrupt errors for de0. Any guess if this is bug in the if_de.c driver or a hardware problem? The rate of messages is 5-30/hour on a system not doing much networking. Jonas Copyright (c) 1992-1996 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.0-CURRENT #0: Fri Jan 24 14:59:03 CST 1997 root@mail-new.accumed-int.com:/usr/src/sys/compile/MAIL-NEW Calibrating clock(s) relative to mc146818A clock ... i8254 clock: 1193260 Hz CPU: i486 DX4 (486-class CPU) Origin = "GenuineIntel" Id = 0x480 Stepping=0 Features=0x3 real memory = 16777216 (16384K bytes) avail memory = 14741504 (14396K bytes) Probing for devices on PCI bus 0: chip0 rev 49 on pci0:5:0 de0 rev 32 int a irq 10 on pci0:10:0 de0: 21140A [10-100Mb/s] pass 2.0 de0: address 00:80:c8:3e:48:bf de0: enabling 100baseTX port vga0 rev 34 int a irq 11 on pci0:11:0 Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> ed0 not found at 0x280 ed1 not found at 0x300 sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 72065B fd0: 1.44MB 3.5in wdc0 at 0x1f0-0x1f7 irq 14 on isa wdc0: unit 0 (wd0): wd0: 1039MB (2128896 sectors), 2112 cyls, 16 heads, 63 S/T, 512 B/S npx0 on motherboard npx0: INT 16 interface de0: system error: master abort de0: system error: master abort From owner-freebsd-hackers Mon Jan 27 17:28:08 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA04392 for hackers-outgoing; Mon, 27 Jan 1997 17:28:08 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA04365 for ; Mon, 27 Jan 1997 17:28:04 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id MAA26741 for ; Mon, 27 Jan 1997 12:57:13 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id VAA14787 for hackers@freebsd.org; Mon, 27 Jan 1997 21:55:50 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id VAA12559; Mon, 27 Jan 1997 21:44:13 +0100 (MET) Message-ID: Date: Mon, 27 Jan 1997 21:44:13 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@freebsd.org Subject: Re: gomoku References: <199701271003.VAA23833@profane.iq.org> X-Mailer: Mutt 0.55-PL10 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: <199701271003.VAA23833@profane.iq.org>; from Julian Assange on Jan 27, 1997 21:03:19 +1100 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Julian Assange wrote: > Is there any reason that gomoku from Lite2 is missing from > /usr/src/games? Yes: nobody ever did start a full userland Lite2 merge (not even a vendor-branch import, but that's already a large part of the work to be done). -- 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 Jan 27 17:28:12 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA04414 for hackers-outgoing; Mon, 27 Jan 1997 17:28:12 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA04388 for ; Mon, 27 Jan 1997 17:28:07 -0800 (PST) Received: from sendero.i-connect.net ([206.190.144.100]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id MAA26727 for ; Mon, 27 Jan 1997 12:56:14 -0800 (PST) Received: (qmail 21759 invoked by uid 1000); 25 Jan 1997 05:09:19 -0000 Message-ID: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Fri, 24 Jan 1997 21:06:30 -0800 (PST) Organization: iConnect Corp. From: Simon Shapiro To: garman@phs.k12.ar.us Subject: RE: CMD640b ide controller bug workarounds? Cc: freebsd-hackers@freebsd.org, (Jason Garman) Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi Jason Garman; On 25-Jan-97 you wrote: > Does anyone have one of these lame ide controllers? These things, in > addition to having the rz1000 flaws, also freeze the machine when both ide > channels are accessed on the machine. Is there any chance for a > workaround in the FreeBSD wdc driver? I have a nice 2 gig drive sitting > here spinning its heads for nothing :-( > > I tried doing some modifications myself, but as the extraordinary novice > kernel hacker I am, I only got it to hang the specific process doing the > disk access, not the entire machine. A little improvement, I guess :-/ > > L*nux has an option `hda=serialize' to do this. Is there any chance > FreeBSD could have an CMD640B_SUCKS_ROCKS_SERIALIZE_REQUESTS option in the > kernel config file? Linux also hasa specific RZ100 option, if I am not mistaken. Simon From owner-freebsd-hackers Mon Jan 27 17:28:23 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA04476 for hackers-outgoing; Mon, 27 Jan 1997 17:28:23 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA04447 for ; Mon, 27 Jan 1997 17:28:18 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id MAA26719 for ; Mon, 27 Jan 1997 12:55:42 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id VAA14741; Mon, 27 Jan 1997 21:53:41 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id VAA12541; Mon, 27 Jan 1997 21:38:18 +0100 (MET) Message-ID: Date: Mon, 27 Jan 1997 21:38:18 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: kmitch@weenix.guru.org (Keith Mitchell) Cc: hackers@freebsd.org Subject: Re: DUMP problem References: <199701270756.CAA03562@weenix.guru.org> X-Mailer: Mutt 0.55-PL10 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: <199701270756.CAA03562@weenix.guru.org>; from Keith Mitchell on Jan 27, 1997 02:56:23 -0500 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Keith Mitchell wrote: > | DUMP: too many slaves, 1 (recompile smaller): Resource temporarily unavailab > le > | DUMP: The ENTIRE dump is aborted. > > > Does anyone know how to fix this too many slaves error condition that keeps > popping up?? if (socketpair(AF_UNIX, SOCK_STREAM, 0, cmd) < 0 || (slaves[i].pid = fork()) < 0) quit("too many slaves, %d (recompile smaller): %s\n", i, strerror(errno)); It translates into ``Cannot fork''. Seems you reached the process limit of the user running amanda. See limits (in the csh), or ulimit (in Bourne-alike shells). -- 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 Jan 27 17:28:36 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA04542 for hackers-outgoing; Mon, 27 Jan 1997 17:28:36 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA04511 for ; Mon, 27 Jan 1997 17:28:31 -0800 (PST) Received: from sendero.i-connect.net ([206.190.144.100]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id MAA26694 for ; Mon, 27 Jan 1997 12:54:56 -0800 (PST) Received: (qmail 9817 invoked by uid 1000); 25 Jan 1997 04:21:22 -0000 Message-ID: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Fri, 24 Jan 1997 20:12:49 -0800 (PST) Organization: iConnect Corp. From: Simon Shapiro To: hackers@freebsd.org Subject: 3.0-970118 Compile... Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Trying to compile said release... 1. Fails in gnu/lib/readline with: cc -fpic -DPIC -O -I/usr/src/gnu/lib/libreadline -I/usr/src/gnu/lib/libreadline/../../../contrib/libreadline -DHAVE_CONFIG_H -c /usr/src/gnu/lib/libreadline/tilde.c -o tilde.so building shared readline library (version 3.0) histfile.so: Definition of symbol `_write_history' (multiply defined) histfile.so: Definition of symbol `_append_history' (multiply defined) histfile.so: Definition of symbol `_read_history_range' (multiply defined) .... .... *** Error code 1 2. Fails in contrib/texinfo with: ===> libtxi cc -O -c /usr/src/gnu/usr.bin/texinfo/libtxi/../../../../contrib/texinfo/libtxi/getop t.c -o getopt.o cc -O -c /usr/src/gnu/usr.bin/texinfo/libtxi/../../../../contrib/texinfo/libtxi/getop t1.c -o getopt1.o building standard txi library ranlib libtxi.a ===> makeinfo cc -O -DSTDC_HEADERS=1 -DHAVE_UNISTD_H=1 -DHAVE_TERMIOS_H=1 -DHAVE_STRINGS_H=1 -DHAVE_STRING_H=1 -DHAVE_VARARGS_H=1 -DHAVE_SYS_ TIME_H=1 -DHAVE_SYS_FCNTL_H=1 -DHAVE_SYS_FILE_H=1 -DHAVE_ALLOCA=1 -DHAVE_SETVBUF=1 -DHAVE_GETCWD=1 -DHAVE_MEMSET=1 -DHAVE_BZERO =1 -DHAVE_STRCHR=1 -DHAVE_STRCASECMP=1 -DHAVE_VFPRINTF=1 -DHAVE_VSPRINTF=1 -DHAVE_STRERROR=1 -DHAVE_SIGPROCMASK=1 -DHAVE_SIGSET MASK=1 -I../libtxi -I/usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/libtxi -c /usr/src/gnu/usr.bin/texinfo /makeinfo/makeinfo.c cc -O -DSTDC_HEADERS=1 -DHAVE_UNISTD_H=1 -DHAVE_TERMIOS_H=1 -DHAVE_STRINGS_H=1 -DHAVE_STRING_H=1 -DHAVE_VARARGS_H=1 -DHAVE_SYS_ TIME_H=1 -DHAVE_SYS_FCNTL_H=1 -DHAVE_SYS_FILE_H=1 -DHAVE_ALLOCA=1 -DHAVE_SETVBUF=1 -DHAVE_GETCWD=1 -DHAVE_MEMSET=1 -DHAVE_BZERO =1 -DHAVE_STRCHR=1 -DHAVE_STRCASECMP=1 -DHAVE_VFPRINTF=1 -DHAVE_VSPRINTF=1 -DHAVE_STRERROR=1 -DHAVE_SIGPROCMASK=1 -DHAVE_SIGSET MASK=1 -I../libtxi -I/usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/libtxi -c /usr/src/gnu/usr.bin/texinfo /makeinfo/../../../../contrib/texinfo/makeinfo/multi.c cc -O -DSTDC_HEADERS=1 -DHAVE_UNISTD_H=1 -DHAVE_TERMIOS_H=1 -DHAVE_STRINGS_H=1 -DHAVE_STRING_H=1 -DHAVE_VARARGS_H=1 -DHAVE_SYS_ TIME_H=1 -DHAVE_SYS_FCNTL_H=1 -DHAVE_SYS_FILE_H=1 -DHAVE_ALLOCA=1 -DHAVE_SETVBUF=1 -DHAVE_GETCWD=1 -DHAVE_MEMSET=1 -DHAVE_BZERO =1 -DHAVE_STRCHR=1 -DHAVE_STRCASECMP=1 -DHAVE_VFPRINTF=1 -DHAVE_VSPRINTF=1 -DHAVE_STRERROR=1 -DHAVE_SIGPROCMASK=1 -DHAVE_SIGSET MASK=1 -I../libtxi -I/usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/libtxi -o makeinfo makeinfo.o multi.o -L../libtxi -ltxi multi.o: Undefined symbol `_multitable_active' referenced from text segment multi.o: Undefined symbol `_multitable_active' referenced from text segment multi.o: Undefined symbol `_multitable_active' referenced from text segment multi.o: Undefined symbol `_multitable_active' referenced from text segment multi.o: Undefined symbol `_multitable_active' referenced from text segment *** Error code 1 Stop. *** Error code 1 More to come... Question: How does one obtain a current, but compilable source tree? Reason of Asking: Attempt to be current with long range development... Thanx Again... Simon From owner-freebsd-hackers Mon Jan 27 17:28:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA04549 for hackers-outgoing; Mon, 27 Jan 1997 17:28:37 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA04520 for ; Mon, 27 Jan 1997 17:28:32 -0800 (PST) Received: from sendero.i-connect.net ([206.190.144.100]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id MAA26702 for ; Mon, 27 Jan 1997 12:55:08 -0800 (PST) Received: (qmail 9815 invoked by uid 1000); 25 Jan 1997 04:21:22 -0000 Message-ID: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Fri, 24 Jan 1997 19:18:56 -0800 (PST) Organization: iConnect Corp. From: Simon Shapiro To: hackers@freebsd.org Subject: 2.2-BETA Questions Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi Y'all; Some questions about 2.2-BETA 1. Does anyone care? Coming from (too much) Linux, and seeing 2.1.6, 2.2-BETa, 3.0... it is not a stupid question. 2. Assunming #1 is true, listen to this (Network Failure System; AKA NFS) scenario: * Linux NFS server, Debian 1.2, Kernel 2.0.27, etc. (nomis) with this in /etc/exports: /usr/src/FreeBSD sendero.i-connect.net(rw,no_root_squash) * FreeBSD 2.2-BETA client doing: # mkdir /NewStuff # mount -t nfs -o ro nomis;/usr/src/FreeBSD /NewStuff # ls -al /NewStuff ls: /NewStuff: Permission denied ls -al / .... drwxr-xr-x 2 root wheel 512 Jan 3 00:08 Linux-Transfers drwxr-xr-x 2 root wheel 512 Jan 23 18:01 NewRoot drwxrwxrwt 13 root sys 512 Jan 8 12:02 SourceControl [ /NewStuff is not there? ] It is, but... ? # umount /NewStuff umount: nomis:/usr/src/FreeBSD: No such file or directory # umount nomis:/usr/src/FreeBSD # ls -altotal 2 drwxr-xr-x 2 root wheel 512 Jan 5 02:36 . drwxr-xr-x 28 root wheel 1024 Jan 24 19:16 ../NewStuff Dunno about you but smells like a bug to me... BTW, works fine the other way around.... 3. Made a kernel with sound, etc... Worked fine until some days ago. Now, all of the sudden, without me doing anything (really :-): # xmcd -debug .... Lock file: /tmp/.cdaudio/lock.f02 Cannot open /dev/rcd0c: errno=6 Lock file: /tmp/.cdaudio/lock.f02 Cannot open /dev/rcd0c: errno=6 .... # ls -al /dev/rcd0c crw-r----- 1 root operator 15, 2 Jan 24 16:01 /dev/rcd0c # ls -al /usr/X11R6/bin/xmcd -rws--x--x 1 root bin 1490836 Dec 4 03:03 /usr/X11R6/bin/xmcd # rm /dev/rcd0c rm: /dev/rcd0c: Read-only file system # df /dev Filesystem 512-blocks Used Avail Capacity Mounted on fdesc 2 2 0 100% /dev # umount /dev # xmcd -debug .... Lock file: /tmp/.cdaudio/lock.f02 Cannot open /dev/rcd0c: errno=6 Lock file: /tmp/.cdaudio/lock.f02 Cannot open /dev/rcd0c: errno=6 .... What Gives? Yes, I tried MAKEDEV. Same difference. 4. Shutdown questions: a. When init goes to single user, prompts, asking for a shell. You press ENTER and it sits on ``(.???msg - Cannot exactly remember) not found'' ^C will get you a prompt, most of the time. Sometimes you get a fast roll talking about some malloc() failure. Sometimes a ^C will stop it, sometimes it will not. b. umount -a will leave things not in /etc/fstab mounted. It always leaves root mounted RW, only to fsck it at boot. Seems lie an unnecessary risk. 5. More CD fun. Once a music CD is played, you cannot mount a data cd because ``device is busy''. Reboot cures. 6. AHA-2940W with iomega Jaz connected; * If Jaz is not spinning, driver (?) complains about ``board did not respond'' or some such. If you reboot, you stand a good chance to crash the system. Workaround: Setup the AHA to include Jaz in BIOS scan, and to send the Jaz a Start Unit command. Also, do not daydream when booting so jaz is still spinning when aic7xxx.c looks for it. 7. trying /stand/sysinstall from a live system dumps core either on (the equivalent of) fdisk or disklabel. 8. Education Question: What is the logic in assigning slice ID's? I understand c to be the entire disk (why `c'? Why not?) Why does sysinstall assign 'e', 'f', but (almost) never 'd'? 9. Some safety checks in disklabel and newfs and/or kernel slice- partition handling could be nice. If you create an 'a' partition which is exactly an overlap of a 'c' in a slice that dominates the disk, newfs will FREEZE the system. Workaround: Make the 'a' partition 64 sectors smaller than the 'c', skipping that many sectors at the beginning. 10. Kernel Question: On an i386 PC, how does one make sure that another driver does not use the same ISA ports as you do? You are trying to be nice and NOT use something someone else is already using. There is a Linux thing to do that... 11. Another Kernel question: A device driver for a controller that is available in ISA, EISA and PCI. How do you split the code? We put the PCI part in pci, the ISA/EISA parts in i386/{isa,eisa}? But the code is NOT i386 dependant. We are putting it in dev/dpt. Is that a good choice? Thanx a million. Simon From owner-freebsd-hackers Mon Jan 27 17:32:22 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA05436 for hackers-outgoing; Mon, 27 Jan 1997 17:32:22 -0800 (PST) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA05425 for ; Mon, 27 Jan 1997 17:32:20 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.3/CET-v2.1) with SMTP id BAA04689; Tue, 28 Jan 1997 01:30:46 GMT Date: Tue, 28 Jan 1997 10:30:46 +0900 (JST) From: Michael Hancock To: Alan Cox cc: Julian Elischer , proff@suburbia.net, dg@root.com, hackers@freebsd.org, alan.cox@linux.org Subject: Re: SLAB stuff, and applications to current net code (fwd) In-Reply-To: <199701271008.KAA26279@snowcrash.cymru.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 27 Jan 1997, Alan Cox wrote: > Its pretty trivial to inspect the Linux and BSD code to see that almost all > objects are of the form > > > struct > { > most used field > regularly used field > buf[blah]; /* rarely accessed */ > } > [memory allocator slop - never used] > > In the end I pulled some messy tricks in Linux 2.0 to keep the cache a bit > saner by building sk_buff's (mbufs to the BSD world) with the buffer > structure at the tail of the object .. ie > > > ptr=malloc(size+struct+15) > struct=ptr-sizeof(struct) > round_down(ptr,16); > struct->data=ptr > > That combined with the fact most linux sk_buff's have the major headers on > the 2nd and 3rd cache line into the buffer gave me a performance improvement > I could benchmark. > > The right answer in current literature is undoubtedly a SLAB allocator and > that is where we are going at the moment. I wonder what would actually perform better in practice, struct member order hackery or a SLAB allocator with its processor cache coloring along with all it's overhead in maintaining a linked list of memory slabs with embedded object arrays and "in-band" free object lists. On the call side the abstraction sure is pretty with it's object constructor and destructor args. It seems that there are things to be gained and things that will be lost. This will be an interesting development to follow. Regards, Mike Hancock From owner-freebsd-hackers Mon Jan 27 17:32:39 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA05530 for hackers-outgoing; Mon, 27 Jan 1997 17:32:39 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA05508 for ; Mon, 27 Jan 1997 17:32:33 -0800 (PST) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id LAA26035 for ; Mon, 27 Jan 1997 11:34:34 -0800 (PST) Received: from misery.sdf.com [204.244.213.33] by misery.sdf.com with smtp (Exim 1.59 #1) id 0vop4l-00031u-00; Mon, 27 Jan 1997 03:18:11 -0800 Date: Mon, 27 Jan 1997 03:18:10 -0800 (PST) From: Tom Samplonius To: Hal Snyder cc: hackers@freebsd.org Subject: Re: directory conventions In-Reply-To: <32ECFBE9.10E8@vailsys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 27 Jan 1997, Hal Snyder wrote: > I just got the following from Blair Zajac, who is working on the next > release of amanda: > > > I'm working on Amanda 2.3.0.4 right this minute. It's got a lot of > > patches included in it, but probably the biggest deal is that it now > > uses automake and autoconf to build the sources. > ... > > Finally, since I've been converting this to automake, GNU has some standard > > places where it likes to shove things. Right now Amanda 2.3.0.4 uses the > > following distribution: > > > > $prefix/bin Amanda server side programs > > $prefix/libexec Amanda backup client programs > > $prefix/share/amanda Runtime configuration files > > $prefix/share/amanda-index Directory for index of dumps > > $prefix/var/amanda Directory for database & log files > > > > I figure that the configuration files and the indexing files can go under > > share, since they are in a format that all OS'es can understand. However, > > the log files and the database (curinfo) files may be OS dependent and should > > go into another directory, say var. This is all customizable using the > > options that configure provides to change the locations of where stuff gets > > installed. Does anybody have any good ideas or comments on this? > > Prefix for BSD's is /usr/local. > > My guess is that config files should go to /usr/local/etc. > > What is the diff in purpose between /usr/local/libexec and > /usr/local/bin? libexec is for executables that are generally executed by other programs (ie. backends). It normaly doesn't make any sense to exec program here directly, and libexec is never in the stanard PATH. > What is /usr/local/share for? Portable bits, as Blair suggests? Arch independant ASCII files, normally. > And what of /usr/local/var? /var has always been "local". You you should probably "man hier" Tom From owner-freebsd-hackers Mon Jan 27 17:50:31 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA06908 for hackers-outgoing; Mon, 27 Jan 1997 17:50:31 -0800 (PST) Received: from panda.hilink.com.au (panda.hilink.com.au [203.2.144.5]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA06897 for ; Mon, 27 Jan 1997 17:50:10 -0800 (PST) Received: (from danny@localhost) by panda.hilink.com.au (8.7.6/8.7.3) id MAA05913; Tue, 28 Jan 1997 12:55:00 +1100 (EST) Date: Tue, 28 Jan 1997 12:54:59 +1100 (EST) From: "Daniel O'Callaghan" To: Brian Somers cc: fredriks@mcs.com, hackers@freebsd.org Subject: Re: Modifications to pppd to make it log connecton times In-Reply-To: <199701280101.BAA19092@awfulhak.demon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 28 Jan 1997, Brian Somers wrote: > > Hi, > > Here are context diffs to pppd that makes pppd log the total > > time in minutes that it has been connected(similar to what ppp does). > > I don't know if I have caught every way pppd can exit(it obviously > > doesn't do this if it dumps core or the machine panics) to make sure > > the data is printed out, but it does work for the normal cases for sure. > [.....] I did this using an external program. The user's login shell is a Bourne shell script with a 'checkin' facility, run before execing pppd. Getty is run from a script which has a 'checkout' facility. That way, whenever pppd exits, and getty is run, the user on that tty is checked out. Danny From owner-freebsd-hackers Mon Jan 27 18:42:30 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA10104 for hackers-outgoing; Mon, 27 Jan 1997 18:42:30 -0800 (PST) Received: from w2xo.pgh.pa.us (w2xo.pgh.pa.us [206.210.70.5]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA10099 for ; Mon, 27 Jan 1997 18:42:27 -0800 (PST) Received: from w2xo.pgh.pa.us (localhost [127.0.0.1]) by w2xo.pgh.pa.us (8.8.4/8.8.4) with SMTP id VAA22721; Mon, 27 Jan 1997 21:42:41 -0500 (EST) Message-ID: <32ED67A1.446B9B3D@w2xo.pgh.pa.us> Date: Mon, 27 Jan 1997 21:42:41 -0500 From: Jim Durham Organization: Dis- X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.1.6-RELEASE i386) MIME-Version: 1.0 To: "A. Radovanovic" CC: hackers@freebsd.org Subject: Re: Help - can't login References: <9701261744.AA27426@risc6.unisa.ac.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk A. Radovanovic wrote: > > My freebsd ran out of disk space in /. Unfortunately I rebooted the > system and now I can't get in - no username or password are accepted. > If I boot in a single user mode, the file system is mounted as a read > only and I can't do anything with the passwd file. > > Is there any way to get in and repair the damage? > Wow..finally a question I can answer! I too have done this deed... You need to mount your root partion with "/". This will make the file system read/write. As in, "mount /dev/wd0a / " . regards, Jim Durham From owner-freebsd-hackers Mon Jan 27 19:16:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA12525 for hackers-outgoing; Mon, 27 Jan 1997 19:16:51 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA12519 for ; Mon, 27 Jan 1997 19:16:48 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id NAA06348; Tue, 28 Jan 1997 13:46:24 +1030 (CST) From: Michael Smith Message-Id: <199701280316.NAA06348@genesis.atrad.adelaide.edu.au> Subject: Re: 2.2-BETA Questions In-Reply-To: from Simon Shapiro at "Jan 24, 97 07:18:56 pm" To: Shimon@i-Connect.Net (Simon Shapiro) Date: Tue, 28 Jan 1997 13:46:23 +1030 (CST) Cc: 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Simon Shapiro stands accused of saying: > Some questions about 2.2-BETA > > 1. Does anyone care? Coming from (too much) Linux, and seeing 2.1.6, > 2.2-BETa, 3.0... it is not a stupid question. Er, yes. Lots of people care. 2.2-BETA is the leadup to 2.2-RELEASE, the next production-level version. 3.0 is the current 'development' version, which will lead to a release probably sometime late this year. Exposing the devlopment process like this means that everyone can see where things are going. > 2. Assunming #1 is true, listen to this (Network Failure System; AKA NFS) > scenario: > > * Linux NFS server, Debian 1.2, Kernel 2.0.27, etc. (nomis) with this > in /etc/exports: > > /usr/src/FreeBSD sendero.i-connect.net(rw,no_root_squash) > > * FreeBSD 2.2-BETA client doing: > > # mkdir /NewStuff > # mount -t nfs -o ro nomis;/usr/src/FreeBSD /NewStuff > # ls -al /NewStuff > ls: /NewStuff: Permission denied What are the permissions on "NewStuff" on the server? Try "ls" without any other flags first. > Dunno about you but smells like a bug to me... It looks to me like the server is being _very_ weird. Someone else (Doug R.?) might have a better idea about that. > 3. Made a kernel with sound, etc... Worked fine until some days ago. > Now, all of the sudden, without me doing anything (really :-): > > # xmcd -debug > .... > Lock file: /tmp/.cdaudio/lock.f02 > Cannot open /dev/rcd0c: errno=6 Is there a CD in the drive? 6 is "not configured", which xmcd should be telling you. A list of the boot-time probe messages (output of 'dmesg') would be handy here, as I suspect that your CD wasn't found. > 4. Shutdown questions: > > a. When init goes to single user, prompts, asking for a shell. > You press ENTER and it sits on ``(.???msg - Cannot exactly > remember) not found'' > ^C will get you a prompt, most of the time. Sometimes you get > a fast roll talking about some malloc() failure. Sometimes a > ^C will stop it, sometimes it will not. Er "init goes to single user"? How are you shutting down? > b. umount -a will leave things not in /etc/fstab mounted. > It always leaves root mounted RW, only to fsck it at boot. > Seems lie an unnecessary risk. You're _definitely_ not shutting down correctly. 'man shutdown'. > 5. More CD fun. Once a music CD is played, you cannot mount a data > cd because ``device is busy''. Reboot cures. Try exiting the CD-playing program first, if you aren't already. > 8. Education Question: What is the logic in assigning slice ID's? > I understand c to be the entire disk > (why `c'? Why not?) > Why does sysinstall assign 'e', 'f', > but (almost) never 'd'? You mean partition names. Tradition, mostly. 'a' is traditionally used for a root filesystem, 'b' for swap, 'c' for the whole disk, and d-h for 'other' partitions. For a while, 'd' was used by various 386 BSD's to deal with the disparity between "the whole disk" and "the whole part of the disk that BSD uses"; this is obsoleted by the 'slice' paradigm. > 9. Some safety checks in disklabel and newfs and/or kernel slice- > partition handling could be nice. If you create an 'a' partition > which is exactly an overlap of a 'c' in a slice that dominates > the disk, newfs will FREEZE the system. Novel. I've never seen that, and I've done it many times. > 10. Kernel Question: On an i386 PC, how does one make sure that > another driver does not use the same ISA ports as you do? > You are trying to be nice and NOT use something someone else is > already using. There is a Linux thing to do that... ISA resource allocation is a particularly noisome can of worms. Currently, if your driver is configured with a base address in a region previously claimed by another driver, your probe routine won't be called. That can obviously cause problems if you plan to probe several possible port ranges in a single probe routine. If you have any particular ideas or requests here, please raise them, as we're always open to suggestions on cleaning this up. > 11. Another Kernel question: A device driver for a controller that > is available in ISA, EISA and PCI. How do you split the code? > We put the PCI part in pci, the ISA/EISA parts in i386/{isa,eisa}? > But the code is NOT i386 dependant. We are putting it in dev/dpt. > Is that a good choice? Perhaps: - have three seperate drivers (bad idea). - look at the 'ahc' and 'bt' drivers; the former is pci/eisa, the latter is pci/isa. The 'ahc' driver also has code in dev/. > Simon -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Mon Jan 27 19:19:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA12693 for hackers-outgoing; Mon, 27 Jan 1997 19:19:47 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA12680 for ; Mon, 27 Jan 1997 19:19:43 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id NAA06367; Tue, 28 Jan 1997 13:49:15 +1030 (CST) From: Michael Smith Message-Id: <199701280319.NAA06367@genesis.atrad.adelaide.edu.au> Subject: Re: Help - can't login In-Reply-To: <32ED67A1.446B9B3D@w2xo.pgh.pa.us> from Jim Durham at "Jan 27, 97 09:42:41 pm" To: durham@w2xo.pgh.pa.us (Jim Durham) Date: Tue, 28 Jan 1997 13:49:14 +1030 (CST) Cc: radova@risc6.unisa.ac.za, 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk First : this should have gone to -questions, not -hackers. Jim Durham stands accused of saying: > A. Radovanovic wrote: > > > > My freebsd ran out of disk space in /. Unfortunately I rebooted the > > system and now I can't get in - no username or password are accepted. > > If I boot in a single user mode, the file system is mounted as a read > > only and I can't do anything with the passwd file. Don't "do anything with the passwd file". FreeBSD uses a dabase-based shadow password system, and changing /etc/passwd won't do you any good at all. > > Is there any way to get in and repair the damage? > > > Wow..finally a question I can answer! I too have done this deed... > > You need to mount your root partion with "/". This will make the > file system read/write. As in, "mount /dev/wd0a / " . It's easier to say 'mount /' actually. Then you'll want 'mount /usr', and then 'passwd' to change root's password. This should be (is probably) in the FAQ. > Jim Durham -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Mon Jan 27 19:31:21 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA13458 for hackers-outgoing; Mon, 27 Jan 1997 19:31:21 -0800 (PST) Received: from sendero.i-connect.net ([206.190.144.100]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id TAA13442 for ; Mon, 27 Jan 1997 19:31:17 -0800 (PST) Received: (qmail 7563 invoked by uid 1000); 28 Jan 1997 04:30:21 -0000 Message-ID: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199701272244.PAA15452@seagull.rtd.com> Date: Mon, 27 Jan 1997 20:21:06 -0800 (PST) Organization: iConnect Corp. From: Simon Shapiro To: Don Yuniskis Subject: Re: suggestion for kernel printk() ? Cc: bde@zeta.org.au, freebsd-hackers@freefall.freebsd.org Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Don Yuniskis; On 27-Jan-97 you wrote: > It seems that Simon Shapiro said: > > > > > I just spent some time fighting a kernel that died miserably > > > > >on boot :-( I was inundated with an endless stream of kernel > > > > >messages (in highlighted text) followed promptly by a hard reset. > > > > >It was quite frustrating to find that there doesn't seem to be a > > > > >mechanism to pause the display at this point! > > > > > > However, is it worthwhile for the mechanism that printk() ?? uses to > > > observe some kind of flow control? It did not recognize scroll_lock, > > > pause, ^S, etc. This would have at least enabled me to read some > > > (i.e. one screen full) of the messages to see what the kernel was > > > complaining about. > > > > I may be offbase here, but scroll-lock, etc. are INPUT, while printk is > > Yes. But all of those mechanisms tie in to provide flow control for > regular console output functions. Apparently, however, this happens > at a higher level than I had hoped/assumed (i.e. more stuff has to be > functional before this mechanism works). Unfortunately, this makes some sense, as there are no interrupts during some of this. I solved this porblems on a SVR4.2 port by providing the UART witha polled mode. Added a walloping 20 lines of code to the driver. What that means in a PC console I really do not know. Real computers should have only serial consoles. Preferebly an LA34. Right? :-) > > > output. No? Maybe a (oops :-) SysV-like mechanism where print{kf} go to > > a circular buffer andanother mechanism dumps it to ``the console''. > > If you like ugly, (if memory serves), you can either pass an additional arg > > to the output routine (A la Linux) or designate the first character in the > > string to tell what to do, as in ~==console and buffer, !=bufferonly, etc. > > I was suggesting having printk() examine the keyboard buffer for a pending > "pause" key and blocking in this event. However, it appears that the > system couldn't handle that crude of an implementation... > > --don I am so new to FreeBSD that I did not even see that there is a printk(). How does that relate to printf() is see everywhere? Simon From owner-freebsd-hackers Mon Jan 27 19:32:36 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA13608 for hackers-outgoing; Mon, 27 Jan 1997 19:32:36 -0800 (PST) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA13531 for ; Mon, 27 Jan 1997 19:32:10 -0800 (PST) Message-Id: <199701280332.TAA13531@freefall.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA164182291; Tue, 28 Jan 1997 14:31:31 +1100 From: Darren Reed Subject: Re: Network interfaces: removal of. To: julian@whistle.com (Julian Elischer) Date: Tue, 28 Jan 1997 14:31:31 +1100 (EDT) Cc: hackers@freebsd.org In-Reply-To: <32ED4558.446B9B3D@whistle.com> from "Julian Elischer" at Jan 27, 97 04:16:24 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In some mail from Julian Elischer, sie said: > > I have a system with frame relay interfaces, and virtual circuits > are reflected by virtual 'interfaces' e.g vc0, vc2 > etc. > > the trouble is that there is no support in the kernel for REMOVING > an interface! > > does anyone have any ideas on this? Hmmm, I once modified the "if_vsr" LKM to be unloadable as an exercise on SunOS4...but even then... > removal of an interface requires that the interface addresses > be freed. this in turn requires that any routes that access that > ifa (e.g in a TCP pcb) discover that it is invalid the next time they > try use it, and try get a new rtentry/ifa. Yup. I did all that myself. Worst part is that it needs to be splimp(). > None of this happens at the moment. > > Add to that the fact that the linked list of interfaces has no support > for removing entries, and that the interface array has no support for > re-using entries. Unless it is all done manually. > The reference counting on rtentries and IFAs is next to useless > as so many places don't use them rigorously, which requires > hacks to keep them allingned with anything even close to reality.. Don't bother. > Is there anyone in the group who feels as though they understand the > situation well enough to work with me in trying to clean this up a bit? There's a few tips, but I worked under a much narrower operational conditions (i.e. I could make sure all the programs using the vif were dead, etc, before I unloaded). There may be a version of that or a more hacked version of it that works better somewhere on the 'net. Darren From owner-freebsd-hackers Mon Jan 27 20:02:35 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA15252 for hackers-outgoing; Mon, 27 Jan 1997 20:02:35 -0800 (PST) Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA15243 for ; Mon, 27 Jan 1997 20:02:28 -0800 (PST) Received: from localhost.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.8.3/8.7.3) with SMTP id XAA03991; Mon, 27 Jan 1997 23:02:20 -0500 (EST) Message-Id: <199701280402.XAA03991@whizzo.transsys.com> X-Mailer: exmh version 2.0alpha 12/3/96 To: Julian Elischer cc: hackers@freebsd.org From: "Louis A. Mamakos" Subject: Re: Network interfaces: removal of. References: <32ED4558.446B9B3D@whistle.com> In-reply-to: Your message of "Mon, 27 Jan 1997 16:16:24 PST." <32ED4558.446B9B3D@whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 27 Jan 1997 23:02:20 -0500 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > does anyone have any ideas on this? One idea: add a new message for the routing socket which can notify routing daemons that you want to delete an interface (or, like it or not, it's gone now). Hopefully they can then arrange to have active references to the interface be removed. I recall another system which had a the ability to "delete" a network interface. What it really did was cheat: it essentially overwrote the interface name, and shoved the data structure off into a corner. It was still around, though, so that if there was some errant reference to it, nothing "bad" would happen. Clearly, this is just a hack. However, it seems to work "well enough", so from a pragmatic perspective, you can't dismiss it completely. While I'm sure that the modules that reference interfaces are finite, there's nothing to allocate references to them. This would require a level of discipline unknown to the BSD net code. Hell, you might just as well wish for locks on the data structures to make the code SMP safe :-) louie From owner-freebsd-hackers Mon Jan 27 20:58:03 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA17727 for hackers-outgoing; Mon, 27 Jan 1997 20:58:03 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA17721 for ; Mon, 27 Jan 1997 20:58:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id UAA13857; Mon, 27 Jan 1997 20:57:43 -0800 (PST) Message-Id: <199701280457.UAA13857@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Lars Jonas Olsson cc: hackers@freebsd.org Subject: Re: de0 timeouts w 486 CPU In-reply-to: Your message of "Mon, 27 Jan 1997 15:34:19 CST." <199701272134.PAA10766@Venus.mcs.net> From: David Greenman Reply-To: dg@root.com Date: Mon, 27 Jan 1997 20:57:43 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >I have a 486DX4-100 system that is doing make worlds fine, but >generates a lot of: > >de0: system error: master abort > >messages with a current kernel. With a 2.1R kernel it was >generating illegal interrupt errors for de0. > Any guess if this is bug in the if_de.c driver or a hardware problem? >The rate of messages is 5-30/hour on a system not doing much >networking. I would guess that it's a PCI DMA problem on the motherboard. There were quite a few 486 PCI machines that had really bad PCI performance (perhaps due to incorrect chipset configuration?). You may wish to look for any BIOS settings related to PCI write buffer, etc.. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Mon Jan 27 21:09:56 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA18409 for hackers-outgoing; Mon, 27 Jan 1997 21:09:56 -0800 (PST) Received: from vdp01.vailsystems.com (root@vdp01.vailsystems.com [207.152.98.18]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA18402 for ; Mon, 27 Jan 1997 21:09:46 -0800 (PST) Received: from crocodile.vale.com (crocodile [204.117.217.147]) by vdp01.vailsystems.com (8.8.3/8.7.3) with ESMTP id XAA01957 for ; Mon, 27 Jan 1997 23:09:38 -0600 (CST) Received: (from driley@localhost) by crocodile.vale.com (8.8.3/8.7.3) id XAA24269; Mon, 27 Jan 1997 23:09:38 -0600 (CST) Date: Mon, 27 Jan 1997 23:09:38 -0600 (CST) From: Dan Riley To: freebsd-hackers@freefall.freebsd.org Subject: Re: suggestion for kernel printk() ? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I think this question may be slightly related to this topic or maybe not, but in any event, after compiling a new kernel (based on a cp of LINT) I never not get any output to the screen while booting the new kernel. What option in LINT disables the boot messages from the kernel so that the first thing(only thing) you see is the login prompt after a restart? The messages are ther once I login and dmesg or check messages... This never seems to happen when I start with a kernel based on the GENERIC example. Thanks On Mon, 27 Jan 1997, Simon Shapiro wrote: > > Hi Don Yuniskis; On 25-Jan-97 you wrote: > > It seems that Bruce Evans said: > > > > > > > I just spent some time fighting a kernel that died miserably > > > >on boot :-( I was inundated with an endless stream of kernel > > > >messages (in highlighted text) followed promptly by a hard reset. > > > >It was quite frustrating to find that there doesn't seem to be a > > > >mechanism to pause the display at this point! > > > > > > I use a serial console and `terminalprogram | tee foo' to capture > > > the output. > > > > Yes, but I would have had to have built the kernel with COMCONSOLE > > (which I didn't). > > > > > > OK, reboot from /kernel.old and look through the logs. Hmmm... > > > >nothing here! Probably the filesystem wasn't even functional when > > > >the boot ran into trouble. > > > > > > Boot messages are supposed to be preserved in the message buffer > > > across reboots. However, many PC BIOSes and/or memory systems do > > > something that invalidates the message buffer even for a soft reboot. > > > > Well, I wasn't observant enough to notice what type of restart the > > PC went through (two different varieties here -- one of which actually > > rampages through memory, etc.) but suspect this is the problem. > > > > However, is it worthwhile for the mechanism that printk() ?? uses to > > observe some kind of flow control? It did not recognize scroll_lock, > > pause, ^S, etc. This would have at least enabled me to read some > > (i.e. one screen full) of the messages to see what the kernel was > > complaining about. > > I may be offbase here, but scroll-lock, etc. are INPUT, while printk is > output. No? Maybe a (oops :-) SysV-like mechanism where print{kf} go to > a circular buffer andanother mechanism dumps it to ``the console''. > If you like ugly, (if memory serves), you can either pass an additional arg > to the output routine (A la Linux) or designate the first character in the > string to tell what to do, as in ~==console and buffer, !=bufferonly, etc. > > Simon > From owner-freebsd-hackers Mon Jan 27 21:34:58 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA19501 for hackers-outgoing; Mon, 27 Jan 1997 21:34:58 -0800 (PST) Received: from monk.via.net (monk.via.net [140.174.204.10]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id VAA19495 for ; Mon, 27 Jan 1997 21:34:56 -0800 (PST) Received: (from joe@localhost) by monk.via.net (8.6.11/8.6.12) id VAA23113 for hackers@freebsd.org; Mon, 27 Jan 1997 21:27:19 -0800 Date: Mon, 27 Jan 1997 21:27:19 -0800 From: Joe McGuckin Message-Id: <199701280527.VAA23113@monk.via.net> To: hackers@freebsd.org Subject: Ethernet bug - 2.1.6-RELEASE X-Sun-Charset: US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've noticed that if I disconnect the ethernet cable from my de0 NIC, I no longer see the warning message about the cable being unplugged. Also, when I plug it back in, I no longer see the message about the UTP cable being plugged in. Also, once disconnected, the ethernet port no longer works and the machine must be rebooted to restore functionality. joe From owner-freebsd-hackers Mon Jan 27 22:58:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA24416 for hackers-outgoing; Mon, 27 Jan 1997 22:58:49 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA24403 for ; Mon, 27 Jan 1997 22:58:43 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id RAA13038; Tue, 28 Jan 1997 17:52:44 +1100 Date: Tue, 28 Jan 1997 17:52:44 +1100 From: Bruce Evans Message-Id: <199701280652.RAA13038@godzilla.zeta.org.au> To: dgy@rtd.com, Shimon@i-Connect.Net Subject: Re: suggestion for kernel printk() ? Cc: bde@zeta.org.au, freebsd-hackers@freefall.freebsd.org Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> Yes. But all of those mechanisms tie in to provide flow control for >> regular console output functions. Apparently, however, this happens >> at a higher level than I had hoped/assumed (i.e. more stuff has to be >> functional before this mechanism works). > >Unfortunately, this makes some sense, as there are no interrupts during >some of this. I solved this porblems on a SVR4.2 port by providing the >UART witha polled mode. Added a walloping 20 lines of code to the driver. >What that means in a PC console I really do not know. Real computers >should have only serial consoles. Preferebly an LA34. Right? :-) It takes 200 lines in sio.c.. >> > output. No? Maybe a (oops :-) SysV-like mechanism where print{kf} go >to >> > a circular buffer andanother mechanism dumps it to ``the console''. >> > If you like ugly, (if memory serves), you can either pass an additional >arg >> > to the output routine (A la Linux) or designate the first character in >the >> > string to tell what to do, as in ~==console and buffer, !=bufferonly, >etc. In BSD, printf output goes to the message buffer and the console. The syscons driver also duplicates it in the scrollback buffer. The problem is getting at this output. Scrollback doesn't work at the panic prompt. I think it was broken when syscons started using timeouts for screen updates. >> I was suggesting having printk() examine the keyboard buffer for a pending > >I am so new to FreeBSD that I did not even see that there is a printk(). >How does that relate to printf() is see everywhere? printk() doesn't exist. There is also uprintf() for printing to the controlling tty of the current process, tprintf() for printing to the controlling terminal of the specified session, ttyprintf() for printing to the specified terminal, and log() which prints to the console if the log device is not open. printf() and log() are supposed to work in interrupt handlers so they normally have to use polled output. The others are higher level. Bruce From owner-freebsd-hackers Mon Jan 27 23:15:26 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA25161 for hackers-outgoing; Mon, 27 Jan 1997 23:15:26 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA25150 for ; Mon, 27 Jan 1997 23:15:24 -0800 (PST) Received: from ghpc6.ihf.rwth-aachen.de (ghpc6.ihf.RWTH-Aachen.DE [134.130.90.6]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id XAA29001 for ; Mon, 27 Jan 1997 23:15:22 -0800 (PST) Received: (from thomas@localhost) by ghpc6.ihf.rwth-aachen.de (8.6.12/8.6.9) id IAA03145; Tue, 28 Jan 1997 08:13:51 +0100 From: Thomas Gellekum Message-Id: <199701280713.IAA03145@ghpc6.ihf.rwth-aachen.de> Subject: Re: 2.2-BETA Questions To: Shimon@i-Connect.Net (Simon Shapiro) Date: Tue, 28 Jan 1997 08:13:50 +0100 (MET) Cc: hackers@FreeBSD.ORG In-Reply-To: from Simon Shapiro at "Jan 24, 97 07:18:56 pm" Organization: Institut f. Hochfrequenztechnik, RWTH Aachen X-Mailer: ELM [version 2.4ME+ PL11 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Simon Shapiro wrote: > 2. Assunming #1 is true, listen to this (Network Failure System; AKA NFS) > scenario: > > * Linux NFS server, Debian 1.2, Kernel 2.0.27, etc. (nomis) with this > in /etc/exports: > > /usr/src/FreeBSD sendero.i-connect.net(rw,no_root_squash) > > * FreeBSD 2.2-BETA client doing: > > # mkdir /NewStuff > # mount -t nfs -o ro nomis;/usr/src/FreeBSD /NewStuff Should be # mount -t nfs -o ro,resvport nomis:/usr/src/FreeBSD /NewStuff tg From owner-freebsd-hackers Mon Jan 27 23:36:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA26848 for hackers-outgoing; Mon, 27 Jan 1997 23:36:37 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA26839 for ; Mon, 27 Jan 1997 23:36:32 -0800 (PST) From: proff@suburbia.net Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with SMTP id XAA02691 for ; Mon, 27 Jan 1997 23:37:42 -0800 (PST) Received: (qmail 11240 invoked by uid 110); 28 Jan 1997 07:36:04 -0000 Message-ID: <19970128073604.11239.qmail@suburbia.net> Subject: Re: gomoku In-Reply-To: from J Wunsch at "Jan 27, 97 09:44:13 pm" To: joerg_wunsch@uriah.heep.sax.de Date: Tue, 28 Jan 1997 18:36:03 +1100 (EST) Cc: 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > As Julian Assange wrote: > > > Is there any reason that gomoku from Lite2 is missing from > > /usr/src/games? > > Yes: nobody ever did start a full userland Lite2 merge (not even a > vendor-branch import, but that's already a large part of the work to > be done). > > -- > 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. ;-) > I've almost finished my lite2 libc merge. The most interesting addition so far is union extensions for readdir(). Would any of the doc people like to volunteer for merging the man pages? Cheers, Julian From owner-freebsd-hackers Mon Jan 27 23:42:20 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA27577 for hackers-outgoing; Mon, 27 Jan 1997 23:42:20 -0800 (PST) Received: from sendero.i-connect.net ([206.190.144.100]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id XAA27562 for ; Mon, 27 Jan 1997 23:42:15 -0800 (PST) Received: (qmail 25535 invoked by uid 1000); 28 Jan 1997 08:41:29 -0000 Message-ID: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199701280316.NAA06348@genesis.atrad.adelaide.edu.au> Date: Tue, 28 Jan 1997 00:00:34 -0800 (PST) Organization: iConnect Corp. From: Simon Shapiro To: Michael Smith Subject: Re: 2.2-BETA Questions Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi Michael Smith; On 28-Jan-97 you wrote: > > 1. Does anyone care? Coming from (too much) Linux, and seeing 2.1.6, > > 2.2-BETa, 3.0... it is not a stupid question. > > Er, yes. Lots of people care. 2.2-BETA is the leadup to 2.2-RELEASE, > the next production-level version. 3.0 is the current 'development' > version, which will lead to a release probably sometime late this > year. Exposing the devlopment process like this means that everyone > can see where things are going. Good. Coming from another freely distributed ``O/S'' over the last couple of years, I am used to bi-weekly versions, etc. This is why I asked. > > # mkdir /NewStuff > > # mount -t nfs -o ro nomis;/usr/src/FreeBSD /NewStuff > > # ls -al /NewStuff > > ls: /NewStuff: Permission denied > > What are the permissions on "NewStuff" on the server? Try "ls" without > any other flags first. Permissions matter not. Can be 777, 1777 755, ... The mount point simply disappears. > It looks to me like the server is being _very_ weird. Someone else > (Doug R.?) might have a better idea about that. Yea, I figured this much, but the Linux ``gurus'' insist, theirs is the only ``correct'' NFS server... As I said, it works (very well!) the other way around... > > > 3. Made a kernel with sound, etc... Worked fine until some days ago. > > Now, all of the sudden, without me doing anything (really :-): > > > > # xmcd -debug > > .... > > Lock file: /tmp/.cdaudio/lock.f02 > > Cannot open /dev/rcd0c: errno=6 > > Is there a CD in the drive? 6 is "not configured", which xmcd should be > telling you. A list of the boot-time probe messages (output of 'dmesg') > would be handy here, as I suspect that your CD wasn't found. Yup. So much so that sysinstall tells me it is not a current installation CD! (Yes, it IS music, not iso9660 - Kitaro ``Ten Years''). Actually, the problem may arise because there was a GNU distribution CD in the drive at boot time. Works for data, does not for music, until the next boot. Ugly. Just checked. I can mount an is09660 CD with no problem (even a Linux one :-), but all the CD music tools I found cannot open /dev/rcd0c crw------- 1 root wheel 15, 536870912 Jan 24 16:01/dev/rcd0.ctl crw-r----- 1 root operator 15, 0 Jan 24 16:01 /dev/rcd0a crw-r----- 1 root operator 15, 2 Jan 24 16:01 /dev/rcd0c crw-r----- 1 root operator 15, 3 Sep 15 18:16 /dev/rcd0d What is the kernel config option for CD audio support? > > > 4. Shutdown questions: > > > > a. When init goes to single user, prompts, asking for a shell. > > You press ENTER and it sits on ``(.???msg - Cannot exactly > > remember) not found'' > > ^C will get you a prompt, most of the time. Sometimes you get > > a fast roll talking about some malloc() failure. Sometimes a > > ^C will stop it, sometimes it will not. > > Er "init goes to single user"? How are you shutting down? # shutdown now > > > b. umount -a will leave things not in /etc/fstab mounted. > > It always leaves root mounted RW, only to fsck it at boot. > > Seems lie an unnecessary risk. > > You're _definitely_ not shutting down correctly. 'man shutdown'. Thanx. But ``shutdown now'' is a valid option, generates no complaints and gives the results indicated. > > 5. More CD fun. Once a music CD is played, you cannot mount a data > > cd because ``device is busy''. Reboot cures. > > Try exiting the CD-playing program first, if you aren't already. Yup. Done that, been there. To no avail. Something IS wron. > > 8. Education Question: What is the logic in assigning slice ID's? > > I understand c to be the entire disk > > (why `c'? Why not?) > > Why does sysinstall assign 'e', 'f', > > but (almost) never 'd'? > > You mean partition names. Tradition, mostly. 'a' is traditionally > used for a root filesystem, 'b' for swap, 'c' for the whole disk, and > d-h for 'other' partitions. For a while, 'd' was used by various > 386 BSD's to deal with the disparity between "the whole disk" and > "the whole part of the disk that BSD uses"; this is obsoleted by > the 'slice' paradigm. Thanx! now I know. > > 9. Some safety checks in disklabel and newfs and/or kernel slice- > > partition handling could be nice. If you create an 'a' partition > > which is exactly an overlap of a 'c' in a slice that dominates > > the disk, newfs will FREEZE the system. > > Novel. I've never seen that, and I've done it many times. I checked some more. It has to do with the manner in which disklabel is called. If you have it use /etc/disktab, all is well. The -e is only safe if you initialized with the (-rwB?) /etc/disktab option. > > 10. Kernel Question: On an i386 PC, how does one make sure that > > another driver does not use the same ISA ports as you do? > > You are trying to be nice and NOT use something someone else is > > already using. There is a Linux thing to do that... > > ISA resource allocation is a particularly noisome can of worms. > Currently, if your driver is configured with a base address in a > region previously claimed by another driver, your probe routine won't > be called. That can obviously cause problems if you plan to probe > several possible port ranges in a single probe routine. Perfect! Linux drivers seem to explicitly call some routine that registers the addresses. I like hte BSD solution better. > If you have any particular ideas or requests here, please raise them, > as we're always open to suggestions on cleaning this up. A blow torch and a stick of dynamite :-) Reason for asking is a PCI controller that can be configured (via BIOS) to ``sit'' in ISA adress range. The Linux driver probes to see that it does not (essentially) overlap with an IDE controller which it can emulate... > > 11. Another Kernel question: A device driver for a controller that > > is available in ISA, EISA and PCI. How do you split the code? > > We put the PCI part in pci, the ISA/EISA parts in i386/{isa,eisa}? > > But the code is NOT i386 dependant. We are putting it in dev/dpt. > > Is that a good choice? > > Perhaps: > - have three seperate drivers (bad idea). > - look at the 'ahc' and 'bt' drivers; the former is pci/eisa, the latter > is pci/isa. The 'ahc' driver also has code in dev/. Yes, but pieces still sit in i386. We will avoid that. Thanx! Simon From owner-freebsd-hackers Tue Jan 28 00:21:11 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA00112 for hackers-outgoing; Tue, 28 Jan 1997 00:21:11 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id AAA00107 for ; Tue, 28 Jan 1997 00:21:05 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA25648 for freebsd-hackers@freebsd.org; Tue, 28 Jan 1997 09:21:03 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id JAA15436; Tue, 28 Jan 1997 09:04:40 +0100 (MET) Message-ID: Date: Tue, 28 Jan 1997 09:04:40 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@freebsd.org Subject: Re: fdisk headache References: X-Mailer: Mutt 0.55-PL10 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 Simon Shapiro on Jan 27, 1997 14:27:12 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Simon Shapiro wrote: > > Why are you using fdisk at all? You are running Unix, you aren't > > running on a PC, you are not supposed to use fdisk (unless other > > systems on your disk force you to this step). > > Slow down.... The gentleman has a valid point, methinks. If not, ...well, and you've cut my smiley. ;-) > please show me how to build 120 filesystems on a disk that is 750GB > large. Impossible/stupid numbers? not really when considering a large > disk array with a very large database. _You_ have a valid point with this, but Jean-Marc didn't -- he wants to use a plain 4-partition only system. -- 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 Jan 28 00:43:58 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA01137 for hackers-outgoing; Tue, 28 Jan 1997 00:43:58 -0800 (PST) Received: from ghpc6.ihf.rwth-aachen.de (ghpc6.ihf.RWTH-Aachen.DE [134.130.90.6]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id AAA01130 for ; Tue, 28 Jan 1997 00:43:55 -0800 (PST) Received: (from thomas@localhost) by ghpc6.ihf.rwth-aachen.de (8.6.12/8.6.9) id JAA03366; Tue, 28 Jan 1997 09:43:40 +0100 From: Thomas Gellekum Message-Id: <199701280843.JAA03366@ghpc6.ihf.rwth-aachen.de> Subject: Re: 2.2-BETA Questions To: Shimon@i-Connect.Net (Simon Shapiro) Date: Tue, 28 Jan 1997 09:43:39 +0100 (MET) Cc: msmith@atrad.adelaide.edu.au, hackers@FreeBSD.ORG In-Reply-To: from Simon Shapiro at "Jan 28, 97 00:00:34 am" Organization: Institut f. Hochfrequenztechnik, RWTH Aachen X-Mailer: ELM [version 2.4ME+ PL11 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Simon Shapiro wrote: [Charset iso-8859-8 unsupported, filtering to ASCII...] > What is the kernel config option for CD audio support? There's nothing special. Could you post the lines from the probe messages (see dmesg(8))? xmcd works fine with a Hitachi drive I have here (CDR-7930, ATAPI, in case someone's interested; xmcd linked with lesstif-0.75a). tg From owner-freebsd-hackers Tue Jan 28 00:51:50 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA01339 for hackers-outgoing; Tue, 28 Jan 1997 00:51:50 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id AAA01333 for ; Tue, 28 Jan 1997 00:51:47 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA25976; Tue, 28 Jan 1997 09:51:39 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id JAA15524; Tue, 28 Jan 1997 09:21:53 +0100 (MET) Message-ID: Date: Tue, 28 Jan 1997 09:21:53 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: Shimon@i-Connect.Net (Simon Shapiro) Cc: hackers@freebsd.org Subject: Re: 2.2-BETA Questions References: X-Mailer: Mutt 0.55-PL10 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 Simon Shapiro on Jan 24, 1997 19:18:56 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Simon Shapiro wrote: > 1. Does anyone care? Coming from (too much) Linux, and seeing 2.1.6, > 2.2-BETa, 3.0... it is not a stupid question. 2.1.6 is the latest release. 2.2 is the next release, currently in post-BETA. 3.0 is the head of the development (``3.0-current'') > # mkdir /NewStuff > # mount -t nfs -o ro nomis;/usr/src/FreeBSD /NewStuff > # ls -al /NewStuff > ls: /NewStuff: Permission denied > ls -al / > .... > drwxr-xr-x 2 root wheel 512 Jan 3 00:08 Linux-Transfers > drwxr-xr-x 2 root wheel 512 Jan 23 18:01 NewRoot > drwxrwxrwt 13 root sys 512 Jan 8 12:02 SourceControl > > [ /NewStuff is not there? ] It is, but... ? That's funny. Never seen this, but i never had an occasion to test against a Linux NFS server. > # xmcd -debug > .... > Lock file: /tmp/.cdaudio/lock.f02 > Cannot open /dev/rcd0c: errno=6 ENXIO. You `cd' driver seems confused. You could hook a few printf's into /sys/scsi/cd.c (inside cd_open()) to see which of the ENXIO's hits. Either the drive claims there's no medium inside, or it fails a READ CAPACITY command. What drive is it? > # ls -al /dev/rcd0c > crw-r----- 1 root operator 15, 2 Jan 24 16:01 /dev/rcd0c Of course, all this doesn't matter. ENXIO must not be confused with any part on the device node itself. It's a plain driver message. > 4. Shutdown questions: > > a. When init goes to single user, prompts, asking for a shell. > You press ENTER and it sits on ``(.???msg - Cannot exactly > remember) not found'' > ^C will get you a prompt, most of the time. Sometimes you get > a fast roll talking about some malloc() failure. Sometimes a > ^C will stop it, sometimes it will not. David Greenman has been the only one by now who also reported such a behaviour. > b. umount -a will leave things not in /etc/fstab mounted. Well, that's what the `-a' means: umount everything in fstab. The options are as follows: -a All of the file systems described in fstab(5) are unmounted. > 5. More CD fun. Once a music CD is played, you cannot mount a data > cd because ``device is busy''. Reboot cures. That's probably related to the error above. Btw., try `cdcontrol' to play your audio CD, and see if it does make a difference. xmcd is a little too funny to trust it as a generic debugging tool. They have a tendency to hack on the SCSI bus, so i wouldn't be surprised if this leaves the driver confused if something behaves different on your drive. > 8. Education Question: What is the logic in assigning slice ID's? > I understand c to be the entire disk > (why `c'? Why not?) > Why does sysinstall assign 'e', 'f', > but (almost) never 'd'? That's explained in section 2.15 of the FAQ (near the bottom). The short answer: for hysterical raisons. > 9. Some safety checks in disklabel and newfs and/or kernel slice- > partition handling could be nice. If you create an 'a' partition > which is exactly an overlap of a 'c' in a slice that dominates > the disk, newfs will FREEZE the system. This seems to happen only on your system, for whatever reason. I know of several people who are running a partition that is full-size the slice (or entire disk). > 10. Kernel Question: On an i386 PC, how does one make sure that > another driver does not use the same ISA ports as you do? If it's assigned using the config stuff, the ISA bus driver code will assure this. Some drivers (like syscons) don't fit right; they use too many ports to describe in config's syntax. The number of ports used by this driver is returned from the driver attach routine. > 11. Another Kernel question: A device driver for a controller that > is available in ISA, EISA and PCI. How do you split the code? > We put the PCI part in pci, the ISA/EISA parts in i386/{isa,eisa}? > But the code is NOT i386 dependant. We are putting it in dev/dpt. > Is that a good choice? Probably the best you could do by now. -- 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 Jan 28 01:20:41 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA02272 for hackers-outgoing; Tue, 28 Jan 1997 01:20:41 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id BAA02267 for ; Tue, 28 Jan 1997 01:20:37 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id KAA26418; Tue, 28 Jan 1997 10:20:30 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id JAA15638; Tue, 28 Jan 1997 09:54:59 +0100 (MET) Message-ID: Date: Tue, 28 Jan 1997 09:54:58 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: driley@vailsys.com (Dan Riley) Cc: freebsd-hackers@freefall.freebsd.org Subject: Re: suggestion for kernel printk() ? References: X-Mailer: Mutt 0.55-PL10 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 Dan Riley on Jan 27, 1997 23:09:38 -0600 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Dan Riley wrote: > I think this question may be slightly related to this topic or maybe not, > but in any event, after compiling a new kernel (based on a cp of LINT) I > never not get any output to the screen while booting the new kernel. What > option in LINT disables the boot messages from the kernel so that the first > thing(only thing) you see is the login prompt after a restart? :-)) You forgot to take out options COMCONSOLE again. *smile* LINT is not a good template to base your own kernel upon. Use GENERIC, and add stuff from LINT once you're sure about the meaning. -- 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 Jan 28 01:46:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA03127 for hackers-outgoing; Tue, 28 Jan 1997 01:46:51 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA03121 for ; Tue, 28 Jan 1997 01:46:49 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.4/8.6.9) with ESMTP id BAA07493; Tue, 28 Jan 1997 01:46:43 -0800 (PST) To: Simon Shapiro cc: hackers@freebsd.org Subject: Re: 2.2-BETA Questions In-reply-to: Your message of "Fri, 24 Jan 1997 19:18:56 PST." Date: Tue, 28 Jan 1997 01:46:43 -0800 Message-ID: <7489.854444803@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > # mkdir /NewStuff > # mount -t nfs -o ro nomis;/usr/src/FreeBSD /NewStuff # mount -t nfs -o ro,resvport nomis:/usr/src/FreeBSD /NewStuff Now try it. > 3. Made a kernel with sound, etc... Worked fine until some days ago. > Now, all of the sudden, without me doing anything (really :-): Hmph. Sound still works just fine for me using this morning's kernel. I don't believe you. :-) You must have mucked something else up, though you're probably looking in the wrong place for "something" right now. > a. When init goes to single user, prompts, asking for a shell. > You press ENTER and it sits on ``(.???msg - Cannot exactly > remember) not found'' I would like to know what that message is. It works fine. > 5. More CD fun. Once a music CD is played, you cannot mount a data > cd because ``device is busy''. Reboot cures. Can't reproduce. Are you SURE that xcdplayer or whatever player you're using isn't still running somewhere? > 7. trying /stand/sysinstall from a live system dumps core either on > (the equivalent of) fdisk or disklabel. Fixed in later versions. > 10. Kernel Question: On an i386 PC, how does one make sure that > another driver does not use the same ISA ports as you do? "you" being whom in this example? The question doesn't quite parse into anything I can immediately answer. One answer might be "boot -c", but that's assuming a certain value for the question. :-) > 11. Another Kernel question: A device driver for a controller that > is available in ISA, EISA and PCI. How do you split the code? 3 probe routines and one common set of driver code, if possible. See how the Buslogic driver is done, for example. Jordan From owner-freebsd-hackers Tue Jan 28 02:20:38 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA04351 for hackers-outgoing; Tue, 28 Jan 1997 02:20:38 -0800 (PST) Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id CAA04314; Tue, 28 Jan 1997 02:20:26 -0800 (PST) Received: from nanguo.chalmers.com.au (chalmers.com.au) by mail.crl.com with SMTP id AA21426 (5.65c/IDA-1.5); Tue, 28 Jan 1997 02:19:52 -0800 Received: (from robert@localhost) by nanguo.chalmers.com.au (8.7.6/8.7.3) id UAA00874; Tue, 28 Jan 1997 20:02:03 +1000 (EST) From: Robert Chalmers Message-Id: <199701281002.UAA00874@nanguo.chalmers.com.au> Subject: progress report on connection problems To: freebsd-questions@freebsd.org (bsd) Date: Tue, 28 Jan 1997 20:02:02 +1000 (EST) Cc: freebsd-isp@freebsd.org (FreeBSD ISP), hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL22 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In the hopes that someone more knowledgable than I may have an explanation. I realise this is not in bug report format. FreeBSD nanguo.chalmers.com.au 2.2-961014-SNAP FreeBSD 2.2-961014-SNAP #0: Tue Jan 28 14:23:53 EST 1997 root@nanguo.chalmers.com.au:/usr/src/sys/compile/MYKERNEL i386 I am connected to the carrier (ISP) through my Stallion EasyServer 8 Port. This is an Annex the same as the XYLogics Annex. Running V9.xx software erpcd. The problem that has surfaced; Some, not all, sites around the world are not able to connect to any of my FreeBSD servers to exchange information. Let me rephrase that: They can connect, but not exchange information past that point. I have no idea what OSs the other sites are using. The number of sites is not large, but significant. I am currently logging over 4000 connections a month from individual places. Well over 1GB of data transferred. the Problem. examples: 1. mail (sendmail) to some sites can only deliver 1 line messages. To other sites not at all. The sites report back with timeout and other messages indicating a failure to complete transactions with my site 2. ftp from other sites into the ftp server will connect then hang, and the connection is reset. Most interestingly, one freebsd site changed to a Linux server, and connected fine, and completed the transfer. 3. http/web servers will connect and hang, others will go so slowly that they are as good as unusable. Most notable are yahoo.com and linkexchange.com. All the other search engines connect and exchange data with no worries. It should be noted that linkexchange.com will talk happily to this site, EXCEPT when it is required to SUBMIT my banner for its archive. It connects, then I get a server error from Linkexchanges server. Yahoo simply fails all together. The error returned is a timeout. Systems known to work with my site with no worries. SCO Unix BSDI NT '95 I can connect to, and be connected to these OSs with no worries. I have tried setting tcp_extensions NO and YES. If set to YES, I am unable to ftp to another FBSD site that also has tcp_extensions set YES (on). The connection simply 'hung'. If I set rfc1323 to 0 (off) the ftp connection worked fine, the other end being (on). The same happened at the other end, when they tried to ftp to me. set tcp_extension on, fail, set it off, fine. The only constant is the Annex. However, why does it pass _most_ traffic, if it is the fault of the Annex, and only fail on some.? If FreeBSD is going to be so fussy about its tcp/ip flow, shouldn't it be reworked. The world is still full of less than leading edge hardware! Some of it brand new... If anyone wants to comment or offer help, I'mm happy to keep trying to track this bug(ger) down. cheers, Robert -- Triple-W: P.O. Box 2003. Mackay. 4740 +61-0412-079025 robert@chalmers.com.au for Whirled Peas http://www.chalmers.com.au Location: Whitsunday Web Works. 21'7" S, 149'14" E. From owner-freebsd-hackers Tue Jan 28 03:47:40 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA09832 for hackers-outgoing; Tue, 28 Jan 1997 03:47:40 -0800 (PST) Received: from ravenock.cybercity.dk (ravenock.cybercity.dk [194.16.57.32]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA09824; Tue, 28 Jan 1997 03:47:32 -0800 (PST) Received: (from sos@localhost) by ravenock.cybercity.dk (8.8.4/8.7.3) id MAA17415; Tue, 28 Jan 1997 12:48:53 +0100 (MET) From: Søren Schmidt Message-Id: <199701281148.MAA17415@ravenock.cybercity.dk> Subject: Re: progress report on connection problems In-Reply-To: <199701281002.UAA00874@nanguo.chalmers.com.au> from Robert Chalmers at "Jan 28, 97 08:02:02 pm" To: robert@nanguo.chalmers.com.au (Robert Chalmers) Date: Tue, 28 Jan 1997 12:48:44 +0100 (MET) Cc: freebsd-questions@freebsd.org, freebsd-isp@freebsd.org, hackers@freebsd.org 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In reply to Robert Chalmers who wrote: [lots o descriptions deleted] > I can connect to, and be connected to these OSs with no worries. > I have tried setting tcp_extensions NO and YES. If set to YES, I am unable > to ftp to another FBSD site that also has tcp_extensions set YES (on). > The connection simply 'hung'. If I set rfc1323 to 0 (off) the ftp connection > worked fine, the other end being (on). The same happened at the other end, > when they tried to ftp to me. set tcp_extension on, fail, set it off, fine. > > The only constant is the Annex. However, why does it pass _most_ traffic, > if it is the fault of the Annex, and only fail on some.? Hmm, I'm seeing problems with the Annex's too if I run with tcp_extensions enabled. Somehow the Annex's turn some of the trafic into "chernobyl" packets (ie all lamps and bells set). This is only a problem if the other end also supports the extensions (ie a FreeBSD box). However all problems dissapear if I disable the extensions. I guess the only solution is to bug the vendor to implement a modern IP stackc... > If FreeBSD is > going to be so fussy about its tcp/ip flow, shouldn't it be reworked. > The world is still full of less than leading edge hardware! Some of it > brand new... Disable the tcp_extentions is the only solution to the problems I'm seeing as it is not the FreeBSD end that is at fault, and hence I cannot fix it :( -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-hackers Tue Jan 28 05:06:35 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA13075 for hackers-outgoing; Tue, 28 Jan 1997 05:06:35 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA13070 for ; Tue, 28 Jan 1997 05:06:32 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id XAA24970; Tue, 28 Jan 1997 23:56:44 +1100 Date: Tue, 28 Jan 1997 23:56:44 +1100 From: Bruce Evans Message-Id: <199701281256.XAA24970@godzilla.zeta.org.au> To: msmith@atrad.adelaide.edu.au, Shimon@i-Connect.Net Subject: Re: 2.2-BETA Questions Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> > 9. Some safety checks in disklabel and newfs and/or kernel slice- >> > partition handling could be nice. If you create an 'a' partition >> > which is exactly an overlap of a 'c' in a slice that dominates >> > the disk, newfs will FREEZE the system. >> >> Novel. I've never seen that, and I've done it many times. > >I checked some more. It has to do with the manner in which disklabel is >called. If you have it use /etc/disktab, all is well. The -e is only safe >if you initialized with the (-rwB?) /etc/disktab option. `disklabel -e' should not start unless the label already exists. Perhaps you had a wrong label and reinitializing it fixed it. >> > 10. Kernel Question: On an i386 PC, how does one make sure that >> > another driver does not use the same ISA ports as you do? >> > You are trying to be nice and NOT use something someone else is >> > already using. There is a Linux thing to do that... >> >> ISA resource allocation is a particularly noisome can of worms. >> Currently, if your driver is configured with a base address in a >> region previously claimed by another driver, your probe routine won't >> be called. That can obviously cause problems if you plan to probe >> several possible port ranges in a single probe routine. > >Perfect! Linux drivers seem to explicitly call some routine that registers >the addresses. I like hte BSD solution better. It's simpler when it works, but inadequate. Bruce From owner-freebsd-hackers Tue Jan 28 06:03:35 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA15141 for hackers-outgoing; Tue, 28 Jan 1997 06:03:35 -0800 (PST) Received: from buffnet4.buffnet.net (root@buffnet4.buffnet.net [205.246.19.13]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id GAA15131; Tue, 28 Jan 1997 06:03:30 -0800 (PST) Received: from buffnet1.buffnet.net (mmdf@buffnet1.buffnet.net [205.246.19.10]) by buffnet4.buffnet.net (8.6.12/8.6.9) with SMTP id IAA04331; Tue, 28 Jan 1997 08:45:49 -0500 Received: from buffnet11.buffnet.net by buffnet1.buffnet.net id aa13578; 28 Jan 97 9:03 EST Date: Tue, 28 Jan 1997 09:03:16 -0500 (EST) From: Steve To: Robert Chalmers cc: bsd , FreeBSD ISP , hackers@freebsd.org Subject: Re: progress report on connection problems In-Reply-To: <199701281002.UAA00874@nanguo.chalmers.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > The only constant is the Annex. However, why does it pass _most_ traffic, > if it is the fault of the Annex, and only fail on some.? > > If FreeBSD is > going to be so fussy about its tcp/ip flow, shouldn't it be reworked. > The world is still full of less than leading edge hardware! Some of it > brand new... I had similar problems using annexes as term servers with user - and have posted numerous times that this problem only exists with freebsd - sco, linux, etc doesnt have trouble - only every time I post it I get bashed about the head and lectured on freebsd having perfect tcp/ip and everything else in the world having faulty tcp/ip. So good luck to you sir! From owner-freebsd-hackers Tue Jan 28 06:09:31 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA15508 for hackers-outgoing; Tue, 28 Jan 1997 06:09:31 -0800 (PST) Received: from ami.tom.computerworks.net (root@AMI.RES.CMU.EDU [128.2.95.1]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id GAA15503 for ; Tue, 28 Jan 1997 06:09:27 -0800 (PST) Received: from bonkers.taronga.com by ami.tom.computerworks.net with smtp (Smail3.1.29.1 #1) id m0vpEDI-0021VbC; Tue, 28 Jan 97 09:08 EST Received: (from peter@localhost) by bonkers.taronga.com (8.6.11/8.6.9) id IAA04275; Tue, 28 Jan 1997 08:04:43 -0600 Date: Tue, 28 Jan 1997 08:04:43 -0600 From: peter@taronga.com (Peter da Silva) Message-Id: <199701281404.IAA04275@bonkers.taronga.com> To: hackers@freebsd.org Subject: Re: file locking / firewalling based on uid/gid Newsgroups: taronga.freebsd.hackers In-Reply-To: <199701031720.SAA00624@yedi.iaf.nl> References: <199701030443.UAA28355@freefall.freebsd.org> Organization: none Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199701031720.SAA00624@yedi.iaf.nl>, Wilko Bulte wrote: >And who does the chown() to allow users to get at their mail? This is only a problem because in 2.7 or so chown() for regular users was disabled to allow for the use of chown() in the "handin" program to verify assignment turn-in for users on the EECS 11/70. Later it was pointed out that you could do it by making the files created by turnin setuid, since chowning disabled the setuid bit, but by then the damage was done. The only reason for disabling chown any more is for quotas, and quotas don't work right anyway. I'd like to recommend going back to the USG semantics for chown(). From owner-freebsd-hackers Tue Jan 28 06:33:35 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA16699 for hackers-outgoing; Tue, 28 Jan 1997 06:33:35 -0800 (PST) Received: from beauty.nacamar.de (root@beauty.nacamar.de [194.112.16.36]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA16688 for ; Tue, 28 Jan 1997 06:33:32 -0800 (PST) Received: from petzi (petzi.nacamar.de [194.162.54.13]) by beauty.nacamar.de (8.8.4/8.7.3) with SMTP id PAA18909 for ; Tue, 28 Jan 1997 15:33:27 +0100 Message-Id: <2.2.32.19970128143327.00b74300@mail.nacamar.de> X-Sender: petzi@mail.nacamar.de X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 28 Jan 1997 15:33:27 +0100 To: hackers@freebsd.org From: Michael Beckmann Subject: 2.2 sources ? Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi there, I wonder where one can get the current FreeBSD 2.2 source tree. It seems that the -current tree is FreeBSD 3.0 now. The reason why I ask is that I want to build a kernel from newer sources than 2.2-BETA. Cheers, Michael From owner-freebsd-hackers Tue Jan 28 06:43:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA17178 for hackers-outgoing; Tue, 28 Jan 1997 06:43:49 -0800 (PST) Received: from atena.eurocontrol.fr (atena.uneec.eurocontrol.fr [147.196.69.10]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id GAA17170 for ; Tue, 28 Jan 1997 06:43:41 -0800 (PST) Received: by atena.eurocontrol.fr; (5.65v3.2/1.3/10May95) id AA29277; Tue, 28 Jan 1997 15:43:36 +0100 Received: (from roberto@localhost) by caerdonn.eurocontrol.fr (8.8.5/caerdonn-1.1) id PAA26987; Tue, 28 Jan 1997 15:43:32 +0100 (MET) Message-Id: <19970128154332.HX30377@caerdonn.eurocontrol.fr> Date: Tue, 28 Jan 1997 15:43:32 +0100 From: roberto@eurocontrol.fr (Ollivier Robert) To: freebsd-hackers@FreeBSD.ORG (FreeBSD Hackers' list) Subject: MAXMEM and userconfig X-Mailer: Mutt 0.59.1 Mime-Version: 1.0 X-Operating-System: FreeBSD 3.0-CURRENT Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk When one has more than 64 MB of RAM, for now, one has to add the MAXMEM option to the kernel configuration file and recompile. I (and others) think that it would be a valuable addition to Userconfig or the bootblock (providing that we have the space of course)... Comments ? -- Ollivier ROBERT -=- Eurocontrol EEC/TS -=- Ollivier.Robert@eurocontrol.fr Usenet Canal Historique From owner-freebsd-hackers Tue Jan 28 07:11:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA18385 for hackers-outgoing; Tue, 28 Jan 1997 07:11:09 -0800 (PST) Received: from ns.ge.com (ns.ge.com [192.35.39.24]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA18379; Tue, 28 Jan 1997 07:11:05 -0800 (PST) Received: from thomas.ge.com (thomas.ge.com [3.47.28.21]) by ns.ge.com (8.8.4/8.7.3) with ESMTP id KAA22402; Tue, 28 Jan 1997 10:07:36 -0500 (EST) Received: from crissy.gemis.ge.com (crissy-ether.gemis.ge.com [3.29.7.204]) by thomas.ge.com (8.8.4/8.7.5) with SMTP id KAA24853; Tue, 28 Jan 1997 10:10:28 -0500 (EST) Received: from terrapin.salem.ge.com (terrapin.salem.ge.com [3.29.6.145]) by crissy.gemis.ge.com (8.6.11/8.6.11) with ESMTP id KAA28015; Tue, 28 Jan 1997 10:01:39 -0500 Received: from combs.salem.ge.com (combs.salem.ge.com [3.29.5.200]) by terrapin.salem.ge.com (8.8.3/8.8.3) with ESMTP id KAA01129; Tue, 28 Jan 1997 10:01:35 -0500 (EST) Received: from localhost (steve@localhost) by combs.salem.ge.com (8.8.3/8.8.3) with SMTP id KAA00635; Tue, 28 Jan 1997 10:01:35 -0500 (EST) Date: Tue, 28 Jan 1997 10:01:34 -0500 (EST) From: "Stephen F. Combs" To: Steve cc: Robert Chalmers , bsd , FreeBSD ISP , hackers@freebsd.org Subject: Re: progress report on connection problems In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Xylogics Annex terminal servers running a s/w release PRIOR to 10.1 don't pass the RFC1323 and RFC 1644 stuff properly. If you set your 'tcp_extensions=NO' it should work just fine. Also tell your ISP to upgrade! I did and it works just fine! ---- Stephen F. Combs Internet: CombsSF@Salem.GE.COM GE Industrial Systems Voice: 540.387.8828 Network Services Home: CombsSF-Home@Salem.GE.COM 1501 Roanoke Blvd FAX: 540.387.7106 Salem, VA 24153 LapTop: CombsSF-Mobile@Salem.GE.COM On Tue, 28 Jan 1997, Steve wrote: > Date: Tue, 28 Jan 1997 09:03:16 -0500 (EST) > From: Steve > To: Robert Chalmers > Cc: bsd , > FreeBSD ISP , hackers@freebsd.org > Subject: Re: progress report on connection problems > > > > > The only constant is the Annex. However, why does it pass _most_ traffic, > > if it is the fault of the Annex, and only fail on some.? > > > > If FreeBSD is > > going to be so fussy about its tcp/ip flow, shouldn't it be reworked. > > The world is still full of less than leading edge hardware! Some of it > > brand new... > > I had similar problems using annexes as term servers with user - and have > posted numerous times that this problem only exists with freebsd - sco, > linux, etc doesnt have trouble - only every time I post it I get bashed > about the head and lectured on freebsd having perfect tcp/ip and > everything else in the world having faulty tcp/ip. > > So good luck to you sir! > > From owner-freebsd-hackers Tue Jan 28 07:24:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA19068 for hackers-outgoing; Tue, 28 Jan 1997 07:24:37 -0800 (PST) Received: from frig.mt.cs.keio.ac.jp (frig.mt.cs.keio.ac.jp [131.113.32.7]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id HAA19062 for ; Tue, 28 Jan 1997 07:24:33 -0800 (PST) Received: (from hosokawa@localhost) by frig.mt.cs.keio.ac.jp (8.6.12+2.4W/3.4Wbeta3) id AAA18649; Wed, 29 Jan 1997 00:23:24 +0900 Date: Wed, 29 Jan 1997 00:23:24 +0900 Message-Id: <199701281523.AAA18649@frig.mt.cs.keio.ac.jp> To: roberto@eurocontrol.fr Cc: freebsd-hackers@freebsd.org, hosokawa@mt.cs.keio.ac.jp Subject: Re: MAXMEM and userconfig In-Reply-To: Your message of Tue, 28 Jan 1997 15:43:32 +0100. <19970128154332.HX30377@caerdonn.eurocontrol.fr> From: hosokawa@mt.cs.keio.ac.jp (HOSOKAWA Tatsumi) X-Mailer: mnews [version 1.18PL3] 1994-08/01(Mon) Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <19970128154332.HX30377@caerdonn.eurocontrol.fr> roberto@eurocontrol.fr writes: >> I (and others) think that it would be a valuable addition to Userconfig or >> the bootblock (providing that we have the space of course)... I second this proposal. I also think that some device-dependent options should be replaced with flags for device driver because of same reasons. -- HOSOKAWA, Tatsumi E-mail: hosokawa@mt.cs.keio.ac.jp WWW homepage: http://www.mt.cs.keio.ac.jp/person/hosokawa.html Department of Computer Science, Keio University, Yokohama, Japan From owner-freebsd-hackers Tue Jan 28 07:46:06 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA20331 for hackers-outgoing; Tue, 28 Jan 1997 07:46:06 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA20322 for ; Tue, 28 Jan 1997 07:46:02 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id CAA28783; Wed, 29 Jan 1997 02:44:14 +1100 Date: Wed, 29 Jan 1997 02:44:14 +1100 From: Bruce Evans Message-Id: <199701281544.CAA28783@godzilla.zeta.org.au> To: freebsd-hackers@freebsd.org, roberto@eurocontrol.fr Subject: Re: MAXMEM and userconfig Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >When one has more than 64 MB of RAM, for now, one has to add the MAXMEM >option to the kernel configuration file and recompile. >I (and others) think that it would be a valuable addition to Userconfig or >the bootblock (providing that we have the space of course)... It's already hacked into config and userconfig: iosiz npx0 See LINT. Bruce From owner-freebsd-hackers Tue Jan 28 07:52:45 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA20743 for hackers-outgoing; Tue, 28 Jan 1997 07:52:45 -0800 (PST) Received: from atena.eurocontrol.fr (atena.uneec.eurocontrol.fr [147.196.69.10]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id HAA20737 for ; Tue, 28 Jan 1997 07:52:41 -0800 (PST) Received: by atena.eurocontrol.fr; (5.65v3.2/1.3/10May95) id AA30019; Tue, 28 Jan 1997 16:52:31 +0100 Received: (from roberto@localhost) by caerdonn.eurocontrol.fr (8.8.5/caerdonn-1.1) id QAA27479; Tue, 28 Jan 1997 16:52:31 +0100 (MET) Message-Id: <19970128165230.SU09584@caerdonn.eurocontrol.fr> Date: Tue, 28 Jan 1997 16:52:30 +0100 From: roberto@eurocontrol.fr (Ollivier Robert) To: bde@zeta.org.au (Bruce Evans) Cc: freebsd-hackers@freebsd.org Subject: Re: MAXMEM and userconfig References: <199701281544.CAA28783@godzilla.zeta.org.au> X-Mailer: Mutt 0.59.1 Mime-Version: 1.0 X-Operating-System: FreeBSD 3.0-CURRENT In-Reply-To: <199701281544.CAA28783@godzilla.zeta.org.au>; from Bruce Evans on Jan 29, 1997 02:44:14 +1100 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to Bruce Evans: > It's already hacked into config and userconfig: > > iosiz npx0 > > See LINT. Thanks, I must have missed the commit. I guess it is only for CURRENT and won't be available for 2.2 ? -- Ollivier ROBERT -=- Eurocontrol EEC/TS -=- Ollivier.Robert@eurocontrol.fr Usenet Canal Historique From owner-freebsd-hackers Tue Jan 28 08:36:04 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA22721 for hackers-outgoing; Tue, 28 Jan 1997 08:36:04 -0800 (PST) Received: from haldjas.folklore.ee (Haldjas.folklore.ee [193.40.6.121]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA22684; Tue, 28 Jan 1997 08:35:54 -0800 (PST) Received: from localhost (narvi@localhost) by haldjas.folklore.ee (8.8.4/8.8.4) with SMTP id SAA02793; Tue, 28 Jan 1997 18:34:26 +0200 (EET) Date: Tue, 28 Jan 1997 18:34:26 +0200 (EET) From: Narvi To: Robert Chalmers cc: bsd , FreeBSD ISP , hackers@freebsd.org Subject: Re: progress report on connection problems In-Reply-To: <199701281002.UAA00874@nanguo.chalmers.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Have you tried switching off the TCP extensions? See /etc/sysconfig, you can turn of support for two related rfc-s there... Sander On Tue, 28 Jan 1997, Robert Chalmers wrote: > In the hopes that someone more knowledgable than I may have an explanation. > > I realise this is not in bug report format. > FreeBSD nanguo.chalmers.com.au 2.2-961014-SNAP FreeBSD 2.2-961014-SNAP #0: Tue Jan 28 14:23:53 EST 1997 root@nanguo.chalmers.com.au:/usr/src/sys/compile/MYKERNEL i386 > > I am connected to the carrier (ISP) through my Stallion EasyServer 8 Port. > This is an Annex the same as the XYLogics Annex. Running V9.xx software erpcd. > > > The problem that has surfaced; > > Some, not all, sites around the world are not able to connect > to any of my FreeBSD servers to exchange information. Let me rephrase that: > They can connect, but not exchange information past that point. > I have no idea what OSs the other sites are using. The number of sites is > not large, but significant. I am currently logging over 4000 connections a > month from individual places. Well over 1GB of data transferred. > > the Problem. > examples: > 1. mail (sendmail) to some sites can only deliver 1 line > messages. To other sites not at all. The sites report back > with timeout and other messages indicating a failure to > complete transactions with my site > > 2. ftp from other sites into the ftp server will connect then > hang, and the connection is reset. > Most interestingly, one freebsd site changed to a Linux > server, and connected fine, and completed the transfer. > > 3. http/web servers will connect and hang, others will go so > slowly that they are as good as unusable. > Most notable are yahoo.com and linkexchange.com. > > All the > other search engines connect and exchange data with no > worries. > > It should be noted that linkexchange.com will talk happily > to this site, EXCEPT when it is required to SUBMIT my > banner for its archive. It connects, then I get a server > error from Linkexchanges server. Yahoo simply fails > all together. The error returned is a timeout. > > > Systems known to work with my site with no worries. > SCO Unix > BSDI > NT > '95 > > I can connect to, and be connected to these OSs with no worries. > I have tried setting tcp_extensions NO and YES. If set to YES, I am unable > to ftp to another FBSD site that also has tcp_extensions set YES (on). > The connection simply 'hung'. If I set rfc1323 to 0 (off) the ftp connection > worked fine, the other end being (on). The same happened at the other end, > when they tried to ftp to me. set tcp_extension on, fail, set it off, fine. > > The only constant is the Annex. However, why does it pass _most_ traffic, > if it is the fault of the Annex, and only fail on some.? > > If FreeBSD is > going to be so fussy about its tcp/ip flow, shouldn't it be reworked. > The world is still full of less than leading edge hardware! Some of it > brand new... > > If anyone wants to comment or offer help, I'mm happy to keep trying to > track this bug(ger) down. > > cheers, > Robert > > -- > Triple-W: P.O. Box 2003. Mackay. 4740 +61-0412-079025 > robert@chalmers.com.au for Whirled Peas http://www.chalmers.com.au > Location: Whitsunday Web Works. 21'7" S, 149'14" E. > From owner-freebsd-hackers Tue Jan 28 08:40:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA23005 for hackers-outgoing; Tue, 28 Jan 1997 08:40:59 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA22999 for ; Tue, 28 Jan 1997 08:40:56 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id DAA29955; Wed, 29 Jan 1997 03:36:49 +1100 Date: Wed, 29 Jan 1997 03:36:49 +1100 From: Bruce Evans Message-Id: <199701281636.DAA29955@godzilla.zeta.org.au> To: bde@zeta.org.au, roberto@eurocontrol.fr Subject: Re: MAXMEM and userconfig Cc: freebsd-hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> iosiz npx0 > >Thanks, I must have missed the commit. I guess it is only for CURRENT and >won't be available for 2.2 ? It's for 2.2 and also for -current. -current doesn't really need it, since -current gets compiled every day (else it isn't current :-), so you need to configure the memory size at compile time to avoid entering it in userconfig too often. Bruce From owner-freebsd-hackers Tue Jan 28 09:11:39 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA24271 for hackers-outgoing; Tue, 28 Jan 1997 09:11:39 -0800 (PST) Received: from hamby1.lightside.net (hamby1.lightside.net [207.67.176.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA24262; Tue, 28 Jan 1997 09:11:34 -0800 (PST) Received: from localhost (jehamby@localhost) by hamby1.lightside.net (8.8.4/8.8.2) with SMTP id JAA00338; Tue, 28 Jan 1997 09:10:45 -0800 (PST) X-Authentication-Warning: hamby1.lightside.net: jehamby owned process doing -bs Date: Tue, 28 Jan 1997 09:10:44 -0800 (PST) From: Jake Hamby X-Sender: jehamby@hamby1 Reply-To: Jake Hamby To: Terry Lambert cc: hasty@rah.star-gate.com, multimedia@freebsd.org, hackers@freebsd.org Subject: Re: New Bt848 Video capture driver for FreeBSD In-Reply-To: <199701252133.OAA00739@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I strongly doubt that the person who wrote the demo used such sneaky speed-ups, since it was designed to show off the new general-purpose texture-mapping routines that will be in the 3D Kit for BeOS DR9. Besides the cube, there was a sphere, an open book, and a pulsing surface that looked like water that a pebble has been dropped into. Furthermore, the cube could be rotated by the user dragging the mouse. In general, texture mapping is straightforward enough, and a PowerPC 604 has enough horsepower to solve it in the general case, that I'm sure that's what they did. In other words, of course the hidden surfaces wouldn't be rendered, but your other suggestions sound a little wacky. Anyway, I didn't mean to bring BeOS into this, except that it's curious that you should announce a driver for a card that I first heard of in connection with the Be demo at MacWorld. I'll have to buy the card and let you know how it works. Maybe I can sneak it into work one day and try it out on the MBONE to FreeBSD Lounge, if I can find a Pentium to sneak FreeBSD onto. :) P.S. I just saw a demo of SGI's new Octane system on the MBONE. Using Alias Wavefront, they did a real-time walkthrough of a robot walking along a street with rain and streetlights! They also showed a dragon flapping its wings rendered in real-time with SoftImage, and emphasized the fact that even though they're a subsidiary of Microsoft now, it still runs best on SGI's! If only I had $25,000 (or whatever the price is after educational discount :) ... ------------------------------------------------------------------------------ |Jake Hamby| Ask me about Unix, FreeBSD, Solaris, The Tick, BeOS, or NT, eh? | ------------------------------------------------------------------------------ "This space intentionally left blank." From owner-freebsd-hackers Tue Jan 28 09:17:16 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA24649 for hackers-outgoing; Tue, 28 Jan 1997 09:17:16 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA24642 for ; Tue, 28 Jan 1997 09:17:13 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA08236; Tue, 28 Jan 1997 09:59:03 -0700 From: Terry Lambert Message-Id: <199701281659.JAA08236@phaeton.artisoft.com> Subject: Re: Network interfaces: removal of. To: louie@TransSys.COM (Louis A. Mamakos) Date: Tue, 28 Jan 1997 09:59:03 -0700 (MST) Cc: julian@whistle.com, hackers@freebsd.org In-Reply-To: <199701280402.XAA03991@whizzo.transsys.com> from "Louis A. Mamakos" at Jan 27, 97 11:02:20 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > While I'm sure that the modules that reference interfaces are finite, > there's nothing to allocate references to them. This would require a > level of discipline unknown to the BSD net code. Hell, you might just > as well wish for locks on the data structures to make the code SMP safe :-) Locking data is not as useful as locking context for SMP-izing them for kernel reentrancy/preemption. Specifically, if you lock data, you must place all your locks in a hierarchical graph, and then compute transitive closure over the entire graph when you go to assert any lock. If you lock, and group locks, by context (subsystem), then you only need to compute transitive closure of the region of the graph that the context is in. Further, if you use intention mode locking, you can precompute everything but the last pass of Warshall's algorithm for the intention nodes, and then compute closure almost instantaneously when an actual assert takes place. On the order of 6,000 times more locks per second than the Tuxedo system is capable of, on the same hardware, actually. 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 Tue Jan 28 09:25:28 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA25192 for hackers-outgoing; Tue, 28 Jan 1997 09:25:28 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA25186 for ; Tue, 28 Jan 1997 09:25:26 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA08287; Tue, 28 Jan 1997 10:07:18 -0700 From: Terry Lambert Message-Id: <199701281707.KAA08287@phaeton.artisoft.com> Subject: Re: 2.2-BETA Questions To: Shimon@i-Connect.Net (Simon Shapiro) Date: Tue, 28 Jan 1997 10:07:18 -0700 (MST) Cc: msmith@atrad.adelaide.edu.au, hackers@freebsd.org In-Reply-To: from "Simon Shapiro" at Jan 28, 97 00:00:34 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Yea, I figured this much, but the Linux ``gurus'' insist, theirs is the > only ``correct'' NFS server... As I said, it works (very well!) the other > way around... Is it still in user space so that each packet in and out is required to cross a protection domain in each direction, and if it contains data to be read or written, another protection domain to obtain/save the data? PS: man mount_nfs (-P), man mount (-o resvport) 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 Jan 28 09:28:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA25395 for hackers-outgoing; Tue, 28 Jan 1997 09:28:01 -0800 (PST) Received: from vdp01.vailsystems.com (root@vdp01.vailsystems.com [207.152.98.18]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA25380 for ; Tue, 28 Jan 1997 09:27:56 -0800 (PST) Received: from crocodile.vale.com (crocodile [204.117.217.147]) by vdp01.vailsystems.com (8.8.3/8.7.3) with ESMTP id LAA03626; Tue, 28 Jan 1997 11:27:49 -0600 (CST) Received: from jaguar (jaguar.vale.com [204.117.217.146]) by crocodile.vale.com (8.8.3/8.7.3) with SMTP id LAA01160; Tue, 28 Jan 1997 11:27:43 -0600 (CST) Message-ID: <32EE370F.7CDD@vailsys.com> Date: Tue, 28 Jan 1997 11:27:43 -0600 From: Hal Snyder Reply-To: hal@vailsys.com Organization: Vail Systems, Inc. X-Mailer: Mozilla 3.0 (WinNT; I) MIME-Version: 1.0 To: hackers@freebsd.org CC: pete@sms.fi Subject: best mtu for lo0? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk While searching FreeBSD archived mail items, I found that Petri Helenius wrote: > What's your lo0 MTU? If it's the 16384 that some > non-tcp-knowledgeable person put in sometime in the past > I think what you are seeing is called "TCP deadlock" which appears when > window size is equal or smaller than the MTU. This makes TCP to be > stop-and-go protocol (remember XMODEM? or non-windowing kermit) and thus > the troughput of the protocol is pretty horrible. This happens on ATM also > if you are running with 4096 or 8192 window sizes and the RFC1577 default > MTU of 9180. > Fortunately not too many applications use the 127.0.0.1 address but use > the loopback provided by the ethernet-interface. (and thus get the MTU of > 1500) Is this correct? I notice 2.1.6-R sets MTU for lo0 to 16384. Should this be reduced to 1500? Will it affect performance of aliased IP addresses, for which a static route through lo0 is usually specified? From owner-freebsd-hackers Tue Jan 28 09:35:15 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA25977 for hackers-outgoing; Tue, 28 Jan 1997 09:35:15 -0800 (PST) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA25934; Tue, 28 Jan 1997 09:35:05 -0800 (PST) Received: from misery.sdf.com [204.244.213.33] by misery.sdf.com with smtp (Exim 1.59 #1) id 0vp9h3-0000Ds-00; Tue, 28 Jan 1997 01:19:05 -0800 Date: Tue, 28 Jan 1997 01:19:05 -0800 (PST) From: Tom Samplonius To: Steve cc: Robert Chalmers , bsd , FreeBSD ISP , hackers@freebsd.org Subject: Re: progress report on connection problems In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 28 Jan 1997, Steve wrote: > > The only constant is the Annex. However, why does it pass _most_ traffic, > > if it is the fault of the Annex, and only fail on some.? > > > > If FreeBSD is > > going to be so fussy about its tcp/ip flow, shouldn't it be reworked. > > The world is still full of less than leading edge hardware! Some of it > > brand new... > > I had similar problems using annexes as term servers with user - and have > posted numerous times that this problem only exists with freebsd - sco, > linux, etc doesnt have trouble - only every time I post it I get bashed > about the head and lectured on freebsd having perfect tcp/ip and > everything else in the world having faulty tcp/ip. > > So good luck to you sir! FreeBSD implements T/TCP. You can disable this via by turning tcp_extensions off. SCO, Linux do not implement T/TCP, which is to their disadvantage. T/TCP gives you big wins if opening and closing a lot of TCP connections. Broken boxes like the Annex don't like T/TCP (it is broken, because if the Annex properly implemented IP/TCP, it wouldn't have a problem). Newer software releases for the Annex fix this problem. I'm not aware of any equipment that doesn't like T/TCP that couldn't be fixed with a software upgrade. Tom From owner-freebsd-hackers Tue Jan 28 09:36:20 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA26113 for hackers-outgoing; Tue, 28 Jan 1997 09:36:20 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA26108; Tue, 28 Jan 1997 09:36:15 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA08314; Tue, 28 Jan 1997 10:18:00 -0700 From: Terry Lambert Message-Id: <199701281718.KAA08314@phaeton.artisoft.com> Subject: Re: progress report on connection problems To: robert@nanguo.chalmers.com.au (Robert Chalmers) Date: Tue, 28 Jan 1997 10:18:00 -0700 (MST) Cc: freebsd-questions@FreeBSD.ORG, freebsd-isp@FreeBSD.ORG, hackers@FreeBSD.ORG In-Reply-To: <199701281002.UAA00874@nanguo.chalmers.com.au> from "Robert Chalmers" at Jan 28, 97 08:02:02 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I can connect to, and be connected to these OSs with no worries. > I have tried setting tcp_extensions NO and YES. If set to YES, I am unable > to ftp to another FBSD site that also has tcp_extensions set YES (on). > The connection simply 'hung'. If I set rfc1323 to 0 (off) the ftp connection > worked fine, the other end being (on). The same happened at the other end, > when they tried to ftp to me. set tcp_extension on, fail, set it off, fine. > > The only constant is the Annex. However, why does it pass _most_ traffic, > if it is the fault of the Annex, and only fail on some.? > > If FreeBSD is > going to be so fussy about its tcp/ip flow, shouldn't it be reworked. > The world is still full of less than leading edge hardware! Some of it > brand new... > > If anyone wants to comment or offer help, I'mm happy to keep trying to > track this bug(ger) down. I don't understand what you are saying here; if you are saying that it works with extensions off, then it is easy to explain: o All TCP/IP implementations *must* support extension negotiation for locally unsupported extensions (they are to negotiate them "off"). Not all TCP/IP implementations are conforming. o All TCP/IP implementations *must* support data in SYN packets, even though most implementations do not generate data in SYN packets. T/TCP will generate data in SYN packets; so will the FreeBSD "finger" (man finger). Not all TCP/IP implementations are conforming. If you detect a non-conforming implementation: 1) Contact the vendor for a fix; one probably exists. 2) If no fix is available, turn extension off on the FreeBSD system, and submit a bug report to the vendor so that a fix will happen. If you think things are bad now, wait until the net begins migrating to IPv6 at the router level. 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 Tue Jan 28 09:46:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA26627 for hackers-outgoing; Tue, 28 Jan 1997 09:46:47 -0800 (PST) Received: from silver.sms.fi (silver.sms.fi [194.111.122.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA26608 for ; Tue, 28 Jan 1997 09:46:15 -0800 (PST) Received: (from pete@localhost) by silver.sms.fi (8.8.3/8.7.3) id TAA25913; Tue, 28 Jan 1997 19:45:36 +0200 (EET) Date: Tue, 28 Jan 1997 19:45:36 +0200 (EET) Message-Id: <199701281745.TAA25913@silver.sms.fi> From: Petri Helenius To: hal@vailsys.com Cc: hackers@freebsd.org Subject: best mtu for lo0? In-Reply-To: <32EE370F.7CDD@vailsys.com> References: <32EE370F.7CDD@vailsys.com> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hal Snyder writes: > While searching FreeBSD archived mail items, I found that > > Petri Helenius wrote: > > > What's your lo0 MTU? If it's the 16384 that some > > non-tcp-knowledgeable person put in sometime in the past > > I think what you are seeing is called "TCP deadlock" which appears when > > window size is equal or smaller than the MTU. This makes TCP to be > > stop-and-go protocol (remember XMODEM? or non-windowing kermit) and thus > > the troughput of the protocol is pretty horrible. This happens on ATM also > > if you are running with 4096 or 8192 window sizes and the RFC1577 default > > MTU of 9180. > > Fortunately not too many applications use the 127.0.0.1 address but use > > the loopback provided by the ethernet-interface. (and thus get the MTU of > > 1500) > > Is this correct? I notice 2.1.6-R sets MTU for lo0 to 16384. Should > this be reduced to 1500? Will it affect performance of aliased IP > addresses, for which a static route through lo0 is usually specified? Want me to comment on this (I'm not on the hackers list any longer though)? The above still stands true that if you set your TCPWIN < MTU you'll experience TCP 'deadlock' which ends up being of horrible performance. Pete From owner-freebsd-hackers Tue Jan 28 09:48:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA26789 for hackers-outgoing; Tue, 28 Jan 1997 09:48:47 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA26727; Tue, 28 Jan 1997 09:48:35 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id JAA01087 ; Tue, 28 Jan 1997 09:48:17 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA08351; Tue, 28 Jan 1997 10:28:29 -0700 From: Terry Lambert Message-Id: <199701281728.KAA08351@phaeton.artisoft.com> Subject: Re: progress report on connection problems To: shovey@buffnet.net (Steve) Date: Tue, 28 Jan 1997 10:28:28 -0700 (MST) Cc: robert@nanguo.chalmers.com.au, freebsd-questions@FreeBSD.ORG, freebsd-isp@FreeBSD.ORG, hackers@FreeBSD.ORG In-Reply-To: from "Steve" at Jan 28, 97 09:03:16 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I had similar problems using annexes as term servers with user - and have > posted numerous times that this problem only exists with freebsd - sco, > linux, etc doesnt have trouble - only every time I post it I get bashed > about the head and lectured on freebsd having perfect tcp/ip and > everything else in the world having faulty tcp/ip. Please notify Annex that their TCP/IP implementation is non-conforming int the area of option negotiation (the "Cherynobl packets", where if any option bits are set, all option bits get set). They are non-compliant with forwarding of SYN packets containing data, since they strip the data. They are also nominally non-compliant with extention negotiation, since they should negotiate with the host to turn extensions they do not support off (ie: RFC 1323 and RFC 1644). They also do not implement RFC 1323 or RFC 1644 (they *must* implement *all* extensions they fail to negotiate off). In short, we *claim* they are broken because they *are* broken. If you wish to be able to interoperate with faulty implementations, you can always turn off the extensions which trigger the problem with the faulty implementation. Meanwhile, it provides a nice diagnostic for detecting bad TCP/IP implementations, which will only be going to hell in a big way all at once when IPv6 gating comes online, otherwise. 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 Tue Jan 28 09:50:33 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA26983 for hackers-outgoing; Tue, 28 Jan 1997 09:50:33 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA26970 for ; Tue, 28 Jan 1997 09:50:29 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA08366; Tue, 28 Jan 1997 10:32:22 -0700 From: Terry Lambert Message-Id: <199701281732.KAA08366@phaeton.artisoft.com> Subject: Re: file locking / firewalling based on uid/gid To: peter@taronga.com (Peter da Silva) Date: Tue, 28 Jan 1997 10:32:22 -0700 (MST) Cc: hackers@freebsd.org In-Reply-To: <199701281404.IAA04275@bonkers.taronga.com> from "Peter da Silva" at Jan 28, 97 08:04:43 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > The only reason for disabling chown any more is for quotas, and quotas don't > work right anyway. I'd like to recommend going back to the USG semantics for > chown(). This is for giving files away to other users, right? There are a number of nasty exploits available via NFS doing this (you can get root on almost any old SGI system this way; check the CERT advisory log). 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 Tue Jan 28 09:53:10 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA27173 for hackers-outgoing; Tue, 28 Jan 1997 09:53:10 -0800 (PST) Received: from magigimmix.xs4all.nl (magigimmix.xs4all.nl [194.109.6.25]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA27160 for ; Tue, 28 Jan 1997 09:53:01 -0800 (PST) Received: from asterix.xs4all.nl (asterix.xs4all.nl [194.109.6.11]) by magigimmix.xs4all.nl (8.7.6/XS4ALL) with ESMTP id SAA22412 for ; Tue, 28 Jan 1997 18:52:21 +0100 (MET) Received: from plm.xs4all.nl (uucp@localhost) by asterix.xs4all.nl (8.7.5/8.7.2) with UUCP id SAA07368 for freebsd-hackers@freebsd.org; Tue, 28 Jan 1997 18:43:10 +0100 (MET) Received: (from plm@localhost) by plm.xs4all.nl (8.8.4/8.7.3) id HAA03234; Tue, 28 Jan 1997 07:47:21 +0100 (MET) To: freebsd-hackers@freebsd.org Subject: Re: bisdn References: <87n2tuz4hf.fsf@totally-fudged-out-message-id> From: Peter Mutsaers Date: 28 Jan 1997 07:47:21 +0100 In-Reply-To: Greg Lehey's message of Mon, 27 Jan 1997 15:42:04 +0100 (MET) Message-ID: <8720b6wb2e.fsf@localhost.xs4all.nl> Lines: 12 X-Mailer: Gnus v5.2.39/Emacs 19.34 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> On Mon, 27 Jan 1997 15:42:04 +0100 (MET), Greg Lehey >> said: GL> Well, to be fair, Gary Jennejohn replied and told me that this GL> related to ppp, which I don't use. I think the problem there GL> is that not many people use ppp over here, so it's not GL> surprising that it's taking a long time. Yes, that is the problem for most people. I'm surprised that you don't use PPP! Here all ISP's offer ISDN access only through syncPPP. I can't even think of another way. If you don't use PPP, then how do you get TCP/IP over ISDN? From owner-freebsd-hackers Tue Jan 28 10:00:57 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA27607 for hackers-outgoing; Tue, 28 Jan 1997 10:00:57 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA27601; Tue, 28 Jan 1997 10:00:46 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA08399; Tue, 28 Jan 1997 10:41:40 -0700 From: Terry Lambert Message-Id: <199701281741.KAA08399@phaeton.artisoft.com> Subject: Re: New Bt848 Video capture driver for FreeBSD To: jehamby@lightside.com Date: Tue, 28 Jan 1997 10:41:40 -0700 (MST) Cc: terry@lambert.org, hasty@rah.star-gate.com, multimedia@freebsd.org, hackers@freebsd.org In-Reply-To: from "Jake Hamby" at Jan 28, 97 09:10:44 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I strongly doubt that the person who wrote the demo used such sneaky > speed-ups, since it was designed to show off the new general-purpose > texture-mapping routines that will be in the 3D Kit for BeOS DR9. Besides > the cube, there was a sphere, an open book, and a pulsing surface that > looked like water that a pebble has been dropped into. Furthermore, the > cube could be rotated by the user dragging the mouse. In general, texture > mapping is straightforward enough, and a PowerPC 604 has enough horsepower > to solve it in the general case, that I'm sure that's what they did. > > In other words, of course the hidden surfaces wouldn't be rendered, but > your other suggestions sound a little wacky. Wacky enough to do the same sort of thing with a cube on a Commodore64... obviously, they were anim files, not Quicktime. "64K?!?! My God! How will you ever fill that up?!?". 8-). Just the knowledge that sneaky is available makes it a little less impressive on a PPC604, though. The old debate between whether you should throw fast hardware or clever software at a problem, I guess... (PS: the correct answer is "both". 8-)). 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 Tue Jan 28 10:05:41 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA28000 for hackers-outgoing; Tue, 28 Jan 1997 10:05:41 -0800 (PST) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA27995 for ; Tue, 28 Jan 1997 10:05:35 -0800 (PST) Received: from misery.sdf.com [204.244.213.33] by misery.sdf.com with smtp (Exim 1.59 #1) id 0vpAAb-0000Jh-00; Tue, 28 Jan 1997 01:49:37 -0800 Date: Tue, 28 Jan 1997 01:49:37 -0800 (PST) From: Tom Samplonius To: Joe McGuckin cc: hackers@freebsd.org Subject: Re: Ethernet bug - 2.1.6-RELEASE In-Reply-To: <199701280527.VAA23113@monk.via.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 27 Jan 1997, Joe McGuckin wrote: > I've noticed that if I disconnect the ethernet cable from my > de0 NIC, I no longer see the warning message about the cable > being unplugged. Also, when I plug it back in, I no longer > see the message about the UTP cable being plugged in. > > Also, once disconnected, the ethernet port no longer works and > the machine must be rebooted to restore functionality. > > joe This seems somewhat dependant on the kind of card used. A SMC Etherpower 10/UTP behaves correctly, if disconnected and reconnected. A D-Link (DE-650?) with BNC/UTP did not do this properly. Fooling about with "ifconfig de0 -linkX" did manage to get it working again. I think the problem is that some cards don't properly indicate whether a particular interface is working, or not working, to the driver, except on power-on. Tom From owner-freebsd-hackers Tue Jan 28 10:08:17 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA28161 for hackers-outgoing; Tue, 28 Jan 1997 10:08:17 -0800 (PST) Received: from buffnet4.buffnet.net (root@buffnet4.buffnet.net [205.246.19.13]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA28149; Tue, 28 Jan 1997 10:08:12 -0800 (PST) Received: from buffnet1.buffnet.net (mmdf@buffnet1.buffnet.net [205.246.19.10]) by buffnet4.buffnet.net (8.6.12/8.6.9) with SMTP id MAA06131; Tue, 28 Jan 1997 12:50:56 -0500 Received: from buffnet11.buffnet.net by buffnet1.buffnet.net id aa18045; 28 Jan 97 13:08 EST Date: Tue, 28 Jan 1997 13:08:44 -0500 (EST) From: Steve To: Terry Lambert cc: Robert Chalmers , freebsd-questions@freebsd.org, freebsd-isp@freebsd.org, hackers@freebsd.org Subject: Re: progress report on connection problems In-Reply-To: <199701281718.KAA08314@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > 1) Contact the vendor for a fix; one probably exists. > > 2) If no fix is available, turn extension off on the FreeBSD > system, and submit a bug report to the vendor so that a > fix will happen. Turning extensions off does not stop the problem. From owner-freebsd-hackers Tue Jan 28 10:48:27 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA01275 for hackers-outgoing; Tue, 28 Jan 1997 10:48:27 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA01262; Tue, 28 Jan 1997 10:48:22 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA08629; Tue, 28 Jan 1997 11:30:09 -0700 From: Terry Lambert Message-Id: <199701281830.LAA08629@phaeton.artisoft.com> Subject: Re: progress report on connection problems To: shovey@buffnet.net (Steve) Date: Tue, 28 Jan 1997 11:30:09 -0700 (MST) Cc: terry@lambert.org, robert@nanguo.chalmers.com.au, freebsd-questions@freebsd.org, freebsd-isp@freebsd.org, hackers@freebsd.org In-Reply-To: from "Steve" at Jan 28, 97 01:08:44 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > 1) Contact the vendor for a fix; one probably exists. > > > > 2) If no fix is available, turn extension off on the FreeBSD > > system, and submit a bug report to the vendor so that a > > fix will happen. > > Turning extensions off does not stop the problem. Does the remote system triggering the problem have extensions enabled? I believe the extensions setting in FreeBSD just changes the default state, and if a remote host negotiates them on, they will be on for that session. Are extensions off on *both* ends? If so, *exactly* what do you see happening, and for what programs? 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 Jan 28 10:54:18 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA01779 for hackers-outgoing; Tue, 28 Jan 1997 10:54:18 -0800 (PST) Received: from gdi.uoregon.edu (gdi.uoregon.edu [128.223.170.30]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA01774 for ; Tue, 28 Jan 1997 10:54:16 -0800 (PST) Received: from localhost (dwhite@localhost) by gdi.uoregon.edu (8.8.4/8.6.12) with SMTP id KAA13963; Tue, 28 Jan 1997 10:53:43 -0800 (PST) Date: Tue, 28 Jan 1997 10:53:43 -0800 (PST) From: Doug White X-Sender: dwhite@localhost Reply-To: Doug White To: Dan Nelson cc: hackers@FreeBSD.ORG Subject: Re: Erroneous Ierrs from vx0 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 22 Jan 1997, Dan Nelson wrote: > I've noticed that when I run 3Com's DOS config program that the card > reports 5K of receive buffers and 3K of send buffers. Is this really > all there is on the card? If so, I can understand the NFS problem, but > I can't believe a 100mbit card woud have such small buffers. A followup to this. I went twiddling around in the 3c90x config program. The option 'Network Driver Optimization' has a direct bearing on this. I set it from .. I think 'better performance' to 'normal' and the bad packets disappeared. FYI. Doug White | University of Oregon Internet: dwhite@resnet.uoregon.edu | Residence Networking Assistant http://gladstone.uoregon.edu/~dwhite | Computer Science Major From owner-freebsd-hackers Tue Jan 28 11:01:48 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA02430 for hackers-outgoing; Tue, 28 Jan 1997 11:01:48 -0800 (PST) Received: from buffnet4.buffnet.net (root@buffnet4.buffnet.net [205.246.19.13]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id LAA02425; Tue, 28 Jan 1997 11:01:45 -0800 (PST) Received: from buffnet1.buffnet.net (mmdf@buffnet1.buffnet.net [205.246.19.10]) by buffnet4.buffnet.net (8.6.12/8.6.9) with SMTP id NAA06657; Tue, 28 Jan 1997 13:44:28 -0500 Received: from buffnet11.buffnet.net by buffnet1.buffnet.net id aa26569; 28 Jan 97 14:02 EST Date: Tue, 28 Jan 1997 14:02:15 -0500 (EST) From: Steve To: Terry Lambert cc: robert@nanguo.chalmers.com.au, freebsd-questions@freebsd.org, freebsd-isp@freebsd.org, hackers@freebsd.org Subject: Re: progress report on connection problems In-Reply-To: <199701281830.LAA08629@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 28 Jan 1997, Terry Lambert wrote: > > > 1) Contact the vendor for a fix; one probably exists. > > > > > > 2) If no fix is available, turn extension off on the FreeBSD > > > system, and submit a bug report to the vendor so that a > > > fix will happen. > > > > Turning extensions off does not stop the problem. > > Does the remote system triggering the problem have extensions enabled? Nope. > > Are extensions off on *both* ends? If so, *exactly* what do you > see happening, and for what programs? Yup - It was with users - only some - same problem as the other guy has.. They would connect to the news server, and not be able to pull headers - or to the web server, and get the text but not the graphics. It would stall. The bandaide I put on it was to number all freebsd boxes on class C's other than those of my annexes, forcing the packets thru my cisco. Everything cleared. From owner-freebsd-hackers Tue Jan 28 11:13:28 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA03152 for hackers-outgoing; Tue, 28 Jan 1997 11:13:28 -0800 (PST) Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA03138 for ; Tue, 28 Jan 1997 11:13:24 -0800 (PST) Received: (from henrich@localhost) by crh.cl.msu.edu (8.8.4/8.8.4) id OAA29909; Tue, 28 Jan 1997 14:13:11 -0500 (EST) From: Charles Henrich Message-Id: <199701281913.OAA29909@crh.cl.msu.edu> Subject: Re: setpwfile: Why was it removed? To: joerg_wunsch@uriah.heep.sax.de Date: Tue, 28 Jan 1997 14:13:11 -0500 (EST) Cc: freebsd-hackers@freebsd.org In-Reply-To: from J Wunsch at "Jan 25, 97 05:29:33 pm" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > If you look into the CVS history and the HISTORY section, you will > notice that it has never been a part of 4.4BSD. > > Btw., which file would you pass to it? There are 4 files to mention, > pwd.db, spwd.db, master.passwd, and passwd. Give it a directory? or four arguments? -Crh Charles Henrich Michigan State University henrich@msu.edu http://pilot.msu.edu/~henrich From owner-freebsd-hackers Tue Jan 28 11:27:11 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA04290 for hackers-outgoing; Tue, 28 Jan 1997 11:27:11 -0800 (PST) Received: from ns.ge.com (ns.ge.com [192.35.39.24]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA04272; Tue, 28 Jan 1997 11:27:04 -0800 (PST) Received: from thomas.ge.com (thomas.ge.com [3.47.28.21]) by ns.ge.com (8.8.4/8.7.3) with ESMTP id OAA26048; Tue, 28 Jan 1997 14:21:06 -0500 (EST) Received: from crissy.gemis.ge.com (crissy-ether.gemis.ge.com [3.29.7.204]) by thomas.ge.com (8.8.4/8.7.5) with SMTP id OAA07246; Tue, 28 Jan 1997 14:23:54 -0500 (EST) Received: from terrapin.salem.ge.com (terrapin.salem.ge.com [3.29.6.145]) by crissy.gemis.ge.com (8.6.11/8.6.11) with ESMTP id OAA08092; Tue, 28 Jan 1997 14:15:04 -0500 Received: from combs.salem.ge.com (combs.salem.ge.com [3.29.5.200]) by terrapin.salem.ge.com (8.8.3/8.8.3) with ESMTP id OAA02045; Tue, 28 Jan 1997 14:13:55 -0500 (EST) Received: from localhost (steve@localhost) by combs.salem.ge.com (8.8.3/8.8.3) with SMTP id OAA00684; Tue, 28 Jan 1997 14:13:53 -0500 (EST) Date: Tue, 28 Jan 1997 14:13:53 -0500 (EST) From: "Stephen F. Combs" To: Steve cc: Terry Lambert , Robert Chalmers , freebsd-questions@FreeBSD.org, freebsd-isp@FreeBSD.org, hackers@FreeBSD.org Subject: Re: progress report on connection problems In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Then something else is wrong! I used to have to turn the tcp extensions off to connect to my annex but after upgrading to 10.1 it went away entirely! I've got about 400 users using my annex at this time, most from windoz[95-n/t], but quite a few using freebsd. works like a champ! ---- Stephen F. Combs Internet: CombsSF@Salem.GE.COM GE Industrial Systems Voice: 540.387.8828 Network Services Home: CombsSF-Home@Salem.GE.COM 1501 Roanoke Blvd FAX: 540.387.7106 Salem, VA 24153 LapTop: CombsSF-Mobile@Salem.GE.COM On Tue, 28 Jan 1997, Steve wrote: > Date: Tue, 28 Jan 1997 13:08:44 -0500 (EST) > From: Steve > To: Terry Lambert > Cc: Robert Chalmers , > freebsd-questions@FreeBSD.org, freebsd-isp@FreeBSD.org, > hackers@FreeBSD.org > Subject: Re: progress report on connection problems > > > > > 1) Contact the vendor for a fix; one probably exists. > > > > 2) If no fix is available, turn extension off on the FreeBSD > > system, and submit a bug report to the vendor so that a > > fix will happen. > > Turning extensions off does not stop the problem. > > From owner-freebsd-hackers Tue Jan 28 11:36:36 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA05085 for hackers-outgoing; Tue, 28 Jan 1997 11:36:36 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA05080 for ; Tue, 28 Jan 1997 11:36:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id LAA16507; Tue, 28 Jan 1997 11:36:05 -0800 (PST) Message-Id: <199701281936.LAA16507@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Petri Helenius cc: hal@vailsys.com, hackers@freebsd.org Subject: Re: best mtu for lo0? In-reply-to: Your message of "Tue, 28 Jan 1997 19:45:36 +0200." <199701281745.TAA25913@silver.sms.fi> From: David Greenman Reply-To: dg@root.com Date: Tue, 28 Jan 1997 11:36:05 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Petri Helenius wrote: > > > > > What's your lo0 MTU? If it's the 16384 that some > > > non-tcp-knowledgeable person put in sometime in the past > > > I think what you are seeing is called "TCP deadlock" which appears when > > > window size is equal or smaller than the MTU. This makes TCP to be ... > > Is this correct? I notice 2.1.6-R sets MTU for lo0 to 16384. Should > > this be reduced to 1500? Will it affect performance of aliased IP > > addresses, for which a static route through lo0 is usually specified? > >Want me to comment on this (I'm not on the hackers list any longer >though)? > >The above still stands true that if you set your TCPWIN < MTU you'll >experience TCP 'deadlock' which ends up being of horrible performance. Pete is likely correct that window < MTU is a problem (that's obvious, right?), but he's wrong that this is occuring in recent versions of FreeBSD. The send/receive windows are set to 3*MTU, and for lo0 this is 49152 bytes. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Tue Jan 28 12:05:20 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA06809 for hackers-outgoing; Tue, 28 Jan 1997 12:05:20 -0800 (PST) Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA06800 for ; Tue, 28 Jan 1997 12:05:17 -0800 (PST) Received: from spooky.rwwa.com (rwwa.com) by mail.crl.com with SMTP id AA17652 (5.65c/IDA-1.5 for ); Tue, 28 Jan 1997 12:04:46 -0800 Received: from spooky.rwwa.com (localhost.rwwa.com [127.0.0.1]) by spooky.rwwa.com (8.7.5/8.7.3) with ESMTP id PAA01969 for ; Tue, 28 Jan 1997 15:02:43 -0500 (EST) Message-Id: <199701282002.PAA01969@spooky.rwwa.com> X-Mailer: exmh version 1.6.9 8/22/96 To: freebsd-hackers@freebsd.org Subject: ATAPI: corrupted data? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 28 Jan 1997 15:02:42 -0500 From: Robert Withrow Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I didn't get anything on the newsgroup: I have a P6-200/VS440FX/2.1.5 system in which I have tried two different ATAPI CDROM drives (a Creative 8x and a toshiba 4x). I get corrupt data when I read large files (like FreeBSD distribution tarballs.) If I repeatedly mount/md5/dismount I get different MD5 checksums for large files each time. If I boot W95 and copy the file, then reboot FreeBSD, the MD5 checksums are OK. Since I have two IDE hard drives on the other channel of this system (working fine on FreeBSD) and the CDROM works on W95 I am reluctant to think the hardware is broken. I thought only the probing of ATAPI CDROM drives was broken. Is reading them (once probed) also broken, or what? ----------------------------------------------------------------------------- Robert Withrow, Tel: +1 617 592 8935, Net: witr@rwwa.COM From owner-freebsd-hackers Tue Jan 28 12:05:25 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA06832 for hackers-outgoing; Tue, 28 Jan 1997 12:05:25 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA06825 for ; Tue, 28 Jan 1997 12:05:22 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA08806; Tue, 28 Jan 1997 12:46:53 -0700 From: Terry Lambert Message-Id: <199701281946.MAA08806@phaeton.artisoft.com> Subject: Re: Erroneous Ierrs from vx0 To: dwhite@resnet.uoregon.edu Date: Tue, 28 Jan 1997 12:46:53 -0700 (MST) Cc: dnelson@emsphone.com, hackers@freebsd.org In-Reply-To: from "Doug White" at Jan 28, 97 10:53:43 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I've noticed that when I run 3Com's DOS config program that the card > > reports 5K of receive buffers and 3K of send buffers. Is this really > > all there is on the card? If so, I can understand the NFS problem, but > > I can't believe a 100mbit card woud have such small buffers. > > A followup to this. > > I went twiddling around in the 3c90x config program. The option 'Network > Driver Optimization' has a direct bearing on this. I set it from .. I > think 'better performance' to 'normal' and the bad packets disappeared. Most cards have a "server" setting, which is a bad thing to select; it's for using the cords in a NetWare server, and optimizes the buffer arrangement for the NetWare server stack utilization patterns (which are moderately pessimal, since they depends on cooperative tasking for thread switching, so can run to completion). 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 Jan 28 12:06:56 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA06935 for hackers-outgoing; Tue, 28 Jan 1997 12:06:56 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA06922; Tue, 28 Jan 1997 12:06:53 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA08815; Tue, 28 Jan 1997 12:48:39 -0700 From: Terry Lambert Message-Id: <199701281948.MAA08815@phaeton.artisoft.com> Subject: Re: progress report on connection problems To: shovey@buffnet.net (Steve) Date: Tue, 28 Jan 1997 12:48:39 -0700 (MST) Cc: terry@lambert.org, robert@nanguo.chalmers.com.au, freebsd-questions@freebsd.org, freebsd-isp@freebsd.org, hackers@freebsd.org In-Reply-To: from "Steve" at Jan 28, 97 02:02:15 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Are extensions off on *both* ends? If so, *exactly* what do you > > see happening, and for what programs? > > Yup - It was with users - only some - same problem as the other guy has.. > They would connect to the news server, and not be able to pull headers - > or to the web server, and get the text but not the graphics. It would > stall. > > The bandaide I put on it was to number all freebsd boxes on class C's > other than those of my annexes, forcing the packets thru my cisco. > Everything cleared. And you are positive that you are using Annex software 10.1 or better, and/or none of the machines are sending data in the SYN packets? The TCP extensions do not bear on whether or not data will be sent in the SYN packet, I don't think. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Jan 28 12:56:35 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA09522 for hackers-outgoing; Tue, 28 Jan 1997 12:56:35 -0800 (PST) Received: from narcissus.ml.org (root@brosenga.st.pitzer.edu [134.173.120.201]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA09506 for ; Tue, 28 Jan 1997 12:56:03 -0800 (PST) Received: (from ben@localhost) by narcissus.ml.org (8.7.5/8.7.3) id MAA27936; Tue, 28 Jan 1997 12:54:28 -0800 (PST) Date: Tue, 28 Jan 1997 12:54:28 -0800 (PST) From: Snob Art Genre To: Robert Withrow cc: freebsd-hackers@FreeBSD.org Subject: Re: ATAPI: corrupted data? In-Reply-To: <199701282002.PAA01969@spooky.rwwa.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk This may be a dumb question but have you tried swapping out the IDE cable in favor of a [new | known good] one? On Tue, 28 Jan 1997, Robert Withrow wrote: > I didn't get anything on the newsgroup: > > I have a P6-200/VS440FX/2.1.5 system in which I have tried two > different ATAPI CDROM drives (a Creative 8x and a toshiba 4x). > I get corrupt data when I read large files (like FreeBSD distribution > tarballs.) If I repeatedly mount/md5/dismount I get different > MD5 checksums for large files each time. If I boot W95 and copy the > file, then reboot FreeBSD, the MD5 checksums are OK. > > Since I have two IDE hard drives on the other channel of this > system (working fine on FreeBSD) and the CDROM works on W95 I am > reluctant to think the hardware is broken. > > I thought only the probing of ATAPI CDROM drives was broken. Is > reading them (once probed) also broken, or what? > > ----------------------------------------------------------------------------- > Robert Withrow, Tel: +1 617 592 8935, Net: witr@rwwa.COM > > > Ben The views expressed above are not those of the Worker's Compensation Board of Queensland, Australia. From owner-freebsd-hackers Tue Jan 28 14:11:02 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA14240 for hackers-outgoing; Tue, 28 Jan 1997 14:11:02 -0800 (PST) Received: from panda.hilink.com.au (panda.hilink.com.au [203.2.144.5]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA14193; Tue, 28 Jan 1997 14:10:47 -0800 (PST) Received: (from danny@localhost) by panda.hilink.com.au (8.7.6/8.7.3) id JAA10781; Wed, 29 Jan 1997 09:14:51 +1100 (EST) Date: Wed, 29 Jan 1997 09:14:51 +1100 (EST) From: "Daniel O'Callaghan" To: Søren Schmidt cc: Robert Chalmers , freebsd-questions@freebsd.org, freebsd-isp@freebsd.org, hackers@freebsd.org Subject: Re: progress report on connection problems In-Reply-To: <199701281148.MAA17415@ravenock.cybercity.dk> 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 freefall.freebsd.org id OAA14200 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 28 Jan 1997, Søren Schmidt wrote: > In reply to Robert Chalmers who wrote: > [lots o descriptions deleted] > > I can connect to, and be connected to these OSs with no worries. > > I have tried setting tcp_extensions NO and YES. If set to YES, I am unable > > > > The only constant is the Annex. However, why does it pass _most_ traffic, > > if it is the fault of the Annex, and only fail on some.? > > Hmm, I'm seeing problems with the Annex's too if I run with tcp_extensions > enabled. Somehow the Annex's turn some of the trafic into "chernobyl" > packets (ie all lamps and bells set). This is only a problem > if the other end also supports the extensions (ie a FreeBSD box). > However all problems dissapear if I disable the extensions. > I guess the only solution is to bug the vendor to implement a > modern IP stackc... Just wondering, but would it be possible to detect these bogus packets from the Annex and revert to no-rfc1323 for the connection? And for Robert: If you read RFC 1323, you'll find that it deals with TCP sequence number wrapping on log fat pipes, so unless you have a 155 Mbps ATM connection to Melbourne, you won't need RFC 1323. After having problems like this with someone in Melbourne who could not send me mail, or read my WWW server, I have disabled RFC 1323 extensions on my main boxes so that Annex-crippled people around the world can talk to me. My 512kbps link means that there is no point to the extensions anyway I'll send you the RFC. regards, Danny From owner-freebsd-hackers Tue Jan 28 14:36:20 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA15548 for hackers-outgoing; Tue, 28 Jan 1997 14:36:20 -0800 (PST) Received: from panda.hilink.com.au (panda.hilink.com.au [203.2.144.5]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA15527; Tue, 28 Jan 1997 14:36:12 -0800 (PST) Received: (from danny@localhost) by panda.hilink.com.au (8.7.6/8.7.3) id JAA10906; Wed, 29 Jan 1997 09:40:22 +1100 (EST) Date: Wed, 29 Jan 1997 09:40:21 +1100 (EST) From: "Daniel O'Callaghan" To: Steve cc: Robert Chalmers , FreeBSD ISP , hackers@freebsd.org Subject: RFC 1323 default settings (was Re: progress report on connection problems) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 28 Jan 1997, Steve wrote: [ Robert writes about his problem with FreeBSD machines and his Annex] > > I had similar problems using annexes as term servers with user - and have > posted numerous times that this problem only exists with freebsd - sco, > linux, etc doesnt have trouble - only every time I post it I get bashed > about the head and lectured on freebsd having perfect tcp/ip and > everything else in the world having faulty tcp/ip. Well, turns out that a Linux 2.0 box also stalled on this. However, methinks it might be time to raise the issue of default settings for RFC 1323 extensions in FreeBSD boxes. Since RFC 1323 deals with long fat pipes, which very few of us have, it would make sense to turn the extensions off in the shipped /etc/sysconfig. Those people who are communicating with TCP between the two ends of a 1.5 Mbps satellite link, or an intercontinental 45 Mbps link, probably know who they are and can turn the extensions on. I know that some people in the continental USA can claim a 45 Mbps path to their favourite ftp site 4 states away, but surely those paths are used by others, reducing the 'fatness' of the pipe for RFC 1323 purposes. Local area ATM might be 'fat' but generally is not 'long' enough to cause the problems with RFC 1323 addresses. Leaving the extensions on by default causes much grief for people with old Annexes, prevents people whose ISPs use Annexes from reading FreeBSD box web pages or sending mail to FreeBSD boxes, and generates enormous amounts of traffic on the FreeBSD mailing lists. regards, Danny From owner-freebsd-hackers Tue Jan 28 14:45:14 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA16017 for hackers-outgoing; Tue, 28 Jan 1997 14:45:14 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA16007; Tue, 28 Jan 1997 14:45:07 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id JAA13081; Wed, 29 Jan 1997 09:13:32 +1030 (CST) From: Michael Smith Message-Id: <199701282243.JAA13081@genesis.atrad.adelaide.edu.au> Subject: Re: progress report on connection problems In-Reply-To: from Steve at "Jan 28, 97 01:08:44 pm" To: shovey@buffnet.net (Steve) Date: Wed, 29 Jan 1997 09:13:31 +1030 (CST) Cc: terry@lambert.org, robert@nanguo.chalmers.com.au, freebsd-questions@freebsd.org, freebsd-isp@freebsd.org, 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Steve stands accused of saying: > > > > 1) Contact the vendor for a fix; one probably exists. > > > > 2) If no fix is available, turn extension off on the FreeBSD > > system, and submit a bug report to the vendor so that a > > fix will happen. > > Turning extensions off does not stop the problem. Ah, but it does. It's just that other FreeBSD systems (like Yahoo) still have them turned on, so the Annex is dropping its guts regardless. As has been mentioned, the _correct_ response is to tell your provider that their Annex is _BROKEN_, and that they need to upgrade its software (which I believe is a free exercise, but you can ransack Xylogics' website for details there) preferably before you take your business elsewhere. -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Tue Jan 28 14:45:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA16117 for hackers-outgoing; Tue, 28 Jan 1997 14:45:32 -0800 (PST) Received: from panda.hilink.com.au (panda.hilink.com.au [203.2.144.5]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA16008; Tue, 28 Jan 1997 14:45:07 -0800 (PST) Received: (from danny@localhost) by panda.hilink.com.au (8.7.6/8.7.3) id JAA10980; Wed, 29 Jan 1997 09:50:41 +1100 (EST) Date: Wed, 29 Jan 1997 09:50:40 +1100 (EST) From: "Daniel O'Callaghan" To: Tom Samplonius cc: bsd , FreeBSD ISP , hackers@freebsd.org Subject: Re: progress report on connection problems In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 28 Jan 1997, Tom Samplonius wrote: > > FreeBSD implements T/TCP. You can disable this via by turning > tcp_extensions off. SCO, Linux do not implement T/TCP, which is to their > disadvantage. T/TCP gives you big wins if opening and closing a lot of > TCP connections. > > Broken boxes like the Annex don't like T/TCP (it is broken, because if > the Annex properly implemented IP/TCP, it wouldn't have a problem). Newer > software releases for the Annex fix this problem. > > I'm not aware of any equipment that doesn't like T/TCP that couldn't be > fixed with a software upgrade. We are not using T/TCP. That is RFC 1644. T/TCP may well be broken in Annexes, but it is RFC 1323 extensions which cause the current grief. regards, Danny From owner-freebsd-hackers Tue Jan 28 15:33:18 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA18721 for hackers-outgoing; Tue, 28 Jan 1997 15:33:18 -0800 (PST) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id PAA18716; Tue, 28 Jan 1997 15:33:14 -0800 (PST) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id XAA03832; Tue, 28 Jan 1997 23:51:17 +0100 From: Luigi Rizzo Message-Id: <199701282251.XAA03832@labinfo.iet.unipi.it> Subject: Re: RFC 1323 default settings (was Re: progress report on connection problems) To: danny@panda.hilink.com.au (Daniel O'Callaghan) Date: Tue, 28 Jan 1997 23:51:17 +0100 (MET) Cc: shovey@buffnet.net, robert@nanguo.chalmers.com.au, freebsd-isp@freebsd.org, hackers@freebsd.org In-Reply-To: from "Daniel O'Callaghan" at Jan 29, 97 09:40:02 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Since RFC 1323 deals with long fat pipes, which very few of us have, it > would make sense to turn the extensions off in the shipped /etc/sysconfig. agreed, although it is sad that such an approach practically bans any TCP extension because some broken equipment won't support it. > Those people who are communicating with TCP between the two ends of a 1.5 > Mbps satellite link, or an intercontinental 45 Mbps link, probably know > who they are and can turn the extensions on. I know that some people in not that it helps much since in many cases the application have hardwired settings for small (<64K) windows. As a matter of fact, has anyone been able to _actually_ make use of >64K windows (i.e. withouth the system changing settings under your feet) ? If yes, which version of FreeBSD ? > 'fatness' of the pipe for RFC 1323 purposes. Local area ATM might be > 'fat' but generally is not 'long' enough to cause the problems with RFC fast ethernet also peaks around 10 KB/ms, which means that going through a couple of (fast) local routers (not switches) might as well bring you close to BW*RTT > 64K 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 Tue Jan 28 15:40:26 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA19282 for hackers-outgoing; Tue, 28 Jan 1997 15:40:26 -0800 (PST) Received: from noc.msc.edu (noc.msc.edu [137.66.12.254]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id PAA19265; Tue, 28 Jan 1997 15:40:21 -0800 (PST) Received: from ww.msc.edu by noc.msc.edu (5.65/MSC/v3.0.1(920324)) id AA17172; Tue, 28 Jan 97 17:40:19 -0600 From: jpt@msc.edu (Joseph Thomas) Received: (jpt@localhost) by ww.msc.edu (8.7.1/8.6.6) id RAA10860; Tue, 28 Jan 1997 17:40:18 -0600 (CST) Message-Id: <199701282340.RAA10860@ww.msc.edu> Subject: Re: RFC 1323 default settings (was Re: progress report on connection problems) To: danny@panda.hilink.com.au (Daniel O'Callaghan) Date: Tue, 28 Jan 1997 17:40:18 -0600 (CST) Cc: shovey@buffnet.net, robert@nanguo.chalmers.com.au, freebsd-isp@freebsd.org, hackers@freebsd.org In-Reply-To: from "Daniel O'Callaghan" at Jan 29, 97 09:40:21 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > > On Tue, 28 Jan 1997, Steve wrote: > > [ Robert writes about his problem with FreeBSD machines and his Annex] > > > > I had similar problems using annexes as term servers with user - and have > > posted numerous times that this problem only exists with freebsd - sco, > > linux, etc doesnt have trouble - only every time I post it I get bashed > > about the head and lectured on freebsd having perfect tcp/ip and > > everything else in the world having faulty tcp/ip. > > Well, turns out that a Linux 2.0 box also stalled on this. However, > methinks it might be time to raise the issue of default settings for RFC > 1323 extensions in FreeBSD boxes. > > Since RFC 1323 deals with long fat pipes, which very few of us have, it > would make sense to turn the extensions off in the shipped /etc/sysconfig. > Those people who are communicating with TCP between the two ends of a 1.5 > Mbps satellite link, or an intercontinental 45 Mbps link, probably know > who they are and can turn the extensions on. I know that some people in > the continental USA can claim a 45 Mbps path to their favourite ftp site 4 > states away, but surely those paths are used by others, reducing the > 'fatness' of the pipe for RFC 1323 purposes. Local area ATM might be > 'fat' but generally is not 'long' enough to cause the problems with RFC > 1323 addresses. As a data point - running a local-area ATM with "out of the box" parameters (for 2.2 this looks to be 16K windows with no-scaling), I get 60 KB/s out of the box vs 3.0-3.5 MB/s into the box, [notice the really bad discrepancy] via ftp. With larger windows (60KB), I can get in the range of 3.5-4.0 MB/s [either 'put xxx /dev/null' or 'get xxx /dev/null' so local disk access is somewhat unrelated. That is, the numbers don't vary much if I'm sending from local disk or receiving to /dev/null.] Using ttcp (tcp user application, memory to memory), I've transmitted close to 70 Mb/s, in the "local-area". I'm not sure that getting twice the throughput counts as being 'not long enough'. [I'm simply providing this as a data point for the discussion, not attempting or interested in arguing for or against either side.] > > Leaving the extensions on by default causes much grief for people with old > Annexes, prevents people whose ISPs use Annexes from reading FreeBSD box > web pages or sending mail to FreeBSD boxes, and generates enormous amounts > of traffic on the FreeBSD mailing lists. > > regards, > > Danny > -- Joseph Thomas E/Mail: jpt@msc.edu Minnesota Supercomputer Center, Inc. jpt@magic.net 1200 Washington Ave So. Tel: +1 612 337 3558 Minneapolis, MN 55415-1227 FAX: +1 612 337 3400 You cannot see what I see because you see what you see. You cannot know what I know because you know what you know. "Mostly Harmless" - Douglas Adams From owner-freebsd-hackers Tue Jan 28 15:50:38 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA19818 for hackers-outgoing; Tue, 28 Jan 1997 15:50:38 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA19806; Tue, 28 Jan 1997 15:50:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id PAA17739; Tue, 28 Jan 1997 15:48:18 -0800 (PST) Message-Id: <199701282348.PAA17739@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Michael Smith cc: shovey@buffnet.net (Steve), terry@lambert.org, robert@nanguo.chalmers.com.au, freebsd-questions@freebsd.org, freebsd-isp@freebsd.org, hackers@freebsd.org Subject: Re: progress report on connection problems In-reply-to: Your message of "Wed, 29 Jan 1997 09:13:31 +1030." <199701282243.JAA13081@genesis.atrad.adelaide.edu.au> From: David Greenman Reply-To: dg@root.com Date: Tue, 28 Jan 1997 15:48:18 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Steve stands accused of saying: >> > >> > 1) Contact the vendor for a fix; one probably exists. >> > >> > 2) If no fix is available, turn extension off on the FreeBSD >> > system, and submit a bug report to the vendor so that a >> > fix will happen. >> >> Turning extensions off does not stop the problem. > >Ah, but it does. It's just that other FreeBSD systems (like Yahoo) still >have them turned on, so the Annex is dropping its guts regardless. > >As has been mentioned, the _correct_ response is to tell your provider >that their Annex is _BROKEN_, and that they need to upgrade its >software (which I believe is a free exercise, but you can ransack >Xylogics' website for details there) preferably before you take your >business elsewhere. The traces that have been posted don't show that as being the problem. TCP extensions cause problems at connection startup and the traces are showing that a regular data packet is being dropped. One possible reason that this problem is being noticed when FreeBSD machines are involved might be due to FreeBSD's Path MTU Discovery causing the packets to be large. It seems likely to me that the Annex can't deal with large packets some or all of the time and drops the packet rather than fragmenting and/or without sending the proper ICMP message (which would break MTU discovery). -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Tue Jan 28 15:58:28 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA20588 for hackers-outgoing; Tue, 28 Jan 1997 15:58:28 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA20573; Tue, 28 Jan 1997 15:58:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id PAA17781; Tue, 28 Jan 1997 15:54:34 -0800 (PST) Message-Id: <199701282354.PAA17781@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Michael Smith cc: shovey@buffnet.net (Steve), terry@lambert.org, robert@nanguo.chalmers.com.au, freebsd-questions@FreeBSD.ORG, freebsd-isp@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: progress report on connection problems In-reply-to: Your message of "Wed, 29 Jan 1997 09:13:31 +1030." <199701282243.JAA13081@genesis.atrad.adelaide.edu.au> From: David Greenman Reply-To: dg@root.com Date: Tue, 28 Jan 1997 15:54:34 -0800 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Steve stands accused of saying: >> > >> > 1) Contact the vendor for a fix; one probably exists. >> > >> > 2) If no fix is available, turn extension off on the FreeBSD >> > system, and submit a bug report to the vendor so that a >> > fix will happen. >> >> Turning extensions off does not stop the problem. > >Ah, but it does. It's just that other FreeBSD systems (like Yahoo) still >have them turned on, so the Annex is dropping its guts regardless. Oh, and BTW, only one side needs to have them disabled for them to be disabled. I highly doubt that Yahoo has the extensions enabled, anyway. I certainly don't on wcarchive.cdrom.com. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Tue Jan 28 16:01:00 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA20980 for hackers-outgoing; Tue, 28 Jan 1997 16:01:00 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA20970; Tue, 28 Jan 1997 16:00:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id QAA17825; Tue, 28 Jan 1997 16:00:13 -0800 (PST) Message-Id: <199701290000.QAA17825@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: "Daniel O'Callaghan" cc: Steve , Robert Chalmers , FreeBSD ISP , hackers@freebsd.org Subject: Re: RFC 1323 default settings (was Re: progress report on connection problems) In-reply-to: Your message of "Wed, 29 Jan 1997 09:40:21 +1100." From: David Greenman Reply-To: dg@root.com Date: Tue, 28 Jan 1997 16:00:13 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Since RFC 1323 deals with long fat pipes, which very few of us have, it >would make sense to turn the extensions off in the shipped /etc/sysconfig. Actually, the main reason it is on is for the other half of RFC 1323 which specifies the "time stamp" extensions for better round-trip time estimates. Unfortunately, I agree with you, however, that RFC 1323 extensions should be disabled by default. The RFC 1644 extensions (T/TCP), however, should remain enabled by default. This will only break "finger", and is useful for keeping vendors TCP stacks compliant. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Tue Jan 28 16:24:54 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA23569 for hackers-outgoing; Tue, 28 Jan 1997 16:24:54 -0800 (PST) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA23564 for ; Tue, 28 Jan 1997 16:24:48 -0800 (PST) Received: from awfulhak.demon.co.uk (localhost.coverform.lan [127.0.0.1]) by awfulhak.demon.co.uk (8.8.4/8.7.3) with ESMTP id AAA23335 for ; Wed, 29 Jan 1997 00:24:45 GMT Message-Id: <199701290024.AAA23335@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: hackers@freebsd.org Subject: PR2347 - recursive malloc() in ppp Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 Jan 1997 00:24:45 +0000 From: Brian Somers Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Anyone interested in running the "fixed" version? It seems ok on my machine. All I've done is made the "work" happen in a call from the top level read-a-packet loop, and triggered it via a variable that's set when an alarm happens. If anyone's interested, there's a compiled copy on freefall in ~brian/src/usr.sbin/ppp Cheers -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Tue Jan 28 16:31:07 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA23829 for hackers-outgoing; Tue, 28 Jan 1997 16:31:07 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA23822; Tue, 28 Jan 1997 16:31:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id QAA17983; Tue, 28 Jan 1997 16:30:11 -0800 (PST) Message-Id: <199701290030.QAA17983@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: jpt@msc.edu (Joseph Thomas) cc: danny@panda.hilink.com.au (Daniel O'Callaghan), shovey@buffnet.net, robert@nanguo.chalmers.com.au, freebsd-isp@freebsd.org, hackers@freebsd.org Subject: Re: RFC 1323 default settings (was Re: progress report on connection problems) In-reply-to: Your message of "Tue, 28 Jan 1997 17:40:18 CST." <199701282340.RAA10860@ww.msc.edu> From: David Greenman Reply-To: dg@root.com Date: Tue, 28 Jan 1997 16:30:11 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > As a data point - running a local-area ATM with "out of the box" >parameters (for 2.2 this looks to be 16K windows with no-scaling), I get >60 KB/s out of the box vs 3.0-3.5 MB/s into the box, [notice the really Yikes, that's really awful. What kind of round-trip times are you seeing? -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Tue Jan 28 16:32:53 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA24300 for hackers-outgoing; Tue, 28 Jan 1997 16:32:53 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA24275; Tue, 28 Jan 1997 16:32:43 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA09502; Tue, 28 Jan 1997 17:13:27 -0700 From: Terry Lambert Message-Id: <199701290013.RAA09502@phaeton.artisoft.com> Subject: Re: RFC 1323 default settings (was Re: progress report on connection problems) To: danny@panda.hilink.com.au (Daniel O'Callaghan) Date: Tue, 28 Jan 1997 17:13:27 -0700 (MST) Cc: shovey@buffnet.net, robert@nanguo.chalmers.com.au, freebsd-isp@freebsd.org, hackers@freebsd.org In-Reply-To: from "Daniel O'Callaghan" at Jan 29, 97 09:40:21 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Leaving the extensions on by default causes much grief for people with old > Annexes, prevents people whose ISPs use Annexes from reading FreeBSD box > web pages or sending mail to FreeBSD boxes, and generates enormous amounts > of traffic on the FreeBSD mailing lists. You forgot "and gets Annex box owners to take advantage of the free upgrade so the problem goes away". 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 Jan 28 16:35:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA24839 for hackers-outgoing; Tue, 28 Jan 1997 16:35:32 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA24834; Tue, 28 Jan 1997 16:35:28 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA09514; Tue, 28 Jan 1997 17:16:05 -0700 From: Terry Lambert Message-Id: <199701290016.RAA09514@phaeton.artisoft.com> Subject: Re: RFC 1323 default settings (was Re: progress report on connection problems) To: jpt@msc.edu (Joseph Thomas) Date: Tue, 28 Jan 1997 17:16:05 -0700 (MST) Cc: danny@panda.hilink.com.au, shovey@buffnet.net, robert@nanguo.chalmers.com.au, freebsd-isp@freebsd.org, hackers@freebsd.org In-Reply-To: <199701282340.RAA10860@ww.msc.edu> from "Joseph Thomas" at Jan 28, 97 05:40:18 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > As a data point - running a local-area ATM with "out of the box" > parameters (for 2.2 this looks to be 16K windows with no-scaling), I get > 60 KB/s out of the box vs 3.0-3.5 MB/s into the box, [notice the really > bad discrepancy] via ftp. With larger windows (60KB), I can get in the > range of 3.5-4.0 MB/s [either 'put xxx /dev/null' or 'get xxx /dev/null' > so local disk access is somewhat unrelated. That is, the numbers don't > vary much if I'm sending from local disk or receiving to /dev/null.] > > Using ttcp (tcp user application, memory to memory), I've transmitted > close to 70 Mb/s, in the "local-area". I'm not sure that getting twice > the throughput counts as being 'not long enough'. > > [I'm simply providing this as a data point for the discussion, not attempting > or interested in arguing for or against either side.] Uh, isn't 70/3.5 20 times, not 2 times? 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 Jan 28 16:46:57 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA25532 for hackers-outgoing; Tue, 28 Jan 1997 16:46:57 -0800 (PST) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA25522 for ; Tue, 28 Jan 1997 16:46:51 -0800 (PST) Received: from awfulhak.demon.co.uk (localhost.coverform.lan [127.0.0.1]) by awfulhak.demon.co.uk (8.8.4/8.7.3) with ESMTP id AAA00558 for ; Wed, 29 Jan 1997 00:46:48 GMT Message-Id: <199701290046.AAA00558@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: hackers@freebsd.org Subject: PR2347 - Oops - signals don't seem to interrupt the select()..... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 Jan 1997 00:46:47 +0000 From: Brian Somers Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Scrap that last message.... :( -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Tue Jan 28 17:23:00 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA28108 for hackers-outgoing; Tue, 28 Jan 1997 17:23:00 -0800 (PST) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA28093 for ; Tue, 28 Jan 1997 17:22:54 -0800 (PST) Received: from awfulhak.demon.co.uk (localhost.coverform.lan [127.0.0.1]) by awfulhak.demon.co.uk (8.8.4/8.7.3) with ESMTP id BAA01460 for ; Wed, 29 Jan 1997 01:07:39 GMT Message-Id: <199701290107.BAA01460@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 cc: hackers@freebsd.org Subject: Re: PR2347 - Oops - signals don't seem to interrupt the select()..... In-reply-to: Your message of "Wed, 29 Jan 1997 00:46:47 GMT." <199701290046.AAA00558@awfulhak.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 Jan 1997 01:07:39 +0000 From: Brian Somers Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Scrap that last message.... :( > Rubbish - yes they do ! The new code in ~brian/src/usr.sbin/ppp seems to be ok now. Anyone care to test ? Thanks. I'll run it for a few days at home and see if it holds up. -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Tue Jan 28 17:35:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA29330 for hackers-outgoing; Tue, 28 Jan 1997 17:35:01 -0800 (PST) Received: from packfish.gateway.net.hk (john@packfish.gateway.net.hk [202.76.19.16]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA29270; Tue, 28 Jan 1997 17:34:45 -0800 (PST) Received: (from john@localhost) by packfish.gateway.net.hk (8.8.3/8.7.3) id JAA16436; Wed, 29 Jan 1997 09:32:36 +0800 (HKT) Date: Wed, 29 Jan 1997 09:32:36 +0800 (HKT) From: John Beukema To: Steve cc: Terry Lambert , robert@nanguo.chalmers.com.au, freebsd-questions@freebsd.org, freebsd-isp@freebsd.org, hackers@freebsd.org Subject: Re: progress report on connection problems In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 28 Jan 1997, Steve wrote: > On Tue, 28 Jan 1997, Terry Lambert wrote: > > > > > 1) Contact the vendor for a fix; one probably exists. > > > > > > > > 2) If no fix is available, turn extension off on the FreeBSD > > > > system, and submit a bug report to the vendor so that a > > > > fix will happen. > > > > > > Turning extensions off does not stop the problem. > > > > Does the remote system triggering the problem have extensions enabled? > > Nope. > > > > > Are extensions off on *both* ends? If so, *exactly* what do you > > see happening, and for what programs? > > Yup - It was with users - only some - same problem as the other guy has.. > They would connect to the news server, and not be able to pull headers - > or to the web server, and get the text but not the graphics. It would ^^^^^^ sounds like software handshaking enabled jbeukema > stall. > > The bandaide I put on it was to number all freebsd boxes on class C's > other than those of my annexes, forcing the packets thru my cisco. > Everything cleared. > > From owner-freebsd-hackers Tue Jan 28 18:20:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA01144 for hackers-outgoing; Tue, 28 Jan 1997 18:20:49 -0800 (PST) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA01139 for ; Tue, 28 Jan 1997 18:20:45 -0800 (PST) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id SAA11106; Tue, 28 Jan 1997 18:18:47 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma011104; Tue Jan 28 18:18:24 1997 Received: (from archie@localhost) by bubba.whistle.com (8.7.5/8.6.12) id SAA21188; Tue, 28 Jan 1997 18:18:24 -0800 (PST) From: Archie Cobbs Message-Id: <199701290218.SAA21188@bubba.whistle.com> Subject: Re: ipdivert & masqd In-Reply-To: <199701251842.SAA11494@awfulhak.demon.co.uk> from Brian Somers at "Jan 25, 97 06:42:20 pm" To: brian@awfulhak.demon.co.uk (Brian Somers) Date: Tue, 28 Jan 1997 18:18:24 -0800 (PST) Cc: hackers@freebsd.org, ari.suutari@ps.carel.fi, cmott@srv.net 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Can I take it from you recent email to the hackers list that > > you solved the problem? > > Nope - as Ari Suutari wrote to me and said: > Hi, > > About two sockets - you might also need them. > My first version used also only one socket, but there > were some cases where kernel packet filtering loop > avoidance code was confused when incoming and outgoing > packets were put into same socket. The result was that > some packets were not diverted which in turn resulted > in connection failures. With separate sockets for > incoming and outgoing packets everything works fine. > > The idea in natd is that user makes modifications in > /etc/rc.firewall to set it up. The test script is only > for testing - you are not expected to use it for anything else. > (perhaps I should mention this in README file). > > Both these main programs are very much alike for obvious > reasons: all the brains is in the code written by Charles. > > Ari S. > > On investigation, he's correct. Tcp & udp return setup packets coming into > the machine with masqd running seem to disappear - masqd sees them, but when > it injects them back into the divert socket they disappear (the app never > sees them). > > This shows itself when you try to initiate a tcp/udp connection through the > divert sockets from the machine running masqd.... a timeout occurs. However, > machines that are having packets forwarded through the masqd machine are fine. > I'll have a look at the divert code and see if I can come up with anything > interresting. Under which version(s) of FreeBSD are you guys having this problem ? I'm trying to track it down... Thanks, -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Tue Jan 28 18:49:12 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA02264 for hackers-outgoing; Tue, 28 Jan 1997 18:49:12 -0800 (PST) Received: from spoon.beta.com (root@[199.165.180.33]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA02259 for ; Tue, 28 Jan 1997 18:49:07 -0800 (PST) Received: from spoon.beta.com (mcgovern@localhost [127.0.0.1]) by spoon.beta.com (8.8.4/8.6.9) with ESMTP id VAA04040 for ; Tue, 28 Jan 1997 21:49:02 -0500 (EST) Message-Id: <199701290249.VAA04040@spoon.beta.com> To: hackers@freebsd.org Subject: Constructive criticism (was: bashing everyone for fun and profit) Date: Tue, 28 Jan 1997 21:49:02 -0500 From: "Brian J. McGovern" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Sorry about the title. I figured it would catch some attention, although the prior part is truely what I hope this will be... constructive criticism. Its roughly 9:30pm, and I'll be heading off to bed soon, as I have to get up at 5am tomorrow, so if this sounds half witted, blame the brain thats half asleep. Now the criticism.... I've been noticing, more an more, that FreeBSD has been/is being divided in to two camps. Basically, the "has", and the "has not". What I mean by this, is that there appears to be the core team, who kick butt making this stuff all work, then the people like me, who'd like to help out where they can, but seem to have an incredible time getting started. Lets take, for instance, the case of ports. I currently have a port of an older version of xtrek running on my box here at home, albiet you can't beam armies up to your ship, but I digress... I'd like to submit it in to the "games" section of the ports. However, I notice this great little file structure that allows you to type "make install clean", and bam! the application is made, installed, and the working space is cleaned up. Pretty slick. However, the bulk of the people I've dealt with using FreeBSD (most of them newbies, albiet, but...) just don't get it. I still have a hard time (which is why I haven't bothered doing it with xtrek) finding a "cookbook" way to set these up. I suspect that if I had a more straight forward way to do one, I'd probably pump about one out per week, and would be willing to take ports on request, and see if I could hack one in to shape (allowing a relative newbie to have his widget X that hasn't already been done). The second major area of concern in my eyes is device drivers. Someone pointed me to a section of handbook that dealt with doing it (supposedly), but it was terribly out of date. Back to ground zero. I hate to say it, but I'll never write the great american device driver, because I can't get the one that returns "A quick brown fox..." when you read from it installed and working. Not because the device driver wouldn't work. Its just that, in my limited experience, it'll take me hours to figure it out - hours that I could be spending writing the great american device driver. To make matters worse, the next version might have a completely different interface. Net result? I do nothing, because I feel my efforts will be obsoleted before I stand a chance in hell of finishing. I guess what I'm driving at is that although the documentation has been getting much better lately, several critical areas are lacking (mostly the technical-weenie stuff). Now, I also realize that the people best suited to writing these documents are the ones that are hard at work actually doing the work. However, on the flip side of the coin, if one were to take a modest 25% of their development time to write this documentation, and then a person (or group of people) could then work a project, being capable of no more than 25% of the work the original person would have done, you still haven't lost anything. If you could make this person or group 50% as efficient, you're now gaining 50% development for a 25% investment in cost (net gain, 25%). I guess what I'm getting at is this: There are a lot of us out here who would write man pages if we knew how to typeset them, those who would write neat utilities if we knew how to poll the information from the kernel (hell, I know about zillion people who'd love to know how to pull IO/up-down, config statistics from their Ethernet interfaces, for instance), those who would write drivers for widget X if they knew how to get them in to the kernel (there are a million books on writing drivers, but none that I know of that speak especially about FreeBSD)... Is it possible to get a commit from the right people to do this, so I can get rid of the conversation flow that looks like: Me: I have X, and would like to do Y. Where can I find docs on it? Them: Look at handbook section X.Y.Z. Me: It doesn't work. Them: Oh, yeah. Its out of date. Me: Then where can I get recent documentation. Them: There isn't any. Try looking at . Me: From owner-freebsd-hackers Tue Jan 28 18:56:23 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA02464 for hackers-outgoing; Tue, 28 Jan 1997 18:56:23 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA02459; Tue, 28 Jan 1997 18:56:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id SAA18540; Tue, 28 Jan 1997 18:53:34 -0800 (PST) Message-Id: <199701290253.SAA18540@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Terry Lambert cc: jpt@msc.edu (Joseph Thomas), danny@panda.hilink.com.au, shovey@buffnet.net, robert@nanguo.chalmers.com.au, freebsd-isp@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: RFC 1323 default settings (was Re: progress report on connection problems) In-reply-to: Your message of "Tue, 28 Jan 1997 17:16:05 MST." <199701290016.RAA09514@phaeton.artisoft.com> From: David Greenman Reply-To: dg@root.com Date: Tue, 28 Jan 1997 18:53:34 -0800 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> As a data point - running a local-area ATM with "out of the box" >> parameters (for 2.2 this looks to be 16K windows with no-scaling), I get >> 60 KB/s out of the box vs 3.0-3.5 MB/s into the box, [notice the really >> bad discrepancy] via ftp. With larger windows (60KB), I can get in the >> range of 3.5-4.0 MB/s [either 'put xxx /dev/null' or 'get xxx /dev/null' >> so local disk access is somewhat unrelated. That is, the numbers don't >> vary much if I'm sending from local disk or receiving to /dev/null.] >> >> Using ttcp (tcp user application, memory to memory), I've transmitted >> close to 70 Mb/s, in the "local-area". I'm not sure that getting twice >> the throughput counts as being 'not long enough'. >> >> [I'm simply providing this as a data point for the discussion, not attempting >> or interested in arguing for or against either side.] > >Uh, isn't 70/3.5 20 times, not 2 times? He's mixing bits and bytes. Pay attention to the case of the "b". -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Tue Jan 28 19:03:04 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA02748 for hackers-outgoing; Tue, 28 Jan 1997 19:03:04 -0800 (PST) Received: from goof.com (root@goof.com [128.173.246.47]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA02737 for ; Tue, 28 Jan 1997 19:02:57 -0800 (PST) Received: (from mmead@localhost) by goof.com (8.7.5/8.7.3) id WAA18981; Tue, 28 Jan 1997 22:02:06 -0500 (EST) From: "matthew c. mead" Message-Id: <199701290302.WAA18981@goof.com> Subject: Re: Driver for New SMC 10/100's To: jc@irbs.com (John Capo) Date: Tue, 28 Jan 1997 22:02:06 -0500 (EST) Cc: hackers@freebsd.org In-Reply-To: from "John Capo" at Jan 22, 97 09:37:26 am 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk John Capo writes: > Quoting matthew c. mead (mmead@goof.com): > > I saw a thread with a patch and a couple of source code > > suggestions to make the new revision of the SMC 10/100 Mbit > > ethernet cards work properly, however, I couldn't get them to > > work. Is there a known fix for 2.1.6? Thanks! > > > > ftp://ftp.irbs.com/FreeBSD/pci/if_de.c adds support for the SMC9332BDT > using a 21140A. I have not used this on a 100Mbs network. Works > fine at 10Mbs. > > John Capo > I've actually placed this in the kernel and replaced the ethernet card in the system with the SMC9332BDT I was trying to use before. It works great. Thanks again for the help! -matt -- Matthew C. Mead mmead@goof.com http://www.goof.com/~mmead/ From owner-freebsd-hackers Tue Jan 28 19:39:40 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA05021 for hackers-outgoing; Tue, 28 Jan 1997 19:39:40 -0800 (PST) Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA05015 for ; Tue, 28 Jan 1997 19:39:34 -0800 (PST) Received: from localhost.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.8.3/8.7.3) with SMTP id WAA00536; Tue, 28 Jan 1997 22:39:08 -0500 (EST) Message-Id: <199701290339.WAA00536@whizzo.transsys.com> X-Mailer: exmh version 2.0alpha 12/3/96 To: dg@root.com cc: Petri Helenius , hal@vailsys.com, hackers@freebsd.org From: "Louis A. Mamakos" Subject: Re: best mtu for lo0? References: <199701281936.LAA16507@root.com> In-reply-to: Your message of "Tue, 28 Jan 1997 11:36:05 PST." <199701281936.LAA16507@root.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 28 Jan 1997 22:39:08 -0500 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > Petri Helenius wrote: > > > > > > > What's your lo0 MTU? If it's the 16384 that some > > > > non-tcp-knowledgeable person put in sometime in the past > > > > I think what you are seeing is called "TCP deadlock" which appears when > > > > window size is equal or smaller than the MTU. This makes TCP to be > ... > > > Is this correct? I notice 2.1.6-R sets MTU for lo0 to 16384. Should > > > this be reduced to 1500? Will it affect performance of aliased IP > > > addresses, for which a static route through lo0 is usually specified? > > > >Want me to comment on this (I'm not on the hackers list any longer > >though)? > > > >The above still stands true that if you set your TCPWIN < MTU you'll > >experience TCP 'deadlock' which ends up being of horrible performance. > > Pete is likely correct that window < MTU is a problem (that's obvious, > right?), but he's wrong that this is occuring in recent versions of FreeBSD. > The send/receive windows are set to 3*MTU, and for lo0 this is 49152 bytes. Even on other systems which don't have this optimization, what's the big harm in running stop-and-wait on the loopback interface? It's not as if there are queues in the networks which you can fill and signficant propagation delays. I don't recall exactly how the queuing is done these days and how ipintr() is invoked, but I'll bet that before the loopback output function returns, there's a software interrupt invoked to process the packet just queued up for ip_input()... louie From owner-freebsd-hackers Tue Jan 28 19:47:41 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA05308 for hackers-outgoing; Tue, 28 Jan 1997 19:47:41 -0800 (PST) Received: from silver.sms.fi (silver.sms.fi [194.111.122.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA05303 for ; Tue, 28 Jan 1997 19:47:38 -0800 (PST) Received: (from pete@localhost) by silver.sms.fi (8.8.3/8.7.3) id FAA26989; Wed, 29 Jan 1997 05:47:24 +0200 (EET) Date: Wed, 29 Jan 1997 05:47:24 +0200 (EET) Message-Id: <199701290347.FAA26989@silver.sms.fi> From: Petri Helenius To: dg@root.com Cc: hal@vailsys.com, hackers@freebsd.org Subject: Re: best mtu for lo0? In-Reply-To: <199701281936.LAA16507@root.com> References: <199701281745.TAA25913@silver.sms.fi> <199701281936.LAA16507@root.com> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk David Greenman writes: > >Want me to comment on this (I'm not on the hackers list any longer > >though)? > > > >The above still stands true that if you set your TCPWIN < MTU you'll > >experience TCP 'deadlock' which ends up being of horrible performance. > > Pete is likely correct that window < MTU is a problem (that's obvious, > right?), but he's wrong that this is occuring in recent versions of FreeBSD. > The send/receive windows are set to 3*MTU, and for lo0 this is 49152 bytes. > When did this change? And doesn't the net.inet.tcp.recvspace and net.inet.tcp.sendspace variables have some doing in this anyway? Pete From owner-freebsd-hackers Tue Jan 28 20:13:58 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA06642 for hackers-outgoing; Tue, 28 Jan 1997 20:13:58 -0800 (PST) Received: from silver.sms.fi (silver.sms.fi [194.111.122.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA06637 for ; Tue, 28 Jan 1997 20:13:54 -0800 (PST) Received: (from pete@localhost) by silver.sms.fi (8.8.3/8.7.3) id GAA27096; Wed, 29 Jan 1997 06:13:49 +0200 (EET) Date: Wed, 29 Jan 1997 06:13:49 +0200 (EET) Message-Id: <199701290413.GAA27096@silver.sms.fi> From: Petri Helenius To: "Louis A. Mamakos" Cc: dg@root.com, hal@vailsys.com, hackers@freebsd.org Subject: Re: best mtu for lo0? In-Reply-To: <199701290339.WAA00536@whizzo.transsys.com> References: <199701281936.LAA16507@root.com> <199701290339.WAA00536@whizzo.transsys.com> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Louis A. Mamakos writes: > > > > Pete is likely correct that window < MTU is a problem (that's obvious, > > right?), but he's wrong that this is occuring in recent versions of FreeBSD. > > The send/receive windows are set to 3*MTU, and for lo0 this is 49152 bytes. > > Even on other systems which don't have this optimization, what's the big > harm in running stop-and-wait on the loopback interface? It's not as if > there are queues in the networks which you can fill and signficant > propagation delays. I don't recall exactly how the queuing is done > these days and how ipintr() is invoked, but I'll bet that before the > loopback output function returns, there's a software interrupt invoked to > process the packet just queued up for ip_input()... > You'll switch your process context between the receiving and sending process once every window. If you would be windowing, you'll doing that less often. Additionally, that gives usually better performance since you have processes to schedule if you for example have to page something in. Pete From owner-freebsd-hackers Tue Jan 28 20:16:11 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA06781 for hackers-outgoing; Tue, 28 Jan 1997 20:16:11 -0800 (PST) Received: from labs.usn.blaze.net.au (labs.usn.blaze.net.au [203.17.53.30]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA06716 for ; Tue, 28 Jan 1997 20:15:58 -0800 (PST) Received: (from davidn@localhost) by labs.usn.blaze.net.au (8.8.4/8.8.5) id PAA00739; Wed, 29 Jan 1997 15:15:34 +1100 (EST) Message-ID: <19970129151534.YC06799@usn.blaze.net.au> Date: Wed, 29 Jan 1997 15:15:34 +1100 From: davidn@unique.usn.blaze.net.au (David Nugent) To: msmith@atrad.adelaide.edu.au (Michael Smith) Cc: Shimon@i-Connect.Net (Simon Shapiro), hackers@freebsd.org Subject: Re: 2.2-BETA Questions References: <199701280316.NAA06348@genesis.atrad.adelaide.edu.au> X-Mailer: Mutt 0.59.1 Mime-Version: 1.0 In-Reply-To: <199701280316.NAA06348@genesis.atrad.adelaide.edu.au>; from Michael Smith on Jan 28, 1997 13:46:23 +1030 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Michael Smith writes: > > 2. Assunming #1 is true, listen to this (Network Failure System; AKA NFS) > > scenario: > > > > * Linux NFS server, Debian 1.2, Kernel 2.0.27, etc. (nomis) with this > > in /etc/exports: > > > > /usr/src/FreeBSD sendero.i-connect.net(rw,no_root_squash) > > > > * FreeBSD 2.2-BETA client doing: > > > > # mkdir /NewStuff > > # mount -t nfs -o ro nomis;/usr/src/FreeBSD /NewStuff > > # ls -al /NewStuff > > ls: /NewStuff: Permission denied > > What are the permissions on "NewStuff" on the server? Try "ls" without > any other flags first. > > > Dunno about you but smells like a bug to me... > > It looks to me like the server is being _very_ weird. Someone else > (Doug R.?) might have a better idea about that. FWIW, I've seen this too. It occurs only when mounting a Linux ext2 filesystem on a FreeBSD system, and then only sometimes. Unfortunately that "sometimes" is *always* repeatable between any two boxes on which it occurs and there doesn't seem to be any other way around it. When I struck this, I ended up mounting the other way and doing what I had to do (backing up the Linux system prior upgrading to FreeBSD, as it turns out :-)). Two other Linux boxes (all three were running Redhat 3.0 and some 2.0.x version of the kernel) mounted just fine. The "disappearing" mount point was quite alarming at first, and I was sure I was losing my mind. I did check permissions, but it did not seem to be related at all. In all other respects, networking in general was working fine. > > 3. Made a kernel with sound, etc... Worked fine until some days ago. > > Now, all of the sudden, without me doing anything (really :-): > > > > # xmcd -debug > > .... > > Lock file: /tmp/.cdaudio/lock.f02 > > Cannot open /dev/rcd0c: errno=6 > > Is there a CD in the drive? 6 is "not configured", which xmcd should be > telling you. A list of the boot-time probe messages (output of 'dmesg') > would be handy here, as I suspect that your CD wasn't found. Or perhaps there was no CD in the drive on bootup? Just a guess. I've never seen this with my atapi nor had the described problem in switching between audio and data cds. > > 8. Education Question: What is the logic in assigning slice ID's? > > I understand c to be the entire disk > > (why `c'? Why not?) > > Why does sysinstall assign 'e', 'f', > > but (almost) never 'd'? This question is indicative of the biggest transition problems in coming from any other PC operating system to BSD. Terminology: 'slice' is the same as a "partition" in DOS/OS2 terms. 'partition' is the internal scheme BSD uses for paritioning disks. > You mean partition names. Tradition, mostly. 'a' is traditionally > used for a root filesystem, 'b' for swap, 'c' for the whole disk, and > d-h for 'other' partitions. For a while, 'd' was used by various > 386 BSD's to deal with the disparity between "the whole disk" and > "the whole part of the disk that BSD uses"; this is obsoleted by > the 'slice' paradigm. 'd' is usable as a standard partition these days. > > 9. Some safety checks in disklabel and newfs and/or kernel slice- > > partition handling could be nice. If you create an 'a' partition > > which is exactly an overlap of a 'c' in a slice that dominates > > the disk, newfs will FREEZE the system. > > Novel. I've never seen that, and I've done it many times. Nor have I. All my partitions are exactly as described - I don't use anything BUT "dd" mode partitioning since I don't run anything other than FreeBSD... It may be a problem with partioning per se, though. I've had some share of fun in getting new disks partitioned. :-) Once I realised that fdisk was unnecessary for DD disks and skipped that part, life was much easier. The core dumps when using /stand/sysinstall after the installation are definitely there though - have been for some years and I keep trying it in the vain hope that it would work. It would be nice if this could be fixed so that sysinstall could be used for partitioning and creating filesystems at any time. I'm sure it would solve many user problems as it is much easier to do it this way than have to fiddle with fdisk/disklabel no matter how educational this might be. :-) Regards, David Nugent - Unique Computing Pty Ltd - Melbourne, Australia Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet davidn@freebsd.org davidn@blaze.net.au http://www.blaze.net.au/~davidn/ From owner-freebsd-hackers Tue Jan 28 20:21:41 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA07378 for hackers-outgoing; Tue, 28 Jan 1997 20:21:41 -0800 (PST) Received: from labs.usn.blaze.net.au (labs.usn.blaze.net.au [203.17.53.30]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA07367 for ; Tue, 28 Jan 1997 20:21:36 -0800 (PST) Received: (from davidn@localhost) by labs.usn.blaze.net.au (8.8.4/8.8.5) id PAA00750; Wed, 29 Jan 1997 15:21:17 +1100 (EST) Message-ID: <19970129152117.AA45867@usn.blaze.net.au> Date: Wed, 29 Jan 1997 15:21:17 +1100 From: davidn@unique.usn.blaze.net.au (David Nugent) To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: Shimon@i-Connect.Net (Simon Shapiro), hackers@freebsd.org Subject: Re: 2.2-BETA Questions References: <7489.854444803@time.cdrom.com> X-Mailer: Mutt 0.59.1 Mime-Version: 1.0 In-Reply-To: <7489.854444803@time.cdrom.com>; from Jordan K. Hubbard on Jan 28, 1997 01:46:43 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Jordan K. Hubbard writes: > > 7. trying /stand/sysinstall from a live system dumps core either on > > (the equivalent of) fdisk or disklabel. > > Fixed in later versions. Great, at last! (fx: runs off to /usr/src/release and builds sysinstall for next time... :-)). FWIW, last time I tried (installing 2.2-BETA), fdisk did work fine, but it dumped core when writing the disklabel. Regards, David Nugent - Unique Computing Pty Ltd - Melbourne, Australia Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet davidn@freebsd.org davidn@blaze.net.au http://www.blaze.net.au/~davidn/ From owner-freebsd-hackers Tue Jan 28 21:32:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA10157 for hackers-outgoing; Tue, 28 Jan 1997 21:32:49 -0800 (PST) Received: from sendero.i-connect.net ([206.190.144.100]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id VAA10140 for ; Tue, 28 Jan 1997 21:32:44 -0800 (PST) Received: (qmail 9334 invoked by uid 1000); 29 Jan 1997 01:05:19 -0000 Message-ID: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Tue, 28 Jan 1997 15:34:33 -0800 (PST) Organization: iConnect Corp. From: Simon Shapiro To: (Joerg Wunsch) Subject: Re: 2.2-BETA Questions Cc: hackers@freebsd.org, (J Wunsch) Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi J Wunsch; On 28-Jan-97 you wrote: ... > 2.1.6 is the latest release. > 2.2 is the next release, currently in post-BETA. > 3.0 is the head of the development (``3.0-current'') Thanx. Iam now doubly aware of these intricacies. I am also of the understanding that all three are actively maintained. How do bug fixes cross the lines? Ah. something to learn... ... [ Linux NFS Server mess ] > That's funny. Never seen this, but i never had an occasion to test > against a Linux NFS server. The solution is to mount with the resvport option. Go figure :-) Thanx to all... ... > ENXIO. You `cd' driver seems confused. I know it is ENXIO. I know the CD driver is confused. I am too new to FreeBSD to maintain this code (which I assume has a maintainer...) > You could hook a few printf's into /sys/scsi/cd.c (inside cd_open()) > to see which of the ENXIO's hits. Either the drive claims there's no > medium inside, or it fails a READ CAPACITY command. This sounds like debugging to me... ;-) Who is the maintainer? Maybe {s{he can help? > What drive is it? wdc1 at 0x170-0x177 irq 15 on isa wdc1: unit 0 (atapi): , removable, intr, dma, iordis The drive wooked correctly for a few days, but will refuse to mount iso9660 disks after playing music ones. Now the roles reveresed. > Of course, all this doesn't matter. ENXIO must not be confused with > any part on the device node itself. It's a plain driver message. I also understand that. It was posted in case minor/major error. > > > 4. Shutdown questions: > > > > a. When init goes to single user, prompts, asking for a shell. > > You press ENTER and it sits on ``(.???msg - Cannot exactly > > remember) not found'' > > ^C will get you a prompt, most of the time. Sometimes you get > > a fast roll talking about some malloc() failure. Sometimes a > > ^C will stop it, sometimes it will not. > > David Greenman has been the only one by now who also reported such a > behaviour. So now there is a confirmation... ... > Well, that's what the `-a' means: umount everything in fstab. Ah. BSD vs. SYSV. Sorry. But ``wolud be nice'' if shutdown would really shut down the system, and correctly too. Even Linux (Debian) now knows to do that, finally. > Btw., try `cdcontrol' to play your audio CD, and see if it does make a > difference. xmcd is a little too funny to trust it as a generic > debugging tool. They have a tendency to hack on the SCSI bus, so i > wouldn't be surprised if this leaves the driver confused if something > behaves different on your drive. Tried that. No change. Also tried cd[0-2]*. Just in case. Same thing. ... > This seems to happen only on your system, for whatever reason. I know > of several people who are running a partition that is full-size the > slice (or entire disk). As I posted before, this happens unless I use disklabel with /etc/disktab. The system will crash, but AFTER reboot the very same partition is OK. I suspect something fishy... ... > If it's assigned using the config stuff, the ISA bus driver code will > assure this. Some drivers (like syscons) don't fit right; they > use too many ports to describe in config's syntax. > > The number of ports used by this driver is returned from the driver > attach routine. Ah. But I need to write one. I just need to ``know'' that. Easy. The question was relating to a PCI controller's driver which wants to know if an IDE card is in that slot already (The card in question is a SCSI card that can ``play IDE'' if setup correctly. Thanx for your support. Simon From owner-freebsd-hackers Tue Jan 28 21:56:57 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA11286 for hackers-outgoing; Tue, 28 Jan 1997 21:56:57 -0800 (PST) Received: from sendero.i-connect.net ([206.190.144.100]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id VAA11281 for ; Tue, 28 Jan 1997 21:56:55 -0800 (PST) Received: (qmail 10659 invoked by uid 1000); 29 Jan 1997 06:56:10 -0000 Message-ID: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199701280843.JAA03366@ghpc6.ihf.rwth-aachen.de> Date: Tue, 28 Jan 1997 21:55:09 -0800 (PST) Organization: iConnect Corp. From: Simon Shapiro To: Thomas Gellekum Subject: WAS: 2.2-BETA Questions IS: Stupidity w/o End Cc: hackers@FreeBSD.ORG, msmith@atrad.adelaide.edu.au Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Thomas Gellekum; On 28-Jan-97 you wrote: ... [ Lots of complaining about CD not playing my music as comanded deleted ] > There's nothing special. Could you post the lines from the probe > messages (see dmesg(8))? xmcd works fine with a Hitachi drive I have > here (CDR-7930, ATAPI, in case someone's interested; xmcd linked with > lesstif-0.75a). The problem was solved by `cat /etc/fstab` and actually LOOKING at what it said. /dev/wcd0c, not /dev/cd0c. My red face says it all... However, I have a host of other problems. Real, I hope... Simon From owner-freebsd-hackers Tue Jan 28 22:39:42 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA13382 for hackers-outgoing; Tue, 28 Jan 1997 22:39:42 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA13374 for ; Tue, 28 Jan 1997 22:39:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id WAA19406; Tue, 28 Jan 1997 22:39:10 -0800 (PST) Message-Id: <199701290639.WAA19406@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Simon Shapiro cc: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch), hackers@freebsd.org Subject: Re: 2.2-BETA Questions In-reply-to: Your message of "Tue, 28 Jan 1997 15:34:33 PST." From: David Greenman Reply-To: dg@root.com Date: Tue, 28 Jan 1997 22:39:10 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> > 4. Shutdown questions: >> > >> > a. When init goes to single user, prompts, asking for a shell. >> > You press ENTER and it sits on ``(.???msg - Cannot exactly >> > remember) not found'' >> > ^C will get you a prompt, most of the time. Sometimes you get >> > a fast roll talking about some malloc() failure. Sometimes a >> > ^C will stop it, sometimes it will not. >> >> David Greenman has been the only one by now who also reported such a >> behaviour. > >So now there is a confirmation... Actually, no, the problem I had was when rebooting, and the symptom there is an apparantly messed up baud rate for a short while (I'm using a serial console). The problem above sounds like something more serious...and not one that I've seen. It might be an indication of a hardware problem. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Tue Jan 28 22:54:06 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA14407 for hackers-outgoing; Tue, 28 Jan 1997 22:54:06 -0800 (PST) Received: from dfw-ix8.ix.netcom.com (dfw-ix8.ix.netcom.com [206.214.98.8]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id WAA14401 for ; Tue, 28 Jan 1997 22:54:04 -0800 (PST) Received: from silvia.HIP.Berkeley.EDU (wck-ca16-15.ix.netcom.com [207.94.231.79]) by dfw-ix8.ix.netcom.com (8.6.13/8.6.12) with ESMTP id WAA25606; Tue, 28 Jan 1997 22:53:27 -0800 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.8.5/8.6.9) id WAA00830; Tue, 28 Jan 1997 22:46:13 -0800 (PST) Date: Tue, 28 Jan 1997 22:46:13 -0800 (PST) Message-Id: <199701290646.WAA00830@silvia.HIP.Berkeley.EDU> To: mcgovern@spoon.beta.com CC: hackers@freebsd.org In-reply-to: <199701290249.VAA04040@spoon.beta.com> (mcgovern@spoon.beta.com) Subject: Re: Constructive criticism (was: bashing everyone for fun and profit) From: asami@vader.cs.berkeley.edu (Satoshi Asami) Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk * Me: I have X, and would like to do Y. Where can I find docs on it? * * Them: Look at handbook section X.Y.Z. The porting section of the handbook is kept quite up-to-date. Section 18.2.5. Satoshi From owner-freebsd-hackers Tue Jan 28 23:23:07 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA15513 for hackers-outgoing; Tue, 28 Jan 1997 23:23:07 -0800 (PST) Received: from lassie.eunet.fi (lassie.eunet.fi [192.26.119.7]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id XAA15500 for ; Tue, 28 Jan 1997 23:22:58 -0800 (PST) Received: from tahko.lpr.carel.fi ([192.46.69.100]) by lassie.eunet.fi with SMTP id AA09497 (5.67a/IDA-1.5 for ); Wed, 29 Jan 1997 09:22:31 +0200 Received: from mercury.ps.carel.fi by tahko.lpr.carel.fi with ESMTP (8.7.5/1.1) id JAA20105; Wed, 29 Jan 1997 09:14:20 +0200 (EET) Received: from sodium.ps.carel.fi (sodium.ps.carel.fi [194.137.216.111]) by mercury.ps.carel.fi (8.8.2/8.8.2) with SMTP id KAA11177; Wed, 29 Jan 1997 10:10:06 +0200 (EET) Received: by sodium.ps.carel.fi with Microsoft Mail id <01BC0DC7.5A8AF380@sodium.ps.carel.fi>; Wed, 29 Jan 1997 09:32:32 +0200 Message-Id: <01BC0DC7.5A8AF380@sodium.ps.carel.fi> From: Ari Suutari To: "'Archie Cobbs'" , Brian Somers Cc: "hackers@freebsd.org" , "cmott@srv.net" Subject: RE: ipdivert & masqd Date: Wed, 29 Jan 1997 09:32:31 +0200 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi everyone, I had these problems with latest 2.2-SNAP release and maybe, just maybe with 2.2-ALPHA. It was quite simple to reproduce the problem - it occurred every time I opened a TCP connection from the same machine that natd was running on. Everything works well if packets come from different interface and are routed to another. I did some investigations in the kernel land (not being any expert on that), but it seemed like the ip_divert_ignore flag was still set (from processing a outgoing packet) when an incoming packet arrived. I used tcpdump and natd (in verbose mode) at the same time initially to figure out that the problem exists. To set up a testing environment with natd, one could say something like: ipfw flush ipfw add divert 32000 ip from any to any via your-if-name ipfw add pass ip from any to any natd -i 32000 -o 32001 -a your-if-address -v The port 32001 here is a dummy - it is required by the current code in natd. However, it is quite harmess, since no packets are diverted to that port with this setup. Hope this helps, Ari S. -----Original Message----- From: Archie Cobbs [SMTP:archie@whistle.com] Sent: 29. tammikuuta 1997 4:18 To: Brian Somers Cc: hackers@freebsd.org; ari.suutari@ps.carel.fi; cmott@srv.net Subject: Re: ipdivert & masqd > On investigation, he's correct. Tcp & udp return setup packets coming into > the machine with masqd running seem to disappear - masqd sees them, but when > it injects them back into the divert socket they disappear (the app never > sees them). > > This shows itself when you try to initiate a tcp/udp connection through the > divert sockets from the machine running masqd.... a timeout occurs. However, > machines that are having packets forwarded through the masqd machine are fine. > I'll have a look at the divert code and see if I can come up with anything > interresting. Under which version(s) of FreeBSD are you guys having this problem ? I'm trying to track it down... Thanks, -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Wed Jan 29 00:18:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA18413 for hackers-outgoing; Wed, 29 Jan 1997 00:18:32 -0800 (PST) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA18404 for ; Wed, 29 Jan 1997 00:18:28 -0800 (PST) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id AAA13315; Wed, 29 Jan 1997 00:17:55 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma013311; Wed Jan 29 00:17:37 1997 Received: (from archie@localhost) by bubba.whistle.com (8.7.5/8.6.12) id AAA22387; Wed, 29 Jan 1997 00:17:37 -0800 (PST) From: Archie Cobbs Message-Id: <199701290817.AAA22387@bubba.whistle.com> Subject: Re: ipdivert & masqd In-Reply-To: <01BC0DC7.5A8AF380@sodium.ps.carel.fi> from Ari Suutari at "Jan 29, 97 09:32:31 am" To: ari.suutari@ps.carel.fi (Ari Suutari) Date: Wed, 29 Jan 1997 00:17:37 -0800 (PST) Cc: archie@whistle.com, brian@awfulhak.demon.co.uk, hackers@freebsd.org, cmott@srv.net 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I had these problems with latest 2.2-SNAP release and > maybe, just maybe with 2.2-ALPHA. It was quite simple > to reproduce the problem - it occurred every time I opened > a TCP connection from the same machine that natd was > running on. Everything works well if packets come > from different interface and are routed to another. > > I did some investigations in the kernel land (not being > any expert on that), but it seemed like the ip_divert_ignore > flag was still set (from processing a outgoing packet) when > an incoming packet arrived. Can I get a quick sanity check on something... the divert code is programmed under the assumption that ip_input() and ip_output() can never sleep (ie., no other packet can be treated before the function returns). This is true, right? Thanks, -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Wed Jan 29 00:19:42 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA18483 for hackers-outgoing; Wed, 29 Jan 1997 00:19:42 -0800 (PST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA18478 for ; Wed, 29 Jan 1997 00:19:38 -0800 (PST) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.4/8.8.4) with SMTP id AAA11920; Wed, 29 Jan 1997 00:11:54 -0800 (PST) Message-ID: <32EF05E4.59E2B600@whistle.com> Date: Wed, 29 Jan 1997 00:10:12 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Ari Suutari CC: "'Archie Cobbs'" , Brian Somers , "hackers@freebsd.org" , "cmott@srv.net" Subject: Re: ipdivert & masqd References: <01BC0DC7.5A8AF380@sodium.ps.carel.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Ari Suutari wrote: Ah a little light shines..... I wonder if it's possible that the ip_output routine might pick up an incoming packet "While it's out there"..? I'll have to think about that.. alternatively, maybe splnet's are nesting with splimp's incorrectly? unlikely.... the whole "global flag" of ip_divert_ignore is a bad idea.. it's not re-entrant at all, but unfortunatly I can't think of a way of fixing that other than adding another argument to ip_input() which I'm sure would go down like a lead balloon. > > Hi everyone, > > I had these problems with latest 2.2-SNAP release and > maybe, just maybe with 2.2-ALPHA. It was quite simple > to reproduce the problem - it occurred every time I opened > a TCP connection from the same machine that natd was > running on. Everything works well if packets come > from different interface and are routed to another. > > I did some investigations in the kernel land (not being > any expert on that), but it seemed like the ip_divert_ignore > flag was still set (from processing a outgoing packet) when > an incoming packet arrived. > > I used tcpdump and natd (in verbose mode) at the > same time initially to figure out that the problem exists. > > To set up a testing environment with natd, one could say > something like: > > ipfw flush > ipfw add divert 32000 ip from any to any via your-if-name > ipfw add pass ip from any to any > > natd -i 32000 -o 32001 -a your-if-address -v > > The port 32001 here is a dummy - it is required by the > current code in natd. However, it is quite harmess, since > no packets are diverted to that port with this setup. > > Hope this helps, > > Ari S. > > -----Original Message----- > From: Archie Cobbs [SMTP:archie@whistle.com] > Sent: 29. tammikuuta 1997 4:18 > To: Brian Somers > Cc: hackers@freebsd.org; ari.suutari@ps.carel.fi; cmott@srv.net > Subject: Re: ipdivert & masqd > > > On investigation, he's correct. Tcp & udp return setup packets coming into > > the machine with masqd running seem to disappear - masqd sees them, but when > > it injects them back into the divert socket they disappear (the app never > > sees them). > > > > This shows itself when you try to initiate a tcp/udp connection through the > > divert sockets from the machine running masqd.... a timeout occurs. However, > > machines that are having packets forwarded through the masqd machine are fine. > > I'll have a look at the divert code and see if I can come up with anything > > interresting. > > Under which version(s) of FreeBSD are you guys having this problem ? > I'm trying to track it down... > > Thanks, > -Archie > > ___________________________________________________________________________ > Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Wed Jan 29 00:35:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA19347 for hackers-outgoing; Wed, 29 Jan 1997 00:35:37 -0800 (PST) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA19341 for ; Wed, 29 Jan 1997 00:35:29 -0800 (PST) Received: from awfulhak.demon.co.uk (localhost.coverform.lan [127.0.0.1]) by awfulhak.demon.co.uk (8.8.4/8.7.3) with ESMTP id IAA03145; Wed, 29 Jan 1997 08:13:21 GMT Message-Id: <199701290813.IAA03145@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: Archie Cobbs cc: hackers@freebsd.org, ari.suutari@ps.carel.fi, cmott@srv.net Subject: Re: ipdivert & masqd In-reply-to: Your message of "Tue, 28 Jan 1997 18:18:24 PST." <199701290218.SAA21188@bubba.whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 Jan 1997 08:13:20 +0000 From: Brian Somers Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [.....] > > Under which version(s) of FreeBSD are you guys having this problem ? > I'm trying to track it down... > > Thanks, > -Archie I'm running 3.0-current and will test it on 2.2-961014-SNAP today. I believe Ari is running 2.2(-BETA?) and suspect that Charles is running much the same or maybe 2.1.6.... -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Wed Jan 29 00:39:04 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA19517 for hackers-outgoing; Wed, 29 Jan 1997 00:39:04 -0800 (PST) Received: from quasi.bis.co.il (quasi.bis.co.il [192.115.114.40]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA19511 for ; Wed, 29 Jan 1997 00:38:55 -0800 (PST) Received: from quasi.bis.co.il (localhost [127.0.0.1]) by quasi.bis.co.il (8.8.3/8.8.3) with SMTP id KAA04336; Wed, 29 Jan 1997 10:41:23 GMT Message-ID: <32EF2952.41C67EA6@bis.co.il> Date: Wed, 29 Jan 1997 10:41:22 +0000 From: Meir Dukhan Organization: Bis Software Systems Ltd X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.1.6-RELEASE i386) MIME-Version: 1.0 To: hackers@freebsd.org CC: mdukhan@quasi.bis.co.il Subject: Sys V IPC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi Ok, I know BSD ppl may not like it, but anyway I have few questions I think some of you know the answers. Sys V ipc (at least the calls related to shared mem and messages queues) seems to _not_ be implemented as system calls. Indeed, ktrace/kdump wont records them as system calls (even if the manpage for shmat is in section 2 ;=) I experienced the following: - msgrcv() with IPC_NOWAIT return EWOULDBLOCK instead of ENOMSG (Linux and Sys V) - a process can have no more than 8 shared mem segments (how can I change this ?) Is the above the expected behaviors ? Can one confirm/infirm ? Tia Meir ps: cc to mdukhan@bis.co.il, I'm not on hackers@freebsd.org, Thanks to all in advance. From owner-freebsd-hackers Wed Jan 29 00:53:11 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA20060 for hackers-outgoing; Wed, 29 Jan 1997 00:53:11 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id AAA20054 for ; Wed, 29 Jan 1997 00:53:08 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA21762; Wed, 29 Jan 1997 09:52:59 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id JAA19852; Wed, 29 Jan 1997 09:46:58 +0100 (MET) Message-ID: Date: Wed, 29 Jan 1997 09:46:58 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: beckmann@mail.nacamar.de (Michael Beckmann) Cc: hackers@freebsd.org Subject: Re: 2.2 sources ? References: <2.2.32.19970128143327.00b74300@mail.nacamar.de> X-Mailer: Mutt 0.55-PL10 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: <2.2.32.19970128143327.00b74300@mail.nacamar.de>; from Michael Beckmann on Jan 28, 1997 15:33:27 +0100 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Michael Beckmann wrote: > I wonder where one can get the current FreeBSD 2.2 source tree. It seems > that the -current tree is FreeBSD 3.0 now. > > The reason why I ask is that I want to build a kernel from newer sources > than 2.2-BETA. I'm not familiar with cvsup's feature to get a particular CVS branch, but i think you should be able to fetch a tree from the RELENG_2_2 tag (that's the name of the beast). -- 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 Jan 29 01:21:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA21180 for hackers-outgoing; Wed, 29 Jan 1997 01:21:01 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id BAA21175 for ; Wed, 29 Jan 1997 01:20:57 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id KAA22267; Wed, 29 Jan 1997 10:20:46 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id JAA19946; Wed, 29 Jan 1997 09:52:15 +0100 (MET) Message-ID: Date: Wed, 29 Jan 1997 09:52:15 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: Shimon@i-Connect.Net (Simon Shapiro) Cc: hackers@freebsd.org Subject: Re: 2.2-BETA Questions References: X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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 Simon Shapiro on Jan 28, 1997 15:34:33 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Simon Shapiro wrote: > > 2.1.6 is the latest release. > > 2.2 is the next release, currently in post-BETA. > > 3.0 is the head of the development (``3.0-current'') > > Thanx. Iam now doubly aware of these intricacies. I am also of > the understanding that all three are actively maintained. How do No, 2.1.6 is a release (so it's a fixed mark, vs. a branch that is ongoing work), and the 2.1.x branch is considered dead. We had to concentrate on something. > bug fixes cross the lines? Ah. something to learn... Bug fixes are being merged from -current into the 2.2 branch. > > You could hook a few printf's into /sys/scsi/cd.c (inside cd_open()) > > to see which of the ENXIO's hits. Either the drive claims there's no > > medium inside, or it fails a READ CAPACITY command. > > This sounds like debugging to me... ;-) Who is the maintainer? I think Søren Schmidt. However, there are too many weird ATAPI drives around, so you're the best person to help here. > > > a. When init goes to single user, prompts, asking for a shell. > > > You press ENTER and it sits on ``(.???msg - Cannot exactly > > > remember) not found'' > > David Greenman has been the only one by now who also reported such a > > behaviour. > > So now there is a confirmation... The confirmation isn't the biggest problem, but rather _finding_ it. :) > > Well, that's what the `-a' means: umount everything in fstab. > > Ah. BSD vs. SYSV. Sorry. But ``wolud be nice'' if shutdown would > really shut down the system, and correctly too. Even Linux > (Debian) now knows to do that, finally. shutdown -h now -- 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 Jan 29 01:42:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA22025 for hackers-outgoing; Wed, 29 Jan 1997 01:42:59 -0800 (PST) Received: from mailbox.uq.edu.au (zzshocki.slip.cc.uq.oz.au [130.102.221.173]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA22018 for ; Wed, 29 Jan 1997 01:42:56 -0800 (PST) Received: from bloop.craftncomp.com (localhost.craftncomp.com [127.0.0.1]) by mailbox.uq.edu.au (8.8.5/8.6.12) with ESMTP id TAA01388 for ; Wed, 29 Jan 1997 19:35:36 +1000 (EST) Message-Id: <199701290935.TAA01388@mailbox.uq.edu.au> X-Mailer: exmh version 2.0beta 12/23/96 To: hackers@freebsd.org Subject: Setting MTU from userland ppp Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 Jan 1997 19:35:34 +1000 From: Stephen Hocking Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk How does one do this? If I try fiddling tun0 (ifconfig tun0 mtu 256) the userland ppp get quite cranky and ppp net connections hang. Stephen From owner-freebsd-hackers Wed Jan 29 03:56:45 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA25886 for hackers-outgoing; Wed, 29 Jan 1997 03:56:45 -0800 (PST) Received: from freenet.hamilton.on.ca (0@main.freenet.hamilton.on.ca [199.212.94.65]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA25881 for ; Wed, 29 Jan 1997 03:56:42 -0800 (PST) Received: from james.freenet.hamilton.on.ca (james.freenet.hamilton.on.ca [199.212.94.66]) by freenet.hamilton.on.ca (8.7.5/8.7.3) with ESMTP id GAA14150; Wed, 29 Jan 1997 06:57:00 -0500 (EST) Received: from localhost (ac199@localhost) by james.freenet.hamilton.on.ca (8.7.5/8.7.3) with SMTP id GAA25609; Wed, 29 Jan 1997 06:58:58 -0500 (EST) X-Authentication-Warning: james.freenet.hamilton.on.ca: ac199 owned process doing -bs Date: Wed, 29 Jan 1997 06:58:58 -0500 (EST) From: Tim Vanderhoek To: "Brian J. McGovern" cc: hackers@freebsd.org Subject: Re: Constructive criticism (was: bashing everyone for fun and profit) In-Reply-To: <199701290249.VAA04040@spoon.beta.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 28 Jan 1997, Brian J. McGovern wrote: > I guess what I'm getting at is this: There are a lot of us out here who would > write man pages if we knew how to typeset them, those who would write neat Well, for manpages there's `man 7 mdoc' and `man 7 mdoc.samples', but personally, the next time I have to write a large manpage (ie. not very soon I plan) I'm going to try writing it in docbook and auto-converting that to manpage format. http://www.ora.com/davenport/index.html, if you're interested. -- Outnumbered? Maybe. Outspoken? Never! tIM...HOEk From owner-freebsd-hackers Wed Jan 29 04:37:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA27813 for hackers-outgoing; Wed, 29 Jan 1997 04:37:47 -0800 (PST) Received: from hda.hda.com (ip65-max1-fitch.ziplink.net [199.232.245.65]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id EAA27792 for ; Wed, 29 Jan 1997 04:37:40 -0800 (PST) Received: (from dufault@localhost) by hda.hda.com (8.6.12/8.6.12) id HAA08800 for hackers@freebsd.org; Wed, 29 Jan 1997 07:32:45 -0500 From: Peter Dufault Message-Id: <199701291232.HAA08800@hda.hda.com> Subject: PC/104 network computer To: hackers@freebsd.org Date: Wed, 29 Jan 1997 07:32:45 -0500 (EST) 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk (I tried hardware. Anyone on -hackers using a PC/104 single board computer?) I'm looking for a single board PC/104 computer with ethernet, flash memory, memory, serial ports, and parallel port on a single card. For ease in bootstrapping it should also have a keyboard and floppy interface. I also need a good looking small enclosure with power supply and external connectors. I'm not concerned with screaming performance or more than 16MB memory. The kind of board I have in mind is similar to the Megatel PC/II+i: http://www.emji.net:80/megatel/pc2ispec.html Can anyone recommend others? Peter -- Peter Dufault (dufault@hda.com) Realtime Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 From owner-freebsd-hackers Wed Jan 29 06:16:30 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA01831 for hackers-outgoing; Wed, 29 Jan 1997 06:16:30 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA01825 for ; Wed, 29 Jan 1997 06:16:24 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id GAA01336; Wed, 29 Jan 1997 06:15:52 -0800 (PST) To: davidn@unique.usn.blaze.net.au (David Nugent) cc: msmith@atrad.adelaide.edu.au (Michael Smith), Shimon@i-Connect.Net (Simon Shapiro), hackers@freebsd.org Subject: Re: 2.2-BETA Questions In-reply-to: Your message of "Wed, 29 Jan 1997 15:15:34 +1100." <19970129151534.YC06799@usn.blaze.net.au> Date: Wed, 29 Jan 1997 06:15:51 -0800 Message-ID: <1332.854547351@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > The core dumps when using /stand/sysinstall after the > installation are definitely there though - have been for some > years and I keep trying it in the vain hope that it would > work. It would be nice if this could be fixed so that Have you reproduced this in the latest SNAP? I finally got purchase authority to build the ultimate spam box from hell - two IDE HDs, an IDE CDROM drive, a SCSI HD and CDROM drive, all in the same box. I'm going to load DOS and Win95 on different drives and try to force FreeBSD to share different combinations as well as set up the "additional" drives after installation over the next couple of days, all of which (I'm sure) will prove instructive. I've never had a system like this to test with before since I've known better than to deliberately build such a horrible combination up to now. :-) Jordan From owner-freebsd-hackers Wed Jan 29 06:58:34 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA03599 for hackers-outgoing; Wed, 29 Jan 1997 06:58:34 -0800 (PST) Received: from nic.follonett.no (nic.follonett.no [194.198.43.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA03594 for ; Wed, 29 Jan 1997 06:58:24 -0800 (PST) Received: (from uucp@localhost) by nic.follonett.no (8.8.5/8.8.3) with UUCP id PAA11776; Wed, 29 Jan 1997 15:56:59 +0100 (MET) Received: from oo7 (oo7.dimaga.com [192.0.0.65]) by dimaga.com (8.7.5/8.7.2) with SMTP id PAA02810; Wed, 29 Jan 1997 15:53:06 +0100 (MET) Message-Id: <3.0.32.19970129155305.00ab11a0@dimaga.com> X-Sender: eivind@dimaga.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 29 Jan 1997 15:53:06 +0100 To: Brian Somers From: Eivind Eklund Subject: Re: ipdivert & masqd Cc: Archie Cobbs , hackers@freebsd.org, ari.suutari@ps.carel.fi, cmott@srv.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 08:13 AM 1/29/97 +0000, Brian Somers wrote: >[.....] >> >> Under which version(s) of FreeBSD are you guys having this problem ? >> I'm trying to track it down... >> > >I'm running 3.0-current and will test it on 2.2-961014-SNAP today. I believe >Ari is running 2.2(-BETA?) and suspect that Charles is running much the same >or maybe 2.1.6.... Charles is running 2.1.0 (or at least he was running 2.1.0 a week ago.), and is (in his own words) "too backwards to test [natd]" BTW: Both masqd and natd need to allocate a large enough buffer to handle PORT-commands being extended. This is done without a buffer check in alias_ftp.c; the maximum size it can be extended to is "PORT 123,123,123,123,123,123\r\n" - 32 characters (including termination) - an extension of 8 characters. The packet payload area _has_ to be large enough handle this. For the IRC DCC case (which I'll hopefully bring to testing point tomorrow - any volunteers?) the expansion can be by 11 characters for each DCC hook in a PRIVMSG, totalling max (payload size)*(4/3), ie expanding to 7/3 the original size for a constructed nasty case. This has bounds-checking, though, and will not do overwrites. Still, extra buffer-space do make it work more reliably. Eivind Eklund / perhaps@yes.no / http://maybe.yes.no/perhaps/ From owner-freebsd-hackers Wed Jan 29 06:58:48 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA03629 for hackers-outgoing; Wed, 29 Jan 1997 06:58:48 -0800 (PST) Received: from quasi.bis.co.il (quasi.bis.co.il [192.115.114.40]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA03621 for ; Wed, 29 Jan 1997 06:58:42 -0800 (PST) Received: from quasi.bis.co.il (localhost [127.0.0.1]) by quasi.bis.co.il (8.8.3/8.8.3) with SMTP id RAA05762; Wed, 29 Jan 1997 17:01:00 GMT Message-ID: <32EF824C.167EB0E7@bis.co.il> Date: Wed, 29 Jan 1997 17:01:00 +0000 From: Meir Dukhan Organization: Bis Software Systems Ltd X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.1.6-RELEASE i386) MIME-Version: 1.0 To: Julian Elischer CC: hackers@freebsd.org, mdukhan@quasi.bis.co.il Subject: Re: Sys V IPC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Thanks for your answer Julian, and let me ask/precise a little bit, Julian Elischer wrote: > > Meir Dukhan wrote: > > > > Hi > >` > > Ok, I know BSD ppl may not like it, but anyway I have few questions I > > think some of you know the answers. > > > > Sys V ipc (at least the calls related to shared mem and messages queues) > > seems to _not_ be implemented as system calls. > > > > Indeed, ktrace/kdump wont records them as system calls (even if the > > manpage for shmat is in section 2 ;=) > they are system calls > you need to enable them in your kernel config. > they are not compiled in to GENERIC. That's was not what I wanted to say. First my GENERIC file has the SYSVSHM, SYSVSEM, SYSVMSG options. and second I work with a kernel that has, too, these options enabled. By saying that they are not sys call, I mean that maybe they are not implemented as system calls, because ktrace doesn't record them . Another possibility is that ktrace is not aware that msgrcv/msgsnd, shmget/shmat and freinds _are_ system calls. I don't know how ktrace works, maybe it make its jobs by looking at a table of existing system calls, instead of checking if a call is actually a system call or a mere function. > > > > - a process can have no more than 8 shared mem segments > > (how can I change this ?) > > compile in a bigger number? Where can I specify this number ? Can one confirm/infirm ? Tia -- Meir ps: cc to mdukhan@bis.co.il, I'm not on hackers@freebsd.org, Thanks to all in advance. From owner-freebsd-hackers Wed Jan 29 07:11:30 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA04910 for hackers-outgoing; Wed, 29 Jan 1997 07:11:30 -0800 (PST) Received: from sumatra.americantv.com (sumatra.americantv.com [199.184.181.250]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA04905 for ; Wed, 29 Jan 1997 07:11:23 -0800 (PST) Received: from right.PCS (right.pcs. [148.105.10.31]) by sumatra.americantv.com (8.7.6/8.7.3) with ESMTP id JAA07636; Wed, 29 Jan 1997 09:22:22 -0600 (CST) Received: (jlemon@localhost) by right.PCS (8.6.13/8.6.4) id PAA20519; Wed, 29 Jan 1997 15:13:50 GMT Message-ID: Date: Wed, 29 Jan 1997 09:13:50 -0600 From: jlemon@americantv.com (Jonathan Lemon) To: jkh@time.cdrom.com ("Jordan K. Hubbard") Cc: hackers@FreeBSD.ORG Subject: Re: 2.2-BETA Questions References: <19970129151534.YC06799@usn.blaze.net.au> <1332.854547351@time.cdrom.com> X-Mailer: Mutt 0.56e Mime-Version: 1.0 In-Reply-To: <1332.854547351@time.cdrom.com>; from "Jordan K. Hubbard" on Jan 29, 1997 06:15:51 -0800 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk "Jordan K. Hubbard" writes: > I finally got purchase authority to build the ultimate spam box from > hell - two IDE HDs, an IDE CDROM drive, a SCSI HD and CDROM drive, all > in the same box. I'm going to load DOS and Win95 on different drives Build? Just go and buy a Packard Bell computer. That should give you a pretty good start. :-) -- Jonathan From owner-freebsd-hackers Wed Jan 29 07:14:53 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA05109 for hackers-outgoing; Wed, 29 Jan 1997 07:14:53 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA05104 for ; Wed, 29 Jan 1997 07:14:49 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id HAA01871; Wed, 29 Jan 1997 07:14:41 -0800 (PST) To: jlemon@americantv.com (Jonathan Lemon) cc: hackers@FreeBSD.ORG Subject: Re: 2.2-BETA Questions In-reply-to: Your message of "Wed, 29 Jan 1997 09:13:50 CST." Date: Wed, 29 Jan 1997 07:14:41 -0800 Message-ID: <1867.854550881@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > "Jordan K. Hubbard" writes: > > I finally got purchase authority to build the ultimate spam box from > > hell - two IDE HDs, an IDE CDROM drive, a SCSI HD and CDROM drive, all > > in the same box. I'm going to load DOS and Win95 on different drives > > Build? Just go and buy a Packard Bell computer. That should give you a > pretty good start. :-) I thought of that, but I wanted something even funkier. Something which personified the very worst of every box I've seen paraded through this group. Packard Bell comes amazingly close to this in an out-of-box configuration, I'll agree, but in the end they just weren't quite Funky Enough. :-) Jordan From owner-freebsd-hackers Wed Jan 29 07:31:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA05732 for hackers-outgoing; Wed, 29 Jan 1997 07:31:59 -0800 (PST) Received: from noc.msc.edu (noc.msc.edu [137.66.12.254]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id HAA05712; Wed, 29 Jan 1997 07:31:54 -0800 (PST) Received: from ww.msc.edu by noc.msc.edu (5.65/MSC/v3.0.1(920324)) id AA09486; Wed, 29 Jan 97 09:31:50 -0600 From: jpt@msc.edu (Joseph Thomas) Received: (jpt@localhost) by ww.msc.edu (8.7.1/8.6.6) id JAA11228; Wed, 29 Jan 1997 09:31:50 -0600 (CST) Message-Id: <199701291531.JAA11228@ww.msc.edu> Subject: Re: RFC 1323 default settings (was Re: progress report on connection problems) To: dg@root.com Date: Wed, 29 Jan 1997 09:31:49 -0600 (CST) Cc: jpt@msc.edu, danny@panda.hilink.com.au, shovey@buffnet.net, robert@nanguo.chalmers.com.au, freebsd-isp@freebsd.org, hackers@freebsd.org In-Reply-To: <199701290030.QAA17983@root.com> from "David Greenman" at Jan 28, 97 04:30:11 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > As a data point - running a local-area ATM with "out of the box" > >parameters (for 2.2 this looks to be 16K windows with no-scaling), I get > >60 KB/s out of the box vs 3.0-3.5 MB/s into the box, [notice the really > > Yikes, that's really awful. What kind of round-trip times are you seeing? > > -DG > > David Greenman > Core-team/Principal Architect, The FreeBSD Project > Transmitter: - 133 MHz Pentium, 32 MB RAM - FreeBSD 2.2-960801-SNAP - FORE PCA200E OC3c adapter - HARP ATM software (http://www.msci.magic.net) - <3C507 R1> ethernet Receiver: - SGI Challenge XL - IRIX64 6.2 03131016 - 2 150 MHZ IP19 Processors - 128 MB RAM, 2-way interleaved - FORE VMA200E OC3c adapter - FORE Systems Release: irix62_A_ForeThought_4.0.2 (1.13) - Integral Ethernet controller: et0 (IO4 card) - Initial packet (Max.) includes ARP time and call setup for ATM ATM: - both parties connected to FORE ASX-200BX - UNI 3.0 - AAL5 - LLC SNAP encapsulation - MSS 9140 (9180 MTU) With ARP and call setup: --- 198.207.143.4 ping statistics --- 101 packets transmitted, 101 packets received, 0% packet loss round-trip min/avg/max = 0.782/1.041/16.027 ms Without ARP and call setup: --- 198.207.143.4 ping statistics --- 101 packets transmitted, 101 packets received, 0% packet loss round-trip min/avg/max = 0.801/0.898/1.349 ms ETHERNET: - parties connected to different 10BaseT hubs - same subnet, no routing - MSS 1460 (1500 MTU) --- 137.66.176.4 ping statistics --- 101 packets transmitted, 101 packets received, 0% packet loss round-trip min/avg/max = 0.939/0.972/2.041 ms Now, that being said, I'm not ready to start pointing fingers at anything yet. It should be noted that using TTCP with window scaling and going to large socket buffers, I've seen 68.58 Mbits out of the machine, and 96.97 Mbits into the machine. I have not run the simple ftp test over ethernet, nor have I looked into why the ATM transmit is so slow. [We're gennerally pretty good at figuring this stuff out, we do it alot over wide-area ATM, including links with satellites.] I really need to do some more investigation of the ATM software, as well as repeat the tests using ethernet. [I should be receiving another pentium machine in the near future. I'm trying to arrange for a second ATM card, as well as some 100Mbit ethernet cards.] My point in the post was only to provide a data point that perhaps we (being the FreeBSD community) ought to think and ask more questions before taking the easy road of "turn it off." [Not that this might not be the correct answer.] It would be more work to go back later and say "opps, we solved the wrong problem and need to turn extensions back on as the default." Anyways... like I said, just a data point for consideration... -- Joseph Thomas E/Mail: jpt@msc.edu Minnesota Supercomputer Center, Inc. jpt@magic.net 1200 Washington Ave So. Tel: +1 612 337 3558 Minneapolis, MN 55415-1227 FAX: +1 612 337 3400 You cannot see what I see because you see what you see. You cannot know what I know because you know what you know. "Mostly Harmless" - Douglas Adams From owner-freebsd-hackers Wed Jan 29 07:54:04 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA06931 for hackers-outgoing; Wed, 29 Jan 1997 07:54:04 -0800 (PST) Received: from zwei.siemens.at (zwei.siemens.at [193.81.246.12]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA06886 for ; Wed, 29 Jan 1997 07:53:58 -0800 (PST) Received: from sol1.gud.siemens.co.at (root@[10.1.143.100]) by zwei.siemens.at (8.7.5/8.7.3) with SMTP id QAA16577 for ; Wed, 29 Jan 1997 16:54:37 +0100 (MET) Received: from ws2301.gud.siemens.co.at by sol1.gud.siemens.co.at with smtp (Smail3.1.28.1 #7 for ) id m0vpcK1-000216C; Wed, 29 Jan 97 16:53 MET Received: by ws2301.gud.siemens.co.at (1.37.109.16/1.37) id AA211803031; Wed, 29 Jan 1997 16:50:31 +0100 From: "Hr.Ladavac" Message-Id: <199701291550.AA211803031@ws2301.gud.siemens.co.at> Subject: Re: 2.2-BETA Questions To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 29 Jan 1997 16:50:30 +0100 (MEZ) Cc: jlemon@americantv.com, hackers@FreeBSD.ORG In-Reply-To: <1867.854550881@time.cdrom.com> from "Jordan K. Hubbard" at Jan 29, 97 07:14:41 am 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-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk E-mail message from Jordan K. Hubbard contained: > > > "Jordan K. Hubbard" writes: > > > I finally got purchase authority to build the ultimate spam box from > > > hell - two IDE HDs, an IDE CDROM drive, a SCSI HD and CDROM drive, all > > > in the same box. I'm going to load DOS and Win95 on different drives > > > > Build? Just go and buy a Packard Bell computer. That should give you a > > pretty good start. :-) > > I thought of that, but I wanted something even funkier. Something > which personified the very worst of every box I've seen paraded > through this group. Packard Bell comes amazingly close to this in an > out-of-box configuration, I'll agree, but in the end they just weren't > quite Funky Enough. :-) You have forgotten a floppy tape and a parallel port Zip drive. And, instead of ATAPI CD-ROM, be a sport and use an ATAPI CD Changer :) /Marino > > Jordan > From owner-freebsd-hackers Wed Jan 29 08:12:17 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA07847 for hackers-outgoing; Wed, 29 Jan 1997 08:12:17 -0800 (PST) Received: from bacall.lodgenet.com (bacall.lodgenet.com [205.138.147.242]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id IAA07839 for ; Wed, 29 Jan 1997 08:12:03 -0800 (PST) Received: (from mail@localhost) by bacall.lodgenet.com (8.6.12/8.6.12) id KAA00280; Wed, 29 Jan 1997 10:10:58 -0600 Received: from garbo.lodgenet.com(204.124.123.250) by bacall via smap (V1.3) id sma000272; Wed Jan 29 10:10:55 1997 Received: from jake.lodgenet.com (jake.lodgenet.com [10.0.11.30]) by garbo.lodgenet.com (8.6.12/8.6.9) with ESMTP id KAA22045; Wed, 29 Jan 1997 10:10:21 -0600 Received: from jake.lodgenet.com (localhost [127.0.0.1]) by jake.lodgenet.com (8.8.4/8.6.12) with ESMTP id KAA19636; Wed, 29 Jan 1997 10:11:21 -0600 (CST) Message-Id: <199701291611.KAA19636@jake.lodgenet.com> X-Mailer: exmh version 2.0beta 12/23/96 To: Meir Dukhan cc: Julian Elischer , hackers@FreeBSD.ORG Subject: Re: Sys V IPC In-reply-to: Your message of "Wed, 29 Jan 1997 17:01:00 GMT." <32EF824C.167EB0E7@bis.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 Jan 1997 10:11:20 -0600 From: "Eric L. Hernes" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Meir Dukhan writes: > >That's was not what I wanted to say. First my GENERIC file has the >SYSVSHM, SYSVSEM, SYSVMSG options. and second I work with a kernel that >has, too, these options enabled. > >By saying that they are not sys call, I mean that maybe they are not >implemented as system calls, because ktrace doesn't record them . The system call is shmsys(); shmget and friends are wrapped up into this. It looks like the real syscalls are there too, but aren't used for whatever reason, binary compats maybe, just left undone maybe. at any rate look for shmsys in kdump's output. > >I don't know how ktrace works, maybe it make its jobs by looking at a >table of existing system calls, instead of checking if a call is >actually a system call or a mere function. ktrace uses the syscall slot number. kdump gets the syscall names from /usr/src/sys/kern/syscalls.c, same as the kernel. > >> > >> > - a process can have no more than 8 shared mem segments >> > (how can I change this ?) >> >> compile in a bigger number? > >Where can I specify this number ? options SHMMAXPGS=4096 options "SHMSEG=128" Although as dyson and others have noted, this is mostly an administrative limit. If you're feeling ambitious, you could probably turn them into a sysctl. >Tia > >-- Meir > >ps: cc to mdukhan@bis.co.il, I'm not on hackers@freebsd.org, Thanks to >all in advance. > eric. -- erich@lodgenet.com http://rrnet.com/~erich erich@rrnet.com From owner-freebsd-hackers Wed Jan 29 08:44:24 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA08996 for hackers-outgoing; Wed, 29 Jan 1997 08:44:24 -0800 (PST) Received: from haldjas.folklore.ee (Haldjas.folklore.ee [193.40.6.121]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA08984 for ; Wed, 29 Jan 1997 08:44:10 -0800 (PST) Received: from localhost (narvi@localhost) by haldjas.folklore.ee (8.8.4/8.8.4) with SMTP id SAA11928; Wed, 29 Jan 1997 18:40:18 +0200 (EET) Date: Wed, 29 Jan 1997 18:40:18 +0200 (EET) From: Narvi To: "Jordan K. Hubbard" cc: hackers@FreeBSD.ORG Subject: Re: 2.2-BETA Questions In-Reply-To: <1332.854547351@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 29 Jan 1997, Jordan K. Hubbard wrote: > > The core dumps when using /stand/sysinstall after the > > installation are definitely there though - have been for some > > years and I keep trying it in the vain hope that it would > > work. It would be nice if this could be fixed so that > > Have you reproduced this in the latest SNAP? > > I finally got purchase authority to build the ultimate spam box from > hell - two IDE HDs, an IDE CDROM drive, a SCSI HD and CDROM drive, all > in the same box. I'm going to load DOS and Win95 on different drives I hope you are getting a CDROM that does not on say the package in bold print taht it works together with Win*, OS/2, Linux & Solaris. I have one and it works together in any position and combination I have tried :-) Sander > and try to force FreeBSD to share different combinations as well as > set up the "additional" drives after installation over the next couple > of days, all of which (I'm sure) will prove instructive. I've never > had a system like this to test with before since I've known better > than to deliberately build such a horrible combination up to now. :-) > > Jordan > From owner-freebsd-hackers Wed Jan 29 08:57:17 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA09511 for hackers-outgoing; Wed, 29 Jan 1997 08:57:17 -0800 (PST) Received: from nic.follonett.no (nic.follonett.no [194.198.43.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA09504 for ; Wed, 29 Jan 1997 08:57:12 -0800 (PST) Received: (from uucp@localhost) by nic.follonett.no (8.8.5/8.8.3) with UUCP id RAA13513; Wed, 29 Jan 1997 17:55:52 +0100 (MET) Received: from oo7 (oo7.dimaga.com [192.0.0.65]) by dimaga.com (8.7.5/8.7.2) with SMTP id RAA03315; Wed, 29 Jan 1997 17:56:37 +0100 (MET) Message-Id: <3.0.32.19970129175636.00ae0c10@dimaga.com> X-Sender: eivind@dimaga.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 29 Jan 1997 17:56:37 +0100 To: Brian Somers From: Eivind Eklund Subject: Re: PR2347 - recursive malloc() in ppp Cc: hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 12:24 AM 1/29/97 +0000, Brian Somers wrote: >Anyone interested in running the "fixed" version? It seems ok on my machine. >All I've done is made the "work" happen in a call from the top level >read-a-packet loop, and triggered it via a variable that's set when an >alarm happens. > >If anyone's interested, there's a compiled copy on freefall in > ~brian/src/usr.sbin/ppp I was interested, and thus tried to get it from here. That seemed awfully hard without having an account on freefall - or am I being stupid here? Anonymous FTP didn't work, nor did http://freefall.freebsd.org/~brian/ A search for freefall at www.freebsd.org didn't turn up anything of interest. Is there something obvious I'm missing, or is this impossible to get at for most of us? (I'm trying to do active maintenance for PPP+pktAlias, and would really like to test/inspect this.) Eivind Eklund / perhaps@yes.no / http://maybe.yes.no/perhaps/ From owner-freebsd-hackers Wed Jan 29 09:11:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA09941 for hackers-outgoing; Wed, 29 Jan 1997 09:11:09 -0800 (PST) Received: from beauty.nacamar.de (petzi@beauty.nacamar.de [194.112.16.36]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA09935 for ; Wed, 29 Jan 1997 09:11:06 -0800 (PST) Received: from localhost (petzi@localhost) by beauty.nacamar.de (8.8.4/8.7.3) with SMTP id SAA04923 for ; Wed, 29 Jan 1997 18:11:02 +0100 Date: Wed, 29 Jan 1997 18:11:01 +0100 (MET) From: Michael Beckmann To: hackers@freebsd.org Subject: 2.2-BETA: options MAXMEM not working Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello, I finally singled out what the problem with my 2.2-BETA installation was. I was able to build a kernel successfully, but the kernel never booted. It panicked during the boot with the message: kmem_suballoc: bad status return of 3 I found out that it was the options "MAXMEM=(256*1024)" in the kernel config file. When I comment it out, the kernel boots fine (but only uses 64 MB RAM). The MAXMEM option used to work fine in previous kernel versions. The syntax is according to the LINT configuration. Oh well... I need that RAM. Cheers, Michael From owner-freebsd-hackers Wed Jan 29 09:19:30 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA10434 for hackers-outgoing; Wed, 29 Jan 1997 09:19:30 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA10427 for ; Wed, 29 Jan 1997 09:19:27 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.5/8.8.5) with ESMTP id JAA25943; Wed, 29 Jan 1997 09:18:39 -0800 (PST) Message-Id: <199701291718.JAA25943@austin.polstra.com> To: joerg_wunsch@uriah.heep.sax.de Subject: Re: 2.2 sources ? Newsgroups: polstra.freebsd.hackers In-Reply-To: References: <2.2.32.19970128143327.00b74300@mail.nacamar.de> Organization: Polstra & Co., Seattle, WA Cc: beckmann@mail.nacamar.de (Michael Beckmann), hackers@freebsd.org Date: Wed, 29 Jan 1997 09:18:39 -0800 From: John Polstra Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I wonder where one can get the current FreeBSD 2.2 source tree. It seems > > that the -current tree is FreeBSD 3.0 now. > > > > The reason why I ask is that I want to build a kernel from newer sources > > than 2.2-BETA. > > I'm not familiar with cvsup's feature to get a particular CVS branch, > but i think you should be able to fetch a tree from the RELENG_2_2 tag > (that's the name of the beast). Yes, that will work. There's a tutorial on how to do it in the FreeBSD handbook, section 17.2, at: http://www.freebsd.org/handbook/handbook.html See especially section 17.2.3. 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 Wed Jan 29 09:23:22 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA10701 for hackers-outgoing; Wed, 29 Jan 1997 09:23:22 -0800 (PST) Received: from gateway.skipstone.com (root@GATEWAY.SKIPSTONE.COM [198.214.10.129]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA10695 for ; Wed, 29 Jan 1997 09:23:19 -0800 (PST) Received: from [204.69.236.50] (hotapplepie.skipstone.com [204.69.236.50]) by gateway.skipstone.com (8.7.4/8.6.9) with SMTP id LAA26467; Wed, 29 Jan 1997 11:20:42 -0600 Date: 29 Jan 97 11:21:25 -0600 Subject: Re: 2.2-BETA Questions From: "Richard Wackerbarth" To: "Joerg Wunsch" Cc: hackers@freebsd.org, "Simon Shapiro" X-Mailer: Cyberdog/2.0a2 MIME-Version: 1.0 Message-Id: Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, Jan 29, 1997 2:52 AM, J Wunsch wrote: >As Simon Shapiro wrote: > >> > 2.1.6 is the latest release. >> > 2.2 is the next release, currently in post-BETA. >> > 3.0 is the head of the development (``3.0-current'') >> >> Thanx. Iam now doubly aware of these intricacies. I am also of >> the understanding that all three are actively maintained. How do > >No, 2.1.6 is a release (so it's a fixed mark, vs. a branch that is >ongoing work), and the 2.1.x branch is considered dead. We had to >concentrate on something. > >> bug fixes cross the lines? Ah. something to learn... > >Bug fixes are being merged from -current into the 2.2 branch. This is not quite accurate. The 2.1 branch still exists and is not quite dead. However, the only "fixes" that get there are the most serious security fixes and an occasional correction to the install procedure that Jordan might throw in. From owner-freebsd-hackers Wed Jan 29 09:29:23 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA11122 for hackers-outgoing; Wed, 29 Jan 1997 09:29:23 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA11112 for ; Wed, 29 Jan 1997 09:29:20 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.5/8.8.5) with ESMTP id JAA26014; Wed, 29 Jan 1997 09:29:16 -0800 (PST) Message-Id: <199701291729.JAA26014@austin.polstra.com> To: dg@root.com Subject: Re: RFC 1323 default settings (was Re: progress report on connection problems) Newsgroups: polstra.freebsd.hackers In-Reply-To: <199701290000.QAA17825@root.com> References: <199701290000.QAA17825@root.com> Organization: Polstra & Co., Seattle, WA Cc: hackers@freebsd.org Date: Wed, 29 Jan 1997 09:29:16 -0800 From: John Polstra Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Actually, the main reason it is on is for the other half of RFC 1323 which > specifies the "time stamp" extensions for better round-trip time estimates. > Unfortunately, I agree with you, however, that RFC 1323 extensions should be > disabled by default. The RFC 1644 extensions (T/TCP), however, should remain > enabled by default. This will only break "finger", and is useful for keeping > vendors TCP stacks compliant. Are you saying that the RFC 1644 extensions have no effect unless the application explicitly elects to use them? I was hoping that would be the case, but it doesn't seem to be. I have an old Lexmark printer hanging off my ethernet. If I turn on RFC 1644 (leaving RFC 1323 turned off), the first communication to the printer kills it so dead that I have to power cycle it to bring it back to life. -- 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 Wed Jan 29 09:53:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA12464 for hackers-outgoing; Wed, 29 Jan 1997 09:53:37 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA12459 for ; Wed, 29 Jan 1997 09:53:34 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA12218; Wed, 29 Jan 1997 10:33:36 -0700 From: Terry Lambert Message-Id: <199701291733.KAA12218@phaeton.artisoft.com> Subject: Re: ipdivert & masqd To: archie@whistle.com (Archie Cobbs) Date: Wed, 29 Jan 1997 10:33:35 -0700 (MST) Cc: ari.suutari@ps.carel.fi, archie@whistle.com, brian@awfulhak.demon.co.uk, hackers@freebsd.org, cmott@srv.net In-Reply-To: <199701290817.AAA22387@bubba.whistle.com> from "Archie Cobbs" at Jan 29, 97 00:17:37 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I did some investigations in the kernel land (not being > > any expert on that), but it seemed like the ip_divert_ignore > > flag was still set (from processing a outgoing packet) when > > an incoming packet arrived. > > Can I get a quick sanity check on something... the divert code is > programmed under the assumption that ip_input() and ip_output() > can never sleep (ie., no other packet can be treated before the > function returns). This is true, right? For the divert handler, you mean? Yes. You can build a state automaton that collects state and generates outbound data at intervals different than the inbound data, though, so long as you return immediately rather than blocking after each inbound-to-the-divert-handler data item has been processed. 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 Wed Jan 29 10:19:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA13417 for hackers-outgoing; Wed, 29 Jan 1997 10:19:37 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA13411 for ; Wed, 29 Jan 1997 10:19:34 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA12267; Wed, 29 Jan 1997 11:00:00 -0700 From: Terry Lambert Message-Id: <199701291800.LAA12267@phaeton.artisoft.com> Subject: Re: 2.2-BETA Questions To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 29 Jan 1997 11:00:00 -0700 (MST) Cc: jlemon@americantv.com, hackers@FreeBSD.ORG In-Reply-To: <1867.854550881@time.cdrom.com> from "Jordan K. Hubbard" at Jan 29, 97 07:14:41 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > I finally got purchase authority to build the ultimate spam box from > > > hell - two IDE HDs, an IDE CDROM drive, a SCSI HD and CDROM drive, all > > > in the same box. I'm going to load DOS and Win95 on different drives > > > > Build? Just go and buy a Packard Bell computer. That should give you a > > pretty good start. :-) > > I thought of that, but I wanted something even funkier. Something > which personified the very worst of every box I've seen paraded > through this group. Packard Bell comes amazingly close to this in an > out-of-box configuration, I'll agree, but in the end they just weren't > quite Funky Enough. :-) Make sure the IDE controller does not support LBA, get a bigger than 512M IDE drive anyway, and install the OnTrack 7.x stuff to load BIOS-based translation and LBA support onto the thing. Oh yeah: get an IDE controller without the shift registers between the slot and the IDE bus, and make sure it uses a CMD640b chip. That way it can be both electrically unreliable, and lock up when you sneeze at it because of the channel interleave bugs on the CMD. Also, your master drive should be non-WD, and your slave should be WD (so that it won't even work under Win95, because WD can't make drives that will slave for other manufacturers because the IDE spec isn't strict enough). Make sure you load the "standard" ATAPI drivers from one vendor, but install the CDROM drive from another... preferrably something you buy for $17 at www.onsale.com because the drive is one of the first 1x IDE CDROMs ever manufactured. Make sure that, internally, it's wired like a Micron Home MPC (ie: the sound output from the CDROM goes through an interrupt hungry sound card that is not quite SB compatible). Definitely install a floppy tape drive, and if you can get one, use the IOMega parallel to SCSI converter as your SCSI interface. Finally, make sure you install PnP ISA cards, but that machine doesn't have a PnP BIOS, so that the OS has to make the PnP I/O calls to get them configured. Be sure the thing has an onboard bus mouse port that uses IRQ 12, and the video card outputs vertical retrace on IRQ2 so the PnP operations will stomp on these interrupts without seeing them... PS: Saturn I/Neptune I/Mercury I chipset for PCI, if possible, so that you don't get PCI DMA cache invalidation signals; too bad you can have an EISA/PCI with both a bogus Intel chipset and the HiNT chipset -- cut the traces for memory bus to slot connections for data lines 25-32, if you have to, to get the same effect. PPS: Don't forget: The Pentium you install should have the FPU bug. PPPS: If you are running an Intel motheboard, get SIMMs with gold contacts; if not, get them with lead. PPPPS: Too bad you can't install VLB bus mastering controllers in a system with PCI slots... then you could really go to hell in a handbasket, since only one of them would require the driver to invalidate the DMA target cache for it because it wasn't in a "master" slot. Actually, if you could get one of the original Gateway or Dell P60 boxes with the 1G IDE drives, you'd almost have all this. As a bonus, you'll have some nice cooling problems with the CPU. 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 Wed Jan 29 10:19:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA13427 for hackers-outgoing; Wed, 29 Jan 1997 10:19:37 -0800 (PST) Received: from ravenock.cybercity.dk (ravenock.cybercity.dk [194.16.57.32]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA13410 for ; Wed, 29 Jan 1997 10:19:32 -0800 (PST) Received: (from sos@localhost) by ravenock.cybercity.dk (8.8.4/8.7.3) id TAA21125; Wed, 29 Jan 1997 19:17:36 +0100 (MET) From: Søren Schmidt Message-Id: <199701291817.TAA21125@ravenock.cybercity.dk> Subject: Re: 2.2-BETA Questions In-Reply-To: <1867.854550881@time.cdrom.com> from "Jordan K. Hubbard" at "Jan 29, 97 07:14:41 am" To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 29 Jan 1997 19:17:27 +0100 (MET) Cc: jlemon@americantv.com, hackers@FreeBSD.org 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-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk In reply to Jordan K. Hubbard who wrote: > > "Jordan K. Hubbard" writes: > > > I finally got purchase authority to build the ultimate spam box from > > > hell - two IDE HDs, an IDE CDROM drive, a SCSI HD and CDROM drive, all > > > in the same box. I'm going to load DOS and Win95 on different drives > > > > Build? Just go and buy a Packard Bell computer. That should give you a > > pretty good start. :-) > > I thought of that, but I wanted something even funkier. Something > which personified the very worst of every box I've seen paraded > through this group. Packard Bell comes amazingly close to this in an > out-of-box configuration, I'll agree, but in the end they just weren't > quite Funky Enough. :-) A couple of ideas: First see to it that the two IDE HD's are of different make, that should get you a good deal of exitement. Eg Quantum & WD or WD & Maxtor or WD & Seagate could give you some interesting funkiness, If you can get hold of a Conner drive, the make of the other doesn't matter, you'll have all the fun anyways), get a Promise or better a HongKong clone of a IDE cache controller, and then a Sanyo 3 disk ATAPI cdrom. Then a Elcheapo MAD or OPTI based soundcard, and a LPT port that only can be set at the lpt3 (0x3bc) address, together with an early Matrox MGA videocard. This should supply you all the fun you can bare for the foreseeable future... Im not to be held responsible for any harm done by you when trying to get this BOFH to work..,.. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-hackers Wed Jan 29 10:31:43 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA13978 for hackers-outgoing; Wed, 29 Jan 1997 10:31:43 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA13973 for ; Wed, 29 Jan 1997 10:31:40 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA12299; Wed, 29 Jan 1997 11:12:57 -0700 From: Terry Lambert Message-Id: <199701291812.LAA12299@phaeton.artisoft.com> Subject: Re: 2.2 sources ? To: jdp@polstra.com (John Polstra) Date: Wed, 29 Jan 1997 11:12:57 -0700 (MST) Cc: joerg_wunsch@uriah.heep.sax.de, beckmann@mail.nacamar.de, hackers@FreeBSD.ORG In-Reply-To: <199701291718.JAA25943@austin.polstra.com> from "John Polstra" at Jan 29, 97 09:18:39 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I'm not familiar with cvsup's feature to get a particular CVS branch, > > but i think you should be able to fetch a tree from the RELENG_2_2 tag > > (that's the name of the beast). > > Yes, that will work. There's a tutorial on how to do it in the FreeBSD > handbook, section 17.2, at: > > http://www.freebsd.org/handbook/handbook.html > > See especially section 17.2.3. I went through these docs the other day... I believe the WWW server is *seriously* underutilized. 1) An HTML page with a CGI-based script generator would be a big win, since the options are not really self-documenting very well. For instance, knowing where things go, and what distributions to get. 2) Another suggestion: a single DOS executable that, when run, will ask for a blank disk, format it, and copy the boot disk out of its internal data area, ask for another, and format it, and write out the second disk. This would let you click a "make BSD install disks" button in any browser that allowed ".exe" file types (ie: MS Internet Explorer 3.x) and end up with disks, without dicking around with rawrite or the other tons of excerment you have to play with now. 3) How about definining a ".sh" file type in the default mailcap for the FreeBSD install for NetScape or whatever, and setting up each port as a button which generates a .sh for the port using a CGI script... "click here to install this, click here to install that" buttons for all ports and packages. Use a CGI script to rotor, and/or have the user select, a mirror site to get packages from. etc. (other things along these lines should be obvious). 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 Wed Jan 29 10:37:06 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA14126 for hackers-outgoing; Wed, 29 Jan 1997 10:37:06 -0800 (PST) Received: from beauty.nacamar.de (petzi@beauty.nacamar.de [194.112.16.36]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA14116 for ; Wed, 29 Jan 1997 10:37:03 -0800 (PST) Received: from localhost (petzi@localhost) by beauty.nacamar.de (8.8.4/8.7.3) with SMTP id TAA06574 for ; Wed, 29 Jan 1997 19:36:59 +0100 Date: Wed, 29 Jan 1997 19:36:58 +0100 (MET) From: Michael Beckmann To: hackers@freebsd.org Subject: 2.2-BETA: options MAXMEM not working (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk OK, after having built a couple more kernels, I found out that the MAXMEM option does not work for me when set to over 128 MB. I now run a kernel that uses only 128 MB, though my machine has 192 MB and will have 256 at the end of the week. Has this problem been fixed in kernels subsequent to 2.2-BETA ? I was using 160 MB just fine with FreeBSD 2.1.5. Cheers, Michael From owner-freebsd-hackers Wed Jan 29 11:10:46 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA15725 for hackers-outgoing; Wed, 29 Jan 1997 11:10:46 -0800 (PST) Received: from sendero.i-connect.net ([206.190.144.100]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id LAA15720 for ; Wed, 29 Jan 1997 11:10:41 -0800 (PST) Received: (qmail 3901 invoked by uid 1000); 29 Jan 1997 20:09:59 -0000 Message-ID: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Wed, 29 Jan 1997 11:13:14 -0800 (PST) Organization: iConnect Corp. From: Simon Shapiro To: hackers@freebsd.org Subject: More 2.2-BETA goodies... Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [ I am cross-posting this to scsi as well, as some of the issues here are SCSI related and I am not sure that readership is overlapping... ] Hi Y'all, Since we are all bored with nothing better to do I decided to burden this nice quorum with some more good ways to use 2.2-BETA. Maybe you can clarify some of them for me: 1. An easy way to panic the system: * Put ``devfs /devs devfs rw 0 0'' in /etc/fstab * Do ``mount -a'' * Do ``mount -a'' (again) * Do ``df'' - You will see /devs mounted twice. Actually you will see /kern and /dev twice if you setup kernfs and/or fdesc. * do ``umount /devs'' You will get a nice little panic with a complaint about dangling inodes. 2. Not a show stopper. More of a question. Under HEAVY disk I/O, with an AHA-2940W, you see all keyboard, mouse, modem activity freeze for few seconds and then resume. I suspected SCSI timeouts, but saw no kernel or driver complaints. It appears as if the system stops processing interrupts for a while. Quiet SCSI timeout (no error messages)? 3. Back to the Iomega Jaz: If it spins down (it likes to do that), and then you try to access it (say mount a file system), you get dropped the kernel debugger (``db>''), with ``.. sd... no slices...'' error message. Now, if you are lucky, you were not in X11, and can see the ``db>'' on the screen. All you need to do is type ``c'' once and all will be well. If you do it too quickly, you will repeat the event. Is this problem: a. The aic7xxx driver timing out too soon b. The SCSI code above the driver deciding to timeout too soon c. Iomega not building hardware to FreeBSD specs :-) If, on the other hand, you were in an X11 session, you are hosed. I think the kernel debugger stops interrupts at this point. What is the way to get at the debugger at this point. Aside from doing the proper thing, which is to configure a serial console, etc. 4. Pppd drops the connection, without warning, under very heavy load. 5. Question: Using xperfmon++ (cool), one observes that a system equipped with AHA2940W enjoys about 3-15 times as many interrupts/sec as disk transfers/sec. The system, does nothing but SCSI right now (cvs checkout in parallel with a tape backup (cpio, I know...). Nothing else. Assumin the #9 S3 card generates no interrupts, keeping my hands off the keyboard and mouse, no Ethernet traffic, no PPP traffic; The system does a peak of 246 disk T/s and about 625 interrupts/sec. Discounting 100 interrupts for the heartbeat, We still have two interrupts per sec charged to the disk I/O. Under HEAVY load, the numbers climb logarithmically; Up to 300 T/s with over 2,500 I/s. Heavy disk load in this note means 8``st'' threads in parallel. So that xperfmon++ will say 300+ T/s, which seems to be the maximum the AHA2940 can sustain. Ts is a Seek Test program we use to excite disks and stress them at the same time. It generates a random (or sequential) stream of I/O requests to a file/device and then measures how it does. It can either read or write, or read-modify-write and do a whole set of nifty things. If there is interest, I can post it. It runs on Slowlaris 2.5.1, linux 2.x and FreeBSD 9of courcse). We prefer it to others because it does true random seeks, very accurate and I wrote it, so it must be good :-). It is also short! Simon From owner-freebsd-hackers Wed Jan 29 11:13:24 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA15937 for hackers-outgoing; Wed, 29 Jan 1997 11:13:24 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA15929 for ; Wed, 29 Jan 1997 11:13:22 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id LAA00697; Wed, 29 Jan 1997 11:12:20 -0800 (PST) To: Narvi cc: hackers@FreeBSD.ORG Subject: Re: 2.2-BETA Questions In-reply-to: Your message of "Wed, 29 Jan 1997 18:40:18 +0200." Date: Wed, 29 Jan 1997 11:12:20 -0800 Message-ID: <693.854565140@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I hope you are getting a CDROM that does not on say the package in bold > print taht it works together with Win*, OS/2, Linux & Solaris. I have one > and it works together in any position and combination I have tried :-) I got the evil "Sound blaster discovery pack" bundle that you see so many Earnest Young Couples stuffing in their minivans over at costco. I figure it's a pretty safe bet that it will: a) Not work. b) Be a frequently reported Not-working-item. :-) From owner-freebsd-hackers Wed Jan 29 11:25:15 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA16690 for hackers-outgoing; Wed, 29 Jan 1997 11:25:15 -0800 (PST) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA16683 for ; Wed, 29 Jan 1997 11:25:13 -0800 (PST) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id LAA17413; Wed, 29 Jan 1997 11:24:39 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma017409; Wed Jan 29 11:24:32 1997 Received: (from archie@localhost) by bubba.whistle.com (8.7.5/8.6.12) id LAA24150; Wed, 29 Jan 1997 11:24:32 -0800 (PST) From: Archie Cobbs Message-Id: <199701291924.LAA24150@bubba.whistle.com> Subject: Re: ipdivert & masqd In-Reply-To: <199701291733.KAA12218@phaeton.artisoft.com> from Terry Lambert at "Jan 29, 97 10:33:35 am" To: terry@lambert.org (Terry Lambert) Date: Wed, 29 Jan 1997 11:24:32 -0800 (PST) Cc: archie@whistle.com, ari.suutari@ps.carel.fi, brian@awfulhak.demon.co.uk, hackers@freebsd.org, cmott@srv.net 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > I did some investigations in the kernel land (not being > > > any expert on that), but it seemed like the ip_divert_ignore > > > flag was still set (from processing a outgoing packet) when > > > an incoming packet arrived. > > > > Can I get a quick sanity check on something... the divert code is > > programmed under the assumption that ip_input() and ip_output() > > can never sleep (ie., no other packet can be treated before the > > function returns). This is true, right? > > For the divert handler, you mean? Yes. Then I don't understand how ip_divert_ignore can ever be incorrectly set (ie., non-zero)... if you look at ip_divert.c, you see the only place that it is ever set to a non-zero value is before the outgoing packet is delivered, via a call to ether ip_input() or ip_output() (in the function div_output()). Then it gets reset to zero after either of these functions returns. Am I missing some subtlety in there? -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Wed Jan 29 12:06:48 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA18309 for hackers-outgoing; Wed, 29 Jan 1997 12:06:48 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA18302 for ; Wed, 29 Jan 1997 12:06:43 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA12629; Wed, 29 Jan 1997 12:47:25 -0700 From: Terry Lambert Message-Id: <199701291947.MAA12629@phaeton.artisoft.com> Subject: Re: ipdivert & masqd To: archie@whistle.com (Archie Cobbs) Date: Wed, 29 Jan 1997 12:47:25 -0700 (MST) Cc: terry@lambert.org, archie@whistle.com, ari.suutari@ps.carel.fi, brian@awfulhak.demon.co.uk, hackers@freebsd.org, cmott@srv.net In-Reply-To: <199701291924.LAA24150@bubba.whistle.com> from "Archie Cobbs" at Jan 29, 97 11:24:32 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > Can I get a quick sanity check on something... the divert code is > > > programmed under the assumption that ip_input() and ip_output() > > > can never sleep (ie., no other packet can be treated before the > > > function returns). This is true, right? > > > > For the divert handler, you mean? Yes. > > Then I don't understand how ip_divert_ignore can ever be incorrectly > set (ie., non-zero)... if you look at ip_divert.c, you see the only > place that it is ever set to a non-zero value is before the outgoing > packet is delivered, via a call to ether ip_input() or ip_output() > (in the function div_output()). Then it gets reset to zero after > either of these functions returns. > > Am I missing some subtlety in there? ...I ....I ...I don't know *that*! *sproing* Yeeeeeaaaaarrrrrrggggggghhhhhhhhh! Actually, I think it's so the outbound packet doesn't get redivirted by that particular handler, but you *can* chain handlers. For instance, say I wanted to chain a cleanwall, a firewall, and a IP proxy server and they were all in seperate divert modules. 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 Wed Jan 29 12:11:34 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA18534 for hackers-outgoing; Wed, 29 Jan 1997 12:11:34 -0800 (PST) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA18524 for ; Wed, 29 Jan 1997 12:11:29 -0800 (PST) Received: from misery.sdf.com [204.244.213.33] by misery.sdf.com with smtp (Exim 1.59 #1) id 0vpYbr-0004t7-00; Wed, 29 Jan 1997 03:55:23 -0800 Date: Wed, 29 Jan 1997 03:55:23 -0800 (PST) From: Tom Samplonius To: Simon Shapiro cc: hackers@freebsd.org Subject: Re: More 2.2-BETA goodies... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 29 Jan 1997, Simon Shapiro wrote: ... > If there is interest, I can post it. It runs on Slowlaris 2.5.1, linux 2.x > and FreeBSD 9of courcse). We prefer it to others because it does true ... I'm interested. I've been looking for something to test transactional limits of SCSI controllers and drives. Problems with tagged command queuing, etc don't show up until you have a very high number of transactions per second. On an other note, have you tried turning AHC_TAGENABLE and/or AHC_SCBPAGING_ENABLE on? AHC_TAGENABLE is pretty reliable if your drives support it. SCSPAGING needs some work yet, I think. Tom From owner-freebsd-hackers Wed Jan 29 12:17:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA18935 for hackers-outgoing; Wed, 29 Jan 1997 12:17:51 -0800 (PST) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA18926 for ; Wed, 29 Jan 1997 12:17:47 -0800 (PST) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id MAA17869; Wed, 29 Jan 1997 12:17:10 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma017867; Wed Jan 29 12:16:42 1997 Received: (from archie@localhost) by bubba.whistle.com (8.7.5/8.6.12) id MAA24360; Wed, 29 Jan 1997 12:16:42 -0800 (PST) From: Archie Cobbs Message-Id: <199701292016.MAA24360@bubba.whistle.com> Subject: Re: ipdivert & masqd In-Reply-To: <199701291947.MAA12629@phaeton.artisoft.com> from Terry Lambert at "Jan 29, 97 12:47:25 pm" To: terry@lambert.org (Terry Lambert) Date: Wed, 29 Jan 1997 12:16:41 -0800 (PST) Cc: archie@whistle.com, terry@lambert.org, ari.suutari@ps.carel.fi, brian@awfulhak.demon.co.uk, hackers@freebsd.org, cmott@srv.net 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > > Can I get a quick sanity check on something... the divert code is > > > > programmed under the assumption that ip_input() and ip_output() > > > > can never sleep (ie., no other packet can be treated before the > > > > function returns). This is true, right? > > > > > > For the divert handler, you mean? Yes. > > > > Then I don't understand how ip_divert_ignore can ever be incorrectly > > set (ie., non-zero)... if you look at ip_divert.c, you see the only > > place that it is ever set to a non-zero value is before the outgoing > > packet is delivered, via a call to ether ip_input() or ip_output() > > (in the function div_output()). Then it gets reset to zero after > > either of these functions returns. > > > > Am I missing some subtlety in there? > > [ ... ] > > Actually, I think it's so the outbound packet doesn't get redivirted > by that particular handler, but you *can* chain handlers. For instance, > say I wanted to chain a cleanwall, a firewall, and a IP proxy server > and they were all in seperate divert modules. Right! That is the purpose of this ip_divert_ignore hack -- for loop avoidance. It allows you to send a packet back out via the divert socket and simultaneously say "Don't divert *this* packet back into *this* socket". The theory was that this loop avoidance was working too well, and seemed to be applying to packets other than the one that it was supposed to. What I'm trying to prove to myself is that this can't be happening. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Wed Jan 29 12:38:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA19791 for hackers-outgoing; Wed, 29 Jan 1997 12:38:49 -0800 (PST) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA19786 for ; Wed, 29 Jan 1997 12:38:44 -0800 (PST) Message-Id: <199701292038.MAA19786@freefall.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA210270266; Thu, 30 Jan 1997 07:37:46 +1100 From: Darren Reed Subject: Re: ipdivert & masqd To: eivind@dimaga.com (Eivind Eklund) Date: Thu, 30 Jan 1997 07:37:46 +1100 (EDT) Cc: brian@awfulhak.demon.co.uk, archie@whistle.com, hackers@FreeBSD.ORG, ari.suutari@ps.carel.fi, cmott@srv.net In-Reply-To: <3.0.32.19970129155305.00ab11a0@dimaga.com> from "Eivind Eklund" at Jan 29, 97 03:53:06 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In some mail from Eivind Eklund, sie said: > > For the IRC DCC case (which I'll hopefully bring to testing point tomorrow > - any volunteers?) the expansion can be by 11 characters for each DCC hook > in a PRIVMSG, totalling max (payload size)*(4/3), ie expanding to 7/3 the > original size for a constructed nasty case. This has bounds-checking, > though, and will not do overwrites. Still, extra buffer-space do make it > work more reliably. But anything after the 512th data byte in the TCP payload will be ignored, so if your message is 512 bytes long, contains a DCC request in it, information will be lost that the sender is not aware about (this assumes the packet is just one IRC message) if the payload size must increase as a result. It is a *much* better idea to redirect IRC to a local TCP port and process it using a proxy agent. Same could also be said for FTP. Darren From owner-freebsd-hackers Wed Jan 29 12:46:57 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA20184 for hackers-outgoing; Wed, 29 Jan 1997 12:46:57 -0800 (PST) Received: from nic.follonett.no (nic.follonett.no [194.198.43.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA20166 for ; Wed, 29 Jan 1997 12:46:54 -0800 (PST) Received: (from uucp@localhost) by nic.follonett.no (8.8.5/8.8.3) with UUCP id VAA16478; Wed, 29 Jan 1997 21:39:44 +0100 (MET) Received: from oo7 (oo7.dimaga.com [192.0.0.65]) by dimaga.com (8.7.5/8.7.2) with SMTP id UAA04642; Wed, 29 Jan 1997 20:47:09 +0100 (MET) Message-Id: <3.0.32.19970129204709.00afdec0@dimaga.com> X-Sender: eivind@dimaga.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 29 Jan 1997 20:47:10 +0100 To: Terry Lambert From: Eivind Eklund Subject: Re: 2.2 sources ? Cc: jdp@polstra.com (John Polstra), joerg_wunsch@uriah.heep.sax.de, beckmann@mail.nacamar.de, hackers@FreeBSD.ORG Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 11:12 AM 1/29/97 -0700, Terry Lambert wrote: >2) >Another suggestion: a single DOS executable that, when run, will ask >for a blank disk, format it, and copy the boot disk out of its internal >data area, ask for another, and format it, and write out the second disk. > >This would let you click a "make BSD install disks" button in any >browser that allowed ".exe" file types (ie: MS Internet Explorer 3.x) >and end up with disks, without dicking around with rawrite or the >other tons of excerment you have to play with now. I don't believe it is possible to do access the raw disks from Win95 or WinNT; at least, it is not possible from a DOS executable. It *might* be possible from a WinNT executable (which will also run under Win95). However, my resident Win95/NT expert didn't know how. >3) >How about definining a ".sh" file type in the default mailcap for >the FreeBSD install for NetScape or whatever, and setting up each >port as a button which generates a .sh for the port using a CGI >script... "click here to install this, click here to install that" >buttons for all ports and packages. Use a CGI script to rotor, and/or >have the user select, a mirror site to get packages from. I still don't like the concept of having the user *automatically* run anything downloaded. I don't think setting ut the mailcap to do so is a good idea, to put it mildly. (It almost give me enough paranoia to make me want to switch to another OS; it is a large part of the reason I don't run IE, _ever_.) Eivind Eklund / perhaps@yes.no / http://maybe.yes.no/perhaps/ From owner-freebsd-hackers Wed Jan 29 12:52:11 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA20501 for hackers-outgoing; Wed, 29 Jan 1997 12:52:11 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA20494 for ; Wed, 29 Jan 1997 12:52:03 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id VAA03897; Wed, 29 Jan 1997 21:51:17 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id UAA21205; Wed, 29 Jan 1997 20:51:37 +0100 (MET) Message-ID: Date: Wed, 29 Jan 1997 20:51:37 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: eivind@dimaga.com (Eivind Eklund) Cc: brian@awfulhak.demon.co.uk (Brian Somers), hackers@freebsd.org Subject: Re: PR2347 - recursive malloc() in ppp References: <3.0.32.19970129175636.00ae0c10@dimaga.com> X-Mailer: Mutt 0.55-PL10 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: <3.0.32.19970129175636.00ae0c10@dimaga.com>; from Eivind Eklund on Jan 29, 1997 17:56:37 +0100 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Eivind Eklund wrote: > >If anyone's interested, there's a compiled copy on freefall in > > ~brian/src/usr.sbin/ppp > > I was interested, and thus tried to get it from here. That seemed awfully > hard without having an account on freefall - or am I being stupid here? Well, Brian, i think as a freefall user you could put it into frefall's incoming. (Uploads from outside have been disabled.) -- 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 Jan 29 12:58:58 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA20842 for hackers-outgoing; Wed, 29 Jan 1997 12:58:58 -0800 (PST) Received: from werple.net.au (melb.werple.net.au [203.9.190.18]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA20834 for ; Wed, 29 Jan 1997 12:58:51 -0800 (PST) Received: (qmail 8847 invoked by uid 5); 29 Jan 1997 20:58:49 -0000 MBOX-Line: From jb@freebsd1.cimlogic.com.au Thu Jan 30 07:24:26 1997 Received: (from jb@localhost) by freebsd1.cimlogic.com.au (8.7.5/8.7.3) id HAA04929; Thu, 30 Jan 1997 07:24:26 +1100 (EST) From: John Birrell Message-Id: <199701292024.HAA04929@freebsd1.cimlogic.com.au> Subject: Re: PC/104 network computer To: dufault@hda.com (Peter Dufault) Date: Thu, 30 Jan 1997 07:24:25 +1100 (EST) Cc: hackers@freebsd.org In-Reply-To: <199701291232.HAA08800@hda.hda.com> from Peter Dufault at "Jan 29, 97 07:32:45 am" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Peter Dufault wrote: > (I tried hardware. Anyone on -hackers using a PC/104 single board > computer?) > > I'm looking for a single board PC/104 computer with ethernet, flash > memory, memory, serial ports, and parallel port on a single card. > For ease in bootstrapping it should also have a keyboard and floppy > interface. I also need a good looking small enclosure with power > supply and external connectors. I'm not concerned with screaming > performance or more than 16MB memory. > > The kind of board I have in mind is similar to the Megatel PC/II+i: > > http://www.emji.net:80/megatel/pc2ispec.html > > Can anyone recommend others? We've just installed two Teknor Viper 806 boards running FreeBSD and using a digital I/O board plugged into the PC104 connector. We sourced the boards from a local distributor, but the brochures refer to: http://www.teknor.com/ > > Peter > > -- > Peter Dufault (dufault@hda.com) Realtime Machine Control and Simulation > HD Associates, Inc. Voice: 508 433 6936 > Regards, -- John Birrell CIMlogic Pty Ltd jb@cimlogic.com.au; jb@netbsd.org 119 Cecil Street Ph +61 3 9690 6900 South Melbourne Vic 3205 Fax +61 3 9690 6650 Australia Mob +61 18 353 137 From owner-freebsd-hackers Wed Jan 29 13:00:43 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA21047 for hackers-outgoing; Wed, 29 Jan 1997 13:00:43 -0800 (PST) Received: from darkstar (ras527.srv.net [205.180.127.27]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA21042 for ; Wed, 29 Jan 1997 13:00:38 -0800 (PST) Received: (from cmott@localhost) by darkstar (8.6.12/8.6.12) id NAA01064; Wed, 29 Jan 1997 13:58:29 -0700 Date: Wed, 29 Jan 1997 13:58:28 -0700 (MST) From: Charles Mott X-Sender: cmott@darkstar To: Darren Reed cc: Eivind Eklund , brian@awfulhak.demon.co.uk, archie@whistle.com, hackers@FreeBSD.ORG, ari.suutari@ps.carel.fi Subject: Re: ipdivert & masqd In-Reply-To: <9701292040.AA22766@snake.srv.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > But anything after the 512th data byte in the TCP payload will be ignored, > so if your message is 512 bytes long, contains a DCC request in it, > information will be lost that the sender is not aware about (this assumes > the packet is just one IRC message) if the payload size must increase as > a result. > > It is a *much* better idea to redirect IRC to a local TCP port and process > it using a proxy agent. Same could also be said for FTP. > > Darren Darren, In theory, one can construct cases where the FTP logic in the packet aliasing software won't work (IP fragmenting a PORT command, or where the PORT command is split between TCP packets with different sequence numbers, or where the PORT command is in the middle of a packet, and so forth). In practice, these situations are not seen, and the packet aliasing software works for FTP. The system loading is very low, and the software easily scales to situations where there are large numbers of users. I don't know about IRC, but my guess is that the real situation is simpler than the theoretical. Whatever Linux does to handle IRC, I am told that it looks fairly similar to what one does for FTP. Charles Mott From owner-freebsd-hackers Wed Jan 29 13:19:44 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA21972 for hackers-outgoing; Wed, 29 Jan 1997 13:19:44 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA21965 for ; Wed, 29 Jan 1997 13:19:41 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA17113; Wed, 29 Jan 1997 13:57:56 -0700 From: Terry Lambert Message-Id: <199701292057.NAA17113@phaeton.artisoft.com> Subject: Re: 2.2 sources ? To: eivind@dimaga.com (Eivind Eklund) Date: Wed, 29 Jan 1997 13:57:56 -0700 (MST) Cc: terry@lambert.org, jdp@polstra.com, joerg_wunsch@uriah.heep.sax.de, beckmann@mail.nacamar.de, hackers@FreeBSD.ORG In-Reply-To: <3.0.32.19970129204709.00afdec0@dimaga.com> from "Eivind Eklund" at Jan 29, 97 08:47:10 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >This would let you click a "make BSD install disks" button in any > >browser that allowed ".exe" file types (ie: MS Internet Explorer 3.x) > >and end up with disks, without dicking around with rawrite or the > >other tons of excerment you have to play with now. > > I don't believe it is possible to do access the raw disks from Win95 or > WinNT; at least, it is not possible from a DOS executable. It *might* be > possible from a WinNT executable (which will also run under Win95). > However, my resident Win95/NT expert didn't know how. You must assert volume locks. These are documented in the Win95 SDK. You can open a channel to the ring 0 stub driver to get at the driver level code. This can all be done from a Windows95 executable which is a "console" application (or you can make it a Windows app). A CGI script can tell a Win95 IE3.x from a WinNT IE3.x, and provide the right executable. > >3) > >How about definining a ".sh" file type in the default mailcap for > >the FreeBSD install for NetScape or whatever, and setting up each > >port as a button which generates a .sh for the port using a CGI > >script... "click here to install this, click here to install that" > >buttons for all ports and packages. Use a CGI script to rotor, and/or > >have the user select, a mirror site to get packages from. > > I still don't like the concept of having the user *automatically* run > anything downloaded. I don't think setting ut the mailcap to do so is a > good idea, to put it mildly. (It almost give me enough paranoia to make me > want to switch to another OS; it is a large part of the reason I don't run > IE, _ever_.) IE has settings which, by default, will offer to download rather than run an executable grabbed this way. You have to override them if you want them to run. But it's one click away. If NetScape doesn't have the same "override" feature in its mailcap definition for external file type handlers, you could build a small X app to pipeline the sh handler, and provide the same feature there (but I'm pretty sure NetScape can do anything IE can do). The point is to make it *much* easier to obtain access to the programs and data on the WW server. For instance, it would have been seriously handy for setting up cvsup to not have to dick with all of the usses, and deal with a forms/checkbox/button interface instead. 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 Wed Jan 29 13:20:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA22121 for hackers-outgoing; Wed, 29 Jan 1997 13:20:59 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA22111 for ; Wed, 29 Jan 1997 13:20:53 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id WAA04513; Wed, 29 Jan 1997 22:20:44 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id WAA21423; Wed, 29 Jan 1997 22:03:51 +0100 (MET) Message-ID: Date: Wed, 29 Jan 1997 22:03:50 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: Shimon@i-Connect.Net (Simon Shapiro) Cc: hackers@FreeBSD.ORG Subject: Re: More 2.2-BETA goodies... References: X-Mailer: Mutt 0.55-PL10 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 Simon Shapiro on Jan 29, 1997 11:13:14 -0800 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Simon Shapiro wrote: > 1. An easy way to panic the system: > > * Put ``devfs /devs devfs rw 0 0'' > in /etc/fstab > * Do ``mount -a'' Shortcut: umount /devs Known sucker. DEVFS is really not yet ready for the masses. (Alas.) > 5. Question: Using xperfmon++ (cool), one observes that a system equipped > with AHA2940W enjoys about 3-15 times as many interrupts/sec as disk > transfers/sec. The system, does nothing but SCSI right now (cvs > checkout in parallel with a tape backup (cpio, I know...). > Nothing else. > > Discounting > 100 interrupts for the heartbeat, ... You have to discount 100 + 128 interrupts per second, there are two clocks. If you're using pcaudio, this increases to 100 + 1024 while pcaudio is running. xperfmon++ has a tendency to not become adapted to more recent changes very quickly (guess whom you should blame for this :-). systat -vmstat might be more authoritative in its data (and also gives you a split view for the various interrupt sources). -- 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 Jan 29 13:25:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA22307 for hackers-outgoing; Wed, 29 Jan 1997 13:25:51 -0800 (PST) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA22302 for ; Wed, 29 Jan 1997 13:25:49 -0800 (PST) Message-Id: <199701292125.NAA22302@freefall.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA221113143; Thu, 30 Jan 1997 08:25:43 +1100 From: Darren Reed Subject: Re: ipdivert & masqd To: cmott@srv.net (Charles Mott) Date: Thu, 30 Jan 1997 08:25:43 +1100 (EDT) Cc: hackers@freebsd.org In-Reply-To: from "Charles Mott" at Jan 29, 97 01:58:28 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In some mail from Charles Mott, sie said: > > > But anything after the 512th data byte in the TCP payload will be ignored, > > so if your message is 512 bytes long, contains a DCC request in it, > > information will be lost that the sender is not aware about (this assumes > > the packet is just one IRC message) if the payload size must increase as > > a result. > > > > It is a *much* better idea to redirect IRC to a local TCP port and process > > it using a proxy agent. Same could also be said for FTP. > > > > Darren > > Darren, > > In theory, one can construct cases where the FTP logic in the packet > aliasing software won't work (IP fragmenting a PORT command, or where the > PORT command is split between TCP packets with different sequence numbers, > or where the PORT command is in the middle of a packet, and so forth). > > In practice, these situations are not seen, and the packet aliasing > software works for FTP. The system loading is very low, and the software > easily scales to situations where there are large numbers of users. > > I don't know about IRC, but my guess is that the real situation is simpler > than the theoretical. Whatever Linux does to handle IRC, I am told that > it looks fairly similar to what one does for FTP. Well, in practice, the TIS FWTK/Gauntlet was sending the FTP PORT command in two packets, so that Linux would break and so too did Firewall-1. Darren From owner-freebsd-hackers Wed Jan 29 13:31:22 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA22667 for hackers-outgoing; Wed, 29 Jan 1997 13:31:22 -0800 (PST) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA22651 for ; Wed, 29 Jan 1997 13:31:15 -0800 (PST) Message-Id: <199701292131.NAA22651@freefall.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA221713349; Thu, 30 Jan 1997 08:29:09 +1100 From: Darren Reed Subject: Re: ipdivert & masqd To: archie@whistle.com (Archie Cobbs) Date: Thu, 30 Jan 1997 08:29:09 +1100 (EDT) Cc: terry@lambert.org, archie@whistle.com, ari.suutari@ps.carel.fi, brian@awfulhak.demon.co.uk, hackers@freebsd.org, cmott@srv.net In-Reply-To: <199701292016.MAA24360@bubba.whistle.com> from "Archie Cobbs" at Jan 29, 97 12:16:41 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In some mail from Archie Cobbs, sie said: > > The theory was that this loop avoidance was working too well, and > seemed to be applying to packets other than the one that it was > supposed to. What I'm trying to prove to myself is that this can't > be happening. Does ip_divert_flag get set/reset inside or outside the loop in ip_input() which dequeues packets ? (src isn't handy) Darren From owner-freebsd-hackers Wed Jan 29 13:32:21 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA22856 for hackers-outgoing; Wed, 29 Jan 1997 13:32:21 -0800 (PST) Received: from darkstar (ras527.srv.net [205.180.127.27]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA22827 for ; Wed, 29 Jan 1997 13:32:13 -0800 (PST) Received: (from cmott@localhost) by darkstar (8.6.12/8.6.12) id OAA01100; Wed, 29 Jan 1997 14:31:48 -0700 Date: Wed, 29 Jan 1997 14:31:47 -0700 (MST) From: Charles Mott X-Sender: cmott@darkstar To: Darren Reed cc: hackers@freebsd.org Subject: Re: ipdivert & masqd In-Reply-To: <9701292125.AA24747@snake.srv.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 30 Jan 1997, Darren Reed wrote: > In some mail from Charles Mott, sie said: > > > > > But anything after the 512th data byte in the TCP payload will be ignored, > > > so if your message is 512 bytes long, contains a DCC request in it, > > > information will be lost that the sender is not aware about (this assumes > > > the packet is just one IRC message) if the payload size must increase as > > > a result. > > > > > > It is a *much* better idea to redirect IRC to a local TCP port and process > > > it using a proxy agent. Same could also be said for FTP. > > > > > > Darren > > > > Darren, > > > > In theory, one can construct cases where the FTP logic in the packet > > aliasing software won't work (IP fragmenting a PORT command, or where the > > PORT command is split between TCP packets with different sequence numbers, > > or where the PORT command is in the middle of a packet, and so forth). > > > > In practice, these situations are not seen, and the packet aliasing > > software works for FTP. The system loading is very low, and the software > > easily scales to situations where there are large numbers of users. > > > > I don't know about IRC, but my guess is that the real situation is simpler > > than the theoretical. Whatever Linux does to handle IRC, I am told that > > it looks fairly similar to what one does for FTP. > > Well, in practice, the TIS FWTK/Gauntlet was sending the FTP PORT command > in two packets, so that Linux would break and so too did Firewall-1. > > Darren > That is curious. What does TIS FWTK/Gauntlet do? Charles Mott From owner-freebsd-hackers Wed Jan 29 13:39:24 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA23304 for hackers-outgoing; Wed, 29 Jan 1997 13:39:24 -0800 (PST) Received: from pat.idt.unit.no (0@pat.idt.unit.no [129.241.103.5]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA23299 for ; Wed, 29 Jan 1997 13:39:21 -0800 (PST) Received: from idt.unit.no (tegge@ikke.idt.unit.no [129.241.111.65]) by pat.idt.unit.no (8.8.5/8.8.5) with ESMTP id WAA21498; Wed, 29 Jan 1997 22:32:21 +0100 (MET) Message-Id: <199701292132.WAA21498@pat.idt.unit.no> To: petzi@mail.nacamar.de Cc: hackers@FreeBSD.ORG Subject: Re: 2.2-BETA: options MAXMEM not working (fwd) In-Reply-To: Your message of "Wed, 29 Jan 1997 19:36:58 +0100 (MET)" References: X-Mailer: Mew version 1.06 on Emacs 19.33.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Wed, 29 Jan 1997 22:32:21 +0100 From: Tor Egge Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > OK, after having built a couple more kernels, I found out that the MAXMEM > option does not work for me when set to over 128 MB. I now run a kernel > that uses only 128 MB, though my machine has 192 MB and will have 256 at > the end of the week. Has this problem been fixed in kernels subsequent to > 2.2-BETA ? I was using 160 MB just fine with FreeBSD 2.1.5. > > Cheers, > > Michael Is bounce buffer support disabled ? It uses some kernel virtual address space. If that does not help, you may want to look at PR kern/1880. - Tor Egge From owner-freebsd-hackers Wed Jan 29 13:42:26 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA23518 for hackers-outgoing; Wed, 29 Jan 1997 13:42:26 -0800 (PST) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA23513 for ; Wed, 29 Jan 1997 13:42:23 -0800 (PST) Message-Id: <199701292142.NAA23513@freefall.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA227324136; Thu, 30 Jan 1997 08:42:16 +1100 From: Darren Reed Subject: Re: ipdivert & masqd To: cmott@srv.net (Charles Mott) Date: Thu, 30 Jan 1997 08:42:16 +1100 (EDT) Cc: avalon@coombs.anu.edu.au, hackers@freebsd.org In-Reply-To: from "Charles Mott" at Jan 29, 97 02:31:47 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In some mail from Charles Mott, sie said: > > > Well, in practice, the TIS FWTK/Gauntlet was sending the FTP PORT command > > in two packets, so that Linux would break and so too did Firewall-1. > > > > Darren > > > > That is curious. What does TIS FWTK/Gauntlet do? does a send/write call for "PORT " and another for the address/port info. Darren From owner-freebsd-hackers Wed Jan 29 14:07:14 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA24902 for hackers-outgoing; Wed, 29 Jan 1997 14:07:14 -0800 (PST) Received: from darkstar (ras527.srv.net [205.180.127.27]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id OAA24866 for ; Wed, 29 Jan 1997 14:05:51 -0800 (PST) Received: (from cmott@localhost) by darkstar (8.6.12/8.6.12) id PAA01136; Wed, 29 Jan 1997 15:05:35 -0700 Date: Wed, 29 Jan 1997 15:05:34 -0700 (MST) From: Charles Mott X-Sender: cmott@darkstar To: Darren Reed cc: avalon@coombs.anu.edu.au, hackers@freebsd.org Subject: Re: ipdivert & masqd In-Reply-To: <9701292142.AA19231@snake.srv.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > That is curious. What does TIS FWTK/Gauntlet do? > > does a send/write call for "PORT " and another for the address/port > info. > > Darren My syntax may have been a little unclear. It is just that I had never heard of the TIS ... Gauntlet program. Is it just an FTP client, or something more advanced? If source code is available, I think that some may wish to update the code. Charles Mott From owner-freebsd-hackers Wed Jan 29 14:33:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA26251 for hackers-outgoing; Wed, 29 Jan 1997 14:33:51 -0800 (PST) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA26240 for ; Wed, 29 Jan 1997 14:33:45 -0800 (PST) Received: from awfulhak.demon.co.uk (localhost.coverform.lan [127.0.0.1]) by awfulhak.demon.co.uk (8.8.4/8.7.3) with ESMTP id WAA13475; Wed, 29 Jan 1997 22:03:39 GMT Message-Id: <199701292203.WAA13475@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: Eivind Eklund cc: hackers@freebsd.org Subject: Re: PR2347 - recursive malloc() in ppp In-reply-to: Your message of "Wed, 29 Jan 1997 17:56:37 +0100." <3.0.32.19970129175636.00ae0c10@dimaga.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 Jan 1997 22:03:38 +0000 From: Brian Somers Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > At 12:24 AM 1/29/97 +0000, Brian Somers wrote: > >Anyone interested in running the "fixed" version? It seems ok on my machine. > >All I've done is made the "work" happen in a call from the top level > >read-a-packet loop, and triggered it via a variable that's set when an > >alarm happens. > > > >If anyone's interested, there's a compiled copy on freefall in > > ~brian/src/usr.sbin/ppp > > I was interested, and thus tried to get it from here. That seemed awfully > hard without having an account on freefall - or am I being stupid here? [.....] No - I am, or at least I'm being inconsiderate. The code has been commited now, so it's available via cvsup. Drop me a line if you want me to send you a patch (if you don't sup). My appologies. -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Wed Jan 29 14:34:06 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA26286 for hackers-outgoing; Wed, 29 Jan 1997 14:34:06 -0800 (PST) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA26273 for ; Wed, 29 Jan 1997 14:34:01 -0800 (PST) Received: from awfulhak.demon.co.uk (localhost.coverform.lan [127.0.0.1]) by awfulhak.demon.co.uk (8.8.4/8.7.3) with ESMTP id VAA13426 for ; Wed, 29 Jan 1997 21:46:13 GMT Message-Id: <199701292146.VAA13426@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: hackers@freebsd.org Subject: lpd - remote printing with an output filter Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 Jan 1997 21:46:13 +0000 From: Brian Somers Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Has anyone got any problems with me making this work ? It's always irritated me ! It consists of two one-liners to printjob.c. -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Wed Jan 29 14:43:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA27025 for hackers-outgoing; Wed, 29 Jan 1997 14:43:09 -0800 (PST) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA27016 for ; Wed, 29 Jan 1997 14:43:05 -0800 (PST) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id OAA19113; Wed, 29 Jan 1997 14:41:13 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma019111; Wed Jan 29 14:40:44 1997 Received: (from archie@localhost) by bubba.whistle.com (8.7.5/8.6.12) id OAA24821; Wed, 29 Jan 1997 14:40:44 -0800 (PST) From: Archie Cobbs Message-Id: <199701292240.OAA24821@bubba.whistle.com> Subject: Re: ipdivert & masqd In-Reply-To: from Charles Mott at "Jan 29, 97 01:58:28 pm" To: cmott@srv.net (Charles Mott) Date: Wed, 29 Jan 1997 14:40:44 -0800 (PST) Cc: avalon@coombs.anu.edu.au, eivind@dimaga.com, brian@awfulhak.demon.co.uk, archie@whistle.com, hackers@FreeBSD.ORG, ari.suutari@ps.carel.fi 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-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > But anything after the 512th data byte in the TCP payload will be ignored, > > so if your message is 512 bytes long, contains a DCC request in it, > > information will be lost that the sender is not aware about (this assumes > > the packet is just one IRC message) if the payload size must increase as > > a result. > > > > It is a *much* better idea to redirect IRC to a local TCP port and process > > it using a proxy agent. Same could also be said for FTP. > > > > Darren > > Darren, > > In theory, one can construct cases where the FTP logic in the packet > aliasing software won't work (IP fragmenting a PORT command, or where the > PORT command is split between TCP packets with different sequence numbers, > or where the PORT command is in the middle of a packet, and so forth). > > In practice, these situations are not seen, and the packet aliasing > software works for FTP. The system loading is very low, and the software > easily scales to situations where there are large numbers of users. My observations are consistent with Charles' .. I've only ever seen the FTP port command alone in it's own packet. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Wed Jan 29 14:46:33 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA27201 for hackers-outgoing; Wed, 29 Jan 1997 14:46:33 -0800 (PST) Received: from panda.hilink.com.au (panda.hilink.com.au [203.2.144.5]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA27188 for ; Wed, 29 Jan 1997 14:45:54 -0800 (PST) Received: (from danny@localhost) by panda.hilink.com.au (8.7.6/8.7.3) id JAA16901; Thu, 30 Jan 1997 09:45:39 +1100 (EST) Date: Thu, 30 Jan 1997 09:45:38 +1100 (EST) From: "Daniel O'Callaghan" To: Charles Mott cc: Darren Reed , Eivind Eklund , brian@awfulhak.demon.co.uk, archie@whistle.com, hackers@freebsd.org, ari.suutari@ps.carel.fi Subject: Re: ipdivert & masqd In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 29 Jan 1997, Charles Mott wrote: > In theory, one can construct cases where the FTP logic in the packet > aliasing software won't work (IP fragmenting a PORT command, or where the > PORT command is split between TCP packets with different sequence numbers, > or where the PORT command is in the middle of a packet, and so forth). > > In practice, these situations are not seen, and the packet aliasing > software works for FTP. The system loading is very low, and the software > easily scales to situations where there are large numbers of users. > > I don't know about IRC, but my guess is that the real situation is simpler > than the theoretical. Whatever Linux does to handle IRC, I am told that > it looks fairly similar to what one does for FTP. People coding these in-stream proxies might also like to look at the slirp code There are quite a few transparent proxies in there. Danny From owner-freebsd-hackers Wed Jan 29 14:47:28 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA27254 for hackers-outgoing; Wed, 29 Jan 1997 14:47:28 -0800 (PST) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA27246 for ; Wed, 29 Jan 1997 14:47:26 -0800 (PST) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id OAA19160; Wed, 29 Jan 1997 14:46:43 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma019158; Wed Jan 29 14:46:19 1997 Received: (from archie@localhost) by bubba.whistle.com (8.7.5/8.6.12) id OAA24842; Wed, 29 Jan 1997 14:46:19 -0800 (PST) From: Archie Cobbs Message-Id: <199701292246.OAA24842@bubba.whistle.com> Subject: Re: ipdivert & masqd In-Reply-To: <199701292130.NAA19395@gatekeeper> from Darren Reed at "Jan 30, 97 08:29:09 am" To: avalon@coombs.anu.edu.au (Darren Reed) Date: Wed, 29 Jan 1997 14:46:19 -0800 (PST) Cc: archie@whistle.com, terry@lambert.org, ari.suutari@ps.carel.fi, brian@awfulhak.demon.co.uk, hackers@freebsd.org, cmott@srv.net 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > The theory was that this loop avoidance was working too well, and > > seemed to be applying to packets other than the one that it was > > supposed to. What I'm trying to prove to myself is that this can't > > be happening. > > Does ip_divert_flag get set/reset inside or outside the loop in > ip_input() which dequeues packets ? (src isn't handy) Ah.. well, it doesn't get reset until ip_input() returns. Perhaps this is the problem... certainly if calling ip_input() with one packet can trigger the ipfw processing of other packets, that would be bad. [ checking source .. ] >From my reading it doesn't seem like this can happen. Packet fragments are queued up and then merged when the last packet arrives, but sending ip_input() a whole separate packet shouldn't trigger this. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Wed Jan 29 14:47:30 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA27266 for hackers-outgoing; Wed, 29 Jan 1997 14:47:30 -0800 (PST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA27251 for ; Wed, 29 Jan 1997 14:47:27 -0800 (PST) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.4/8.8.4) with SMTP id OAA25606 for ; Wed, 29 Jan 1997 14:46:26 -0800 (PST) Message-ID: <32EFD2E2.167EB0E7@whistle.com> Date: Wed, 29 Jan 1997 14:44:50 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: hackers@freebsd.org Subject: [Fwd: freebsd performance.] Content-Type: multipart/mixed; boundary="------------794BDF32446B9B3D2781E494" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This is a multi-part message in MIME format. --------------794BDF32446B9B3D2781E494 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit A commnet from someone using FreeBSD in a production project.. I know nothing about the regex stuff... anyone have comments? people who have committed their proffesional name on using freeBSD deserve sume special support. julian --------------794BDF32446B9B3D2781E494 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: Received: from whistle.com (whistle.whistle.com [207.76.205.131]) by alpo.whistle.com (8.8.4/8.8.4) with ESMTP id JAA18431 for ; Wed, 29 Jan 1997 09:42:39 -0800 (PST) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id JAA16637 for ; Wed, 29 Jan 1997 09:42:37 -0800 (PST) Received: from gatekeeper.whistle.com(207.76.204.2) by whistle.com via smap (V1.3) id sma016635; Wed Jan 29 09:42:31 1997 Received: (from smap@localhost) by gatekeeper (8.7.5/8.6.12) id JAA15158 for ; Wed, 29 Jan 1997 09:42:31 -0800 (PST) Received: from idiom.com(140.174.82.4) by gatekeeper via smap (V1.3) id sma015156; Wed Jan 29 09:41:12 1997 Received: from localhost (jason@localhost [127.0.0.1]) by idiom.com (8.8.5/8.8.3) with SMTP id JAA10621 for ; Wed, 29 Jan 1997 09:41:11 -0800 (PST) Message-Id: <199701291741.JAA10621@idiom.com> X-Authentication-Warning: idiom.com: jason@localhost [127.0.0.1] didn't use HELO protocol To: julian@whistle.com Subject: freebsd performance. Date: Wed, 29 Jan 1997 09:41:11 -0800 From: Jason Venner The posix regex library is VERY VERY slow. I have a program that uses a large regex to parse some input. I have a version in perl and a version in C++ using the freebsd posix regex library. The perl version is 100X faster that the C++ version. gprof on the C++ version shows 99% of the spend in: 91.53 46.17 46.17 1152366 0.04 0.04 lstep 6.52 49.46 3.29 98497 0.03 0.47 lslow --------------794BDF32446B9B3D2781E494-- From owner-freebsd-hackers Wed Jan 29 14:47:40 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA27305 for hackers-outgoing; Wed, 29 Jan 1997 14:47:40 -0800 (PST) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id OAA27295 for ; Wed, 29 Jan 1997 14:47:37 -0800 (PST) Received: from becker2.u.washington.edu by agora.rdrop.com with smtp (Smail3.1.29.1 #17) id m0vpims-000907C; Wed, 29 Jan 97 14:47 PST Received: from localhost (spaz@localhost) by becker2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW96.12) with SMTP id OAA26572; Wed, 29 Jan 1997 14:45:42 -0800 (PST) Date: Wed, 29 Jan 1997 14:45:40 -0800 (PST) From: John Utz To: Michael Beckmann cc: hackers@FreeBSD.ORG Subject: Re: 2.2-BETA: options MAXMEM not working (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi; This sounds like a variable length problem, such as a variable that is declared as an int but actually needs to be a long int...., thus you might be getting a wrap-around modulo the largest value that the variable can actually hold... just my 0.02.... On Wed, 29 Jan 1997, Michael Beckmann wrote: > OK, after having built a couple more kernels, I found out that the MAXMEM > option does not work for me when set to over 128 MB. I now run a kernel > that uses only 128 MB, though my machine has 192 MB and will have 256 at > the end of the week. Has this problem been fixed in kernels subsequent to > 2.2-BETA ? I was using 160 MB just fine with FreeBSD 2.1.5. > > Cheers, > > Michael > > ******************************************************************************* John Utz spaz@u.washington.edu idiocy is the impulse function in the convolution of life From owner-freebsd-hackers Wed Jan 29 15:06:05 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA28261 for hackers-outgoing; Wed, 29 Jan 1997 15:06:05 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA28255 for ; Wed, 29 Jan 1997 15:06:01 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id KAA17182; Thu, 30 Jan 1997 10:02:03 +1100 Date: Thu, 30 Jan 1997 10:02:03 +1100 From: Bruce Evans Message-Id: <199701292302.KAA17182@godzilla.zeta.org.au> To: j@uriah.heep.sax.de, Shimon@i-Connect.Net Subject: Re: More 2.2-BETA goodies... Cc: hackers@FreeBSD.ORG Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> Discounting >> 100 interrupts for the heartbeat, ... > >You have to discount 100 + 128 interrupts per second, there are two >clocks. If you're using pcaudio, this increases to 100 + 1024 while >pcaudio is running. 16000 + 128 when pcaudio is running. 100 + 1024 when profiling is running. I use pcaudio to stress the system. Bruce From owner-freebsd-hackers Wed Jan 29 15:35:11 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA29745 for hackers-outgoing; Wed, 29 Jan 1997 15:35:11 -0800 (PST) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA29721 for ; Wed, 29 Jan 1997 15:34:55 -0800 (PST) Received: from awfulhak.demon.co.uk (localhost.coverform.lan [127.0.0.1]) by awfulhak.demon.co.uk (8.8.4/8.7.3) with ESMTP id XAA14485; Wed, 29 Jan 1997 23:30:52 GMT Message-Id: <199701292330.XAA14485@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: Archie Cobbs cc: terry@lambert.org (Terry Lambert), ari.suutari@ps.carel.fi, hackers@freebsd.org, cmott@srv.net Subject: Re: ipdivert & masqd In-reply-to: Your message of "Wed, 29 Jan 1997 12:16:41 PST." <199701292016.MAA24360@bubba.whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 Jan 1997 23:30:52 +0000 From: Brian Somers Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [.....] > > Actually, I think it's so the outbound packet doesn't get redivirted > > by that particular handler, but you *can* chain handlers. For instance, > > say I wanted to chain a cleanwall, a firewall, and a IP proxy server > > and they were all in seperate divert modules. > > Right! That is the purpose of this ip_divert_ignore hack -- for loop > avoidance. It allows you to send a packet back out via the divert socket > and simultaneously say "Don't divert *this* packet back into *this* socket". > > The theory was that this loop avoidance was working too well, and > seemed to be applying to packets other than the one that it was > supposed to. What I'm trying to prove to myself is that this can't > be happening. > > -Archie Not exactly - on my machine, there are two problems (3.0-current). The machine that's doing the masquerading is 10.0.1.254. 1. When I do a tcp setup from 10.0.1.254 to 10.0.1.1, the packet goes out ok, 10.0.1.1 receives it and replies (netstat shows ESTABLISHED). Masqd/natd receives the packet, fixes it and re-injects it.... then, all of a sudden, nothing happens. After a long wait, nothing continues to happen :( It's as if the ip_sum is wrong, but I don't believe that yet as it works ok when there are two divert sockets involved. 2. When a ping is sent from 10.0.1.1 to 10.0.1.254, the incoming icmp packet is picked up by masqd/natd, fondled and re-injected. That's *all* that masqd/natd sees. However, 10.0.1.1 gets an ICMP reply. Everything else works. -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Wed Jan 29 15:48:27 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA00434 for hackers-outgoing; Wed, 29 Jan 1997 15:48:27 -0800 (PST) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA00429 for ; Wed, 29 Jan 1997 15:48:23 -0800 (PST) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id PAA19873; Wed, 29 Jan 1997 15:47:45 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma019871; Wed Jan 29 15:47:15 1997 Received: (from archie@localhost) by bubba.whistle.com (8.7.5/8.6.12) id PAA25117; Wed, 29 Jan 1997 15:47:14 -0800 (PST) From: Archie Cobbs Message-Id: <199701292347.PAA25117@bubba.whistle.com> Subject: Re: ipdivert & masqd In-Reply-To: <199701292330.XAA14485@awfulhak.demon.co.uk> from Brian Somers at "Jan 29, 97 11:30:52 pm" To: brian@awfulhak.demon.co.uk (Brian Somers) Date: Wed, 29 Jan 1997 15:47:14 -0800 (PST) Cc: archie@whistle.com, terry@lambert.org, ari.suutari@ps.carel.fi, hackers@freebsd.org, cmott@srv.net 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Not exactly - on my machine, there are two problems (3.0-current). The > machine that's doing the masquerading is 10.0.1.254. > > 1. When I do a tcp setup from 10.0.1.254 to 10.0.1.1, the packet goes out > ok, 10.0.1.1 receives it and replies (netstat shows ESTABLISHED). > Masqd/natd receives the packet, fixes it and re-injects it.... then, > all of a sudden, nothing happens. After a long wait, nothing continues > to happen :( It's as if the ip_sum is wrong, but I don't believe that > yet as it works ok when there are two divert sockets involved. > > 2. When a ping is sent from 10.0.1.1 to 10.0.1.254, the incoming icmp > packet is picked up by masqd/natd, fondled and re-injected. That's > *all* that masqd/natd sees. However, 10.0.1.1 gets an ICMP reply. Hmmm.. a couple of questions, trying to understand the setup. Sorry if this is starting to get tiring... :-) - What is your network topology (ASCII art if possible)? That is, what IP interfaces are on what networks with what addresses assigned? - What are the ipfw rules that are installed on the diverting machine? - Why are any packets having their IP addresses remapped if the two machines (at 10.0.1.254 and 10.0.1.1) are on the same subnet? Also, if netstat shows ESTABLISHED (on either end), then at least one packet must have successfully made it across in both directions, due to the TCP handshaking involved in getting to that state. Thanks, -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Wed Jan 29 15:56:07 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA00809 for hackers-outgoing; Wed, 29 Jan 1997 15:56:07 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA00800 for ; Wed, 29 Jan 1997 15:56:05 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id PAA09608; Wed, 29 Jan 1997 15:55:41 -0800 (PST) To: Julian Elischer cc: hackers@FreeBSD.ORG Subject: Re: [Fwd: freebsd performance.] In-reply-to: Your message of "Wed, 29 Jan 1997 14:44:50 PST." <32EFD2E2.167EB0E7@whistle.com> Date: Wed, 29 Jan 1997 15:55:40 -0800 Message-ID: <9604.854582140@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I know nothing about the regex stuff... > anyone have comments? We know. Keith Bostic was grousing about it at USENIX, and apparently Henry Spencer was supposed to do more stuff with the regexp code but never did, so it's sort of up for grabs. Jordan From owner-freebsd-hackers Wed Jan 29 15:59:03 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA00931 for hackers-outgoing; Wed, 29 Jan 1997 15:59:03 -0800 (PST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA00926 for ; Wed, 29 Jan 1997 15:59:00 -0800 (PST) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.4/8.8.4) with SMTP id PAA27625; Wed, 29 Jan 1997 15:56:10 -0800 (PST) Message-ID: <32EFE339.31DFF4F5@whistle.com> Date: Wed, 29 Jan 1997 15:54:33 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Joerg Wunsch CC: Simon Shapiro , hackers@freebsd.org Subject: Re: More 2.2-BETA goodies... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk J Wunsch wrote: > > As Simon Shapiro wrote: > > > Shortcut: umount /devs > > Known sucker. DEVFS is really not yet ready for the masses. (Alas.) damm! I tought I fixed that! oh well hpefully I'll get back to it again.. > > > 5. Question: Using xperfmon++ (cool), one observes that a system equipped > > with AHA2940W enjoys about 3-15 times as many interrupts/sec as disk > > transfers/sec. The system, does nothing but SCSI right now (cvs > > checkout in parallel with a tape backup (cpio, I know...). > > Nothing else. > > > > Discounting > > 100 interrupts for the heartbeat, ... > > You have to discount 100 + 128 interrupts per second, there are two > clocks. If you're using pcaudio, this increases to 100 + 1024 while > pcaudio is running. actually thats 16000 for pcaudio it interrupts twice per audio sample :) > > xperfmon++ has a tendency to not become adapted to more recent changes > very quickly (guess whom you should blame for this :-). systat > -vmstat might be more authoritative in its data (and also gives you a > split view for the various interrupt sources). julian From owner-freebsd-hackers Wed Jan 29 16:21:19 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA02282 for hackers-outgoing; Wed, 29 Jan 1997 16:21:19 -0800 (PST) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA02277 for ; Wed, 29 Jan 1997 16:21:08 -0800 (PST) Received: from awfulhak.demon.co.uk (localhost.coverform.lan [127.0.0.1]) by awfulhak.demon.co.uk (8.8.4/8.7.3) with ESMTP id AAA15020; Thu, 30 Jan 1997 00:11:56 GMT Message-Id: <199701300011.AAA15020@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: Archie Cobbs cc: terry@lambert.org, ari.suutari@ps.carel.fi, hackers@freebsd.org, cmott@srv.net Subject: Re: ipdivert & masqd In-reply-to: Your message of "Wed, 29 Jan 1997 15:47:14 PST." <199701292347.PAA25117@bubba.whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 30 Jan 1997 00:11:56 +0000 From: Brian Somers Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > Not exactly - on my machine, there are two problems (3.0-current). The > > machine that's doing the masquerading is 10.0.1.254. > > > > 1. When I do a tcp setup from 10.0.1.254 to 10.0.1.1, the packet goes out > > ok, 10.0.1.1 receives it and replies (netstat shows ESTABLISHED). > > Masqd/natd receives the packet, fixes it and re-injects it.... then, > > all of a sudden, nothing happens. After a long wait, nothing continues > > to happen :( It's as if the ip_sum is wrong, but I don't believe that > > yet as it works ok when there are two divert sockets involved. > > > > 2. When a ping is sent from 10.0.1.1 to 10.0.1.254, the incoming icmp > > packet is picked up by masqd/natd, fondled and re-injected. That's > > *all* that masqd/natd sees. However, 10.0.1.1 gets an ICMP reply. > > Hmmm.. a couple of questions, trying to understand the setup. Sorry if > this is starting to get tiring... :-) > > - What is your network topology (ASCII art if possible)? That is, > what IP interfaces are on what networks with what addresses assigned? > > - What are the ipfw rules that are installed on the diverting machine? > > - Why are any packets having their IP addresses remapped if the two > machines (at 10.0.1.254 and 10.0.1.1) are on the same subnet? > > Also, if netstat shows ESTABLISHED (on either end), then at least > one packet must have successfully made it across in both directions, > due to the TCP handshaking involved in getting to that state. > > Thanks, > -Archie I've essentially got the following: ---------------- ---------------------- | 10.0.10.2 |------------------| 10.0.10.1 | ---------------- | | | 10.0.1.254 (ed0) | ---------------------- | | ----------------- | | 10.0.1.1 |--------------------------- ----------------- with a mask of ffffff00 everywhere and the machine in the middle using the following: ipfw add 100 divert 6668 all from any to any via ed0 The masqd/natd programs then pick up all packets and call the packet aliasing code. *All* packets get mangled so that there are no real/alias port conflicts - that is, an outgoing packet to 10.0.1.1:21 from 10.0.1.254:1025 cannot keep the 1025 port because it may conflict with an already existing "alias" port - making it impossible to figure out what to do with the returning 10.0.1.254:1025 packet. Instead, all packets have their source port changed to an alias port on the way out, and changed back to what it should be on the way back in. A table is maintained, mapping alias ports to real IP/port pairs. Needless to say, the "point" behind this is to have the 10.0.10.0/24 network connected to the 10.0.1.1/24 network through the 10.0.1.254 IP. The problems with the 10.0.1.254 machine itself are a bit of a shame because that's the machine that didn't need to do anything special in the first place :) -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Wed Jan 29 16:28:27 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA02705 for hackers-outgoing; Wed, 29 Jan 1997 16:28:27 -0800 (PST) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA02697 for ; Wed, 29 Jan 1997 16:28:24 -0800 (PST) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id QAA20289; Wed, 29 Jan 1997 16:27:45 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma020287; Wed Jan 29 16:27:22 1997 Received: (from archie@localhost) by bubba.whistle.com (8.7.5/8.6.12) id QAA25259; Wed, 29 Jan 1997 16:27:21 -0800 (PST) From: Archie Cobbs Message-Id: <199701300027.QAA25259@bubba.whistle.com> Subject: Re: ipdivert & masqd In-Reply-To: <199701300011.AAA15020@awfulhak.demon.co.uk> from Brian Somers at "Jan 30, 97 00:11:56 am" To: brian@awfulhak.demon.co.uk (Brian Somers) Date: Wed, 29 Jan 1997 16:27:21 -0800 (PST) Cc: archie@whistle.com, terry@lambert.org, ari.suutari@ps.carel.fi, hackers@freebsd.org, cmott@srv.net 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I've essentially got the following: > > ---------------- ---------------------- > | 10.0.10.2 |------------------| 10.0.10.1 | > ---------------- | | > | 10.0.1.254 (ed0) | > ---------------------- > | > | > ----------------- | > | 10.0.1.1 |--------------------------- > ----------------- > > with a mask of ffffff00 everywhere and the machine in the middle using > the following: > > ipfw add 100 divert 6668 all from any to any via ed0 A-HAH! :-) Could you try the following patch? Thanks, -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com Index: ip_input.c =================================================================== RCS file: /cvs/freebsd/src/sys/netinet/ip_input.c,v retrieving revision 1.50.2.1 diff -c -r1.50.2.1 ip_input.c *** 1.50.2.1 1996/11/11 23:40:45 --- ip_input.c 1997/01/30 00:26:55 *************** *** 431,436 **** --- 431,438 ---- return; ours: + ip_divert_ignore = 0; /* This packet is being consumed locally, + so we can turn off loop avoidance. */ /* * If offset or IP_MF are set, must reassemble. From owner-freebsd-hackers Wed Jan 29 16:29:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA02886 for hackers-outgoing; Wed, 29 Jan 1997 16:29:59 -0800 (PST) Received: from fog.xinside.com (fog.xinside.com [199.164.187.39]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA02877 for ; Wed, 29 Jan 1997 16:29:55 -0800 (PST) Received: (from smap@localhost) by fog.xinside.com (8.8.3/8.7.3) id RAA13970 for ; Wed, 29 Jan 1997 17:29:54 -0700 (MST) X-Authentication-Warning: fog.xinside.com: smap set sender to using -f Received: from chon.xinside.com(199.164.187.134) by fog.xinside.com via smap (V1.3) id sma013968; Wed Jan 29 17:29:38 1997 Received: (from patrick@localhost) by chon.xinside.com (8.7.5/8.6.12) id RAA02431; Wed, 29 Jan 1997 17:29:19 -0700 (MST) Date: Wed, 29 Jan 1997 17:29:19 -0700 (MST) Message-Id: <199701300029.RAA02431@chon.xinside.com> From: Patrick Giagnocavo To: hackers@freebsd.org Subject: [Fwd: freebsd performance.] In-Reply-To: <32EFD2E2.167EB0E7@whistle.com> References: <32EFD2E2.167EB0E7@whistle.com> Reply-To: patrick@xinside.com Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Julian Elischer writes: > The posix regex library is VERY VERY slow. > > I have a program that uses a large regex to parse some input. > > I have a version in perl and a version in C++ using the freebsd posix > regex library. > > The perl version is 100X faster that the C++ version. > > gprof on the C++ version shows 99% of the spend in: > > 91.53 46.17 46.17 1152366 0.04 0.04 lstep > 6.52 49.46 3.29 98497 0.03 0.47 lslow I am surprised that some of our more erudite members on the list have not jumped on this. So, a definitely non-erudite person will. The best book to get on the subject is the newly released 'Mastering Regular Expressions' by Jeffrey Freidl; it is published by O'Reilly and Associates. Posix regex is explained in the book; as well, there are a number of tests, gambits, and special cases that can be used to substantially speed up searches. There are two different 'engines' - NFA (nondeterministic finite automaton) and DFA (deterministic finite automaton). Perl is 'traditional NFA' according to Mr. Friedl, while POSIX leans towards DFA-like behavior in all cases (always returns 'leftmost-longest' that matches - perl returns I believe the first part that matches). Also, Perl does not 'do' POSIX IIRC; so the results can actually be different when using the same regex string. Perl does however have some very powerful features for its regex - covered in the book. Anyways, get the book - it is well written and very informative. Another book that covers this is the 'Red Dragon' compiler book by Aho Sethi and Ullman. Page 113 and following in the version I have. Maybe this fellow should post all or part of his regex strings - there may well be a way to optimize them. I am sure that there is a way to speed it up to get it faster. 100X difference is just too great to say that it is the library, IMHO. Cordially Patrick Giagnocavo patrick@xinside.com -Opinions expressed are not even mine, let alone my employers'!- From owner-freebsd-hackers Wed Jan 29 16:48:17 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA04792 for hackers-outgoing; Wed, 29 Jan 1997 16:48:17 -0800 (PST) Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA04783 for ; Wed, 29 Jan 1997 16:48:14 -0800 (PST) Received: from awfulhak.demon.co.uk by mail.crl.com with SMTP id AA02871 (5.65c/IDA-1.5 for ); Wed, 29 Jan 1997 16:47:36 -0800 Received: from awfulhak.demon.co.uk (localhost.coverform.lan [127.0.0.1]) by awfulhak.demon.co.uk (8.8.4/8.7.3) with ESMTP id AAA15572 for ; Thu, 30 Jan 1997 00:43:57 GMT Message-Id: <199701300043.AAA15572@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: hackers@freebsd.org Subject: Source code commits Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 30 Jan 1997 00:43:57 +0000 From: Brian Somers Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Is it possible to commit source code locally, and get cvsup to send the udpates back to freefall ? If not, would there be a lot of work involved ? -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Wed Jan 29 16:59:34 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA05821 for hackers-outgoing; Wed, 29 Jan 1997 16:59:34 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA05813 for ; Wed, 29 Jan 1997 16:59:31 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id LAA23779; Thu, 30 Jan 1997 11:29:18 +1030 (CST) From: Michael Smith Message-Id: <199701300059.LAA23779@genesis.atrad.adelaide.edu.au> Subject: Kernel extensions, &c. &c. In-Reply-To: <1.5.4.32.19970122145501.00691f78@jump.net> from Lee Crites at "Jan 22, 97 08:55:01 am" To: adonai@jump.net (Lee Crites) Date: Thu, 30 Jan 1997 11:29:17 +1030 (CST) Cc: 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk (Mailbox overload!) Lee Crites stands accused of saying: > >>> Having been on the kernel extension writing end of things, I can appreciate >>> how complex it would be to configure a live, running kernel that can accept > >> aribrary extensions on the fly. However, making something that can > >> link/re-link on reboot wouldn't be as difficult. > > > >Are you admitting some experience and maybe offering to help? Wonderful! > > Well, I've tried to 'admit[] some experience and maybe offer[] to help' > twice before. This is the first time I have received a positive response to it. That's unhappy 8( > The first time (about sockets and such) seemed to have actually garnered > some quasi-offense. I was, in fact, somewhat surprised. After two decades > in the computer industry, including working as a consultant in many > different fields, this was the first time I felt snubbed at the offer of > free help. (While it is true that loading the os on a machine and joining > some lists doesn't make me a 'part' of FreeBSD, I did have some hopes at > kind of wedging my foot in the door, so to speak, by trying to help out in > areas I understood fairly well.) TBH, I don't recall this at all. I certainly don't think that it could be described as the "normal" state of affairs. > I wish you guys luck in trying to come to a good conclusion in this (and the > few other) debate going on. A 'good' conclusion, imo, is one where all > parties can come away feeling good with what is happening and where it is > going, and are happily working together towards the same goals. Thanks! Hopefully your mail problems have been resolved and you can share in the process; I for one would be happy to have your experience and perspective around, and I'm certain I wouldn't be alone. > Lee -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Wed Jan 29 17:20:36 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA07683 for hackers-outgoing; Wed, 29 Jan 1997 17:20:36 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA07674 for ; Wed, 29 Jan 1997 17:20:31 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id LAA24028; Thu, 30 Jan 1997 11:50:11 +1030 (CST) From: Michael Smith Message-Id: <199701300120.LAA24028@genesis.atrad.adelaide.edu.au> Subject: Re: Constructive criticism (was: bashing everyone for fun and profit) In-Reply-To: <199701290249.VAA04040@spoon.beta.com> from "Brian J. McGovern" at "Jan 28, 97 09:49:02 pm" To: mcgovern@spoon.beta.com (Brian J. McGovern) Date: Thu, 30 Jan 1997 11:50:10 +1030 (CST) Cc: 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Brian J. McGovern stands accused of saying: > I've been noticing, more an more, that FreeBSD has been/is being > divided in to two camps. Basically, the "has", and the "has > not". What I mean by this, is that there appears to be the core > team, who kick butt making this stuff all work, then the people like > me, who'd like to help out where they can, but seem to have an > incredible time getting started. This is called the "learning curve". There are two ways to climb it, for climb it you must if you want to do anything. 1) Spend lots of time trying, asking questions, exercising your intelligence and patience. 2) Give lots of money to someone else to have them force you through 1). The "have/have not" stance, in this case, is sour grapes because you haven't made it up yet. There isn't some cabal trying to keep you ignorant and frustrated - developers are desperately desired! Case 2) really only manifests when there are lots of people desperate to climb and stupid enough to part with the sort of money involved, which isn't the case with FreeBSD. > you can't beam armies up to your ship, but I digress... I'd like to > submit it in to the "games" section of the ports. However, I notice > this great little file structure that allows you to type "make > install clean", and bam! the application is made, installed, and the > working space is cleaned up. It's in the handbook, in the section on ports. It looks like a cookbook to me. Or perhaps you could look at a few other ones that might be similar to yours - learn by example? > The second major area of concern in my eyes is device > drivers. Someone pointed me to a section of handbook that dealt with > doing it (supposedly), but it was terribly out of date. Back to If you can't work out how device drivers are integrated, I seriously doubt that you're up to writing one in the first place. 8( However, I'll note that I've been helping people learning DD writing for a while now (not that I'm any expert at it either), and I've never seen your name attached to a question going past. How are you supposed to learn if you never _ask_? > I guess what I'm getting at is this: There are a lot of us out here > who would write man pages if we knew how to typeset them, those who > would write neat utilities if we knew how to poll the information > from the kernel (hell, I know about zillion people who'd love to > know how to pull IO/up-down, config statistics from their Ethernet > interfaces, for instance), those who would write drivers for widget > X if they knew how to get them in to the kernel (there are a million > books on writing drivers, but none that I know of that speak > especially about FreeBSD)... I hate to say it, but I think that the right line for you is "there are a lot of us out here that like to whine about doing stuff because it requires some effort, and we're socialised to expect everything handed to us on a platter covered with disclaimers". _prove_me_wrong_ : I (and plenty of others) are willing to help you achieve your goals. It's why we're here. > Them: There isn't any. Try looking at out of date code here>. > > Me: Looks like I'm right so far. Go for it. Please? -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Wed Jan 29 17:26:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA07868 for hackers-outgoing; Wed, 29 Jan 1997 17:26:51 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA07861 for ; Wed, 29 Jan 1997 17:26:47 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id RAA11495; Wed, 29 Jan 1997 17:25:20 -0800 (PST) To: Terry Lambert cc: jlemon@americantv.com, hackers@FreeBSD.ORG Subject: Re: 2.2-BETA Questions In-reply-to: Your message of "Wed, 29 Jan 1997 11:00:00 MST." <199701291800.LAA12267@phaeton.artisoft.com> Date: Wed, 29 Jan 1997 17:25:20 -0800 Message-ID: <11491.854587520@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Make sure the IDE controller does not support LBA, get a bigger than > 512M IDE drive anyway, and install the OnTrack 7.x stuff to load > .. a whole bunch of similar instructions deleted .. Why do I get the feeling that Terry is enjoying this? Terry, you sadist! :-) Jordan From owner-freebsd-hackers Wed Jan 29 17:44:15 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA08896 for hackers-outgoing; Wed, 29 Jan 1997 17:44:15 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA08891 for ; Wed, 29 Jan 1997 17:44:13 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id RAA11626; Wed, 29 Jan 1997 17:44:08 -0800 (PST) To: Brian Somers cc: hackers@freebsd.org Subject: Re: Source code commits In-reply-to: Your message of "Thu, 30 Jan 1997 00:43:57 GMT." <199701300043.AAA15572@awfulhak.demon.co.uk> Date: Wed, 29 Jan 1997 17:44:07 -0800 Message-ID: <11622.854588647@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Is it possible to commit source code locally, and get cvsup to send the > udpates back to freefall ? If not, would there be a lot of work involved ? This isn't cvsup's domain, actually, but it is something CVS can handle itself. You simply set CVS_RSH to ``ssh' and CVSROOT to ``freefall.freebsd.org:/home/ncvs'', then you do your CVS operations as normal. I have some shell functions which I use so that I can keep things checked out relative to my local CVS repository (and obviously many times faster than using freefall's) up until the point where I want to commit the changes, then it fools CVS into thinking that the sources were originally checked out from freefall too: function do-local-cvs { setenv CVSROOT /home/ncvs [ -f CVS/Root ] && echo $CVSROOT > CVS/Root } function do-remote-cvs { setenv CVSROOT freefall.freebsd.org:/home/ncvs [ -f CVS/Root ] && echo $CVSROOT > CVS/Root } function cvscommit { do-remote-cvs cvs commit $* do-local-cvs } From owner-freebsd-hackers Wed Jan 29 17:59:52 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA09819 for hackers-outgoing; Wed, 29 Jan 1997 17:59:52 -0800 (PST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA09802 for ; Wed, 29 Jan 1997 17:59:49 -0800 (PST) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.4/8.8.4) with SMTP id RAA00697; Wed, 29 Jan 1997 17:56:17 -0800 (PST) Message-ID: <32EFFF5F.794BDF32@whistle.com> Date: Wed, 29 Jan 1997 17:54:40 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Michael Smith CC: Lee Crites , hackers@freebsd.org Subject: Re: Kernel extensions, &c. &c. References: <199701300059.LAA23779@genesis.atrad.adelaide.edu.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Michael Smith wrote: > > (Mailbox overload!) > > Lee Crites stands accused of saying: > > > >>> Having been on the kernel extension writing end of things, I can appreciate > >>> how complex it would be to configure a live, running kernel that can accept > > >> aribrary extensions on the fly. However, making something that can > > >> link/re-link on reboot wouldn't be as difficult. > > > > > >Are you admitting some experience and maybe offering to help? Wonderful! > > > > Well, I've tried to 'admit[] some experience and maybe offer[] to help' > > twice before. This is the first time I have received a positive response to it. The trouble seems to be that there is no single "task master" who can tell you what you should be doing. So if peple are hacking away on their own code they usually feel that they haven't really got the time to explain every thing to some-one new , or that they are not happy with others seeing their code in that state, etc. you need to find something you are interested in and just start on it yourself.. other people will very quickly notice you and include you in the relevant conversations. > > That's unhappy 8( > > > The first time (about sockets and such) seemed to have actually garnered > > some quasi-offense. I was, in fact, somewhat surprised. After two decades > > in the computer industry, including working as a consultant in many > > different fields, this was the first time I felt snubbed at the offer of > > free help. (While it is true that loading the os on a machine and joining > > some lists doesn't make me a 'part' of FreeBSD, I did have some hopes at > > kind of wedging my foot in the door, so to speak, by trying to help out in > > areas I understood fairly well.) What did you offer? there must have been a miscommunication somewhere.. > > TBH, I don't recall this at all. I certainly don't think that it could be > described as the "normal" state of affairs. > > > I wish you guys luck in trying to come to a good conclusion in this (and the > > few other) debate going on. A 'good' conclusion, imo, is one where all > > parties can come away feeling good with what is happening and where it is > > going, and are happily working together towards the same goals. > > Thanks! Hopefully your mail problems have been resolved and you can > share in the process; I for one would be happy to have your experience > and perspective around, and I'm certain I wouldn't be alone. me too > > > Lee > > -- > ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ > ]] Genesis Software genesis@gsoft.com.au [[ > ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ > ]] realtime instrument control. (ph) +61-8-8267-3493 [[ > ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Wed Jan 29 18:01:02 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA10037 for hackers-outgoing; Wed, 29 Jan 1997 18:01:02 -0800 (PST) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA10010 for ; Wed, 29 Jan 1997 18:00:54 -0800 (PST) Message-Id: <199701300200.SAA10010@freefall.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA019119490; Thu, 30 Jan 1997 12:58:10 +1100 From: Darren Reed Subject: Re: ipdivert & masqd To: archie@whistle.com (Archie Cobbs) Date: Thu, 30 Jan 1997 12:58:10 +1100 (EDT) Cc: avalon@coombs.anu.edu.au, archie@whistle.com, terry@lambert.org, ari.suutari@ps.carel.fi, brian@awfulhak.demon.co.uk, hackers@FreeBSD.ORG, cmott@srv.net In-Reply-To: <199701292246.OAA24842@bubba.whistle.com> from "Archie Cobbs" at Jan 29, 97 02:46:19 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In some mail from Archie Cobbs, sie said: > > > > > The theory was that this loop avoidance was working too well, and > > > seemed to be applying to packets other than the one that it was > > > supposed to. What I'm trying to prove to myself is that this can't > > > be happening. > > > > Does ip_divert_flag get set/reset inside or outside the loop in > > ip_input() which dequeues packets ? (src isn't handy) > > Ah.. well, it doesn't get reset until ip_input() returns. Perhaps > this is the problem... certainly if calling ip_input() with one > packet can trigger the ipfw processing of other packets, that would > be bad. > > [ checking source .. ] > > >From my reading it doesn't seem like this can happen. Packet fragments > are queued up and then merged when the last packet arrives, but sending > ip_input() a whole separate packet shouldn't trigger this. Not what I meant...the ethernet drivers queue up packets using IF_ENQUEUE() (right ?) and ip_input() picks them off using IF_DEQUEUE()...or is there an external loop calling ip_input() now that does the IF_DEQUEUE() ? Darren From owner-freebsd-hackers Wed Jan 29 18:02:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA10162 for hackers-outgoing; Wed, 29 Jan 1997 18:02:37 -0800 (PST) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA10143 for ; Wed, 29 Jan 1997 18:02:31 -0800 (PST) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id TAA01256; Wed, 29 Jan 1997 19:02:25 -0700 (MST) Date: Wed, 29 Jan 1997 19:02:25 -0700 (MST) Message-Id: <199701300202.TAA01256@rocky.mt.sri.com> From: Nate Williams To: Brian Somers Cc: hackers@freebsd.org Subject: Re: Source code commits In-Reply-To: <199701300043.AAA15572@awfulhak.demon.co.uk> References: <199701300043.AAA15572@awfulhak.demon.co.uk> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Is it possible to commit source code locally, and get cvsup to send the > udpates back to freefall ? If not, would there be a lot of work involved ? Nope. The possibility of someone else modifying the source is too great. There has to be a 'central' database, and that database is freefall. Nate From owner-freebsd-hackers Wed Jan 29 18:03:15 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA10266 for hackers-outgoing; Wed, 29 Jan 1997 18:03:15 -0800 (PST) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA10250 for ; Wed, 29 Jan 1997 18:03:11 -0800 (PST) Message-Id: <199701300203.SAA10250@freefall.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA021069778; Thu, 30 Jan 1997 13:02:58 +1100 From: Darren Reed Subject: Re: ipdivert & masqd To: cmott@srv.net (Charles Mott) Date: Thu, 30 Jan 1997 13:02:58 +1100 (EDT) Cc: hackers@freebsd.org In-Reply-To: from "Charles Mott" at Jan 29, 97 03:05:34 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In some mail from Charles Mott, sie said: > > > > That is curious. What does TIS FWTK/Gauntlet do? > > > > does a send/write call for "PORT " and another for the address/port > > info. > > > > Darren > > My syntax may have been a little unclear. It is just that I had never > heard of the TIS ... Gauntlet program. Is it just an FTP client, or > something more advanced? If source code is available, I think that some > may wish to update the code. Firewall product. The point is, it isn't Gauntlet or the Firewall Toolkit which is doing anything wrong, it is the "transparent proxy" which makes bad assumptions (although 99% of the time it gets away with them). Darren From owner-freebsd-hackers Wed Jan 29 18:13:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA10733 for hackers-outgoing; Wed, 29 Jan 1997 18:13:59 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id SAA10725 for ; Wed, 29 Jan 1997 18:13:54 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id SAA20752; Wed, 29 Jan 1997 18:54:44 -0700 From: Terry Lambert Message-Id: <199701300154.SAA20752@phaeton.artisoft.com> Subject: Re: 2.2-BETA Questions To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 29 Jan 1997 18:54:44 -0700 (MST) Cc: terry@lambert.org, jlemon@americantv.com, hackers@FreeBSD.ORG In-Reply-To: <11491.854587520@time.cdrom.com> from "Jordan K. Hubbard" at Jan 29, 97 05:25:20 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Make sure the IDE controller does not support LBA, get a bigger than > > 512M IDE drive anyway, and install the OnTrack 7.x stuff to load > > .. a whole bunch of similar instructions deleted .. > > Why do I get the feeling that Terry is enjoying this? Terry, you > sadist! :-) Because if you personally have to put up with the crap, you're going to gain a whole lot of sympathy for the poor schmucks who bought machines with the crap preinstalled, and now want to unistall a small amount of the crap (namely, whatever MS OS they are replacing with BSD). 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 Wed Jan 29 18:18:31 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA11057 for hackers-outgoing; Wed, 29 Jan 1997 18:18:31 -0800 (PST) Received: from smyrno.sol.net (smyrno.sol.net [206.55.64.117]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA11051 for ; Wed, 29 Jan 1997 18:18:24 -0800 (PST) Received: from solaria.sol.net (solaria.sol.net [206.55.65.75]) by smyrno.sol.net (8.8.3/8.8.3) with SMTP id UAA20887; Wed, 29 Jan 1997 20:17:34 -0600 (CST) Received: from localhost by solaria.sol.net (8.5/8.5) id TAA29530; Wed, 29 Jan 1997 19:56:56 -0600 From: Joe Greco Message-Id: <199701300156.TAA29530@solaria.sol.net> Subject: Re: Constructive criticism (was: bashing everyone for fun and profit) To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Wed, 29 Jan 97 19:56:55 CST Cc: mcgovern@spoon.beta.com, hackers@FreeBSD.ORG In-Reply-To: <199701300120.LAA24028@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Jan 30, 97 11:50:10 am X-Mailer: ELM [version 2.4dev PL65] MIME-Version: 1.0 Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > This is called the "learning curve". There are two ways to climb it, for > climb it you must if you want to do anything. > > 1) Spend lots of time trying, asking questions, exercising your intelligence > and patience. > 2) Give lots of money to someone else to have them force you through 1). 3) Spend lots of time trying and bludgeon your way mostly through it, then read the documentation (even if its out of date), and it will probably make a lot more sense. > It's in the handbook, in the section on ports. It looks like a cookbook > to me. Or perhaps you could look at a few other ones that might be > similar to yours - learn by example? That worked for me... I wanted a port for "tripwire" and I bludgeoned my way through, just fine. Mind you, I don't necessarily consider it unreasonable to climb a 150' "learning curve" by wearing my magnetic boots... I spent the better part of a day building a minimal FreeBSD floppy that could NFS mount /usr/X11R6 off of a read only NFS server and act as a diskless Xterminal. That was fun :-) > I hate to say it, but I think that the right line for you is "there > are a lot of us out here that like to whine about doing stuff because > it requires some effort, and we're socialised to expect everything > handed to us on a platter covered with disclaimers". Hmmm, I don't know if that's fair... but then again, maybe it is. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 From owner-freebsd-hackers Wed Jan 29 18:24:38 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA11266 for hackers-outgoing; Wed, 29 Jan 1997 18:24:38 -0800 (PST) Received: (from jmb@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA11235; Wed, 29 Jan 1997 18:22:05 -0800 (PST) From: "Jonathan M. Bresler" Message-Id: <199701300222.SAA11235@freefall.freebsd.org> Subject: Re: Worst Marketing Strategies To: cbt@mcia.com Date: Wed, 29 Jan 1997 18:22:05 -0800 (PST) Cc: webmaster@owlsnest.com, hackers In-Reply-To: <32EFCEFD.2849@mcia.com> from "CBTravenss" at Jan 29, 97 02:28:13 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The FreeBSD Project Inc. is in no way affliated with owlsnet.com. it seems that owlsnet.com uses FreeBSD to run their website www.owlsnet.com. The FreeBSD Project Inc, is not responsible for the actions of others that use FreeBSD, just as Scott Paper Company is not responsible for the actions of juveniles that use Scott Paper Company products to "paper" someone else's property. jmb -- Jonathan M. Bresler FreeBSD Postmaster jmb@FreeBSD.ORG FreeBSD--4.4BSD Unix for PC clones, source included. http://www.freebsd.org/ PGP 2.6.2 Fingerprint: 31 57 41 56 06 C1 40 13 C5 1C E3 E5 DC 62 0E FB CBTravenss wrote: > > Receiving unsolicited email from owlsnest.com was annoying enough but > stating that by replying and returning a copy of your email, I am > therein giving owlsnet.com personnel authorization > to do something and then bill me is totally outrageous. I'm contributing > to an article on Internet marketing techniques and will use your > technique as an example of the worst of them. > > Your affiliation with the FreeBSD organization (your one-page Web > presence: > www.owlsnest.com > offers only one link and the link is to the FreeBSD site), prompts me to > send copies of this message to them so that they can rethink their > affiliation with you, or if your organization and theirs is one and the > same, the marketing strategy you have devised can be more thoughtfully > planned. > > CBT > From owner-freebsd-hackers Wed Jan 29 18:28:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA11388 for hackers-outgoing; Wed, 29 Jan 1997 18:28:01 -0800 (PST) Received: from spooky.rwwa.com (rwwa.com [198.115.177.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA11365 for ; Wed, 29 Jan 1997 18:27:58 -0800 (PST) Received: from spooky.rwwa.com (localhost.rwwa.com [127.0.0.1]) by spooky.rwwa.com (8.7.5/8.7.3) with ESMTP id VAA00299 for ; Wed, 29 Jan 1997 21:27:50 -0500 (EST) Message-Id: <199701300227.VAA00299@spooky.rwwa.com> X-Mailer: exmh version 1.6.9 8/22/96 To: freebsd-hackers@freebsd.org Subject: biosboot config? Mime-Version: 1.0 Content-Type: text/plain Date: Wed, 29 Jan 1997 21:27:49 -0500 From: Robert Withrow Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Attempting to actually solve the ``I wanna automatically boot off my dang scsi drive even though I have two IDE drives in my stupid system'', I think I have a glimmer... I am able to boot my system with ``3:sd(0,a)/kernel'', which seems strange since I have only three drives and the 3: would seem to refer to the fourth drive, no? Any idea why this is? Is this because a ATAPI cdrom gets inserted in the table? Another mystery is this: Booteasy comes up on the first IDE drive (where I installed it), but F5 goes directly to the first SCSI drive. Why is that? Anyway, how's this: 1) I need to CD to /usr/src/sys/i386/boot/biosboot/ 2) I need to rebuild with BOOT_HD_BIAS=3 3) I need to install it onto the disk. HOWZATDONE? Any chance of this working? Will this automatically make ``3:sd(0,a)/kernel'' the default boot? ----------------------------------------------------------------------------- Robert Withrow, Tel: +1 617 592 8935, Net: witr@rwwa.COM From owner-freebsd-hackers Wed Jan 29 18:30:46 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA11551 for hackers-outgoing; Wed, 29 Jan 1997 18:30:46 -0800 (PST) Received: from darkstar (ras540.srv.net [205.180.127.40]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id SAA11546 for ; Wed, 29 Jan 1997 18:30:42 -0800 (PST) Received: (from cmott@localhost) by darkstar (8.6.12/8.6.12) id TAA01376; Wed, 29 Jan 1997 19:30:08 -0700 Date: Wed, 29 Jan 1997 19:30:06 -0700 (MST) From: Charles Mott X-Sender: cmott@darkstar To: Darren Reed cc: hackers@freebsd.org Subject: Re: ipdivert & masqd In-Reply-To: <9701300203.AA10014@snake.srv.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > My syntax may have been a little unclear. It is just that I had never > > heard of the TIS ... Gauntlet program. Is it just an FTP client, or > > something more advanced? If source code is available, I think that some > > may wish to update the code. > > Firewall product. > > The point is, it isn't Gauntlet or the Firewall Toolkit which is doing > anything wrong, it is the "transparent proxy" which makes bad assumptions > (although 99% of the time it gets away with them). > > Darren > I've seen quite a bit of feedback from several continents on the software I have written. In particular, any time I have made a mistake, I have been *very* quickly informed by users. I have yet to see any complaints from users about ftp handling. In any event, it would be unusual to have such a firewall behind the packet aliasing software I have written. It would be interesting to see whether the authors of the firewall product you mention were being deliberately "difficult". Standards are flexible. Most well-intentioned authors of free software want to see their products be as compatible as possible with outside solutions. Having software work with transparent proxies is something that many people are aware of. Of course, people writing commercial products often have very different motives. Your comments are interesting, but your attitude is not constructive in my view. Charles Mott From owner-freebsd-hackers Wed Jan 29 18:34:40 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA11679 for hackers-outgoing; Wed, 29 Jan 1997 18:34:40 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id SAA11674 for ; Wed, 29 Jan 1997 18:34:38 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id TAA20836; Wed, 29 Jan 1997 19:16:02 -0700 From: Terry Lambert Message-Id: <199701300216.TAA20836@phaeton.artisoft.com> Subject: Re: Source code commits To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 29 Jan 1997 19:16:01 -0700 (MST) Cc: brian@awfulhak.demon.co.uk, hackers@freebsd.org In-Reply-To: <11622.854588647@time.cdrom.com> from "Jordan K. Hubbard" at Jan 29, 97 05:44:07 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Is it possible to commit source code locally, and get cvsup to send the > > udpates back to freefall ? If not, would there be a lot of work involved ? > > This isn't cvsup's domain, actually, but it is something CVS can > handle itself. You simply set CVS_RSH to ``ssh' and CVSROOT to > ``freefall.freebsd.org:/home/ncvs'', then you do your CVS operations > as normal. > > I have some shell functions which I use so that I can keep things > checked out relative to my local CVS repository (and obviously many > times faster than using freefall's) up until the point where I want to > commit the changes, then it fools CVS into thinking that the sources > were originally checked out from freefall too: [ ... ] Not too useful to those of us who checkin to our local repository because we can't checkin to Freefall... It would be nice if I could: cvsup <-- tree without my tag cvs co src [ set local tag ] [ edit file locally ] [ check in under tag ] cvsup <-- tree without my tag [ edit file more locally ] cvsup <-- tree without my tag [ check in again under tag ] cvsup <-- tree without my tag [ create diff locally ] [ send diff to Julian (or whever has commit privs ] [ set new local tag ] cvsup <-- tree without my tag cvsup <-- tree without my tag [ edit file more locally ] cvsup <-- tree without my tag [ check in again under tag ] cvsup <-- tree without my tag [ Julian commits changes ] cvsup <-- tree without my tag, but with commits from "local tag" to to "new local tag" ] *** Here's the bugger: *** [ I merge local tag, so deltas after "new local tag" are applied relative to post-merge code ] cvsup <-- tree without my tag [ I repeat "send diff..." ] ... Right now, I have to wait for the checkin, and can do no new work until it has occurred (making it against my best interests to check in). Plus, I can't "rebranch" my local tag, or run several concurrent derivative branches (also making it a bad idea to send diffs). Plus you guys lose my edit history, which is what cuts the code up into small enough change domains for you guys to digest (ie: tag1, code, tag2, code, tag3, code, tag4, submit 1-2, submit 2-3, submit 3-4). 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 Wed Jan 29 18:43:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA12136 for hackers-outgoing; Wed, 29 Jan 1997 18:43:59 -0800 (PST) Received: from narcissus.ml.org (root@brosenga.Pitzer.edu [134.173.120.201]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA12131 for ; Wed, 29 Jan 1997 18:43:54 -0800 (PST) Received: (from ben@localhost) by narcissus.ml.org (8.7.5/8.7.3) id SAA06295; Wed, 29 Jan 1997 18:43:52 -0800 (PST) Date: Wed, 29 Jan 1997 18:43:52 -0800 (PST) From: Snob Art Genre To: "Jordan K. Hubbard" cc: Terry Lambert , jlemon@americantv.com, hackers@FreeBSD.ORG Subject: Re: 2.2-BETA Questions In-Reply-To: <11491.854587520@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 29 Jan 1997, Jordan K. Hubbard wrote: > > Make sure the IDE controller does not support LBA, get a bigger than > > 512M IDE drive anyway, and install the OnTrack 7.x stuff to load > > .. a whole bunch of similar instructions deleted .. > > Why do I get the feeling that Terry is enjoying this? Terry, you > sadist! :-) Everybody's enjoying this -- I forwarded a copy to a Linux-using friend of mine and even he enjoyed it. > > Jordan > Ben The views expressed above are not those of the Worker's Compensation Board of Queensland, Australia. From owner-freebsd-hackers Wed Jan 29 18:50:16 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA12515 for hackers-outgoing; Wed, 29 Jan 1997 18:50:16 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id SAA12509 for ; Wed, 29 Jan 1997 18:50:14 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id TAA20882; Wed, 29 Jan 1997 19:30:15 -0700 From: Terry Lambert Message-Id: <199701300230.TAA20882@phaeton.artisoft.com> Subject: Re: Constructive criticism (was: bashing everyone for fun and profit) To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Wed, 29 Jan 1997 19:30:15 -0700 (MST) Cc: mcgovern@spoon.beta.com, hackers@FreeBSD.ORG In-Reply-To: <199701300120.LAA24028@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Jan 30, 97 11:50:10 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I've been noticing, more an more, that FreeBSD has been/is being > > divided in to two camps. Basically, the "has", and the "has > > not". What I mean by this, is that there appears to be the core > > team, who kick butt making this stuff all work, then the people like > > me, who'd like to help out where they can, but seem to have an > > incredible time getting started. > > This is called the "learning curve". There are two ways to climb it, for > climb it you must if you want to do anything. [ ... ] How about flattening the curve, instead? It's not an inherent property. [ ... ] > If you can't work out how device drivers are integrated, I seriously > doubt that you're up to writing one in the first place. 8( This is wrong... I don't have to understand linker sets to be a good driver writer, but if I don't, how the driver gets integrated is a bit of FreeBSD-specific mystery, totally abstract from the concept of writing drivers themselves. [ ... wishful thinking on a document describing the existing DKI ... ] > I hate to say it, but I think that the right line for you is "there > are a lot of us out here that like to whine about doing stuff because > it requires some effort, and we're socialised to expect everything > handed to us on a platter covered with disclaimers". Or "we're interested in solving the problems themselves using a defined methodology, than in examining code to determine, each on our own, what a successful methodology might look like; if everyone has to reinvent the wheel, then no one will have time left to work on the wagon". Point of view, really... he did say he was willing to figuratively "reinvent the wheel and document it so other won't have to", only he had the problem with "reinventing how to document". Can't have a wheel until someone documents "how to make a circle"... 8-). Note: I betting that you realize that if you are arguing against documentation, you can't win. 8-) 8-). 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 Wed Jan 29 18:53:56 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA12783 for hackers-outgoing; Wed, 29 Jan 1997 18:53:56 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id SAA12768 for ; Wed, 29 Jan 1997 18:53:53 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id TAA20892; Wed, 29 Jan 1997 19:32:47 -0700 From: Terry Lambert Message-Id: <199701300232.TAA20892@phaeton.artisoft.com> Subject: Re: Constructive criticism (was: bashing everyone for fun and profit) To: jgreco@solaria.sol.net (Joe Greco) Date: Wed, 29 Jan 1997 19:32:47 -0700 (MST) Cc: msmith@atrad.adelaide.edu.au, mcgovern@spoon.beta.com, hackers@freebsd.org In-Reply-To: <199701300156.TAA29530@solaria.sol.net> from "Joe Greco" at Jan 29, 97 07:56:55 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Mind you, I don't necessarily consider it > unreasonable to climb a 150' "learning curve" by wearing my magnetic > boots... Which reminds me... how did Picard and Worf's magnetic boots stick to the Entrprise's Titanium hull? PS: Magnetic boots are only a help if your learning curve is ferromagnetic... 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 Wed Jan 29 19:01:50 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA13697 for hackers-outgoing; Wed, 29 Jan 1997 19:01:50 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA13682 for ; Wed, 29 Jan 1997 19:01:46 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id NAA25266; Thu, 30 Jan 1997 13:29:33 +1030 (CST) From: Michael Smith Message-Id: <199701300259.NAA25266@genesis.atrad.adelaide.edu.au> Subject: Re: Constructive criticism (was: bashing everyone for fun and profit) In-Reply-To: <199701300230.TAA20882@phaeton.artisoft.com> from Terry Lambert at "Jan 29, 97 07:30:15 pm" To: terry@lambert.org (Terry Lambert) Date: Thu, 30 Jan 1997 13:29:31 +1030 (CST) Cc: msmith@atrad.adelaide.edu.au, mcgovern@spoon.beta.com, 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-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Terry Lambert stands accused of saying: > > > > This is called the "learning curve". There are two ways to climb it, for > > climb it you must if you want to do anything. > > [ ... ] > > How about flattening the curve, instead? It's not an inherent property. Flattening the curve requires reducing the amount of knowledge required for a given task. Reducing the amount of knowledge required in the current context is not a simple or useful task in any other than the longest, most divorced-from-reality view. > > If you can't work out how device drivers are integrated, I seriously > > doubt that you're up to writing one in the first place. 8( > > This is wrong... I don't have to understand linker sets to be a good > driver writer, but if I don't, how the driver gets integrated is a > bit of FreeBSD-specific mystery, totally abstract from the concept > of writing drivers themselves. You're (deliberately?) misreading me. Try the alternative interpretation of what I said. > Note: I betting that you realize that if you are arguing against > documentation, you can't win. 8-) 8-). I'm arguing against someone saying "You're making it too hard" with the response "I'm no bloody genius, and if I can do it, you can too". This makes the generous assumption that the other party is as capable as I am, which is IMHO fairly realistic. > Terry Lambert -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Wed Jan 29 19:02:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA13757 for hackers-outgoing; Wed, 29 Jan 1997 19:02:09 -0800 (PST) Received: from spoon.beta.com (root@[199.165.180.33]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA13725 for ; Wed, 29 Jan 1997 19:01:59 -0800 (PST) Received: from spoon.beta.com (mcgovern@localhost [127.0.0.1]) by spoon.beta.com (8.8.4/8.6.9) with ESMTP id WAA09208; Wed, 29 Jan 1997 22:01:40 -0500 (EST) Message-Id: <199701300301.WAA09208@spoon.beta.com> To: msmith@atrad.adelaide.edu.au cc: hackers@freebsd.org Subject: Cases (was: Constructive Criticism) Date: Wed, 29 Jan 1997 22:01:40 -0500 From: "Brian J. McGovern" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> I've been noticing, more an more, that FreeBSD has been/is being >> divided in to two camps. Basically, the "has", and the "has >> not". What I mean by this, is that there appears to be the core >> team, who kick butt making this stuff all work, then the people like >> me, who'd like to help out where they can, but seem to have an >> incredible time getting started. > >This is called the "learning curve". There are two ways to climb it, for >climb it you must if you want to do anything. > >1) Spend lots of time trying, asking questions, exercising your intelligence > and patience. >2) Give lots of money to someone else to have them force you through 1). I disagree with your two cases. As with any development decision, if I can't justify the cost of undertaking the certain project, I won't even begin it. In the case of #1, its a time/learning curve that is out of reach. By the time I figure it out for release x.y.z, its usually changed. Even so, digesting x amount of data in reasonable size time chunks (I usually get 20 minutes a couple of time a day here or there to work on these types of projects, maybe totalling an hour or so a day). In your second case, the dollar cost would also be out of reach. > >The "have/have not" stance, in this case, is sour grapes because you >haven't made it up yet. There isn't some cabal trying to keep you >ignorant and frustrated - developers are desperately desired! > >Case 2) really only manifests when there are lots of people desperate >to climb and stupid enough to part with the sort of money involved, >which isn't the case with FreeBSD. > >> you can't beam armies up to your ship, but I digress... I'd like to >> submit it in to the "games" section of the ports. However, I notice >> this great little file structure that allows you to type "make >> install clean", and bam! the application is made, installed, and the >> working space is cleaned up. > >It's in the handbook, in the section on ports. It looks like a cookbook >to me. Or perhaps you could look at a few other ones that might be >similar to yours - learn by example? Ok, so one bad example ;p But, still, I've noted a good chunk of the technical docs in the handbook always seems to be a release out of date. Again, perhaps its something that can be undertaken. > >> The second major area of concern in my eyes is device >> drivers. Someone pointed me to a section of handbook that dealt with >> doing it (supposedly), but it was terribly out of date. Back to > >If you can't work out how device drivers are integrated, I seriously >doubt that you're up to writing one in the first place. 8( > Ah, again, a circle effect. You'll never get good till you've chewed on a handful of them. And you'll never start on your first till you think you can do it. A lack of documentation makes it infinately more difficult. Again, being under time limitations to "play" with this type of material in _ORDER_ to get good at it, it will take some spoon feeding. But, like my original message said, if I _am_ able to learn something useful, and return an equal amount, or more time on development than what you took to teach me, its a win all around. >However, I'll note that I've been helping people learning DD writing for >a while now (not that I'm any expert at it either), and I've never >seen your name attached to a question going past. How are you supposed >to learn if you never _ask_? > Thats easy. Its something I have a passing interest in undertaking. Unfortunately, my time to tinker with such things is limited. I've banged out some test code in the past (simple device reads, writes, etc), but don't have a weekend to figure out how to stick it in the kernel. And until I know I have a weekend to make a concerted effort, I won't bother anyone with the newbie question. Why ask the question if the answer would be useless? When the time comes, I'll ask. However, I'd also like to keep the number of questions I have to ask to a bare minimum. I'd rather have it be "I'm doing XYZPDQ, and it blows up in such and such a way. Can any one see any obvious problem", than "What do I do now?". It needs to be something I can digest in 20 minute chunks of time, over a long period of time. >> I guess what I'm getting at is this: There are a lot of us out here >> who would write man pages if we knew how to typeset them, those who >> would write neat utilities if we knew how to poll the information >> from the kernel (hell, I know about zillion people who'd love to >> know how to pull IO/up-down, config statistics from their Ethernet >> interfaces, for instance), those who would write drivers for widget >> X if they knew how to get them in to the kernel (there are a million >> books on writing drivers, but none that I know of that speak >> especially about FreeBSD)... > >I hate to say it, but I think that the right line for you is "there >are a lot of us out here that like to whine about doing stuff because >it requires some effort, and we're socialised to expect everything >handed to us on a platter covered with disclaimers". > >_prove_me_wrong_ : I (and plenty of others) are willing to help you >achieve your goals. It's why we're here. 0 I tend to disagree with this sentiment (the silver platter comment) , as well. I agree that a lot of people are like this. But, there are also different levels of interest, and different timeframes. I spend 8 hours plus a day writing code for Cisco. Coming home and spending four hours reviewing device drivers to figure out how to put one together is crazy. However, if there was sufficient documentation on the structures and routines that need to be called to get things set up, I can save the four hours and go straight to putting my effort in to writing the driver. I also realize that some of the kernel routines are being documented in the 3.0 code. I applaud the person (people) doing the work. Also, there are people that learn poorly from example. I'm one of them. That includes everything from programming to learning to fly helicopters (which I now do well, BTW). For me, example goes as far as "Thats neat". For me to grow beyond copying an example in the book, I really need to understand _why_ I'm doing what i'm doing. Reading someone else's chunk of code doesn't tell you WHY they implemented something a certain way... Good commenting would, but if all the code in the world had sufficient commenting, we wouldn't be having this discussion :) But, because I don't like arguing for the sake of arguing, here's a plan. Tomorrow, whilest I'm at work, I will write some code for a pseudo-device driver I wish to call foo. I will write routines for fooinit, fooread, and foowrite. According to the documentation I've read, I should be able to leave the open and close routines set to (I guess NULL ?) nothing. fooinit will also exist, but will just contain a printf to announce the presence of the pseudo-driver. The driver will be a character driver, with major number of 20. Minor number will represent buffer numbers, each buffer will be 1K in length. Writes to a buffer will set the string. Reads will return it (if the full length is specified). Optionally, I'll use the offset attributes to allow multiple reads and writes. Lastly, all of these routines will be in a file called foodev.c. Now, based on my reading, and what I've seen in some of the drivers I _have_ looked at, I believe that I'll have to set a cdevsw structure up, and it looks like a struct isa_driver. I also see probe() and attach() routines that I have not seen documentation on before in the books I have read. I see devfs support thrown in... Looks kinky. Probably will need help there eventually... Anyhow, want to lecture me on what some of these things are, whats required, whats optional, and how my stuff will fit in the cosmic scheme of things? And no, I don't randomly shoot my mouth off about how miserable something is unless I think its worth salvaging, and I'm willing to pitch in _where I can_. If I really just wanted to gripe, I'd keep my mouth shut... Saves on calories. -Brian From owner-freebsd-hackers Wed Jan 29 19:06:55 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA14099 for hackers-outgoing; Wed, 29 Jan 1997 19:06:55 -0800 (PST) Received: from vinyl.quickweb.com (vinyl.quickweb.com [206.222.77.8]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA14094 for ; Wed, 29 Jan 1997 19:06:52 -0800 (PST) Received: from localhost (mark@localhost) by vinyl.quickweb.com (8.7.5/8.6.12) with SMTP id WAA02410; Wed, 29 Jan 1997 22:05:29 -0500 (EST) Date: Wed, 29 Jan 1997 22:05:29 -0500 (EST) From: Mark Mayo To: Michael Smith cc: "Brian J. McGovern" , hackers@freebsd.org Subject: Re: Constructive criticism (was: bashing everyone for fun and profit) In-Reply-To: <199701300120.LAA24028@genesis.atrad.adelaide.edu.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 30 Jan 1997, Michael Smith wrote: > Brian J. McGovern stands accused of saying: > > > I've been noticing, more an more, that FreeBSD has been/is being > > divided in to two camps. Basically, the "has", and the "has [big SNIP] > > > The second major area of concern in my eyes is device > > drivers. Someone pointed me to a section of handbook that dealt with > > doing it (supposedly), but it was terribly out of date. Back to > > If you can't work out how device drivers are integrated, I seriously > doubt that you're up to writing one in the first place. 8( > > However, I'll note that I've been helping people learning DD writing for > a while now (not that I'm any expert at it either), and I've never > seen your name attached to a question going past. How are you supposed > to learn if you never _ask_? > I'm a beginning Unix programmer also, and when I looked at the device driver section of the handbook, it was very uncomplete. I understand, however, that writing device drivers in Unix is quite similar across most unix platforms.. Can you recomend a good book on device driver writing for Unix, that would minimize my headaches when I try to make mine work with FreeBSD? TIA. -Mark ---------------------------------------------------------------------------- Mark Mayo mark@quickweb.com RingZero Comp. http://vinyl.quickweb.com/mark ---------------------------------------------------------------------------- "I prefer tongue-tied knowledge to ignorant loquacity." Cicero (106-43 B.C.) > > -- > ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ > ]] Genesis Software genesis@gsoft.com.au [[ > ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ > ]] realtime instrument control. (ph) +61-8-8267-3493 [[ > ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ > From owner-freebsd-hackers Wed Jan 29 19:31:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA15662 for hackers-outgoing; Wed, 29 Jan 1997 19:31:51 -0800 (PST) Received: from smyrno.sol.net (smyrno.sol.net [206.55.64.117]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA15657 for ; Wed, 29 Jan 1997 19:31:43 -0800 (PST) Received: from solaria.sol.net (solaria.sol.net [206.55.65.75]) by smyrno.sol.net (8.8.3/8.8.3) with SMTP id VAA21382; Wed, 29 Jan 1997 21:31:31 -0600 (CST) Received: from localhost by solaria.sol.net (8.5/8.5) id VAA00309; Wed, 29 Jan 1997 21:10:53 -0600 From: Joe Greco Message-Id: <199701300310.VAA00309@solaria.sol.net> Subject: Re: Constructive criticism (was: bashing everyone for fun and profit) To: terry@lambert.org (Terry Lambert) Date: Wed, 29 Jan 97 21:10:50 CST Cc: msmith@atrad.adelaide.edu.au, mcgovern@spoon.beta.com, hackers@freebsd.org In-Reply-To: <199701300232.TAA20892@phaeton.artisoft.com> from "Terry Lambert" at Jan 29, 97 07:32:47 pm X-Mailer: ELM [version 2.4dev PL65] MIME-Version: 1.0 Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Mind you, I don't necessarily consider it > > unreasonable to climb a 150' "learning curve" by wearing my magnetic > > boots... > > Which reminds me... how did Picard and Worf's magnetic boots stick to > the Entrprise's Titanium hull? Maybe a side effect of the Structural Integrity Field? :-) When you're dumping boatloads of energy into the hull, after all... it doesn't seem to be hard to generate gravity, given energy. A minor amount of magnetism should be easier. The hull isn't just tritanium, incidentally, unless things simplified considerably since the time of the Enterprise-D. (ST:TNG Tech Manual, standard issue office literature, and there is no "titanium" at all in the Enterprise's hull, TYVM ;-) - but there are several layers of tritanium). > PS: Magnetic boots are only a help if your learning curve is > ferromagnetic... I make you a deal, Terry... you _show_ me a learning curve, and we will see if it is ferromagnetic. :-) Grin, ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 From owner-freebsd-hackers Wed Jan 29 19:34:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA15832 for hackers-outgoing; Wed, 29 Jan 1997 19:34:32 -0800 (PST) Received: from limbic.gc2.kloepfer.org (limbic.gc2.kloepfer.org [206.225.39.2]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA15826 for ; Wed, 29 Jan 1997 19:34:28 -0800 (PST) Received: (from gil@localhost) by limbic.gc2.kloepfer.org (8.8.5/8.8.5) id VAA07917 for freebsd-hackers@freebsd.org; Wed, 29 Jan 1997 21:34:26 -0600 (CST) Message-Id: <199701300334.VAA07917@limbic.gc2.kloepfer.org> Subject: Submitted UPS monitor software to PR system To: freebsd-hackers@freebsd.org Date: Wed, 29 Jan 1997 21:34:26 -0600 (CST) From: "Gil Kloepfer Jr." X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At Jordan's suggestion, I submitted my contribution (?) to the FreeBSD project of a Tripp Lite UPS monitor daemon to the PR system. The ID number is misc/2617 and contains a shar of the C code, Makefile, and manual page. This is really a first shot at a means of managing a UPS under FreeBSD (at least for me it is anyhow). I realize ideally it should be able to handle other UPS monitoring port specs, and be configurable as to its action. I'm more than willing to take on the responsibility for some of this. Unfortunately I don't have a lot of UPS monitoring port specs to work with. I developed this from scratch, even though I was aware of some linux work going on in this regard. It didn't appear from my reading that it did exactly what I wanted, and I didn't want to be discouraged from getting this done (I had a set of batteries melt along with frying my UPS not long ago). Basically I tested all the functions I could on the UPS itself, and created a simulator to test the those that would take too long (low battery). I can probably do the same for UPSs that use opto-isolators, relays, and LEDs for control...so to add new UPSs, I may be able to develop from the spec and have some nice soul test it. The shutdown mechanism is not as elegant as one may desire, but I felt that a "graceful" UPS shutdown was an alternative to pulling the plug while everything was running. Creating elaborate kernel code to perform this function may have been the literally "correct" way to do it, but it would have been highly hardware-dependent and horrible to maintain (as well as overkill under the circumstances). The cable involves some strange (ab)uses of the modem control signals and TxD from a serial port. It needs one resistor for pull-up wired between two pins. The cable is trivially made. Constructive feedback is welcome, of course. Hopefully this will be useful for someone. --- Gil Kloepfer gil@gc2.kloepfer.org http://www.gc2.kloepfer.org/ From owner-freebsd-hackers Wed Jan 29 19:53:33 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA16689 for hackers-outgoing; Wed, 29 Jan 1997 19:53:33 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA16684 for ; Wed, 29 Jan 1997 19:53:30 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id OAA26563; Thu, 30 Jan 1997 14:22:45 +1030 (CST) From: Michael Smith Message-Id: <199701300352.OAA26563@genesis.atrad.adelaide.edu.au> Subject: Re: Cases (was: Constructive Criticism) In-Reply-To: <199701300301.WAA09208@spoon.beta.com> from "Brian J. McGovern" at "Jan 29, 97 10:01:40 pm" To: mcgovern@spoon.beta.com (Brian J. McGovern) Date: Thu, 30 Jan 1997 14:22:44 +1030 (CST) Cc: msmith@atrad.adelaide.edu.au, 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Brian J. McGovern stands accused of saying: > > > >This is called the "learning curve". There are two ways to climb it, for > >climb it you must if you want to do anything. > > > >1) Spend lots of time trying, asking questions, exercising your intelligence > > and patience. > >2) Give lots of money to someone else to have them force you through 1). > > I disagree with your two cases. As with any development decision, if > I can't justify the cost of undertaking the certain project, I won't > even begin it. Do you read Dilbert? If it weren't for your other comments, I would have to say that you were trained management. You need to lift your eyes a little and look at the longer-term benefits of a given exercise. > In the case of #1, its a time/learning curve that is > out of reach. By the time I figure it out for release x.y.z, its > usually changed. You're joking, right? The driver integration model has changed _once_ in something like ten years, and that change is simple, straightforward, and if you asked could be explained in less than a screenfull of words. > Ok, so one bad example ;p But, still, I've noted a good chunk of the > technical docs in the handbook always seems to be a release out of > date. Again, perhaps its something that can be undertaken. Writing documentation is lots of work. Tina and her ilk are a rare resource. > >If you can't work out how device drivers are integrated, I seriously > >doubt that you're up to writing one in the first place. 8( > > > > Ah, again, a circle effect. You'll never get good till you've chewed on a > handful of them. Correct. > And you'll never start on your first till you think you > can do it. *This* is your failing point, and it is annoyingly common. Given "you can never know until you try", your attitude means that you will _never_learn_ because without an ironclad guarantee of success, you'll never make the effort. An attitude like that is a guarantee of failure. > A lack of documentation makes it infinately more difficult. I would assert that the mailing lists are a form of interactive documentation that transcends anything that can be statically committed to any media. > But, like my original > message said, if I _am_ able to learn something useful, and return an equal > amount, or more time on development than what you took to teach me, its a > win all around. Your offerings would be gratefully accepted, believe you me 8) > Unfortunately, my time to tinker with such things is limited. I've > banged out some test code in the past (simple device reads, writes, > etc), but don't have a weekend to figure out how to stick it in the > kernel. And until I know I have a weekend to make a concerted > effort, I won't bother anyone with the newbie question. Why ask the > question if the answer would be useless? How can you make an assessment like that when you claim ignorance? Perhaps integrating your driver is a 5-minute task? Will you let your timidity hold you back? > When the time comes, I'll ask. However, I'd also like to keep the > number of questions I have to ask to a bare minimum. I'd rather have > it be "I'm doing XYZPDQ, and it blows up in such and such a way. Can > any one see any obvious problem", than "What do I do now?". I think "I have some device driver routines, how do I glue them together so that the kernel can use them" is a pretty straightforward question. I could (and would happily) answer that in a fashion that you should be able to do something with directly. > For me to grow beyond copying an example in the book, I really need > to understand _why_ I'm doing what i'm doing. Why not ask them then? The authors of the code you're fretting about (or at the very least people that understand it) are all around, and most are easily approachable. > Reading someone else's chunk of code doesn't tell you WHY they > implemented something a certain way... Good commenting would, but if > all the code in the world had sufficient commenting, we wouldn't be > having this discussion :) Reading the code in its larger context will often make obvious why something was implemented in a particular fashion. Often "expediency" is the only succinct answer 8) > Tomorrow, whilest I'm at work, I will write some code for a pseudo-device > driver I wish to call foo. I will write routines for fooinit, fooread, > and foowrite. According to the documentation I've read, I should be able to > leave the open and close routines set to (I guess NULL ?) nothing. fooinit > will also exist, but will just contain a printf to announce the presence of > the pseudo-driver. The driver will be a character driver, with major number > of 20. Minor number will represent buffer numbers, each buffer will be 1K > in length. Writes to a buffer will set the string. Reads will return it (if > the full length is specified). Optionally, I'll use the offset attributes > to allow multiple reads and writes. Lastly, all of these routines will > be in a file called foodev.c. Ok, sounds like a plan. > Now, based on my reading, and what I've seen in some of the drivers > I _have_ looked at, I believe that I'll have to set a cdevsw structure up, > and it looks like a struct isa_driver. I also see probe() and attach() > routines that I have not seen documentation on before in the books I have > read. I see devfs support thrown in... Looks kinky. Probably will need help > there eventually... Ok. > Anyhow, want to lecture me on what some of these things are, whats required, > whats optional, and how my stuff will fit in the cosmic scheme of things? Sure; I'll keep it cc'd to -hackers so that others can snipe at my ignorance, and if you save all of these messages, you should have an excellent reference on which to base your documentation. I'll restrict myself to ISA drivers, as these are where I'm most familiar. PCI drivers are generally similar, but have an easier time in some regards. I'll use your 'foo' driver as an example. ==== Driver initialisation is seperated into two parts, known as 'probe' and 'attach'. The purpose of the 'probe' routine is to ascertain whether the hardware is present, and optionally determine its configuration. Probe/attach for ISA device drivers is triggered by the presence of a non-static isa_driver structure in the driver; at least the first three fields should be initialised, with the probe and attach routines and the name of the driver : struct isa_driver foodriver = { fooprobe, fooattach, "foo"}; The 'fooprobe' function is called during startup to determine whether the device is present or not. It should return zero if the probe for the hardware failed, or the size of the I/O space occupied by the device if the probe succeeded. static int fooprobe(struct isa_device *dev) It is legitimate to alter the contents of the fields in the isa_device structure, if new values are determined by probing for the hardware. Note that the id_irq field is a bitmask, not a numeric value. The probe routine should not emit any text unless it comes up against something particularly alarming. The probe routine is called once per instance of the driver in the configuration file. Attach is called, again once per instance of the driver in the config, when the device has been successfully probed and does not conflict. static int fooattach(struct isa_device *dev) The attach routine should build any local data structures required for management of the device. It is traditional for the attach routine to emit a line like : foo0: Snarklewacker 200, rotating Floib, no BoBoBoBoB. The startup code will have already emitted a line like : foo0 at 0x10-20 irq 1 iomem 0x12345 on isa Once internal state for the driver has been established, you add an entry to the device switch for the driver. In the case of a character device, the following fragment is normally used : dev = makedev(CDEV_MAJOR,0); cdevsw_add(&dev,&foo_cdevsw,NULL); Where CDEV_MAJOR is the major device number assigned to the driver (normally #defined somewhere obvious). A typical cdevsw initialisation might look like : static d_open_t fooopen; static d_close_t fooclose; static d_read_t fooread; static d_write_t foowrite; static d_ioctl_t fooioctl; static d_select_t fooselect; #define CDEV_MAJOR 20 static struct cdevsw foo_cdevsw = { fooopen, fooclose, fooread, foowrite, fooioctl, nullstop, nullreset, nodevtotty, fooselect, nommap, NULL, driver_name, NULL, -1 }; Note that some of the placeholders are "no*" and some are "null*" - I think that this is laziness on someone's part 8( To create a devfs device node : sc->devfs_token = devfs_add_devsw(&foo_cdevsw, unit, DEV_CHR, UID_ROOT, GID_WHEEL, 0660, "foo%d", unit); This returns a token which is saved (here) in the devfs_token field in the device's softc structure (the per-device state structure). The cdevsw structure defines the driver's entrypoints, unit is the unit number associated with the device node (you can encode major/minor data here if you wish), DEV_CHR indicates a character device node, the UID_ROOT, GID_WHEEL and 0660 entries set the ownership/permissions on the new device node, and the remaining arguments are printf-style, with a format string and parameters for the format string which yield the name of the device node. You can call this several times to create multiple nodes for a single instance of the driver. ==== That should get you probing and attached; keep us in touch! > -Brian -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Wed Jan 29 19:54:38 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA16765 for hackers-outgoing; Wed, 29 Jan 1997 19:54:38 -0800 (PST) Received: from smyrno.sol.net (smyrno.sol.net [206.55.64.117]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA16759 for ; Wed, 29 Jan 1997 19:54:35 -0800 (PST) Received: from solaria.sol.net (solaria.sol.net [206.55.65.75]) by smyrno.sol.net (8.8.3/8.8.3) with SMTP id VAA21433; Wed, 29 Jan 1997 21:54:27 -0600 (CST) Received: from localhost by solaria.sol.net (8.5/8.5) id VAA00595; Wed, 29 Jan 1997 21:33:48 -0600 From: Joe Greco Message-Id: <199701300333.VAA00595@solaria.sol.net> Subject: Re: Network interfaces: removal of. To: louie@TransSys.COM (Louis A. Mamakos) Date: Wed, 29 Jan 97 21:33:45 CST Cc: julian@whistle.com, hackers@freebsd.org In-Reply-To: <199701280402.XAA03991@whizzo.transsys.com> from "Louis A. Mamakos" at Jan 27, 97 11:02:20 pm X-Mailer: ELM [version 2.4dev PL65] MIME-Version: 1.0 Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > does anyone have any ideas on this? > > One idea: add a new message for the routing socket which can notify > routing daemons that you want to delete an interface (or, like it or not, > it's gone now). Hopefully they can then arrange to have active references > to the interface be removed. > > I recall another system which had a the ability to "delete" a network > interface. What it really did was cheat: it essentially overwrote the > interface name, and shoved the data structure off into a corner. It was > still around, though, so that if there was some errant reference to it, > nothing "bad" would happen. > > Clearly, this is just a hack. However, it seems to work "well enough", > so from a pragmatic perspective, you can't dismiss it completely. > > While I'm sure that the modules that reference interfaces are finite, > there's nothing to allocate references to them. This would require a > level of discipline unknown to the BSD net code. Hell, you might just > as well wish for locks on the data structures to make the code SMP safe :-) It's (definitely!) not BSD, but Solaris has some support for this. Their interfaces are done on the fly.. # ifconfig le1 ifconfig: SIOCGIFFLAGS: le1: no such interface # ifconfig le1 plumb # ifconfig le1 10.1.1.1 # ifconfig le1 le1: flags=842 mtu 1500 inet 10.1.1.1 netmask ff000000 broadcast 10.255.255.255 ether 8:0:20:1a:f5:1e # ifconfig le1 up # route add net 192.168.0.0 10.1.2.3 1 add net 192.168.0.0: gateway 10.1.2.3 # ifconfig le1 le1: flags=843 mtu 1500 inet 10.1.1.1 netmask ff000000 broadcast 10.255.255.255 ether 8:0:20:1a:f5:1e # netstat -rn|grep 192.168 192.168.0.0 10.1.2.3 UG 0 0 # ifconfig le1 down # netstat -rn|grep 192.168 192.168.0.0 10.1.2.3 UG 0 0 # ifconfig le1 unplumb # ifconfig le1 ifconfig: SIOCGIFFLAGS: le1: no such interface # netstat -rn|grep 192.168 192.168.0.0 10.1.2.3 UG 0 0 # Not ideal... but something. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 From owner-freebsd-hackers Wed Jan 29 20:00:11 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA17107 for hackers-outgoing; Wed, 29 Jan 1997 20:00:11 -0800 (PST) Received: from weenix.guru.org (unix.guru.org [198.82.200.65]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA17057 for ; Wed, 29 Jan 1997 20:00:06 -0800 (PST) Received: (from kmitch@localhost) by weenix.guru.org (8.8.4/8.8.4) id WAA25499 for hackers@freebsd.org; Wed, 29 Jan 1997 22:59:33 -0500 (EST) Date: Wed, 29 Jan 1997 22:59:33 -0500 (EST) From: Keith Mitchell Message-Id: <199701300359.WAA25499@weenix.guru.org> To: hackers@freebsd.org Subject: Re: lpd - remote printing with an output filter X-Newsreader: TIN [UNIX 1.3 unoff BETA release 970124] Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Has anyone got any problems with me making this work ? It's always > irritated me ! It consists of two one-liners to printjob.c. No, but I would like to see it happen. I have several printers hanging off a HP JetDirect EX print server and there is no way to run an output filter on them. Consequently, the user must KNOW not to just blindly print to it. (sigh). From owner-freebsd-hackers Wed Jan 29 20:13:26 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA17724 for hackers-outgoing; Wed, 29 Jan 1997 20:13:26 -0800 (PST) Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id UAA17718 for ; Wed, 29 Jan 1997 20:13:23 -0800 (PST) Received: from spoon.beta.com ([199.165.180.33]) by mail.crl.com with SMTP id AA21297 (5.65c/IDA-1.5 for ); Wed, 29 Jan 1997 20:12:50 -0800 Received: from spoon.beta.com (mcgovern@localhost [127.0.0.1]) by spoon.beta.com (8.8.4/8.6.9) with ESMTP id XAA09417; Wed, 29 Jan 1997 23:08:34 -0500 (EST) Message-Id: <199701300408.XAA09417@spoon.beta.com> To: Mark Mayo Cc: Michael Smith , "Brian J. McGovern" , hackers@freebsd.org, mcgovern@spoon.beta.com Subject: Re: Constructive criticism (was: bashing everyone for fun and profit) In-Reply-To: Your message of "Wed, 29 Jan 1997 22:05:29 EST." Date: Wed, 29 Jan 1997 23:08:33 -0500 From: "Brian J. McGovern" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Mark, I've seen at LEAST two titles called "Writing a Unix device driver". One is good, as it tends to take things piece by piece, rather than dumping the whole picture on you. The other was cryptic, and just difficult to read. IF you'd like I'd beam you the author's name of the one I particularly liked. Unfortunately, I've yet to find a good one that really has to do with 4.4ish stuff. Most deal with SCO. But... -Brian From owner-freebsd-hackers Wed Jan 29 21:06:16 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA19846 for hackers-outgoing; Wed, 29 Jan 1997 21:06:16 -0800 (PST) Received: from spoon.beta.com (root@[199.165.180.33]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA19832 for ; Wed, 29 Jan 1997 21:06:08 -0800 (PST) Received: from spoon.beta.com (mcgovern@localhost [127.0.0.1]) by spoon.beta.com (8.8.4/8.6.9) with ESMTP id AAA09649; Thu, 30 Jan 1997 00:05:43 -0500 (EST) Message-Id: <199701300505.AAA09649@spoon.beta.com> To: msmith@atrad.adelaide.edu.au cc: hackers@freebsd.org Subject: The continuting email... Date: Thu, 30 Jan 1997 00:05:43 -0500 From: "Brian J. McGovern" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Do you read Dilbert? If it weren't for your other comments, I would have >to say that you were trained management. You need to lift your eyes a >little and look at the longer-term benefits of a given exercise. There are long term benefits, and there are short term realities. The long term benefits is that I may get good at this. The short term reality is that I have a certain length of time to aquire the information to do this. If the time required is excessive, or unrealistic, it makes a better choice to either hire someone to do it, or wait for someone else to do it, and put my energies where not only will I have efficiency, but I'll have success. Perhaps it is being "trained management", but you'll notice that the number of learned people working with FreeBSD that could develop a userful driver is nearly nil compared to the number of people running FreeBSD. Why is that? They all put their resources where it will gain them the most. Many people, like myself, have limited time, and a lot to do. >> Ok, so one bad example ;p But, still, I've noted a good chunk of the >> technical docs in the handbook always seems to be a release out of >> date. Again, perhaps its something that can be undertaken. >Writing documentation is lots of work. Tina and her ilk are a rare >resource. I'd be more than happy to hammer out documentation. I do it quite frequently. However, doing documentation requires a.) Coordination with the group as a whole, b.) A _serious_ understanding of what you're writing about (unless you opt to sound like you're clueless, or be wrong, etc), and c.) understanding of the mechanism to write the documentation. Right now, I would say that I fail in all cases. a.) is covered by the fact I don't deal with the developers regularly. I should, and I try, but it doesn't happen. b.) This is optional, based on what I'd try to document. Workings of a service, like tftpd? Sure, no problem. Give me two hours on a Saturday... Working of a device driver interface? Yeah, right... Give me a year. c.) Some one was nice enough to point out the appropriate man pages for writing man pages. Given a weekend of tinkering with it, I'm sure I could figure it out. But, theres 8-10 hours right there. Is documentation what I'd be _most_ useful at? >> And you'll never start on your first till you think you >> can do it. >*This* is your failing point, and it is annoyingly common. Given "you can >never know until you try", your attitude means that you will _never_learn_ >because without an ironclad guarantee of success, you'll never make the >effort. An attitude like that is a guarantee of failure. It depends on your definition of ironclad guarantee of success. When I start any project at work, I have a fairly good idea of what I'm going to do, and how to get there. So long as I maintain at least one path to reach my goal, I will continue to plug away at it. If I don't have one, and a reasonable amount of investigation doesn't give me a new path. The project goes on "hold" indefinately until I can find a new path to pursue. Also, in lieu of another comment earlier that I wanted to drop over the sake of arguement (but it applies here, so I'll bring it back up), I did once (about 2 weeks ago) post about getting my ficticious 'foo' driver installed in the kernel to the hackers list. I got one (1) reply from someone with a handbook section to check out. I downloaded it, printed it, and followed the steps. Didn't work. Queried hackers as to why it didn't work. I think it was Jordan who replied that the section in question (excuse my fuzziness on the _exact_ answer, but its been awhile, and I didn't pay much attention beyond the basic meaning of the message) was for FreeBSD versions through 2.1.5 or 2.1.6. As I was running 2.2-BETA on all my machines (trying, in my minimalist way to find any bugs for the pending release - of which I've submitted 3-4 minor ones to date [so I don't bang on the machines as hard as some..]), the handbook section became useless. As no one else answered that and future messages on the subject, and the docs were out of date, I no longer had a path. Hence, it went on hold till I saw enough people mentioning the things I saw, and I summarized it in an opinion message.... >> A lack of documentation makes it infinately more difficult. >I would assert that the mailing lists are a form of interactive >documentation that transcends anything that can be statically >committed to any media. As per the message above, it doesn't always work. Timing becomes critical. People become critical. If your timing is off (someone takes a day off, or mail is lost, etc), or the one person who has a good answer isn't available, it doesn't work. However, if that person was to do a brain-dump on to a white paper. Not even documentation per say, but their thoughts on the hows, whys, and wheres, it would at least provide a static source for some place to start. >> But, like my original >> message said, if I _am_ able to learn something useful, and return an equal >> amount, or more time on development than what you took to teach me, its a >> win all around. >Your offerings would be gratefully accepted, believe you me 8) As I would like to offer. Again, I really don't want to argue with anyone. My merest dialog (originally) was to stress that static, written, up to date documentation would allow people (such as myself) to learn these things at their own pace, in their own time. Then, once their ready, their newly found skill sets would be available to assist the development goals. However, I see it taking an initial capital of properly trained people to provide static documentation for this purpose. >> Unfortunately, my time to tinker with such things is limited. I've >> banged out some test code in the past (simple device reads, writes, >> etc), but don't have a weekend to figure out how to stick it in the >> kernel. And until I know I have a weekend to make a concerted >> effort, I won't bother anyone with the newbie question. Why ask the >> question if the answer would be useless? >How can you make an assessment like that when you claim ignorance? >Perhaps integrating your driver is a 5-minute task? Will you let your >timidity hold you back? Because I have already sunk over a week (80 hours) in to just reading up on how to properly write a driver. I have looked at other drivers, and I can usually anticipate my learning curve. If it were a five minute task, please, surprise me. However, I think 10 hours over a weekend that I can dedicate to it would really be a more realistic number. I'll probably need more in the long run. And no, its not timidity thats holding me back. Its my desire to bring completion to the things I start. I despise not finishing things on schedule (management again?) >> When the time comes, I'll ask. However, I'd also like to keep the >> number of questions I have to ask to a bare minimum. I'd rather have >> it be "I'm doing XYZPDQ, and it blows up in such and such a way. Can >> any one see any obvious problem", than "What do I do now?". >I think "I have some device driver routines, how do I glue them together >so that the kernel can use them" is a pretty straightforward question. >I could (and would happily) answer that in a fashion that you should be >able to do something with directly. But, you're also making two assumptions. One, that I am in fact ready, and two, that I would like the answer. That was not the point of my original posting. The point of my original posting was that via good docs, a.) The question would (should?) never have to be asked in the first place (siting driver writing as an example), b.) the system, overall, would be better documented, and c.) It provides 'newbies' with a unified set of documentation for how to go about a task, so that the learning curve will be as greatly reduced as possible (read: dump the tinkering and show me how to do something useful). >> For me to grow beyond copying an example in the book, I really need >> to understand _why_ I'm doing what i'm doing. >Why not ask them then? The authors of the code you're fretting about >(or at the very least people that understand it) are all around, and most >are easily approachable. I don't disagree with this. However, it comes back to time, timing, effort, and energy. Time, as in I only have limited time, and if I spend the time I have trying to find the right person to talk to, wait for replies, etc, the time I have to actually WORK on something is gone, and we all have to wait till the next cycle (which, by then, would cause me to forget the answer anyways :) ). Timing, as in if the "right" person isn't available, whether you even get an answer becomes shaky at best. Effort, as in which is easier? Asking all the right questions, or reading up to get a base understanding, and THEN asking about what you don't get. Energy, as in see "Time". Also, I oft feel (as others do), that if I were high guru on a mountain, and someone came to me and asked "How do I program in C?", the answer would not be a 30 hour class. It would be "Why not get a book on it". Likewise, a simple question stands a far better chance of being answered (correctly), than a "I don't have a clue, save me" question. That is the type of question that people who expect answers on silver platters will ask. It is the type of question that, personally, I don't think should ever need to be asked _provided there is an alternate source for the information_. >> Reading someone else's chunk of code doesn't tell you WHY they >> implemented something a certain way... Good commenting would, but if >> all the code in the world had sufficient commenting, we wouldn't be > having this discussion :) >Reading the code in its larger context will often make obvious why something >was implemented in a particular fashion. Often "expediency" is the only >succinct answer 8) See "time" (above) >> Tomorrow, whilest I'm at work, I will write some code for a pseudo-device >> driver I wish to call foo. I will write routines for fooinit, fooread, >> and foowrite. According to the documentation I've read, I should be able to >> leave the open and close routines set to (I guess NULL ?) nothing. fooinit >> will also exist, but will just contain a printf to announce the presence of >> the pseudo-driver. The driver will be a character driver, with major number >> of 20. Minor number will represent buffer numbers, each buffer will be 1K >> in length. Writes to a buffer will set the string. Reads will return it (if >> the full length is specified). Optionally, I'll use the offset attributes >> to allow multiple reads and writes. Lastly, all of these routines will >> be in a file called foodev.c. >Ok, sounds like a plan. >> Now, based on my reading, and what I've seen in some of the drivers >> I _have_ looked at, I believe that I'll have to set a cdevsw structure up, >> and it looks like a struct isa_driver. I also see probe() and attach() >> routines that I have not seen documentation on before in the books I have >> read. I see devfs support thrown in... Looks kinky. Probably will need help >> there eventually... >Ok. >> Anyhow, want to lecture me on what some of these things are, whats required, >> whats optional, and how my stuff will fit in the cosmic scheme of things? >Sure; I'll keep it cc'd to -hackers so that others can snipe at my ignorance, >and if you save all of these messages, you should have an excellent reference >on which to base your documentation. >I'll restrict myself to ISA drivers, as these are where I'm most familiar. >PCI drivers are generally similar, but have an easier time in some >regards. >I'll use your 'foo' driver as an example. ==== >Driver initialisation is seperated into two parts, known as 'probe' and >'attach'. The purpose of the 'probe' routine is to ascertain whether >the hardware is present, and optionally determine its configuration. >Probe/attach for ISA device drivers is triggered by the presence of a >non-static isa_driver structure in the driver; at least the first three >fields should be initialised, with the probe and attach routines and the >name of the driver : Ok. I know the what. Any particular reason it has to be non-static? I assume to cause it to blow up if there is another driver with the same name, but, am I correct? Secondly, what are the fields after the first 3? Also, I did a grep for "isa_driver" in /usr/include via a find (ie - grep "isa_driver" `find .` to no avail. Which header should I include? (BTW: I noted to jordan that the ssys.* set in -BETA had trailing garbage at the end. I don't know if it means the set is corrupt and I'm missing something) >struct isa_driver foodriver = { fooprobe, fooattach, "foo"}; >The 'fooprobe' function is called during startup to determine whether >the device is present or not. It should return zero if the probe >for the hardware failed, or the size of the I/O space occupied by >the device if the probe succeeded. Please define "size of the I/O space". To me, this can mean many things, probably all of which are wrong. Is it the number of ports a device uses? Amount of memory (shared or otherwise)? And how about our simulated pseudo device, which won't control hardware, but might have a few K in buffers? >static int >fooprobe(struct isa_device *dev) >It is legitimate to alter the contents of the fields in the isa_device >structure, if new values are determined by probing for the hardware. >Note that the id_irq field is a bitmask, not a numeric value. The >probe routine should not emit any text unless it comes up against >something particularly alarming. Ok. id_irq is a bitmask. I'll have to save my other questions once I can find struct isa_device. I am currently assuming that this contains the info in the kernel config file when called. Same for a pseudo-device? > >The probe routine is called once per instance of the driver in the >configuration file. > >Attach is called, again once per instance of the driver in the config, >when the device has been successfully probed and does not conflict. Does the driver make the call as to the conflict? Or does the system look at the struct isa_device, and if a conflict occurs, not call the probe and attach routines? > >static int >fooattach(struct isa_device *dev) > >The attach routine should build any local data structures required for >management of the device. It is traditional for the attach routine to >emit a line like : > >foo0: Snarklewacker 200, rotating Floib, no BoBoBoBoB. > >The startup code will have already emitted a line like : > >foo0 at 0x10-20 irq 1 iomem 0x12345 on isa > Ok. This smells like the init routines I'm used to seeing. >Once internal state for the driver has been established, you add an entry >to the device switch for the driver. In the case of a character device, >the following fragment is normally used : > > dev = makedev(CDEV_MAJOR,0); > cdevsw_add(&dev,&foo_cdevsw,NULL); > Ok. Looks clear enough. I'm assuming we're still in attach here... I'm also assuming that block devices would call bdevsw_add (wrong name i think, but I think I get the idea). How about STREAMS types or tty type devices that are linked off through a line protocol? Once I'm done with driver foo, I'd like to start work on an ISA multi-modem card thats being prepped by Cisco for inclusion in to their routers (the modem modules, not the ISA cards). I'll need to run SLIP and PPP across the link. the _documentation I have_ says I'll have to make it a little more special than a "normal" character device... >Where CDEV_MAJOR is the major device number assigned to the driver >(normally #defined somewhere obvious). > >A typical cdevsw initialisation might look like : > >static d_open_t fooopen; >static d_close_t fooclose; >static d_read_t fooread; >static d_write_t foowrite; >static d_ioctl_t fooioctl; >static d_select_t fooselect; > >#define CDEV_MAJOR 20 >static struct cdevsw foo_cdevsw = >{ > fooopen, fooclose, fooread, foowrite, > fooioctl, nullstop, nullreset, nodevtotty, > fooselect, nommap, NULL, driver_name, > NULL, -1 >}; > Ok. Some of it makes sense. Is there a blank generic one that gives the appropriate order? For instance, I see nullstop and nullreset. There should also be a poll routine in there some where? Is it a NULL? a no? a -1? >Note that some of the placeholders are "no*" and some are "null*" - I >think that this is laziness on someone's part 8( Again, see the note above. Docs on what they "should be" could help fix this :) > >To create a devfs device node : > > sc->devfs_token = devfs_add_devsw(&foo_cdevsw, unit, > DEV_CHR, UID_ROOT, GID_WHEEL, > 0660, "foo%d", unit); > >This returns a token which is saved (here) in the devfs_token field in >the device's softc structure (the per-device state structure). The >cdevsw structure defines the driver's entrypoints, unit is the unit >number associated with the device node (you can encode major/minor >data here if you wish), DEV_CHR indicates a character device node, the >UID_ROOT, GID_WHEEL and 0660 entries set the ownership/permissions on >the new device node, and the remaining arguments are printf-style, >with a format string and parameters for the format string which yield >the name of the device node. > Ok. Is creating a devfs node mandatory? I know people would like to move to it, but when/is it required? What makes the decision if it is optional? >You can call this several times to create multiple nodes for a single >instance of the driver. Ok. I assume this means that it'll generate the same major numbers with appropriate minor numbers? > > > ==== > >That should get you probing and attached; keep us in touch! > >> -Brian > I appreciate the help to date. Again, my goal is not to argue, but to assist. Can't assist without knowledge, can't gain knowledge without documentation (I despise cultural learning. Too much pure data gets damaged in the retelling...) >- -- >]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ >]] Genesis Software genesis@gsoft.com.au [[ >]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ >]] realtime instrument control. (ph) +61-8-8267-3493 [[ >]] Unix hardware collector. "Where are your PEZ?" The Tick [[ > >------- End of Forwarded Message > > From owner-freebsd-hackers Wed Jan 29 21:17:36 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA20228 for hackers-outgoing; Wed, 29 Jan 1997 21:17:36 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA20223 for ; Wed, 29 Jan 1997 21:17:33 -0800 (PST) Received: (from jdp@localhost) by austin.polstra.com (8.8.5/8.8.5) id VAA01442; Wed, 29 Jan 1997 21:17:32 -0800 (PST) To: freebsd-hackers@freebsd.org Path: not-for-mail From: jdp@polstra.com (John Polstra) Newsgroups: polstra.freebsd.hackers Subject: Re: Source code commits Date: 29 Jan 1997 21:17:31 -0800 Organization: Polstra & Co., Seattle, WA Lines: 8 Distribution: local Message-ID: <5cpatb$1cv@austin.polstra.com> References: <199701300043.AAA15572@awfulhak.demon.co.uk> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Is it possible to commit source code locally, and get cvsup to send the > udpates back to freefall ? If not, would there be a lot of work involved ? No and yes, respectively. :-) -- 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 Wed Jan 29 21:24:53 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA20518 for hackers-outgoing; Wed, 29 Jan 1997 21:24:53 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA20513 for ; Wed, 29 Jan 1997 21:24:49 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id PAA27382; Thu, 30 Jan 1997 15:54:35 +1030 (CST) From: Michael Smith Message-Id: <199701300524.PAA27382@genesis.atrad.adelaide.edu.au> Subject: Re: The continuting email... In-Reply-To: <199701300505.AAA09649@spoon.beta.com> from "Brian J. McGovern" at "Jan 30, 97 00:05:43 am" To: mcgovern@spoon.beta.com (Brian J. McGovern) Date: Thu, 30 Jan 1997 15:54:34 +1030 (CST) Cc: msmith@atrad.adelaide.edu.au, 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk (I'm splitting the thread here. This half really needs to die, the other half should survive) Brian J. McGovern stands accused of saying: > > where not only will I have efficiency, but I'll have > success. Perhaps it is being "trained management", but you'll notice > that the number of learned people working with FreeBSD that could > develop a userful driver is nearly nil compared to the number of > people running FreeBSD. Why is that? They all put their resources > where it will gain them the most. Many people, like myself, have > limited time, and a lot to do. I beg to differ on your demographic, but I take your point. > Also, in lieu of another comment earlier that I wanted to drop over > the sake of arguement (but it applies here, so I'll bring it back > up), I did once (about 2 weeks ago) post about getting my ficticious > 'foo' driver installed in the kernel to the hackers list. MHA; I honestly do not recall this, sorry. 8( > available to assist the development goals. However, I see it taking > an initial capital of properly trained people to provide static > documentation for this purpose. Ok; so I prod you to start doing, which will result in you asking questions, and causing people on this list to start producing the information that you require. Hopefully the net result is worthwhile. > bring completion to the things I start. I despise not finishing things on > schedule (management again?) Yes, but Ray Dolby would sympathise 8) (And I envy you; I'm a chronic non-finisher in my personal projects, as I always take on too much at once 8( ) > I appreciate the help to date. Again, my goal is not to argue, but to > assist. Can't assist without knowledge, can't gain knowledge without > documentation (I despise cultural learning. Too much pure data > gets damaged in the retelling...) Understood, and I appreciate your points. Let's drive. -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Wed Jan 29 21:26:42 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA20612 for hackers-outgoing; Wed, 29 Jan 1997 21:26:42 -0800 (PST) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA20592 for ; Wed, 29 Jan 1997 21:26:37 -0800 (PST) Message-Id: <199701300526.VAA20592@freefall.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA090311978; Thu, 30 Jan 1997 16:26:18 +1100 From: Darren Reed Subject: Re: ipdivert & masqd To: cmott@srv.net (Charles Mott) Date: Thu, 30 Jan 1997 16:26:18 +1100 (EDT) Cc: hackers@freebsd.org In-Reply-To: from "Charles Mott" at Jan 29, 97 07:30:06 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In some mail from Charles Mott, sie said: > > > > My syntax may have been a little unclear. It is just that I had never > > > heard of the TIS ... Gauntlet program. Is it just an FTP client, or > > > something more advanced? If source code is available, I think that some > > > may wish to update the code. > > > > Firewall product. > > > > The point is, it isn't Gauntlet or the Firewall Toolkit which is doing > > anything wrong, it is the "transparent proxy" which makes bad assumptions > > (although 99% of the time it gets away with them). > > > > Darren > > > > I've seen quite a bit of feedback from several continents on the software I > have written. In particular, any time I have made a mistake, I have > been *very* quickly informed by users. I have yet to see any complaints > from users about ftp handling. > > In any event, it would be unusual to have such a firewall behind the > packet aliasing software I have written. It would be interesting to see > whether the authors of the firewall product you mention were being > deliberately "difficult". Nobody was, just the Firewall-1/Linux implementations are imperfect. > Your comments are interesting, but your attitude is not constructive in > my view. This probably reflects my frustration of how difficult it is to implement properly. Darren From owner-freebsd-hackers Wed Jan 29 21:37:57 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA21231 for hackers-outgoing; Wed, 29 Jan 1997 21:37:57 -0800 (PST) Received: from aries.bb.cc.wa.us (root@[208.8.136.11]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA21224 for ; Wed, 29 Jan 1997 21:37:54 -0800 (PST) Received: from localhost (chris@localhost) by aries.bb.cc.wa.us (8.8.3/8.6.9) with SMTP id VAA25715; Wed, 29 Jan 1997 21:35:49 -0800 (PST) Date: Wed, 29 Jan 1997 21:35:49 -0800 (PST) From: Chris Coleman To: "Brian J. McGovern" cc: Mark Mayo , Michael Smith , hackers@freebsd.org Subject: Re: Constructive criticism (was: bashing everyone for fun and profit) In-Reply-To: <199701300408.XAA09417@spoon.beta.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Alright, I have had enough. I work at Big Bend Community College. I have talked them into using FreeBSD as our campus Standard for Internet Resources. Mainly because of its reliability and availability. They also were very pleased with the tight-nit core team that puts out a reliable release every six months. Now it time for me to lend a hand. Im not that great a programmer, but I teach, and i like to write. So I am embarking on a project. I am taking this chatter about lack of documentation very seriously. Im Going to Write a Book. I am in the middle of setting up two FreeBSD machines and am documenting the things that i do as i go. I want to write a basic book that is from a user point of view. I spent six months struggling through the download and setup of my first FreeBSD box. I knew nothing about computers three years ago. I want to add to the project. This is a User Run Project. So I the User am going to do Somthing about it. Therefore, If you don't like the documentation, Write something. Even if it is just a well documented complaint. I will be accepting contributions, and criticizm and whatever helpful things you have to offer. So stop complaining about What doesn't work and What isnt documented, And do something. If anyone else is working on a title, or has anything partially started I would like to hear form them, so we can get organized and not duplicate each other work. I have put together a home page, and all my work will be open for review as I get it put together. Many thanks for all the Advice that you have given me. This list has been a livesaver many times. Chris Coleman (chris@aries.bb.cc.wa.us) Computer Support Technician I (509)-766-8873 Big Bend Community College Internet Instructor FreeBSD Book Project: http://www.bb.cc.wa.us/~chris/book.html Death is life's way of telling you you're fired. From owner-freebsd-hackers Wed Jan 29 21:53:21 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA21740 for hackers-outgoing; Wed, 29 Jan 1997 21:53:21 -0800 (PST) Received: from phoenix.its.rpi.edu (dec@phoenix.its.rpi.edu [128.113.161.45]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA21735 for ; Wed, 29 Jan 1997 21:53:18 -0800 (PST) Received: (from dec@localhost) by phoenix.its.rpi.edu (8.8.4/8.8.3) id AAA00562 for hackers@freebsd.org; Thu, 30 Jan 1997 00:53:35 -0500 (EST) Date: Thu, 30 Jan 1997 00:53:35 -0500 (EST) From: "David E. Cross" Message-Id: <199701300553.AAA00562@phoenix.its.rpi.edu> To: hackers@freebsd.org Subject: Motif 2.0.1 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have access to the sources to Motif 2.0.1 (under my university's site license)... However I have yet to successfully compile motif 2.0.1 on 2.1.6-RELEASE (or any version)... Is there anyone out there who has gotten it working, and could give me a few pointers? -- David Cross ACS Help Desk From owner-freebsd-hackers Wed Jan 29 21:54:14 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA21782 for hackers-outgoing; Wed, 29 Jan 1997 21:54:14 -0800 (PST) Received: from phoenix.its.rpi.edu (dec@phoenix.its.rpi.edu [128.113.161.45]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA21777 for ; Wed, 29 Jan 1997 21:54:08 -0800 (PST) Received: (from dec@localhost) by phoenix.its.rpi.edu (8.8.4/8.8.3) id AAA00738 for hackers@freebsd.org; Thu, 30 Jan 1997 00:54:35 -0500 (EST) Date: Thu, 30 Jan 1997 00:54:35 -0500 (EST) From: "David E. Cross" Message-Id: <199701300554.AAA00738@phoenix.its.rpi.edu> To: hackers@freebsd.org Subject: Ensoniq SoundScape Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Has anyone gotten this card to work under FreeBSD? If so, could you give me a hand (I think I am close, just missing that one last step) -- David Cross ACS Help Desk From owner-freebsd-hackers Wed Jan 29 22:02:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA22121 for hackers-outgoing; Wed, 29 Jan 1997 22:02:01 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA22113 for ; Wed, 29 Jan 1997 22:01:55 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id QAA27658; Thu, 30 Jan 1997 16:31:39 +1030 (CST) From: Michael Smith Message-Id: <199701300601.QAA27658@genesis.atrad.adelaide.edu.au> Subject: Device Drivers 101 In-Reply-To: <199701300505.AAA09649@spoon.beta.com> from "Brian J. McGovern" at "Jan 30, 97 00:05:43 am" To: mcgovern@spoon.beta.com (Brian J. McGovern) Date: Thu, 30 Jan 1997 16:31:38 +1030 (CST) Cc: msmith@atrad.adelaide.edu.au, 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Brian J. McGovern stands accused of saying: > > >Driver initialisation is seperated into two parts, known as 'probe' and > >'attach'. The purpose of the 'probe' routine is to ascertain whether > >the hardware is present, and optionally determine its configuration. > > >Probe/attach for ISA device drivers is triggered by the presence of a > >non-static isa_driver structure in the driver; at least the first three > >fields should be initialised, with the probe and attach routines and the > >name of the driver : > > Ok. I know the what. Any particular reason it has to be non-static? I assume > to cause it to blow up if there is another driver with the same name, but, > am I correct? The structures are collated at link time into what is known as a 'linker set'. This results in a statically-initialised array of all of the isa_device structures which can be processed by the startup code. The structure has to be non-static so that it is visible to the linker. > Secondly, what are the fields after the first 3? There is only one other field at the moment : struct isa_driver { int (*probe) __P((struct isa_device *idp)); /* test whether device is present */ int (*attach) __P((struct isa_device *idp)); /* setup driver for a device */ char *name; /* device name */ int sensitive_hw; /* true if other probes confuse us */ } Drivers with sensitive_hw set to true are probed before others to avoid being confused by other probes to the same space. > Also, I did a grep for "isa_driver" in /usr/include via a find (ie - > grep "isa_driver" `find .` to no avail. Which header should I include? #include , found in /sys/i386/isa/. As a kernel-only header, it't not found under /usr/include. > >struct isa_driver foodriver = { fooprobe, fooattach, "foo"}; > > >The 'fooprobe' function is called during startup to determine whether > >the device is present or not. It should return zero if the probe > >for the hardware failed, or the size of the I/O space occupied by > >the device if the probe succeeded. > > Please define "size of the I/O space". To me, this can mean many > things, probably all of which are wrong. Is it the number of ports a > device uses? Amount of memory (shared or otherwise)? And how about > our simulated pseudo device, which won't control hardware, but might > have a few K in buffers? The size of the range of I/O ports that the device occupies. This is, as has been observed elsewhere, a poor choice, as there are devices that occupy no I/O ports, and others that occupy several disjoint ranges. Pseudo-devices are handled differently. The 'vn' driver is a good place to look for a readable example (/sys/dev/vn/vn.c), but the basic strategy involves using the SYSINIT macro to register a startup function which calls the pseudo-device's init function, which in turn uses [cb]devsw_add and optionally devfs_add* to register the driver's existence. (For "normal" devices, the bus probe code for the bus to which the device belongs processes the linker set described above and calls the probe/attach pairs.) > >It is legitimate to alter the contents of the fields in the isa_device > >structure, if new values are determined by probing for the hardware. > >Note that the id_irq field is a bitmask, not a numeric value. The > >probe routine should not emit any text unless it comes up against > >something particularly alarming. > > Ok. id_irq is a bitmask. I'll have to save my other questions once I can > find struct isa_device. I am currently assuming that this contains the > info in the kernel config file when called. Same for a pseudo-device? Pseudo-devices don't get any config information. The isa_device structure is initialised by the config file data, yes. > >Attach is called, again once per instance of the driver in the config, > >when the device has been successfully probed and does not conflict. > Does the driver make the call as to the conflict? Or does the system look > at the struct isa_device, and if a conflict occurs, not call the probe > and attach routines? The bus code is responsible for deciding whether a driver is in conflict; drivers should ideally know nothing about the bus or other drivers. > >Once internal state for the driver has been established, you add an entry > >to the device switch for the driver. In the case of a character device, > >the following fragment is normally used : > > > > dev = makedev(CDEV_MAJOR,0); > > cdevsw_add(&dev,&foo_cdevsw,NULL); > > > > Ok. Looks clear enough. I'm assuming we're still in attach here... I'm > also assuming that block devices would call bdevsw_add (wrong name i think, > but I think I get the idea). The name is correct too 8) > How about STREAMS types or tty type devices that are linked off > through a line protocol? No STREAMS in the BSD kernel 8). Tty devices are character devices; there's extra state involved in interacting with the tty stack, which is logically layered on top of the character driver. This is a topic on which Bruce is best qualified to comment; I'm just going to refer to sio.c and translate what I read into English 8) > >Where CDEV_MAJOR is the major device number assigned to the driver > >(normally #defined somewhere obvious). > > > >A typical cdevsw initialisation might look like : > > > >static d_open_t fooopen; > >static d_close_t fooclose; > >static d_read_t fooread; > >static d_write_t foowrite; > >static d_ioctl_t fooioctl; > >static d_select_t fooselect; > > > >#define CDEV_MAJOR 20 > >static struct cdevsw foo_cdevsw = > >{ > > fooopen, fooclose, fooread, foowrite, > > fooioctl, nullstop, nullreset, nodevtotty, > > fooselect, nommap, NULL, driver_name, > > NULL, -1 > >}; > > > > Ok. Some of it makes sense. Is there a blank generic one that gives the > appropriate order? For instance, I see nullstop and nullreset. There should > also be a poll routine in there some where? Is it a NULL? a no? a -1? I don't believe that there's a blank. The structure and the blanks are listed in /sys/sys/conf.h. I should have been a little more thoughtful about the no vs. null comment : The no* versions return ENODEV, the null* versions always succeed but do nothing, the nx* versions return ENXIO (but are a bad idea according to the comment in sys/kern/subr_xxx.c where they are defined). BSD doesn't have a poll syscall; 'similar' functionality is afforded by select(2). > Ok. Is creating a devfs node mandatory? I know people would like to move to > it, but when/is it required? What makes the decision if it is optional? It's not mandatory, but if you don't put a call in to create it, someone else will 8) Normally devfs node creation is conditionalised on DEVFS. > >You can call this several times to create multiple nodes for a single > >instance of the driver. > > Ok. I assume this means that it'll generate the same major numbers with > appropriate minor numbers? Devfs doesn't really 'do' major and minor numbers; there's a logically direct translation from the named node to your switch entry and the unit number you supply when you create the node. -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Wed Jan 29 22:13:35 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA22614 for hackers-outgoing; Wed, 29 Jan 1997 22:13:35 -0800 (PST) Received: from clipper.cs.kiev.ua (root@cs-demon.ua.net [193.124.48.251]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id WAA22608 for ; Wed, 29 Jan 1997 22:13:28 -0800 (PST) Received: from dog.farm.org by clipper.cs.kiev.ua with uucp id m0vppdO-000t47C; Thu, 30 Jan 97 08:06 WET Received: (from dk@localhost) by dog.farm.org (8.7.5/dk#3) id VAA03336; Wed, 29 Jan 1997 21:59:48 -0800 (PST) Date: Wed, 29 Jan 1997 21:59:48 -0800 (PST) From: Dmitry Kohmanyuk Message-Id: <199701300559.VAA03336@dog.farm.org> To: shocking@mailbox.uq.edu.au (Stephen Hocking) Cc: freebsd-hackers@freebsd.org Subject: Re: Setting MTU from userland ppp Newsgroups: cs-monolit.gated.lists.freebsd.hackers Organization: FARM Computing Association Reply-To: dk+@ua.net X-Newsreader: TIN [version 1.2 PL2] Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199701290935.TAA01388@mailbox.uq.edu.au> you wrote: > How does one do this? If I try fiddling tun0 (ifconfig tun0 mtu 256) the > userland ppp get quite cranky and ppp net connections hang. set mtu 576 in /etc/ppp/ppp.conf works for me. This would specify your _tranimission_ size. To change it on the other side, change the other end's setup. Don't use 256 as your MTU. (violates the RFC) From owner-freebsd-hackers Wed Jan 29 22:14:13 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA22655 for hackers-outgoing; Wed, 29 Jan 1997 22:14:13 -0800 (PST) Received: from schizo.cdsnet.net (schizo.cdsnet.net [204.118.244.32]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA22648 for ; Wed, 29 Jan 1997 22:14:08 -0800 (PST) Received: (from mrcpu@localhost) by schizo.cdsnet.net (8.8.4/8.7.3) id WAA01444 for hackers@freebsd.org; Wed, 29 Jan 1997 22:14:06 -0800 (PST) Date: Wed, 29 Jan 1997 22:14:06 -0800 (PST) From: Jaye Mathisen Message-Id: <199701300614.WAA01444@schizo.cdsnet.net> To: hackers@freebsd.org Subject: Bind 4.9.5-P1 on FreeBSD going bonkers... Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'm having an intermittent problem on my main nameserver for my ISP site. I'm using FreeBSD -current as of about August on a P5-90, 64MB's RAM. Basically the following tells the whole story. It works fine for a while, and then every request comes back as non-authoritative. They're not even always right. Restarting the nameserver fixes the problem for the short term. Note that this is not for my own domain, nor hosts that we serve, but just random places out there on the net. # nslookup www.stroud.com Server: ns.cdsnet.net Address: 204.118.244.2 Non-authoritative answer: Name: www.stroud.com Address: 204.107.221.239 # named.restart Jan 29 22:09:59 ns named[28248]: starting. named 4.9.5-P1 Tue Jan 21 16:09:56 PST 1997 root@ns.cdsnet.net:/usr/local/src/bind-4.9.5-P1/named Jan 29 22:10:00 ns named[28249]: Ready to answer queries. nslookup www.stroud.com Name Server Restarted # # Server: ns.cdsnet.net Address: 204.118.244.2 Name: www.stroud.com Addresses: 204.107.221.239, 199.35.192.140 This is a serious problem, since my squid server won't use any non-authoritative answers from the DNS, and so several thousand customers can't access the web. Restarting named *always* fixes it. Any ideas appreciated. From owner-freebsd-hackers Wed Jan 29 22:50:43 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA24136 for hackers-outgoing; Wed, 29 Jan 1997 22:50:43 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA24127 for ; Wed, 29 Jan 1997 22:50:40 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id WAA12336; Wed, 29 Jan 1997 22:49:09 -0800 (PST) To: Terry Lambert cc: brian@awfulhak.demon.co.uk, hackers@freebsd.org Subject: Re: Source code commits In-reply-to: Your message of "Wed, 29 Jan 1997 19:16:01 MST." <199701300216.TAA20836@phaeton.artisoft.com> Date: Wed, 29 Jan 1997 22:49:09 -0800 Message-ID: <12332.854606949@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I suggested a sort of "write-through" validation/submission system for the CVS tree a year ago, where anyone could "commit" to the source tree but for those people who weren't actually authorized to commit directly, what would happen instead is that the diffs would be automagically sent to the person or persons actually responsible for the code in question, and they would review and optionally commit it. Unfortunately, someone still needs to add the feature and that someone is not me. :-) Jordan From owner-freebsd-hackers Thu Jan 30 00:08:06 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA27292 for hackers-outgoing; Thu, 30 Jan 1997 00:08:06 -0800 (PST) Received: from emout06.mail.aol.com (emout06.mx.aol.com [198.81.11.97]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA27286 for ; Thu, 30 Jan 1997 00:08:01 -0800 (PST) From: StevenR362@aol.com Received: (from root@localhost) by emout06.mail.aol.com (8.7.6/8.7.3/AOL-2.0.0) id DAA08082; Thu, 30 Jan 1997 03:07:30 -0500 (EST) Date: Thu, 30 Jan 1997 03:07:30 -0500 (EST) Message-ID: <970130001449_1313001207@emout06.mail.aol.com> To: sos@ravenock.cybercity.dk, jkh@time.cdrom.com cc: hackers@freebsd.org Subject: Re: 2.2-BETA Questions MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Transfer-Encoding: 8bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In a message dated 97-01-29 13:53:12 EST, sos@ravenock.cybercity.dk (Søren Schmidt) writes: > A couple of ideas: > > First see to it that the two IDE HD's are of different make, that should > get you a good deal of exitement. Eg Quantum & WD or WD & Maxtor or > WD & Seagate could give you some interesting funkiness, If you can get > hold of a Conner drive, the make of the other doesn't matter, you'll > have all the fun anyways), get a Promise or better a HongKong clone > of a IDE cache controller, and then a Sanyo 3 disk ATAPI cdrom. > Then a Elcheapo MAD or OPTI based soundcard, and a LPT port that > only can be set at the lpt3 (0x3bc) address, together with an early > Matrox MGA videocard. > > This should supply you all the fun you can bare for the foreseeable > future... Hmmm, parts of the above listing sound suspiciously like the hardware I sent you. :) Glad to see that you are having fun with it! Steve From owner-freebsd-hackers Thu Jan 30 00:26:13 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA27873 for hackers-outgoing; Thu, 30 Jan 1997 00:26:13 -0800 (PST) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA27865 for ; Thu, 30 Jan 1997 00:26:11 -0800 (PST) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id BAA02591; Thu, 30 Jan 1997 01:26:03 -0700 (MST) Date: Thu, 30 Jan 1997 01:26:03 -0700 (MST) Message-Id: <199701300826.BAA02591@rocky.mt.sri.com> From: Nate Williams To: "Jordan K. Hubbard" Cc: Terry Lambert , brian@awfulhak.demon.co.uk, hackers@freebsd.org Subject: Re: Source code commits In-Reply-To: <12332.854606949@time.cdrom.com> References: <199701300216.TAA20836@phaeton.artisoft.com> <12332.854606949@time.cdrom.com> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I suggested a sort of "write-through" validation/submission system for > the CVS tree a year ago, where anyone could "commit" to the source > tree but for those people who weren't actually authorized to commit > directly, what would happen instead is that the diffs would be > automagically sent to the person or persons actually responsible for > the code in question, and they would review and optionally commit it. Aieee, why go for trivial solutions when we can do something much more useful (and difficult). I think it would be easier to rewrite CVS from scratch. :) Nate From owner-freebsd-hackers Thu Jan 30 00:48:53 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA28792 for hackers-outgoing; Thu, 30 Jan 1997 00:48:53 -0800 (PST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA28785 for ; Thu, 30 Jan 1997 00:48:48 -0800 (PST) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.4/8.8.4) with SMTP id AAA06603; Thu, 30 Jan 1997 00:44:53 -0800 (PST) Date: Thu, 30 Jan 1997 00:43:08 -0800 (PST) From: Julian Elischer To: "Brian J. McGovern" cc: msmith@atrad.adelaide.edu.au, hackers@freebsd.org Subject: Re: The continuting email... In-Reply-To: <199701300505.AAA09649@spoon.beta.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 30 Jan 1997, Brian J. McGovern wrote: > >I'll restrict myself to ISA drivers, as these are where I'm most familiar. > >PCI drivers are generally similar, but have an easier time in some > >regards. PCI drivers register themselves differently, and the PCI code recognises the harware and calls the 'attach' routine directly.. the probe() routine is redunant (yay!) > > >I'll use your 'foo' driver as an example. > > ==== > > >Probe/attach for ISA device drivers is triggered by the presence of a > >non-static isa_driver structure in the driver; at least the first three > >fields should be initialised, with the probe and attach routines and the > >name of the driver : > > Ok. I know the what. Any particular reason it has to be non-static? I assume > to cause it to blow up if there is another driver with the same name, but, > am I correct? It has to be non static because the presence of the device in teh kernel configuration file will cause a reference to this structure to be made in a generated .c file which will be linked into the kernel. look in a kernel build directory (e.g. /sys/compile/GENERIC) for the file ioconf.c . This file is generated from the kernel config file. > > Secondly, what are the fields after the first 3? nope, that's all. In other BSD systems there are sometimes more > > Also, I did a grep for "isa_driver" in /usr/include via a find (ie - > grep "isa_driver" `find .` to no avail. Which header should I include? in /sys/i386/isa/isa_device.h > > >struct isa_driver foodriver = { fooprobe, fooattach, "foo"}; > > >The 'fooprobe' function is called during startup to determine whether > >the device is present or not. It should return zero if the probe > >for the hardware failed, or the size of the I/O space occupied by > >the device if the probe succeeded. > > Please define "size of the I/O space". To me, this can mean many > things, probably all of which are wrong. Is it the number of ports a > device uses? Amount of memory (shared or otherwise)? And how about > our simulated pseudo device, which won't control hardware, but might > have a few K in buffers? The number of IO ports. you may fill in the size of the shared memory buffer in the isa_device structure (and other fields) as well > > >static int > >fooprobe(struct isa_device *dev) > > >It is legitimate to alter the contents of the fields in the isa_device > >structure, if new values are determined by probing for the hardware. > >Note that the id_irq field is a bitmask, not a numeric value. The > >probe routine should not emit any text unless it comes up against > >something particularly alarming. > > Ok. id_irq is a bitmask. I'll have to save my other questions once I can > find struct isa_device. I am currently assuming that this contains the > info in the kernel config file when called. Same for a pseudo-device? > > > > >The probe routine is called once per instance of the driver in the > >configuration file. > > > >Attach is called, again once per instance of the driver in the config, > >when the device has been successfully probed and does not conflict. > Does the driver make the call as to the conflict? Or does the system look > at the struct isa_device, and if a conflict occurs, not call the probe > and attach routines? The kernel makes the call after the probe has checked the values it was given and changed anything.. there is also (I seem to remember) a check BEFORE that as well > > > > >static int > >fooattach(struct isa_device *dev) > > > >The attach routine should build any local data structures required for > >management of the device. It is traditional for the attach routine to > >emit a line like : > > > >foo0: Snarklewacker 200, rotating Floib, no BoBoBoBoB. > > > >The startup code will have already emitted a line like : > > > >foo0 at 0x10-20 irq 1 iomem 0x12345 on isa > > > Ok. This smells like the init routines I'm used to seeing. > > > >Once internal state for the driver has been established, you add an entry > >to the device switch for the driver. In the case of a character device, > >the following fragment is normally used : > > > > dev = makedev(CDEV_MAJOR,0); > > cdevsw_add(&dev,&foo_cdevsw,NULL); > > > > Ok. Looks clear enough. I'm assuming we're still in attach here... Well, no..well, maybe.. this must be called exactly ONCE for each driver. It is possible that the attach code is called more than that so the code needs to have "have I been here before" protection.. In many drivers there is no hardware so no attach function os called. for an example look at mem.c This driver uses a facility in the kernel called SYSINIT. the SYSINIT facility allows an arbitrary function to specify where it is to be called in the boot sequence. Most drivers have a SYSINIT entry in addition to the attach/probe stuff. and pseudo-device driver MUST have one.. The SYSINIT entry usually specifies an 'init' routine that is run ONCE and ONLY ONCE (unless you have two SYSINIT entries). This is the IDEAL place to put the cdevs_add() calls as it will ensure that it happens once, before it's needed. Note also that in some ways the 'init' code is exactly what would need to be called to link in the driver had it been an LKM. when all drivers use SYSINIT and all cdevsw/bdevsw entries are dynamic and all interrupts are hooked in dynamically, then in effect you will be able to load device drivers as LKMs with no extra work. DEVFS gives you a view into this dynamic world. > I'm > also assuming that block devices would call bdevsw_add (wrong name i think, > but I think I get the idea). no, it IS bdevsw_add. notice that the bdevsw and cdevsw entries in your driver are THE ACTUAL ENTRIES. In FreeBSD the cdevsw and bdevsw tables are an array of POINTERS, and not an array of actual structs. The cdevsw_add() can be asked to CHOOSE a major number for you if you don't have one in mind. The number used is STORED IN THE cdevsw/bdevsw table entry, so examine it afterwards to discover what you got. They also have crosspointers, so given a cdev you can quickly find the related bdev and visa versa. (and also the driver 'name' for use in error messages etc. (e.g. 'foo') > How about STREAMS typesi BSD doesn't have streams, but if they did they would be initialised through the same SYSINIT method (see /sys/kernel.h) (SI_SUB_DRIVERS) as we don't have them I have no idea how you'd access them :) > or tty type devices that tty devices are just normal devices.. pty devices are pseudo devices and thus have a SYSINIT entry. > are linked off through a line protocol? Once I'm done with driver foo, > I'd like to start work on an ISA multi-modem card thats being prepped > by Cisco for inclusion in to their routers (the modem modules, not the ISA > cards). I'll need to run SLIP and PPP across the link. the _documentation I > have_ says I'll have to make it a little more special than a "normal" character > device... why? > > >Where CDEV_MAJOR is the major device number assigned to the driver > >(normally #defined somewhere obvious). Well Majors are assigned in /sys/i386/conf/majors (or something) but that file isn't actually used..it's just for reference. > > > >A typical cdevsw initialisation might look like : > > > >static d_open_t fooopen; > >static d_close_t fooclose; > >static d_read_t fooread; > >static d_write_t foowrite; > >static d_ioctl_t fooioctl; > >static d_select_t fooselect; > > > >#define CDEV_MAJOR 20 > >static struct cdevsw foo_cdevsw = > >{ > > fooopen, fooclose, fooread, foowrite, > > fooioctl, nullstop, nullreset, nodevtotty, > > fooselect, nommap, NULL, driver_name, > > NULL, -1 > >}; > > > > Ok. Some of it makes sense. Is there a blank generic one that gives the > appropriate order? For instance, I see nullstop and nullreset. There should > also be a poll routine in there some where? Is it a NULL? a no? a -1? Poll is sysV there is no poll in BSD.. the similar entry is the 'select' entry. > >Note that some of the placeholders are "no*" and some are "null*" - I > >think that this is laziness on someone's part 8( > Again, see the note above. Docs on what they "should be" could help fix this :) agreed.. it MIGHT be in conf.h > > > > >To create a devfs device node : > > > > sc->devfs_token = devfs_add_devsw(&foo_cdevsw, unit, > > DEV_CHR, UID_ROOT, GID_WHEEL, > > 0660, "foo%d", unit); > > > >This returns a token which is saved (here) in the devfs_token field in > >the device's softc structure (the per-device state structure). The reason for keeping the token is in case you want to removethe device. you do so by supplying the token you were given to the devfs_??? function (it's in the chapter 9 man page I believe) > >The > >cdevsw structure defines the driver's entrypoints, unit is the unit > >number associated with the device node (you can encode major/minor > >data here if you wish), DEV_CHR indicates a character device node, the > >UID_ROOT, GID_WHEEL and 0660 entries set the ownership/permissions on > >the new device node, and the remaining arguments are printf-style, > >with a format string and parameters for the format string which yield > >the name of the device node. > > > Ok. Is creating a devfs node mandatory? I know people would like to move to > it, but when/is it required? What makes the decision if it is optional? Well If I can get the bugs shaken out we should move to it asap :) > > >You can call this several times to create multiple nodes for a single > >instance of the driver. > > Ok. I assume this means that it'll generate the same major numbers with > appropriate minor numbers? no, YOU supply a differnt minor number and name each time.. this is effectively making entries in /dev for your driver. you can also make links for devices that want different names. how you interpret teh minor number is up to the driver so only the driver can decide how to allocate them.. > > I appreciate the help to date. Again, my goal is not to argue, but to > assist. Can't assist without knowledge, can't gain knowledge without > documentation (I despise cultural learning. Too much pure data > gets damaged in the retelling...) > julian (let me know more about this device and PPP I may have some info for you on that too) > From owner-freebsd-hackers Thu Jan 30 01:49:02 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA01670 for hackers-outgoing; Thu, 30 Jan 1997 01:49:02 -0800 (PST) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA01664 for ; Thu, 30 Jan 1997 01:48:59 -0800 (PST) Message-Id: <199701300948.BAA01664@freefall.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA152817733; Thu, 30 Jan 1997 20:48:53 +1100 From: Darren Reed Subject: Re: ipdivert & masqd To: cmott@srv.net Date: Thu, 30 Jan 1997 20:48:53 +1100 (EDT) Cc: hackers@freebsd.org In-Reply-To: <199701300526.VAA20592@freefall.freebsd.org> from "Darren Reed" at Jan 30, 97 04:26:18 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In some mail from Darren Reed, sie said: > > > > The point is, it isn't Gauntlet or the Firewall Toolkit which is doing > > > anything wrong, it is the "transparent proxy" which makes bad assumptions > > > (although 99% of the time it gets away with them). > > Your comments are interesting, but your attitude is not constructive in > > my view. > > This probably reflects my frustration of how difficult it is to > implement properly. And more to the point, ipmasqd/ipdivertd are in a good position to do it properly so some effort should be made to see what can be done to create a solution that overcomes deficincies in other existing systems. Wasting this oppotunity doesn't seem very sensible (to me). IMHO, some effort should be made to attempt to "do it properly". Maybe the "simpler" solutions could be imlpemented but they should be done so only with a clear understanding that its a temporary solution and work is being done on fixing it. (Is that a bit more constructive ?) Darren From owner-freebsd-hackers Thu Jan 30 02:07:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA02207 for hackers-outgoing; Thu, 30 Jan 1997 02:07:49 -0800 (PST) Received: from ui-gate.utell.co.uk (ui-gate.utell.co.uk [194.200.4.253]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA02202 for ; Thu, 30 Jan 1997 02:07:40 -0800 (PST) Received: from dibble.utell.net (dibble.utell.net [97.3.0.10]) by ui-gate.utell.co.uk (8.7.6/8.7.3) with ESMTP id KAA29835; Thu, 30 Jan 1997 10:07:30 GMT Message-Id: <199701301007.KAA29835@ui-gate.utell.co.uk> From: "Brian Somers" To: Cc: Subject: Re: PR2347 - recursive malloc() in ppp Date: Thu, 30 Jan 1997 10:02:46 -0000 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Brian, > > I didn't mean to jump into the middle of your mail conversion > related to this recursive malloc. Forgive me if I do cause > any problems here. > > I modified the original 2.0.5 code for a local ISP who > used FreeBSD as their main engines and made it work reliably. > . But after the ISP upgraded the code to 2.1.5 and I still noticed > that there are a few problems that were not fixed properly. One of > the problems that I noticed was relatively new to the ppp code. > > Sometimes when the line is dropped, ppp just locks up > and the tail -f /var/log/ppp.log stops to show any more traces. > netstat -m shows that the mbuf usage is relatively reasonable. > There is no way that I can get out of it. I put a data scope on > the line and noticed that ppp did not respond to any ppp command > from the peer side. This system is fully loaded with ip-filter running > NAT and RDR, caching proxy, sockd, netcat, etc. We have ruled out > everything except ppp because when we changed to sppp, the problem > went away. The only way to get out of it is to kill -9. It works > fine after it is restarted it again. > > Allow me to ask you if your patch related to the problem > mentioned above. If it does, would you please send me the patch > . > > Many thanks. > > Fran I'm not sure what your problem might have been, but lots of changes have been done to ppp since then. You can pick up the current sources from ftp://ftp.freebsd.org:/pub/FreeBSD/FreeBSD-current/src/usr.sbin/ppp if you want to have a look at the "current" version, but I don't think it'll compile on 2.1*. If you're interested in *just* the patches, have a look on http://www.freebsd.org/~brian. -- Brian Don't _EVER_ lose your sense of humour From owner-freebsd-hackers Thu Jan 30 03:04:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA04669 for hackers-outgoing; Thu, 30 Jan 1997 03:04:47 -0800 (PST) Received: from ki1.chemie.fu-berlin.de (ki1.Chemie.FU-Berlin.DE [160.45.24.21]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id DAA04663 for ; Thu, 30 Jan 1997 03:04:41 -0800 (PST) Received: by ki1.chemie.fu-berlin.de (Smail3.1.28.1) from mail.hanse.de (193.174.9.9) with smtp id ; Thu, 30 Jan 97 12:04 MET Received: from wavehh.UUCP by mail.hanse.de with UUCP for Freebsd-hackers@freebsd.org id ; Thu, 30 Jan 97 12:04 MET Received: by wavehh.hanse.de (4.1/SMI-4.1) id AA20685; Thu, 30 Jan 97 11:10:09 +0100 Date: Thu, 30 Jan 97 11:10:09 +0100 From: cracauer@wavehh.hanse.de (Martin Cracauer) Message-Id: <9701301010.AA20685@wavehh.hanse.de> To: julian@whistle.COM Cc: Freebsd-hackers@freebsd.org, jason@idiom.com Subject: Re: [Fwd: freebsd performance.] Newsgroups: hanse-ml.freebsd.hackers References: <32EFD2E2.167EB0E7@whistle.com> Reply-To: cracauer@wavehh.hanse.de Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >From: Jason Venner >The posix regex library is VERY VERY slow. >I have a program that uses a large regex to parse some input. >I have a version in perl and a version in C++ using the freebsd posix >regex library. >The perl version is 100X faster that the C++ version. >gprof on the C++ version shows 99% of the spend in: > 91.53 46.17 46.17 1152366 0.04 0.04 lstep > 6.52 49.46 3.29 98497 0.03 0.47 lslow Adding to the explanations about different kinds of regular expressions by Patrick Giagnocavo, I'd like to note that I found *BSD's regex support to be quite fast. I benchmarked Spencers code against various versions of GNU regex stuff and found Spencers library to be about 30% faster than the GNU stuff from GNU-sed-2.x and that the GNU sed-3.00/regex-1.0 stuff didn't even pass my benchmarks without coredumping. I didn't take perl's library into account because I found no easy way to use it from C. I'd say it is a valid goal to make perl's regex library availiable as a C library (maybe someone already did). For different regex syntax anyway and maybe for performance also. I'd like to second the request for a simplified test case that shows the difference so we can investigate the problem. Jason, do you copy, can you provide a regex and a testfile? I tend to say some easy-to-solve thing must have been triggered. After all, perl's regex code is derived from Spencer's, too. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin_Cracauer@wavehh.hanse.de http://cracauer.cons.org Fax.: +4940 5228536 "As far as I'm concerned, if something is so complicated that you can't ex- plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin From owner-freebsd-hackers Thu Jan 30 03:05:10 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA04720 for hackers-outgoing; Thu, 30 Jan 1997 03:05:10 -0800 (PST) Received: from ui-gate.utell.co.uk (ui-gate.utell.co.uk [194.200.4.253]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA04713 for ; Thu, 30 Jan 1997 03:05:04 -0800 (PST) Received: from dibble.utell.net (dibble.utell.net [97.3.0.10]) by ui-gate.utell.co.uk (8.7.6/8.7.3) with ESMTP id KAA00746; Thu, 30 Jan 1997 10:57:47 GMT Message-Id: <199701301057.KAA00746@ui-gate.utell.co.uk> From: "Brian Somers" To: Cc: , , , , Subject: Re: ipdivert & masqd Date: Thu, 30 Jan 1997 10:53:04 -0000 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I've essentially got th