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