From owner-freebsd-current Sun Nov 12 01:33:19 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA02029 for current-outgoing; Sun, 12 Nov 1995 01:33:19 -0800 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA02011 ; Sun, 12 Nov 1995 01:32:57 -0800 Received: from grumble.grondar.za (grumble.grondar.za [196.7.18.130]) by grunt.grondar.za (8.6.12/8.6.9) with ESMTP id LAA05966; Sun, 12 Nov 1995 11:32:49 +0200 Received: from localhost (localhost [127.0.0.1]) by grumble.grondar.za (8.6.12/8.6.9) with SMTP id LAA24354; Sun, 12 Nov 1995 11:32:48 +0200 Message-Id: <199511120932.LAA24354@grumble.grondar.za> X-Authentication-Warning: grumble.grondar.za: Host localhost didn't use HELO protocol To: bruce@freebsd.org cc: current@freebsd.org Subject: /dev/random permissions etc Date: Sun, 12 Nov 1995 11:32:47 +0200 From: Mark Murray Sender: owner-current@freebsd.org Precedence: bulk Hi A couple of weeks ago I agreed that the right permissions for /dev/*random were 660 and owned by root.kmem. I have discussed this with the original author, and am now quite firmly of the opinion that this is bad. Here are my reasons: The original idea was that protecting these devices would help prevent denial-of-service attacks. I believe that this is not really valid given that easier amd harsher attacks are possible (fork bombs, disk fillers etc). It is easy to find a job that has gone crazy reading all the entropy. By making the device non-world-readable, forces programs like PGP to be at least setgid. MAJOR LOSE! An attacker can now read /dev/kmem using pgp! It also makes the device difficult to use, as the secure writing of set[gu]id programs is nortoriously unsafe ;-) The original author's idea was that /dev/urandom would be "sufficiently random", while /dev/random would be "as random as possible", so the latter device only gives as many bits of randomness at it believes it has. This does not mean that /dev/urandom has lousy numbers. On the contrary, it has very good numbers which only extremelely powerful adversaries with hefty computing power have a chance of breaking. Due to the nature of the MD5 algorithm used, chances of such breakages depend mainly on hitherto un{discovered|published} weaknesses in MD5. Future developments to this device will include users' ability to add randomess, and root's ability to increase or decrease the entropy estimate. This will require the device to be world readable and writeable. I am going to set /dev/*random to mode 666 owner root.wheel (like /dev/null) and put them in the same paragraph (std) in MAKEDEV. Any objections? Speak now, or forever hold the pieces. :-) M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grumble.grondar.za for PGP key From owner-freebsd-current Sun Nov 12 03:24:56 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA05919 for current-outgoing; Sun, 12 Nov 1995 03:24:56 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id DAA05914 for ; Sun, 12 Nov 1995 03:24:52 -0800 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id MAA07757 for ; Sun, 12 Nov 1995 12:24:42 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id MAA04834 for freebsd-current@FreeBSD.org; Sun, 12 Nov 1995 12:24:42 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id MAA19450 for freebsd-current@FreeBSD.org; Sun, 12 Nov 1995 12:22:04 +0100 From: J Wunsch Message-Id: <199511121122.MAA19450@uriah.heep.sax.de> Subject: low-mem machines awfully slow now To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sun, 12 Nov 1995 12:22:04 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1195 Sender: owner-current@FreeBSD.org Precedence: bulk I'm just testing a self-compiled snapshot of 2.1. As usual, i'm using a spare 386sx/16 with 6 MB RAM for this. I noticed that the installation procedure became *awfully* slow now. At the first attempt, i've even given up since i thought the installation was dead. The machine were stuck with the ``Creating root file system'' message. Eventually, after about a minute or so, it continued. This slugginess continues all the time. The strange thing is that it's for no apparent reason. It's just ``sitting there'', no disk activity, screen echo on the holographic shell yes, but no command execution. Once it's going on again, everything works as `quick' as usual, even the response to an `ls' command on the holographic shell is within less than a second then. I've first noticing this at the fixit floppy on the same machine, btw. The floppy works fine on a faster one, but on this slow box, it continuously falls back into ``deep thinking'' every now and then. Does anybody have an idea how to investigate the bottleneck? -- 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-current Sun Nov 12 03:52:50 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA06267 for current-outgoing; Sun, 12 Nov 1995 03:52:50 -0800 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id DAA06262 for ; Sun, 12 Nov 1995 03:52:48 -0800 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id DAA15346; Sun, 12 Nov 1995 03:52:18 -0800 To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) cc: freebsd-current@FreeBSD.org (FreeBSD-current users) Subject: Re: low-mem machines awfully slow now In-reply-to: Your message of "Sun, 12 Nov 1995 12:22:04 +0100." <199511121122.MAA19450@uriah.heep.sax.de> Date: Sun, 12 Nov 1995 03:52:18 -0800 Message-ID: <15344.816177138@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.org Precedence: bulk > I'm just testing a self-compiled snapshot of 2.1. As usual, i'm using > a spare 386sx/16 with 6 MB RAM for this. > > I noticed that the installation procedure became *awfully* slow now. > At the first attempt, i've even given up since i thought the > installation was dead. The machine were stuck with the ``Creating > root file system'' message. Eventually, after about a minute or so, Hmmm. Any swap space configured? One recent change I made was to do the swapon first, before anything else (e.g. newfs'ing root). It's possible that this is having some strange effects, though the lack of disk activity means that traditional swapping-to-death behavior is not the cause. Also, don't forget that everything in /stand is crunched, so it will take some time to decompress things in memory if you're running them from there. More than that, I can't really say.. Jordan From owner-freebsd-current Sun Nov 12 05:31:39 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA07670 for current-outgoing; Sun, 12 Nov 1995 05:31:39 -0800 Received: from nanolon.gun.de (nanolon.gun.de [192.109.159.5]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA07665 ; Sun, 12 Nov 1995 05:31:23 -0800 Received: (from uucp@localhost) by nanolon.gun.de (8.6.8.1/8.6.6) id OAA07387; Sun, 12 Nov 1995 14:30:38 +0100 Received: from knobel.gun.de (localhost [127.0.0.1]) by knobel.gun.de (8.6.12/8.6.12) with SMTP id OAA04909; Sun, 12 Nov 1995 14:27:57 +0100 Date: Sun, 12 Nov 1995 14:27:57 +0100 (MET) From: Andreas Klemm To: hackers@freebsd.org, current@freebsd.org Subject: Diffs to the dump utility, rewritten with respect to your comments Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-895630724-816182877=:4791" Sender: owner-current@freebsd.org Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-895630724-816182877=:4791 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi ! Here again my diffs for the dump utility. I rewrote my changes because of your comments (division through zero, same default dump device as tar). I made the context diffs against the FreeBSD-stable source of today: Sun Nov 12 14:01:21 MET 1995. Changes in detail: main.c - line 167: abort dump if a blocksize > 32 (K) was chosen using dump's "b" option, because restore is unable to restore dumps with blocksizes over 32 K. Someone said here, there might be a bug in the scsi tape driver. This should be fixed as soon as possible. Users/Administrators are now protected from the worst case situation, that they can't restore their dump if they choosed a blocksize over 32. Dump does it all fine, but later, &@&%" ;-) "So this patch prevent's dump from being a BOFH tool ;-))" - line 447: here ends the dump time, needed for calculation of dumptime and throughput. - line 460: report dump time and performance after dump. check that dumptime isn't zero, that would cause a division through zero. when calculating the performance. dump.h - line 82: introducnd new variable for dumptime calculation tend_writing. dump.8 - line 105: changed default dump device to /dev/rst0. Now it's the same as in tar (for Joerg ;-). He convinced me, that a) not all people have a dump device, where everything fits on one tape and b) that /dev/rst0 is the standard in tar, too. Ok, you win ;-)) - line 259: In the example I deceided to dump to the first connected tape drive, most people will have only one tape device, so the example becomes more praxis oriented ;-) - line 285: FILES section: changed /dev/rmt8 to /dev/rst0 - line 314: BUG section: tell the people to use blocksizes <= 32 K. If they don't follow that, then dump takes care and aborts ;-) Never do backups, you can't read ;-) - line 341: Updated the history section. pathnames.h - line 38: changed default dump device to /dev/rst0 That's it folks, hope you enjoyed it. I hope the verbose comments help, to incorporate these (partly important) fixes to the source tree very quickly. I think the fix that prevents to use blocksizes over 32k, is really important. Figure out, someone relies on the backup, that he made on his brand new Tape or DAT ... Let's assume, he makes two backups, to be save, but he too lazy or inexperienced, to check, if he can read it in.... If then the system crashes and he is unable to restore his data, then ..... figure out yourself ! Perhaps this might be a reason, to "break" the code freeze in this case. A System, that is unable to read it's own dumps under certain circumstances without a big warning to the operator is deadly bad ;-) Think over it twice, it was called FreeBSD-stable the last weeks ;-) Prevent calling it: "FreeBSD-crashed-unable_to_restore" ;-)) happy weekend :) Andreas /// -- andreas@knobel.gun.de /\/\___ Wiechers & Partner Datentechnik GmbH Andreas Klemm ___/\/\/ - Support Unix - aklemm@wup.de - \/ ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz apsfilter - magic print filter 4lpd >>> knobel is powered by FreeBSD <<< --0-895630724-816182877=:4791 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="diff.akl" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: diffs to dump(8) FreeBSD-stable KioqIG1haW4uYy5vcmlnCVN1biBOb3YgMTIgMTM6NDE6NDMgMTk5NQ0KLS0t IG1haW4uYwlTdW4gTm92IDEyIDEzOjQ0OjE5IDE5OTUNCioqKioqKioqKioq KioqKg0KKioqIDE2NywxNzIgKioqKg0KLS0tIDE2NywxNzkgLS0tLQ0KICAJ CWNhc2UgJ2InOgkJLyogYmxvY2tzIHBlciB0YXBlIHdyaXRlICovDQogIAkJ CW50cmVjID0gbnVtYXJnKCdiJywgIm51bWJlciBvZiBibG9ja3MgcGVyIHdy aXRlIiwNCiAgCQkJICAgIDFMLCAxMDAwTCwgJmFyZ2MsICZhcmd2KTsNCisg CQkJLyogWFhYIHJlc3RvcmUgaXMgdW5hYmxlIHRvIHJlc3RvcmUgZHVtcHMg dGhhdCANCisgCQkJICAgd2VyZSBjcmVhdGVkICB3aXRoIGEgYmxvY2tzaXpl IGxhcmdlciB0aGFuIDMySy4NCisgCQkJICAgUG9zc2libHkgYnVnIGluIHRo ZSBzY3NpIHRhcGUgZHJpdmVyLiBBS0wgKi8NCisgCQkJaWYgKCBudHJlYyA+ IDMyICkgew0KKyAJCQkJbXNnKCJwbGVhc2UgY2hvb3NlIGEgYmxvY2tzaXpl IDw9IDMyXG4iKTsNCisgCQkJCWV4aXQoWF9BQk9SVCk7DQorIAkJCX0NCiAg CQkJYnJlYWs7DQogIA0KICAJCWNhc2UgJ0InOgkJLyogYmxvY2tzIHBlciBv dXRwdXQgZmlsZSAqLw0KKioqKioqKioqKioqKioqDQoqKiogNDQwLDQ0NSAq KioqDQotLS0gNDQ3LDQ1MyAtLS0tDQogIAkJKHZvaWQpZHVtcGlubyhkcCwg aW5vKTsNCiAgCX0NCiAgDQorIAkodm9pZCl0aW1lKCh0aW1lX3QgKikmKHRl bmRfd3JpdGluZykpOwkJLyogQUtMIGVuZCB0aW1lICovDQogIAlzcGNsLmNf dHlwZSA9IFRTX0VORDsNCiAgCWZvciAoaSA9IDA7IGkgPCBudHJlYzsgaSsr KQ0KICAJCXdyaXRlaGVhZGVyKG1heGlubyAtIDEpOw0KKioqKioqKioqKioq KioqDQoqKiogNDQ4LDQ1MyAqKioqDQotLS0gNDU2LDQ3MSAtLS0tDQogIAll bHNlDQogIAkJbXNnKCJEVU1QOiAlbGQgdGFwZSBibG9ja3Mgb24gJWQgdm9s dW1lcyhzKVxuIiwNCiAgCQkgICAgc3BjbC5jX3RhcGVhLCBzcGNsLmNfdm9s dW1lKTsNCisgDQorIAkvKiBBS0w6IHJlcG9ydCBkdW1wIHBlcmZvcm1hbmNl LCBhdm9pZCBkaXZpc2lvbiB0aHJvdWdoIHplcm8gKi8NCisgCWlmKHRlbmRf d3JpdGluZy10c3RhcnRfd3JpdGluZyA9PSAwKQ0KKyAJCW1zZygiRFVNUDog ZmluaXNoZWQgaW4gJWQgc2Vjb25kc1xuIiwNCisgCQkJdGVuZF93cml0aW5n LXRzdGFydF93cml0aW5nKTsNCisgCWVsc2UNCisgCQltc2coIkRVTVA6IGZp bmlzaGVkIGluICVkIHNlY29uZHMsIHRocm91Z2hwdXQgJWQgS0J5dGVzL3Nl Y1xuIiwNCisgCQkJdGVuZF93cml0aW5nLXRzdGFydF93cml0aW5nLA0KKyAJ CQlzcGNsLmNfdGFwZWEvKHRlbmRfd3JpdGluZy10c3RhcnRfd3JpdGluZykp Ow0KKyANCiAgCXB1dGR1bXB0aW1lKCk7DQogIAl0cmV3aW5kKCk7DQogIAli cm9hZGNhc3QoIkRVTVAgSVMgRE9ORSFcN1w3XG4iKTsNCioqKiBkdW1wLmgu b3JpZwlTdW4gTm92IDEyIDEzOjQxOjQzIDE5OTUNCi0tLSBkdW1wLmgJU3Vu IE5vdiAxMiAxMzo0NDoxOSAxOTk1DQoqKioqKioqKioqKioqKioNCioqKiA3 OSw4NCAqKioqDQotLS0gNzksODUgLS0tLQ0KICBpbnQJYmxvY2tzd3JpdHRl bjsJLyogbnVtYmVyIG9mIGJsb2NrcyB3cml0dGVuIG9uIGN1cnJlbnQgdGFw ZSAqLw0KICBpbnQJdGFwZW5vOwkJLyogY3VycmVudCB0YXBlIG51bWJlciAq Lw0KICB0aW1lX3QJdHN0YXJ0X3dyaXRpbmc7CS8qIHdoZW4gc3RhcnRlZCB3 cml0aW5nIHRoZSBmaXJzdCB0YXBlIGJsb2NrICovDQorIHRpbWVfdAl0ZW5k X3dyaXRpbmc7CS8qIGFmdGVyIHdyaXRpbmcgdGhlIGxhc3QgdGFwZSBibG9j ayBBS0wgKi8NCiAgc3RydWN0CWZzICpzYmxvY2s7CS8qIHRoZSBmaWxlIHN5 c3RlbSBzdXBlciBibG9jayAqLw0KICBjaGFyCXNibG9ja19idWZbTUFYQlNJ WkVdOw0KICBsb25nCWRldl9ic2l6ZTsJLyogYmxvY2sgc2l6ZSBvZiB1bmRl cmx5aW5nIGRpc2sgZGV2aWNlICovDQoqKiogZHVtcC44Lm9yaWcJU3VuIE5v diAxMiAxMzo0MTo0MyAxOTk1DQotLS0gZHVtcC44CVN1biBOb3YgMTIgMTM6 NDQ6MTkgMTk5NQ0KKioqKioqKioqKioqKioqDQoqKiogMTAyLDEwOCAqKioq DQogIC5BciBmaWxlDQogIG1heSBiZSBhIHNwZWNpYWwgZGV2aWNlIGZpbGUN CiAgbGlrZQ0KISAuUGEgL2Rldi9ybXQxMg0KICAoYSB0YXBlIGRyaXZlKSwN CiAgLlBhIC9kZXYvcnNkMWMNCiAgKGEgZGlzayBkcml2ZSksDQotLS0gMTAy LDEwOCAtLS0tDQogIC5BciBmaWxlDQogIG1heSBiZSBhIHNwZWNpYWwgZGV2 aWNlIGZpbGUNCiAgbGlrZQ0KISAuUGEgL2Rldi9yc3QwDQogIChhIHRhcGUg ZHJpdmUpLA0KICAuUGEgL2Rldi9yc2QxYw0KICAoYSBkaXNrIGRyaXZlKSwN CioqKioqKioqKioqKioqKg0KKioqIDI1NiwyNjIgKioqKg0KICAuSXQNCiAg QWx3YXlzIHN0YXJ0IHdpdGggYSBsZXZlbCAwIGJhY2t1cCwgZm9yIGV4YW1w bGU6DQogIC5CZCAtbGl0ZXJhbCAtb2Zmc2V0IGluZGVudA0KISAvc2Jpbi9k dW1wIDB1ZiAvZGV2L25yc3QxIC91c3Ivc3JjDQogIC5FZA0KICAuUHANCiAg VGhpcyBzaG91bGQgYmUgZG9uZSBhdCBzZXQgaW50ZXJ2YWxzLCBzYXkgb25j ZSBhIG1vbnRoIG9yIG9uY2UgZXZlcnkgdHdvIG1vbnRocywNCi0tLSAyNTYs MjYyIC0tLS0NCiAgLkl0DQogIEFsd2F5cyBzdGFydCB3aXRoIGEgbGV2ZWwg MCBiYWNrdXAsIGZvciBleGFtcGxlOg0KICAuQmQgLWxpdGVyYWwgLW9mZnNl dCBpbmRlbnQNCiEgL3NiaW4vZHVtcCAwdWYgL2Rldi9ucnN0MCAvdXNyL3Ny Yw0KICAuRWQNCiAgLlBwDQogIFRoaXMgc2hvdWxkIGJlIGRvbmUgYXQgc2V0 IGludGVydmFscywgc2F5IG9uY2UgYSBtb250aCBvciBvbmNlIGV2ZXJ5IHR3 byBtb250aHMsDQoqKioqKioqKioqKioqKioNCioqKiAyODIsMjg4ICoqKioN CiAgcm90YXRlZCBvdXQgb2YgdGhlIGR1bXAgY3ljbGUgYW5kIGZyZXNoIHRh cGVzIGJyb3VnaHQgaW4uDQogIC5TaCBGSUxFUw0KICAuQmwgLXRhZyAtd2lk dGggL2V0Yy9kdW1wZGF0ZXMgLWNvbXBhY3QNCiEgLkl0IFBhIC9kZXYvcm10 OA0KICBkZWZhdWx0IHRhcGUgdW5pdCB0byBkdW1wIHRvDQogIC5JdCBQYSAv ZXRjL2R1bXBkYXRlcw0KICBkdW1wIGRhdGUgcmVjb3Jkcw0KLS0tIDI4Miwy ODggLS0tLQ0KICByb3RhdGVkIG91dCBvZiB0aGUgZHVtcCBjeWNsZSBhbmQg ZnJlc2ggdGFwZXMgYnJvdWdodCBpbi4NCiAgLlNoIEZJTEVTDQogIC5CbCAt dGFnIC13aWR0aCAvZXRjL2R1bXBkYXRlcyAtY29tcGFjdA0KISAuSXQgUGEg L2Rldi9yc3QwDQogIGRlZmF1bHQgdGFwZSB1bml0IHRvIGR1bXAgdG8NCiAg Lkl0IFBhIC9ldGMvZHVtcGRhdGVzDQogIGR1bXAgZGF0ZSByZWNvcmRzDQoq KioqKioqKioqKioqKioNCioqKiAzMTEsMzE2ICoqKioNCi0tLSAzMTEsMzIw IC0tLS0NCiAgcmVlbHMgYWxyZWFkeSB3cml0dGVuIGp1c3QgaGFuZyBhcm91 bmQgdW50aWwgdGhlIGVudGlyZSB0YXBlDQogIGlzIHdyaXR0ZW4uDQogIC5Q cA0KKyByZXN0b3JlKDgpIGlzIGN1cnJlbnRseSB1bmFibGUgdG8gcmVzdG9y ZSBkdW1wcyB0aGF0IHdlcmUgY3JlYXRlZA0KKyB3aXRoIGEgYmxvY2tzaXpl IGxhcmdlciB0aGFuIDMyLiBXb3JrYXJvdW5kIGZvciBzYWZldHkgcmVhc29u czogDQorIGR1bXAgYWJvcnRzIHdpdGggYSB3YXJuaW5nIG1lc3NhZ2Ugd2hl biBjaG9vc2luZyBhIGJsb2Nrc2l6ZSA+IDMyLg0KKyAuUHANCiAgLk5tIER1 bXANCiAgd2l0aCB0aGUNCiAgLkNtIFcNCioqKioqKioqKioqKioqKg0KKioq IDMzNCwzMzYgKioqKg0KLS0tIDMzOCwzNTAgLS0tLQ0KICBBDQogIC5ObSBk dW1wDQogIGNvbW1hbmQgYXBwZWFyZWQgaW4gVmVyc2lvbiA2IEFUJlQgVU5J WC4NCisgLlBwDQorIEFkZGl0aW9uYWwgZHVtcCBtZXNzYWdlIChzaW1pbGFy IHRvIFNvbGFyaXMgMikgDQorIGJ5IEFuZHJlYXMgS2xlbW0gPGFuZHJlYXNA a25vYmVsLmd1bi5kZT4gcmVwb3J0aW5nIA0KKyAuTm0gYmFja3VwIHRpbWUN CisgaW4gc2Vjb25kcyBhbmQNCisgLk5tIHdyaXRlIHBlcmZvcm1hbmNlIA0K KyBpbiBLYnl0ZXMgcGVyIHNlY29uZC4gQ2hhbmdlZCBkZWZhdWx0IGR1bXAg ZGV2aWNlIGZyb20NCisgdGhlIG9sZCBmYXNoaW9uZWQgcm10OCBkZXZpY2Ug dG8gL2Rldi9yc3QwIChzbyBpdCdzIHRoZSBzYW1lDQorIGFzIHVzZWQgYnkg dGFyKS4NCisgQXBwZWFyZWQgZmlyc3QgaW4gRnJlZUJTRCAyLjIuDQoqKiog cGF0aG5hbWVzLmgub3JpZwlTdW4gTm92IDEyIDEzOjQxOjQzIDE5OTUNCi0t LSBwYXRobmFtZXMuaAlTdW4gTm92IDEyIDEzOjQ0OjE5IDE5OTUNCioqKioq KioqKioqKioqKg0KKioqIDM1LDQxICoqKioNCiAgDQogICNpbmNsdWRlIDxw YXRocy5oPg0KICANCiEgI2RlZmluZQlfUEFUSF9ERUZUQVBFCSIvZGV2L3Jt dDgiDQogICNkZWZpbmUJX1BBVEhfRFRNUAkiL2V0Yy9kdG1wIg0KICAjZGVm aW5lCV9QQVRIX0RVTVBEQVRFUwkiL2V0Yy9kdW1wZGF0ZXMiDQogICNkZWZp bmUJX1BBVEhfTE9DSwkiL3RtcC9kdW1wbG9ja1hYWFhYWCINCi0tLSAzNSw0 MSAtLS0tDQogIA0KICAjaW5jbHVkZSA8cGF0aHMuaD4NCiAgDQohICNkZWZp bmUJX1BBVEhfREVGVEFQRQkiL2Rldi9yc3QwIgkvKiBBS0wgKi8NCiAgI2Rl ZmluZQlfUEFUSF9EVE1QCSIvZXRjL2R0bXAiDQogICNkZWZpbmUJX1BBVEhf RFVNUERBVEVTCSIvZXRjL2R1bXBkYXRlcyINCiAgI2RlZmluZQlfUEFUSF9M T0NLCSIvdG1wL2R1bXBsb2NrWFhYWFhYIg0K --0-895630724-816182877=:4791-- From owner-freebsd-current Sun Nov 12 05:51:09 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA08029 for current-outgoing; Sun, 12 Nov 1995 05:51:09 -0800 Received: from hda.com (hda.com [199.232.40.182]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA08024 for ; Sun, 12 Nov 1995 05:51:04 -0800 Received: (from dufault@localhost) by hda.com (8.6.11/8.6.9) id IAA00279 for current@freebsd.org; Sun, 12 Nov 1995 08:50:58 -0500 From: Peter Dufault Message-Id: <199511121350.IAA00279@hda.com> Subject: Re: ISP state their FreeBSD concerns To: current@freebsd.org Date: Sun, 12 Nov 1995 08:50:57 -0500 (EST) In-Reply-To: from "owner-freebsd-current@freebsd.org" at Nov 11, 95 09:07:00 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 713 Sender: owner-current@freebsd.org Precedence: bulk > > 1. A concern that FreeBSD tends to "bind" for brief periods when > loaded... Can this is an IDE issue? I never saw anything like this until I configured an IDE mail server. That system pauses for seconds sometimes, and then continues. This is running -stable, syscons only (no X), no messages logged, etc. The echo stops going to the display, the ethernet activity is stopped, all in all it seems to be locked up for three or four seconds. We have three SCSI only systems and haven't ever seen this, and one IDE system that pauses. -- Peter Dufault Real Time Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 dufault@hda.com Fax: 508 433 5267 From owner-freebsd-current Sun Nov 12 05:55:12 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA08136 for current-outgoing; Sun, 12 Nov 1995 05:55:12 -0800 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA08130 for ; Sun, 12 Nov 1995 05:55:06 -0800 Received: from grumble.grondar.za (grumble.grondar.za [196.7.18.130]) by grunt.grondar.za (8.6.12/8.6.9) with ESMTP id PAA06217 for ; Sun, 12 Nov 1995 15:54:47 +0200 Received: from localhost (localhost [127.0.0.1]) by grumble.grondar.za (8.6.12/8.6.9) with SMTP id PAA01842 for ; Sun, 12 Nov 1995 15:54:47 +0200 Message-Id: <199511121354.PAA01842@grumble.grondar.za> X-Authentication-Warning: grumble.grondar.za: Host localhost didn't use HELO protocol To: current@freebsd.org Subject: Dual-personality crypt(3)!! Date: Sun, 12 Nov 1995 15:54:46 +0200 From: Mark Murray Sender: owner-current@freebsd.org Precedence: bulk Hi What do you think? I have modified the DES crypt(3) to do an MD5 (exportable-style "encryption" if the first three characters are "$1$". (Someone (PHK?) gave me the idea _ages_ ago.) This will allow folks to upgrade their machines to DES encryption without having to fix all the user passwords in master.passwd. If you want to test it - I'll give you a copy. I am testing it myself, and will commit it in a day or two if no-one objects? M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grumble.grondar.za for PGP key From owner-freebsd-current Sun Nov 12 06:39:18 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA08739 for current-outgoing; Sun, 12 Nov 1995 06:39:18 -0800 Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.20.4]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA08734 for ; Sun, 12 Nov 1995 06:39:16 -0800 Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id IAA26217; Sun, 12 Nov 1995 08:38:01 -0600 From: Joe Greco Message-Id: <199511121438.IAA26217@brasil.moneng.mei.com> Subject: Re: Dual-personality crypt(3)!! To: mark@grondar.za (Mark Murray) Date: Sun, 12 Nov 1995 08:37:59 -0600 (CST) Cc: current@freebsd.org In-Reply-To: <199511121354.PAA01842@grumble.grondar.za> from "Mark Murray" at Nov 12, 95 03:54:46 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@freebsd.org Precedence: bulk > Hi > > What do you think? > > I have modified the DES crypt(3) to do an MD5 (exportable-style > "encryption" if the first three characters are "$1$". (Someone (PHK?) > gave me the idea _ages_ ago.) This will allow folks to upgrade their > machines to DES encryption without having to fix all the user passwords > in master.passwd. > > If you want to test it - I'll give you a copy. I am testing it myself, > and will commit it in a day or two if no-one objects? This is very useful; I did it myself once. While it is just a little work to do, it would be oh-so-much-nicer to have it as part of the system by default.. ... JG From owner-freebsd-current Sun Nov 12 07:00:17 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA10174 for current-outgoing; Sun, 12 Nov 1995 07:00:17 -0800 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA10165 for ; Sun, 12 Nov 1995 07:00:13 -0800 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id HAA02148; Sun, 12 Nov 1995 07:00:12 -0800 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id GAA02175; Sun, 12 Nov 1995 06:59:43 -0800 Message-Id: <199511121459.GAA02175@corbin.Root.COM> To: Mark Murray cc: current@freebsd.org Subject: Re: Dual-personality crypt(3)!! In-reply-to: Your message of "Sun, 12 Nov 95 15:54:46 +0200." <199511121354.PAA01842@grumble.grondar.za> From: David Greenman Reply-To: davidg@Root.COM Date: Sun, 12 Nov 1995 06:59:43 -0800 Sender: owner-current@freebsd.org Precedence: bulk >What do you think? > >I have modified the DES crypt(3) to do an MD5 (exportable-style >"encryption" if the first three characters are "$1$". (Someone (PHK?) >gave me the idea _ages_ ago.) This will allow folks to upgrade their >machines to DES encryption without having to fix all the user passwords >in master.passwd. > >If you want to test it - I'll give you a copy. I am testing it myself, >and will commit it in a day or two if no-one objects? Hmmm... what if my DES password legitimately starts with "$1$"? Wouldn't it be better to just try the DES password and if that fails (doesn't match), then try using MD5? -DG From owner-freebsd-current Sun Nov 12 07:07:29 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA10486 for current-outgoing; Sun, 12 Nov 1995 07:07:29 -0800 Received: from asstdc.scgt.oz.au (root@asstdc.scgt.oz.au [202.14.234.65]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA10481 for ; Sun, 12 Nov 1995 07:07:24 -0800 Received: (from imb@localhost) by asstdc.scgt.oz.au (8.6.12/BSD-4.4) id CAA12014 for current@freebsd.org; Mon, 13 Nov 1995 02:07:19 +1100 From: michael butler Message-Id: <199511121507.CAA12014@asstdc.scgt.oz.au> Subject: calcru: negative time: %qd usec To: current@freebsd.org Date: Mon, 13 Nov 1995 02:07:17 +1100 (EST) X-Mailer: ELM [version 2.4 PL24beta] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 222 Sender: owner-current@freebsd.org Precedence: bulk What causes "calcru: negative time: %qd usec" to appear all over the console. I'm running -current sup'd today on a 486DX2/66. I know it comes from ../sys/kern/microtime.as but did something change to break it ? michael From owner-freebsd-current Sun Nov 12 07:11:06 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA10726 for current-outgoing; Sun, 12 Nov 1995 07:11:06 -0800 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA10720 for ; Sun, 12 Nov 1995 07:10:58 -0800 Received: from grumble.grondar.za (grumble.grondar.za [196.7.18.130]) by grunt.grondar.za (8.6.12/8.6.9) with ESMTP id RAA06293; Sun, 12 Nov 1995 17:08:07 +0200 Received: from localhost (localhost [127.0.0.1]) by grumble.grondar.za (8.6.12/8.6.9) with SMTP id RAA02276; Sun, 12 Nov 1995 17:08:06 +0200 Message-Id: <199511121508.RAA02276@grumble.grondar.za> X-Authentication-Warning: grumble.grondar.za: Host localhost didn't use HELO protocol To: davidg@Root.COM cc: current@freebsd.org Subject: Re: Dual-personality crypt(3)!! Date: Sun, 12 Nov 1995 17:08:05 +0200 From: Mark Murray Sender: owner-current@freebsd.org Precedence: bulk > Hmmm... what if my DES password legitimately starts with "$1$"? Wouldn't it > be better to just try the DES password and if that fails (doesn't match), > then try using MD5? Naah. once your password is DES-crypted it is a 13-char string from the set [./A-Za-z0-9]. This $1$ `marker' is a useful way of determining that the password was crypted with PHK's MD5 routine. M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grumble.grondar.za for PGP key From owner-freebsd-current Sun Nov 12 07:32:05 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA11199 for current-outgoing; Sun, 12 Nov 1995 07:32:05 -0800 Received: (from jkh@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA11191 for current; Sun, 12 Nov 1995 07:32:03 -0800 Date: Sun, 12 Nov 1995 07:32:03 -0800 From: "Jordan K. Hubbard" Message-Id: <199511121532.HAA11191@freefall.freebsd.org> To: current Subject: edit-pr - no man page? Sender: owner-current@FreeBSD.org Precedence: bulk Also, is there any synopsis of which "states" are valid? I'd like to take some of the open PRs who's status I call into question and change them from open to "pending" or "examined" or something that essentially lets me fill in a comment field which both shows that I've examined the PR and have some comments and gets those same comments sent to the author. Thanks. Jordan From owner-freebsd-current Sun Nov 12 07:40:12 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA11482 for current-outgoing; Sun, 12 Nov 1995 07:40:12 -0800 Received: from asstdc.scgt.oz.au (root@asstdc.scgt.oz.au [202.14.234.65]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA11477 for ; Sun, 12 Nov 1995 07:40:07 -0800 Received: (from imb@localhost) by asstdc.scgt.oz.au (8.6.12/BSD-4.4) id CAA12498 for current@freebsd.org; Mon, 13 Nov 1995 02:40:04 +1100 From: michael butler Message-Id: <199511121540.CAA12498@asstdc.scgt.oz.au> Subject: Re: calcru: negative time: %qd usec To: current@freebsd.org Date: Mon, 13 Nov 1995 02:40:04 +1100 (EST) X-Mailer: ELM [version 2.4 PL24beta] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 272 Sender: owner-current@freebsd.org Precedence: bulk I wrote: > What causes "calcru: negative time: %qd usec" to appear all over the > console. I'm running -current sup'd today on a 486DX2/66. I know it comes > from ../sys/kern/microtime.as .. Sorry .. it's from /sys/kern/kern_resource.c (~line 493) .. , michael From owner-freebsd-current Sun Nov 12 07:59:37 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA11969 for current-outgoing; Sun, 12 Nov 1995 07:59:37 -0800 Received: from kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA11964 for ; Sun, 12 Nov 1995 07:59:33 -0800 Received: from venus.mcs.com (root@Venus.mcs.com [192.160.127.92]) by kitten.mcs.com (8.6.10/8.6.9) with SMTP id JAA00524 for ; Sun, 12 Nov 1995 09:59:27 -0600 Received: by venus.mcs.com (/\==/\ Smail3.1.28.1 #28.5) id ; Sun, 12 Nov 95 09:59 CST Message-Id: Subject: Re: ISP state their FreeBSD concerns To: current@freebsd.org Date: Sun, 12 Nov 1995 09:59:26 -0600 (CST) From: "Karl Denninger, MCSNet" In-Reply-To: from "owner-freebsd-current@freebsd.org" at Nov 11, 95 09:07:00 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 5669 Sender: owner-current@freebsd.org Precedence: bulk > I have been having a lot of contact with various local ISPs (we seem > to have an excessive number of these guys in this area). All of them > are aware of FreeBSD, but almost universally there is a frame of mind > that says FreeBSD should be avoided. Hi guys. > Naturally, I quizzed them as to what brought them to that conclusion if the > reason wasn't something we can't fix like "Alphas rule, Intels SUCK", etc. > In general each had three to five comments/concerns that were at the > heart of their negative view. I'll comment on these things. > These are generally ordered with the highest concerns first: > > 1. A concern that FreeBSD tends to "bind" for brief periods when > loaded. Here is how it was described to me: You will be doing > something (like skimming news articles in trn or tin) that is > hitting the hard disk perhaps once every five seconds and you > are getting instant response. This is baloney. We run a *NEWS SERVER* here on FreeBSD, and I also have a general public machine online. Someone's got a bad, bad configuration problem if they're seeing this. > 2. A concern that disk I/O on large (4GB or bigger) hard disks or > large numbers of hard disks is not reliable, particularly on > systems with more than 32MB of RAM. If you use EISA or adapters (recommended anyway) this is a non-issue. The 1742A is completely stable under this environment. I understand PCI is as well. There *WAS* a bug in the dump utility that made it impossible to dump filesystems over 4G, but that has been corrected. Bad disks are bad disks, and will fail in mysterious ways on ANY OS. I've seen this "failure" on BSDI -- there are known bad disk drives which cause problems. Micropolis is particularly known for this. > 3. A concern about things in FreeBSD that impact INN performance, or > force them to compile INN special for FreeBSD. They are talking > about MMAP support. Don't use MMAP, and you'll be fine. BTW, FreeBSD-STABLE does run ok with MMAP defined, but it is *slower* with it on than off over time as RAM gets fragmented. > 4. A concern about problems related to filesystem stacks, such as > ISO9660 and DOS. (They may be talking about Samba, and not > the actual mounting of DOS filesystems.) No data one way or the other. I don't do this kind of thing here. > 5. Not at all obvious what system resources to increase for > large and/or heavily loaded systems, and what ratios of > parameter settings are best. This is a general BSD thing - either you understand the BSD system or you do not. Truth is, there isn't much (other than Mbuf clusters) that you usually want to tweak. We have a set of override parameters we use here for heavily loaded systems, and they are nearly identical for BSDI and FreeBSD. > 6. Multi-port serial support and even single-port serial support. No data. > 7. Concern that there is still a lot of "tinkering under the hood" in > FreeBSD in areas that aren't broadening the system as a whole. Huh? > 8. File creation (particularly directories) appears to be slow compared > to other BSD-like systems. They say the stats for INN and CNEWS > for articles processed per second are quite a bit lower than that > on some "other" systems. Wait until you try to actually *use* those other systems. FreeBSD holds up under a heavy multiprocess load MUCH better than BSDI. > 9. A concern that man pages don't stay formatted. They would rather > chew disk space than have newbies constantly reformatting 'ls' and > 'cat'. No big deal one way or the other; this is quibbling with ants. > 10. More support for high-end hardware. I put this last because > it is one of the harder things for FreeBSD to do much about > since hardware vendors don't always want to tell us the tricks > to making their hardware work. They aren't just talking about > plug-in cards. These guys are interested in multiple-processors, > things that make load scale nicely, extremely fast interconnects > between systems, shared disk farms, Video-delivery bandwidths, etc. > Having Support the latest whizzo video cards aren't a big deal to > them, but support for disk controllers, CPUs and network interfaces > are. This makes their priorities different in general from those > that the average FreeBSD user probably has. Most of us aren't > ready to pop down and buy a four-processor P6 system with 256Meg > of RAM and three 100Mbit network interfaces, but these guys are. Yes. That I agree with. The only other issue we have here is the nasty NFS-write problem that makes shared access to remote resources tricky at best. If *THAT* was fixed we would be running FreeBSD exclusively here. I've been using FreeBSD exclusively for news service for quite a while (some clients use NFS, others NNTP to read) and its been fine. What we have a problem with is using it for our web server and general user system farm; the small NFS writes that the httpds do to the log disks cause system lockups and hundreds of processes in a hung state. The problem is understood, but there is no immediate path to a fix from what I've been told. We also can't have general user systems that do this -- people *WILL* exploit that to crash the network once they know about it. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity Modem: [+1 312 248-0900] | (shell, PPP, SLIP, leased) in Chicagoland Voice: [+1 312 803-MCS1] | 7 Chicagoland POPs, ISDN, 28.8, much more Fax: [+1 312 248-9865] | Email to "info@mcs.net" WWW: http://www.mcs.net ISDN - Get it here TODAY! | Home of Chicago's *Three STAR A* Clarinet feed! From owner-freebsd-current Sun Nov 12 08:01:14 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA12052 for current-outgoing; Sun, 12 Nov 1995 08:01:14 -0800 Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.20.4]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA12043 for ; Sun, 12 Nov 1995 08:01:08 -0800 Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id KAA26310; Sun, 12 Nov 1995 10:00:35 -0600 From: Joe Greco Message-Id: <199511121600.KAA26310@brasil.moneng.mei.com> Subject: Re: ISP state their FreeBSD concerns To: dyson@freefall.freebsd.org (John Dyson) Date: Sun, 12 Nov 1995 10:00:34 -0600 (CST) Cc: current@freebsd.org In-Reply-To: <199511120557.VAA24917@freefall.freebsd.org> from "John Dyson" at Nov 11, 95 09:57:36 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@freebsd.org Precedence: bulk > > 8. File creation (particularly directories) appears to be slow compared > > to other BSD-like systems. They say the stats for INN and CNEWS > > for articles processed per second are quite a bit lower than that > > on some "other" systems. They say that file deletion seems to be > > a bit slower than BSDI, but not by much. I think they are talking > > 2.0.5 on this item, although one ISP was experimenting with 1026 SNAP. > > I am working on this stuff right now. Give me benchmarks!!!! I'll > do what I can. :-( I have a little suite of programs I use for performance testing. The tests are absolutely slanted towards news server type applications. The one in particular I will quote is "small-file-write.c", a program that writes 10000 files in subdirectories, creating the subdirectories if needed (much like a news server would do). So the "first run" numbers include the time needed to make dirs: Slowaris 5.4 - SS10/30 - 64MB RAM (SCSI II, reasonable drive) 10000 files in 332 seconds - first run 10000 files in 20 !!! seconds - second run Slowaris 5.4 - SS10/30 - 64MB RAM (SCSI II, Barracuda drive) 10000 files in 249 seconds - first run 10000 files in 13 !!! seconds - second run Slowaris 5.4 - SS10/30 - 64MB RAM - PrestoServe (SCSI II, Barracuda drive) 10000 files in 76 seconds - first run 10000 files in 12 seconds - second run FreeBSD 2.0.5R - ASUS SP3G AMD 486DX2/66 + NCR810 - 8MB (SCSI II, reasonable drive) 10000 files in 620 seconds - first run :-( :-( 10000 files in 310 seconds - second run :-( :-( :-( !! FreeBSD 1026-SNAP - ASUS SP3G AMD 486DX4/100 + NCR810 - 48MB (SCSI II, SLOW drive, fs mounted -o async) 10000 files in 569 seconds - first run :-( :-( 10000 files in 207 seconds - second run :-( :-( :-( !! Now, I can't swear that by tweaking newfs options, etc., it isn't able to improve this - I simply haven't tried because I didn't realize until just now how abominable this performance was. Does anybody have advice about what might be tweakable to help this? This is really sad. The program itself: #include #include #include #include #include #include char *pathn(int x) { static char *buffer[1024]; int d1, d2, d3; d1 = x; x /= 10; d1 -= x * 10; d2 = x; x /= 10; d2 -= x * 10; d3 = x; x /= 10; d3 -= x * 10; sprintf(buffer, "%d/%d/%d/%d", d1, d2, d3, x); return(buffer); } int writef(char *name) { int fd; char *ptr; if ((fd = open(name, O_CREAT|O_RDWR, 0644)) < 0) { if (errno == ENOENT) { ptr = name; while (ptr = strchr(ptr, '/')) { *ptr = '\0'; if (mkdir(name, 0755) < 0) { if (errno != EEXIST) { perror(name); exit(1); } } *ptr++ = '/'; } return(writef(name)); } else { perror(name); exit(1); } } else { close(fd); } } int main() { int i, n; time_t tm = time(NULL); n = 10000; for (i = 0; i < n; i++) { writef(pathn(i)); if (! (i % 100)) { printf("%d..", i); fflush(stdout); } } printf("\n%d files in %d seconds\n", n, time(NULL) - tm); exit(0); } From owner-freebsd-current Sun Nov 12 08:14:04 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA12578 for current-outgoing; Sun, 12 Nov 1995 08:14:04 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA12460 for ; Sun, 12 Nov 1995 08:10:47 -0800 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id RAA12189 for ; Sun, 12 Nov 1995 17:05:10 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id RAA06917 for freebsd-current@FreeBSD.org; Sun, 12 Nov 1995 17:05:10 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id PAA20456 for freebsd-current@FreeBSD.org; Sun, 12 Nov 1995 15:47:59 +0100 From: J Wunsch Message-Id: <199511121447.PAA20456@uriah.heep.sax.de> Subject: /usr/share/man/cat* To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sun, 12 Nov 1995 15:47:59 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 391 Sender: owner-current@FreeBSD.org Precedence: bulk I notice that these directories do exist after the installing a recent snapshot. Fine. The question is, i remember some file /sys/compile/.keep_me. Perhaps this would have been an easier solution for the cat directories, too? -- 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-current Sun Nov 12 08:51:26 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA15088 for current-outgoing; Sun, 12 Nov 1995 08:51:26 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA15083 for ; Sun, 12 Nov 1995 08:51:19 -0800 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id RAA12818 for ; Sun, 12 Nov 1995 17:51:11 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id RAA07243 for freebsd-current@FreeBSD.org; Sun, 12 Nov 1995 17:51:11 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id RAA21559 for freebsd-current@FreeBSD.org; Sun, 12 Nov 1995 17:29:32 +0100 From: J Wunsch Message-Id: <199511121629.RAA21559@uriah.heep.sax.de> Subject: Re: low-mem machines awfully slow now To: freebsd-current@FreeBSD.org Date: Sun, 12 Nov 1995 17:29:31 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <15344.816177138@time.cdrom.com> from "Jordan K. Hubbard" at Nov 12, 95 03:52:18 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 792 Sender: owner-current@FreeBSD.org Precedence: bulk As Jordan K. Hubbard wrote: > > Hmmm. Any swap space configured? One recent change I made was to do Of course. I accepted the default configuration (A)utomatic in the label editor). I've noticed that it's just the crunched sysinstall binary. It's as slow as during installation also when running it in multi-user mode. I'm rather surprised, since i think most of its pages should remain in-core (in particular at installation time), and if not, should be backed to swap. But the disk LED never lit during these long pauses, so it wasn't grabbing a page from swap. I'm pretty sure this didn't happen in previous releases. -- 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-current Sun Nov 12 08:51:35 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA15107 for current-outgoing; Sun, 12 Nov 1995 08:51:35 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA15101 for ; Sun, 12 Nov 1995 08:51:30 -0800 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id RAA12826 for ; Sun, 12 Nov 1995 17:51:19 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id RAA07249 for current@freebsd.org; Sun, 12 Nov 1995 17:51:19 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id RAA21728 for current@freebsd.org; Sun, 12 Nov 1995 17:37:40 +0100 From: J Wunsch Message-Id: <199511121637.RAA21728@uriah.heep.sax.de> Subject: Re: Dual-personality crypt(3)!! To: current@freebsd.org Date: Sun, 12 Nov 1995 17:37:40 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199511121354.PAA01842@grumble.grondar.za> from "Mark Murray" at Nov 12, 95 03:54:46 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 502 Sender: owner-current@freebsd.org Precedence: bulk As Mark Murray wrote: > > This will allow folks to upgrade their ^^^^^^^ > machines to DES encryption without having to fix all the user passwords > in master.passwd. You wanna say: ``downgrade'' :-) Anyway, i like it. This would allow me to upgrade to MD5 some day without losing all my DES passwords. ;-) -- 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-current Sun Nov 12 09:00:06 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA15290 for current-outgoing; Sun, 12 Nov 1995 09:00:06 -0800 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA15278 for ; Sun, 12 Nov 1995 08:59:58 -0800 Received: from grumble.grondar.za (grumble.grondar.za [196.7.18.130]) by grunt.grondar.za (8.6.12/8.6.9) with ESMTP id SAA06437; Sun, 12 Nov 1995 18:59:46 +0200 Received: from localhost (localhost [127.0.0.1]) by grumble.grondar.za (8.6.12/8.6.9) with SMTP id SAA03128; Sun, 12 Nov 1995 18:59:44 +0200 Message-Id: <199511121659.SAA03128@grumble.grondar.za> X-Authentication-Warning: grumble.grondar.za: Host localhost didn't use HELO protocol To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) cc: current@freebsd.org Subject: Re: Dual-personality crypt(3)!! Date: Sun, 12 Nov 1995 18:59:43 +0200 From: Mark Murray Sender: owner-current@freebsd.org Precedence: bulk > As Mark Murray wrote: > > > > This will allow folks to upgrade their > ^^^^^^^ > > machines to DES encryption without having to fix all the user passwords > > in master.passwd. > > You wanna say: ``downgrade'' :-) Nyah nyah nyah... ;-) > Anyway, i like it. This would allow me to upgrade to MD5 some day > without losing all my DES passwords. ;-) Not without a bit of extra work. The default encryption when no salt is specified will be DES. This was designed as a convenience for those who have MD5 and want to go DES without irritating all their users. as folks change their passwords, they will be DES'ed. M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grumble.grondar.za for PGP key From owner-freebsd-current Sun Nov 12 09:13:51 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA15605 for current-outgoing; Sun, 12 Nov 1995 09:13:51 -0800 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA15600 for ; Sun, 12 Nov 1995 09:13:41 -0800 Received: from grumble.grondar.za (grumble.grondar.za [196.7.18.130]) by grunt.grondar.za (8.6.12/8.6.9) with ESMTP id TAA06463 for ; Sun, 12 Nov 1995 19:13:35 +0200 Received: from localhost (localhost [127.0.0.1]) by grumble.grondar.za (8.6.12/8.6.9) with SMTP id TAA03516 for ; Sun, 12 Nov 1995 19:13:34 +0200 Message-Id: <199511121713.TAA03516@grumble.grondar.za> X-Authentication-Warning: grumble.grondar.za: Host localhost didn't use HELO protocol to: current@freebsd.org Subject: Re: Dual-personality crypt(3)!! Date: Sun, 12 Nov 1995 19:13:33 +0200 From: Mark Murray Sender: owner-current@freebsd.org Precedence: bulk > What do you think? > > I have modified the DES crypt(3) to do an MD5 (exportable-style > "encryption" if the first three characters are "$1$". (Someone (PHK?) > gave me the idea _ages_ ago.) This will allow folks to upgrade their > machines to DES encryption without having to fix all the user passwords > in master.passwd. > > If you want to test it - I'll give you a copy. I am testing it myself, > and will commit it in a day or two if no-one objects? I have put a copy in freefall:~markm/libcrypt.tar.gz if anyone wants to take a look... M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grumble.grondar.za for PGP key From owner-freebsd-current Sun Nov 12 09:17:49 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA15737 for current-outgoing; Sun, 12 Nov 1995 09:17:49 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA15731 for ; Sun, 12 Nov 1995 09:17:45 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id EAA17041; Mon, 13 Nov 1995 04:17:27 +1100 Date: Mon, 13 Nov 1995 04:17:27 +1100 From: Bruce Evans Message-Id: <199511121717.EAA17041@godzilla.zeta.org.au> To: current@freebsd.org, imb@scgt.oz.au Subject: Re: calcru: negative time: %qd usec Sender: owner-current@freebsd.org Precedence: bulk >What causes "calcru: negative time: %qd usec" to appear all over the >console. I'm running -current sup'd today on a 486DX2/66. I know it comes It is caused by the clock running backwards. `%qd' is supposed to show how much the clock is wrong by, but the kernel printf doesn't support quads. >from ../sys/kern/microtime.as but did something change to break it ? The message comes from kern_resource.c. The bogus time [difference] probably comes from a bug in microtime(). Perhaps the 8254 counter is not being read correctly, or a time daemon is fiddling with the clock. You can delete the message without losing much (first change it to print the value as 2 longs). The negative times are now replaced by 0. In 2.0.5R, a negative time of -1 usec gave a resource usage of 2^32-1 usec. I wonder if this was responsible for the "freezes". The scheduler should give a very low priority to a process that has consumed 2^32-1 usec of time resources in a few usec of real time :-). Bruce From owner-freebsd-current Sun Nov 12 09:30:11 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA16201 for current-outgoing; Sun, 12 Nov 1995 09:30:11 -0800 Received: from asstdc.scgt.oz.au (root@asstdc.scgt.oz.au [202.14.234.65]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA16196 for ; Sun, 12 Nov 1995 09:30:07 -0800 Received: (from imb@localhost) by asstdc.scgt.oz.au (8.6.12/BSD-4.4) id EAA00906; Mon, 13 Nov 1995 04:29:53 +1100 From: michael butler Message-Id: <199511121729.EAA00906@asstdc.scgt.oz.au> Subject: Re: calcru: negative time: %qd usec To: bde@zeta.org.au (Bruce Evans) Date: Mon, 13 Nov 1995 04:29:50 +1100 (EST) Cc: current@freebsd.org In-Reply-To: <199511121717.EAA17041@godzilla.zeta.org.au> from "Bruce Evans" at Nov 13, 95 04:17:27 am X-Mailer: ELM [version 2.4 PL24beta] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 554 Sender: owner-current@freebsd.org Precedence: bulk > It is caused by the clock running backwards. That's cute :-) > The message comes from kern_resource.c. The bogus time [difference] > probably comes from a bug in microtime(). Perhaps the 8254 counter is > not being read correctly, or a time daemon is fiddling with the clock. I am running xntpd but, with the machine under load (e.g. make world), these messages appear at 5-10 second intervals even though there is no time "stepping" going on .. only adjtime to correct a ~13ppm drift with ~53ppm stability (steps are very infrequent), michael From owner-freebsd-current Sun Nov 12 09:35:03 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA16341 for current-outgoing; Sun, 12 Nov 1995 09:35:03 -0800 Received: from kryten.atinc.com (kryten.Atinc.COM [198.138.38.7]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA16318 ; Sun, 12 Nov 1995 09:34:57 -0800 Received: (jmb@localhost) by kryten.atinc.com (8.6.9/8.3) id MAA13334; Sun, 12 Nov 1995 12:25:30 -0500 Date: Sun, 12 Nov 1995 12:25:28 -0500 (EST) From: "Jonathan M. Bresler" Subject: Re: ISP state their FreeBSD concerns To: current@freebsd.org cc: freebsd-isp@freebsd.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk On Sat, 11 Nov 1995 owner-freebsd-current@freebsd.org wrote: > I have been having a lot of contact with various local ISPs (we seem > to have an excessive number of these guys in this area). All of them > are aware of FreeBSD, but almost universally there is a frame of mind > that says FreeBSD should be avoided. [disclaimers: i dont run an isp. i dont have a LARGE news system. i dont have lots of dialin users. ] these points|perceptions are important. XXX has evidently talked with a number of isp's and expended some effort to identify the characteristics of FreeBSD that isp's free are most lacking. let's call it a call-for-dialog. freebsd-isp@freebsd.org can provide the forum. from the initial post and the responses, i gather 0. more dialog between isp's and the freebsd development team. 1. there is a desperate need for additional documentation of the tutorial + example form 2. we need suggested configurations for specific tasks: news spool, dial-in box, web server.... 3. problem reports need to provide information on how to reproduce the problem. system configuration. system activity. log file output. 4. isp's need to be willing to test bug fixes Jonathan M. Bresler jmb@kryten.atinc.com | Analysis & Technology, Inc. FreeBSD Postmaster jmb@FreeBSD.Org | 2341 Jeff Davis Hwy play go. | Arlington, VA 22202 ride bike. hack FreeBSD.--ah the good life | 703-418-2800 x346 From owner-freebsd-current Sun Nov 12 09:56:48 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA16714 for current-outgoing; Sun, 12 Nov 1995 09:56:48 -0800 Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA16709 for ; Sun, 12 Nov 1995 09:56:44 -0800 Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id JAA17034; Sun, 12 Nov 1995 09:55:42 -0800 From: "Rodney W. Grimes" Message-Id: <199511121755.JAA17034@GndRsh.aac.dev.com> Subject: Re: /usr/share/man/cat* To: joerg_wunsch@uriah.heep.sax.de Date: Sun, 12 Nov 1995 09:55:42 -0800 (PST) Cc: freebsd-current@FreeBSD.org In-Reply-To: <199511121447.PAA20456@uriah.heep.sax.de> from "J Wunsch" at Nov 12, 95 03:47:59 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 571 Sender: owner-current@FreeBSD.org Precedence: bulk > > I notice that these directories do exist after the installing a recent > snapshot. Fine. > > The question is, i remember some file /sys/compile/.keep_me. Perhaps > this would have been an easier solution for the cat directories, too? The .keep_me file is to stop cvs co -P or cvs update -P from removing the compile directory from the source tree, the catman directories do not live in the source tree :-). -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Sun Nov 12 10:37:50 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA18491 for current-outgoing; Sun, 12 Nov 1995 10:37:50 -0800 Received: from localhost.lightside.com (user47.lightside.com [198.81.209.47]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA18484 ; Sun, 12 Nov 1995 10:37:44 -0800 Received: (from jehamby@localhost) by localhost.lightside.com (8.6.12/8.6.9) id KAA00453; Sun, 12 Nov 1995 10:39:36 -0800 Date: Sun, 12 Nov 1995 10:39:36 -0800 (PST) From: Jake Hamby X-Sender: jehamby@localhost To: Peter Dufault cc: current@freebsd.org, freebsd-isp@freebsd.org Subject: Re: ISP state their FreeBSD concerns In-Reply-To: <199511121350.IAA00279@hda.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk On Sun, 12 Nov 1995, Peter Dufault wrote: > > > > 1. A concern that FreeBSD tends to "bind" for brief periods when > > loaded... > > Can this is an IDE issue? I never saw anything like this until > I configured an IDE mail server. That system pauses for seconds > sometimes, and then continues. This is running -stable, syscons > only (no X), no messages logged, etc. The echo stops going to > the display, the ethernet activity is stopped, all in all it seems > to be locked up for three or four seconds. > > We have three SCSI only systems and haven't ever seen this, and > one IDE system that pauses. On my system at home (486DX4/100, 850MB Western Digital IDE, VLB IDE controller, 24MB RAM) the system does seem to freeze up for as much as 5 seconds when I start up a large process such as Netscape or cause one of the existing processes to greatly expand their RAM usage (for example, looking through the 1000 messages that sometimes accumulate in my INBOX using pine, or loading a large number of pictures into XV). I think it's a problem with the VM code swapping pages to disk, and the IDE driver using up a large percentage of CPU doing PIO transfers instead of DMA transfers that an EIDE driver (such as the one in Linux?) would be able to do. I know, I know, IDE sucks, but a large number of users (and hopefully, a very SMALL number of ISP's use it) and so any improvement to the IDE driver to add EIDE support, especially DMA transfers, would speed things up nicely. I know someone was working on this, has it made its way into -current yet? ------------------------------------------------------------------------------ Jake Hamby | E-Mail: jehamby@lightside.com Student, Cal Poly University, Pomona | System Administrator, JPL ------------------------------------------------------------------------------ From owner-freebsd-current Sun Nov 12 11:00:06 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA18866 for current-outgoing; Sun, 12 Nov 1995 11:00:06 -0800 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA18849 ; Sun, 12 Nov 1995 11:00:01 -0800 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id KAA16520; Sun, 12 Nov 1995 10:59:31 -0800 To: Jake Hamby cc: Peter Dufault , current@freebsd.org, freebsd-isp@freebsd.org Subject: Re: ISP state their FreeBSD concerns In-reply-to: Your message of "Sun, 12 Nov 1995 10:39:36 PST." Date: Sun, 12 Nov 1995 10:59:30 -0800 Message-ID: <16518.816202770@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org Precedence: bulk > On my system at home (486DX4/100, 850MB Western Digital IDE, VLB IDE > controller, 24MB RAM) the system does seem to freeze up for as much as 5 > seconds when I start up a large process such as Netscape or cause one of > the existing processes to greatly expand their RAM usage (for example, > looking through the 1000 messages that sometimes accumulate in my INBOX > using pine, or loading a large number of pictures into XV). I think it's Huh. Well, all I can say is that this definitely points at IDE because I can't reproduce it at all, and that includes starting the most bloated netscape v2.0b1 binaries, systems like KCL and other notorious memory hogs. I also know that our IDE driver isn't exactly likely to win land records for speed - it's one of those icky parts of the system that nobody really wanted to work on once it got to a state where it was fairly bulletproof. I also agree with Jake - if there's an ISP using IDE CDROM drives out there for anything then they should donate those drives to charity just as fast as they can rip them out of the machines and buy SCSI drives. I was helping an ISP recently who had several machines that I was horrified to learn had IDE drives in them. The systems were not performing very well under heavy load, and he called me in to try and figure out why. The very first thing I did was threaten to come back with a ball peen hammer and do extreme violence to any IDE drives I found lurking in any machines on the premises, and he hastily yanked them out (I'm not sure he knew whether or not I was joking, and frankly neither did I :-). Since then, his systems have been just champing along. He's very happy. Jordan From owner-freebsd-current Sun Nov 12 11:11:02 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA19273 for current-outgoing; Sun, 12 Nov 1995 11:11:02 -0800 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA19248 ; Sun, 12 Nov 1995 11:10:56 -0800 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id LAA16613; Sun, 12 Nov 1995 11:10:33 -0800 To: Jake Hamby , Peter Dufault , current@freebsd.org, freebsd-isp@freebsd.org Subject: Re: ISP state their FreeBSD concerns In-reply-to: Your message of "Sun, 12 Nov 1995 10:59:30 PST." <16518.816202770@time.cdrom.com> Date: Sun, 12 Nov 1995 11:10:33 -0800 Message-ID: <16610.816203433@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org Precedence: bulk > I also agree with Jake - if there's an ISP using IDE CDROM drives out ^^^^^ Argh! Disks I mean, disks! Sorry, I've been fooling with the IDE CDROM install for the last 24 hours, so I've got IDE CDROM drives on the brain! :-) Jordan From owner-freebsd-current Sun Nov 12 11:21:20 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA19464 for current-outgoing; Sun, 12 Nov 1995 11:21:20 -0800 Received: from user47.lightside.com (user39.lightside.com [198.81.209.39]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA19457 ; Sun, 12 Nov 1995 11:21:17 -0800 Received: (from jehamby@localhost) by user47.lightside.com (8.6.12/8.6.9) id LAA00584; Sun, 12 Nov 1995 11:23:12 -0800 Date: Sun, 12 Nov 1995 11:22:48 -0800 (PST) From: Jake Hamby To: "Jordan K. Hubbard" cc: Peter Dufault , current@freebsd.org, freebsd-isp@freebsd.org Subject: Re: ISP state their FreeBSD concerns In-Reply-To: <16610.816203433@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk On Sun, 12 Nov 1995, Jordan K. Hubbard wrote: > > I also agree with Jake - if there's an ISP using IDE CDROM drives out > ^^^^^ > Argh! Disks I mean, disks! > > Sorry, I've been fooling with the IDE CDROM install for the last > 24 hours, so I've got IDE CDROM drives on the brain! :-) > > Jordan Well, IDE CDROM's too! :-) Here's a question: I would really like to upgrade to SCSI, but the controller cards are so damn expensive! Are there any good VLB (I know, I wish I had a PCI motherboard, but VLB is what I've got) SCSI-2 controllers that don't cost $200 or more?? I hear Buslogic and Adaptec make decent VLB controllers, can anyone point me in the right direction for a company that sells good SCSI controllers at decent prices? Thanks! BTW, I bought one of those Iomega Zip drives a month ago, and they are really impressive! I flat-out refused to buy the parallel port version (a "standard", and I use the term loosely, even worse than IDE, IMO) so now I have this awesome removable 100MB disk system, and no SCSI controller to plug it into. So I did the next best thing and plugged it into my old 1990-vintage Amiga 500 (GVP Series II SCSI controller) and it's working great (sure faster than the old 50MB [not 500MB!] Quantum LPS that's also in there)! Just goes to show you how the benefits of SCSI can revitalize any old machine... ------------------------------------------------------------------------------ Jake Hamby | E-Mail: jehamby@lightside.com Student, Cal Poly University, Pomona | System Administrator, JPL ------------------------------------------------------------------------------ From owner-freebsd-current Sun Nov 12 11:24:27 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA19960 for current-outgoing; Sun, 12 Nov 1995 11:24:27 -0800 Received: from ast.com (irvine.ast.com [165.164.128.2]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id LAA19945 for ; Sun, 12 Nov 1995 11:24:24 -0800 Received: from fw.ast.com by ast.com with SMTP id AA15336 (5.67b/IDA-1.5 for ); Sun, 12 Nov 1995 11:25:42 -0800 Received: from nemesis by fw.ast.com with uucp (Smail3.1.29.1 #4) id m0tEhlt-000085C; Sun, 12 Nov 95 13:08 CST Received: by nemesis.lonestar.org (Smail3.1.27.1 #19) id m0tEhh1-000J05C; Sun, 12 Nov 95 13:03 WET Message-Id: Date: Sun, 12 Nov 95 13:03 WET To: jkh@time.cdrom.com, current@freebsd.org From: uhclem%nemesis@fw.ast.com (Frank Durda IV) Sent: Sun Nov 12 1995, 13:03:50 CST Subject: Re: ISP state their FreeBSD concerns Sender: owner-current@freebsd.org Precedence: bulk [0]First off, I really have to wonder why Frank Durda went to what was [0]obviously a considerable effort to be anonymous. The message had no [0]signature and has been sent with a "From" of -current. Uh, sorry it wasn't meant to be *that* way. I was playing with some options of xmail for re-routing replies and this was the result. I see I also botched the sig inclusion. Serves me right for composing at goofy hours of the night, but I got going and wanted to finish before the scribbled notes on resturant napkins became a useless jumble. I really felt that any discussion of this should be where it can be seen, rather than just between select flamers. I tried to keep the comments as truthful and objective to the responses I have got from local ISPs. I entirely agree that these represent a tiny fraction of the potential user base for FreeBSD, but unfortunately, a lot of people ask them what *they* are using or what that recommend, and it is a lot like those "when we talk they listen" ads. Their word can influence interest (or the lack of it) in FreeBSD. So it would be nice if the ISPs were better informed on the state of FreeBSD. [0]Well, I'll certainly do my best to address these points, as I'm sure [0]will others, but it does beg the question: How do we get the [0]information back to them? If you're willing to act as a conduit, [0]great, otherwise it'll be something of a wasted effort.. Some are subscribers to the lists, others are getting copies of all replies from other routes, including me. They are watching and keen to hear our side of the story. They've heard the spin from the Linux group or from magazines with slants toward other systems. Frank Durda IV |"The Knights who say "LETNi" or uhclem%nemesis@fw.ast.com (Fastest Route)| demand... A SEGMENT REGISTER!!!" ...letni!rwsys!nemesis!uhclem |"A what?" ...decvax!fw.ast.com!nemesis!uhclem |"LETNi! LETNi! LETNi!" - 1983 Did it right this time! From owner-freebsd-current Sun Nov 12 11:24:29 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA19971 for current-outgoing; Sun, 12 Nov 1995 11:24:29 -0800 Received: from ast.com (irvine.ast.com [165.164.128.2]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id LAA19951 for ; Sun, 12 Nov 1995 11:24:26 -0800 Received: from fw.ast.com by ast.com with SMTP id AA15340 (5.67b/IDA-1.5 for ); Sun, 12 Nov 1995 11:25:44 -0800 Received: from nemesis by fw.ast.com with uucp (Smail3.1.29.1 #4) id m0tEhwP-00008RC; Sun, 12 Nov 95 13:19 CST Received: by nemesis.lonestar.org (Smail3.1.27.1 #19) id m0tEhqS-000J05C; Sun, 12 Nov 95 13:13 WET Message-Id: Date: Sun, 12 Nov 95 13:13 WET To: dufault@hda.com, current@freebsd.org From: uhclem%nemesis@fw.ast.com (Frank Durda IV) Sent: Sun Nov 12 1995, 13:13:36 CST Subject: Re: Disk I/O that binds Sender: owner-current@freebsd.org Precedence: bulk [0]1. A concern that FreeBSD tends to "bind" for brief periods when [0] loaded... [1]Can this is an IDE issue? I never saw anything like this until [1]I configured an IDE mail server. That system pauses for seconds [1]sometimes, and then continues. This is running -stable, syscons [1]only (no X), no messages logged, etc. The echo stops going to [1]the display, the ethernet activity is stopped, all in all it seems [1]to be locked up for three or four seconds. I just called the guy that reported this - he is a 100% SCSI shop, mostly Adaptecs with the odd NCR. He didn't have model numbers of the controllers handy. The drives are all Seagate 2G and 4G, some Baracuda, all SCSI II, none wide. My system where I have seen something that somewhat resembles his description is a mixed IDE SCSI system, and when things bog, the hog process and the binding process are both trying to get to the same SCSI drive. The IDE is for swap and root and is idle during these events. And in answer to someone elses' question, there was no tape I/O or CD-ROM I/O active during these events on either system. Only SCSI disk. Frank Durda IV |"The Knights who say "LETNi" or uhclem%nemesis@fw.ast.com (Fastest Route)| demand... A SEGMENT REGISTER!!!" ...letni!rwsys!nemesis!uhclem |"A what?" ...decvax!fw.ast.com!nemesis!uhclem |"LETNi! LETNi! LETNi!" - 1983 From owner-freebsd-current Sun Nov 12 11:24:46 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA20059 for current-outgoing; Sun, 12 Nov 1995 11:24:46 -0800 Received: from kryten.atinc.com (kryten.Atinc.COM [198.138.38.7]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA20037 ; Sun, 12 Nov 1995 11:24:38 -0800 Received: (jmb@localhost) by kryten.atinc.com (8.6.9/8.3) id OAA18129; Sun, 12 Nov 1995 14:15:03 -0500 Date: Sun, 12 Nov 1995 14:14:58 -0500 (EST) From: "Jonathan M. Bresler" Subject: Re: ISP state their FreeBSD concerns To: "Jordan K. Hubbard" cc: Jake Hamby , Peter Dufault , current@freebsd.org, freebsd-isp@freebsd.org In-Reply-To: <16518.816202770@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk sounds like we have the first entry in an document here. 1. Trash all IDE devices--or expect piss-poor performance. Suck is the nature of IDE drives: little or no cache, poor seek times (numbers needed) ... 2. Get SCSI devices. why? normally 256kB cache or more command chaining low interrupt load ... whoever wrote the ide driver and scsi drivers knows this inside and out. how about writing a one page explaination? On Sun, 12 Nov 1995, Jordan K. Hubbard wrote: > > On my system at home (486DX4/100, 850MB Western Digital IDE, VLB IDE > > controller, 24MB RAM) the system does seem to freeze up for as much as 5 > > seconds when I start up a large process such as Netscape or cause one of > > the existing processes to greatly expand their RAM usage (for example, > > looking through the 1000 messages that sometimes accumulate in my INBOX > > using pine, or loading a large number of pictures into XV). I think it's > > Huh. Well, all I can say is that this definitely points at IDE > because I can't reproduce it at all, and that includes starting the > most bloated netscape v2.0b1 binaries, systems like KCL and other > notorious memory hogs. I also know that our IDE driver isn't exactly > likely to win land records for speed - it's one of those icky parts of > the system that nobody really wanted to work on once it got to a state > where it was fairly bulletproof. > > I also agree with Jake - if there's an ISP using IDE CDROM drives out > there for anything then they should donate those drives to charity > just as fast as they can rip them out of the machines and buy SCSI > drives. I was helping an ISP recently who had several machines that I > was horrified to learn had IDE drives in them. The systems were not > performing very well under heavy load, and he called me in to try and > figure out why. The very first thing I did was threaten to come back > with a ball peen hammer and do extreme violence to any IDE drives I > found lurking in any machines on the premises, and he hastily yanked > them out (I'm not sure he knew whether or not I was joking, and > frankly neither did I :-). Since then, his systems have been just > champing along. He's very happy. > > Jordan > Jonathan M. Bresler jmb@kryten.atinc.com | Analysis & Technology, Inc. FreeBSD Postmaster jmb@FreeBSD.Org | 2341 Jeff Davis Hwy play go. | Arlington, VA 22202 ride bike. hack FreeBSD.--ah the good life | 703-418-2800 x346 From owner-freebsd-current Sun Nov 12 11:37:38 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA23306 for current-outgoing; Sun, 12 Nov 1995 11:37:38 -0800 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA23260 ; Sun, 12 Nov 1995 11:37:31 -0800 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id LAA16741; Sun, 12 Nov 1995 11:37:08 -0800 To: Jake Hamby cc: Peter Dufault , current@freebsd.org, freebsd-isp@freebsd.org Subject: Re: ISP state their FreeBSD concerns In-reply-to: Your message of "Sun, 12 Nov 1995 11:22:48 PST." Date: Sun, 12 Nov 1995 11:37:08 -0800 Message-ID: <16739.816205028@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org Precedence: bulk > Here's a question: I would really like to upgrade to SCSI, but the > controller cards are so damn expensive! Are there any good VLB (I know, > I wish I had a PCI motherboard, but VLB is what I've got) SCSI-2 > controllers that don't cost $200 or more?? I hear Buslogic and Adaptec > make decent VLB controllers, can anyone point me in the right direction > for a company that sells good SCSI controllers at decent prices? Thanks! Where are you? I have an older Bt445C controller you can HAVE, just get it out of my sight! :-) Jordan From owner-freebsd-current Sun Nov 12 11:39:15 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA23850 for current-outgoing; Sun, 12 Nov 1995 11:39:15 -0800 Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id LAA23841 for ; Sun, 12 Nov 1995 11:39:13 -0800 X-Authentication-Warning: freefall.freebsd.org: Host localhost.cdrom.com didn't use HELO protocol To: current Subject: A couple of things MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <23838.816205152.1@freefall.freebsd.org> Date: Sun, 12 Nov 1995 11:39:12 -0800 Message-ID: <23839.816205152@freefall.freebsd.org> From: Poul-Henning Kamp Sender: owner-current@FreeBSD.org Precedence: bulk 1. The slower sysinstall: we don not use the same scenario now as in 2.0.5 that's why the exec gzip stuff is so much slower. in 2.0.5 the MFS disk contained uncompressed binaries, relying on kzip to compress the entire thing, not the MFS disk contains gziped bins too. I'm now committing the permanent fix for the sysctl bogusness, the malloc() stunt wasn't what I planned on using, but I needed to to get netscape working so I could get my head back from Peter to think with doing the rest of this stuff. Poul-Henning From owner-freebsd-current Sun Nov 12 11:46:46 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA25251 for current-outgoing; Sun, 12 Nov 1995 11:46:46 -0800 Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA25213 ; Sun, 12 Nov 1995 11:46:37 -0800 Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id LAA17209; Sun, 12 Nov 1995 11:46:13 -0800 From: "Rodney W. Grimes" Message-Id: <199511121946.LAA17209@GndRsh.aac.dev.com> Subject: Re: ISP state their FreeBSD concerns To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Sun, 12 Nov 1995 11:46:13 -0800 (PST) Cc: jehamby@lightside.com, dufault@hda.com, current@freebsd.org, freebsd-isp@freebsd.org In-Reply-To: <16739.816205028@time.cdrom.com> from "Jordan K. Hubbard" at Nov 12, 95 11:37:08 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 826 Sender: owner-current@freebsd.org Precedence: bulk > > > Here's a question: I would really like to upgrade to SCSI, but the > > controller cards are so damn expensive! Are there any good VLB (I know, > > I wish I had a PCI motherboard, but VLB is what I've got) SCSI-2 > > controllers that don't cost $200 or more?? I hear Buslogic and Adaptec > > make decent VLB controllers, can anyone point me in the right direction > > for a company that sells good SCSI controllers at decent prices? Thanks! > > Where are you? I have an older Bt445C controller you can HAVE, just > get it out of my sight! :-) Damn... and I was going to try and sell him my used one for $100.00, looks like you have a better price :-). -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Sun Nov 12 11:51:09 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA26574 for current-outgoing; Sun, 12 Nov 1995 11:51:09 -0800 Received: from chrome.jdl.com (chrome.onramp.net [199.1.166.202]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA26531 for ; Sun, 12 Nov 1995 11:51:01 -0800 Received: from localhost.jdl.com (localhost.jdl.com [127.0.0.1]) by chrome.jdl.com (8.6.11/8.6.9) with SMTP id NAA18005; Sun, 12 Nov 1995 13:50:32 -0600 Message-Id: <199511121950.NAA18005@chrome.jdl.com> X-Authentication-Warning: chrome.jdl.com: Host localhost.jdl.com didn't use HELO protocol To: Peter Dufault cc: current@freebsd.org Subject: Re: ISP state their FreeBSD concerns In-reply-to: Your message of "Sun, 12 Nov 1995 08:50:57 EST." <199511121350.IAA00279@hda.com> Reply-To: jdl@chromatic.com Clarity-Index: null Threat-Level: none Software-Engineering-Dead-Seriousness: There's no excuse for unreadable code. Net-thought: If you meet the Buddha on the net, put him in your Kill file. Date: Sun, 12 Nov 1995 13:50:32 -0600 From: Jon Loeliger Sender: owner-current@freebsd.org Precedence: bulk Apparently, Peter Dufault scribbled: > > > > 1. A concern that FreeBSD tends to "bind" for brief periods when > > loaded... > > Can this is an IDE issue? I never saw anything like this until > I configured an IDE mail server. That system pauses for seconds > sometimes, and then continues. This is running -stable, syscons > only (no X), no messages logged, etc. The echo stops going to > the display, the ethernet activity is stopped, all in all it seems > to be locked up for three or four seconds. > > We have three SCSI only systems and haven't ever seen this, and > one IDE system that pauses. Hmmm.... Curious. I've got a lame-o IDE 2.0.5-95 0622 system, and I see some occasional pauses too. Most notably as I mentioned earlier with the "talk" program. I *thought* I correlated it to receiving mail one day, but wasn't sure at all... Since I only ever run "talk" to the west coast, it could easily be a line probelm at the ISP on their end. Has anyone else seen talk display this freezing-up behaviour? Do I alone imagine it? Should I cut back on my (non-)Bass/Guiness drinking? :-) jdl From owner-freebsd-current Sun Nov 12 12:05:25 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA00366 for current-outgoing; Sun, 12 Nov 1995 12:05:25 -0800 Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id MAA00351 for ; Sun, 12 Nov 1995 12:05:23 -0800 X-Authentication-Warning: freefall.freebsd.org: Host localhost.cdrom.com didn't use HELO protocol To: current Subject: Dual personality crypt. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <348.816206722.1@freefall.freebsd.org> Date: Sun, 12 Nov 1995 12:05:23 -0800 Message-ID: <349.816206723@freefall.freebsd.org> From: Poul-Henning Kamp Sender: owner-current@FreeBSD.org Precedence: bulk Mark, Great idea. I think you should offer an option to make new encryptions a) DES b) MD5 c) "the same as before" to make it general. I don't know if you can do this without changing the passwd program btw. Poul-Henning From owner-freebsd-current Sun Nov 12 12:09:12 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA01392 for current-outgoing; Sun, 12 Nov 1995 12:09:12 -0800 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA01359 ; Sun, 12 Nov 1995 12:09:07 -0800 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id MAA16900; Sun, 12 Nov 1995 12:08:26 -0800 To: "Rodney W. Grimes" cc: jehamby@lightside.com, dufault@hda.com, current@freebsd.org, freebsd-isp@freebsd.org Subject: Re: ISP state their FreeBSD concerns In-reply-to: Your message of "Sun, 12 Nov 1995 11:46:13 PST." <199511121946.LAA17209@GndRsh.aac.dev.com> Date: Sun, 12 Nov 1995 12:08:26 -0800 Message-ID: <16898.816206906@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org Precedence: bulk > > > > > Here's a question: I would really like to upgrade to SCSI, but the > > > controller cards are so damn expensive! Are there any good VLB (I know, > > > I wish I had a PCI motherboard, but VLB is what I've got) SCSI-2 > > > controllers that don't cost $200 or more?? I hear Buslogic and Adaptec > > > make decent VLB controllers, can anyone point me in the right direction > > > for a company that sells good SCSI controllers at decent prices? Thanks! > > > > Where are you? I have an older Bt445C controller you can HAVE, just > > get it out of my sight! :-) > > Damn... and I was going to try and sell him my used one for $100.00, looks > like you have a better price :-). Well, I'm still going to make him pay the shipping.. :-) Jordan From owner-freebsd-current Sun Nov 12 12:15:04 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA03258 for current-outgoing; Sun, 12 Nov 1995 12:15:04 -0800 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA02788 ; Sun, 12 Nov 1995 12:14:07 -0800 Received: from grumble.grondar.za (grumble.grondar.za [196.7.18.130]) by grunt.grondar.za (8.6.12/8.6.9) with ESMTP id WAA06701; Sun, 12 Nov 1995 22:13:25 +0200 Received: from localhost (localhost [127.0.0.1]) by grumble.grondar.za (8.6.12/8.6.9) with SMTP id WAA16847; Sun, 12 Nov 1995 22:13:24 +0200 Message-Id: <199511122013.WAA16847@grumble.grondar.za> X-Authentication-Warning: grumble.grondar.za: Host localhost didn't use HELO protocol To: Poul-Henning Kamp cc: current@freefall.freebsd.org Subject: Re: Dual personality crypt. Date: Sun, 12 Nov 1995 22:13:24 +0200 From: Mark Murray Sender: owner-current@FreeBSD.org Precedence: bulk I'm trying to build a stripped down 2.0.5 kernel for fd0. Towards that goal, I tried to remove all network support (devices and protocols). Removing protocol support leaves a reference but no defintion for netisr_set causing the loader to barf. Looking through the code it appears I need to include one of the protocols (INET, ISO etc) to define NETISR_SET. Is there a way to remove all networking support from the kernel ? Thanks in advance tony # make all loading kernel machdep.o: Undefined symbol `_netisr_set' referenced from text segment *** Error code 1 From owner-freebsd-current Sun Nov 12 12:37:54 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA06455 for current-outgoing; Sun, 12 Nov 1995 12:37:54 -0800 Received: from zibbi.mikom.csir.co.za (zibbi.mikom.csir.co.za [146.64.24.58]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA06441 ; Sun, 12 Nov 1995 12:37:47 -0800 Received: (from jhay@localhost) by zibbi.mikom.csir.co.za (8.6.12/8.6.9) id WAA10257; Sun, 12 Nov 1995 22:33:21 +0200 From: John Hay Message-Id: <199511122033.WAA10257@zibbi.mikom.csir.co.za> Subject: Re: Dual personality crypt. To: phk@freefall.freebsd.org (Poul-Henning Kamp) Date: Sun, 12 Nov 1995 22:33:20 +0200 (SAT) Cc: current@freefall.freebsd.org In-Reply-To: <349.816206723@freefall.freebsd.org> from "Poul-Henning Kamp" at Nov 12, 95 12:05:23 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 365 Sender: owner-current@FreeBSD.org Precedence: bulk > > Mark, Great idea. > > I think you should offer an option to make new encryptions > a) DES > b) MD5 > c) "the same as before" > > to make it general. I don't know if you can do this without changing > the passwd program btw. > Yes, I like this. I would not like to be forced to have ALL new passwords using des. John -- John Hay -- John.Hay@csir.co.za From owner-freebsd-current Sun Nov 12 13:37:37 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA23258 for current-outgoing; Sun, 12 Nov 1995 13:37:37 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA23224 for ; Sun, 12 Nov 1995 13:37:31 -0800 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id WAA17635; Sun, 12 Nov 1995 22:37:19 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id WAA10079; Sun, 12 Nov 1995 22:37:19 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id WAA22212; Sun, 12 Nov 1995 22:34:37 +0100 From: J Wunsch Message-Id: <199511122134.WAA22212@uriah.heep.sax.de> Subject: Re: Dual-personality crypt(3)!! To: mark@grondar.za (Mark Murray) Date: Sun, 12 Nov 1995 22:34:37 +0100 (MET) Cc: joerg_wunsch@uriah.heep.sax.de, current@freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199511121659.SAA03128@grumble.grondar.za> from "Mark Murray" at Nov 12, 95 06:59:43 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1026 Sender: owner-current@freebsd.org Precedence: bulk As Mark Murray wrote: > > > Anyway, i like it. This would allow me to upgrade to MD5 some day > > without losing all my DES passwords. ;-) > > Not without a bit of extra work. The default encryption when no salt is > specified will be DES. This was designed as a convenience for those > who have MD5 and want to go DES without irritating all their users. > as folks change their passwords, they will be DES'ed. Well, i could UTSL. Anyway, wouldn't it be possible to add a knob (e.g. an environmental variable) that would allow to select the default behaviour, defaulting to DES? This way, we could satisfy both camps: people who want to `downgrade' to DES for the one or the other reason, or people who've been running with DES, but wish to use MD5 instead, e.g. since it's known to be stronger. This would allow for a gradual migration in both directions. -- 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-current Sun Nov 12 13:43:29 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA26285 for current-outgoing; Sun, 12 Nov 1995 13:43:29 -0800 Received: from poe.b2.org (poe.b2.org [206.55.128.9]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA26252 ; Sun, 12 Nov 1995 13:43:24 -0800 Received: (from mlh@localhost) by poe.b2.org (8.6.11/8.6.9) id QAA25877; Sun, 12 Nov 1995 16:42:48 -0500 Date: Sun, 12 Nov 1995 16:42:48 -0500 (EST) From: Michael Hendrick To: Jake Hamby cc: Peter Dufault , current@freebsd.org, freebsd-isp@freebsd.org Subject: Re: ISP state their FreeBSD concerns In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk On Sun, 12 Nov 1995, Jake Hamby wrote: > > > 1. A concern that FreeBSD tends to "bind" for brief periods when > > > loaded... > > We have three SCSI only systems and haven't ever seen this, and > > one IDE system that pauses. > On my system at home (486DX4/100, 850MB Western Digital IDE, VLB IDE > controller, 24MB RAM) the system does seem to freeze up for as much as 5 > seconds when I start up a large process such as Netscape or cause one of When I had IDE drives, this would also happen quite frequently under Linux, so I would guess a timing problem of some sort with the IDE controller, not specific to FreeBSD. -- mlh@b2.org (Michael Hendrick) From owner-freebsd-current Sun Nov 12 13:44:58 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA26698 for current-outgoing; Sun, 12 Nov 1995 13:44:58 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA26670 for ; Sun, 12 Nov 1995 13:44:52 -0800 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id WAA17796; Sun, 12 Nov 1995 22:44:47 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id WAA10106; Sun, 12 Nov 1995 22:44:46 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id WAA22475; Sun, 12 Nov 1995 22:39:47 +0100 From: J Wunsch Message-Id: <199511122139.WAA22475@uriah.heep.sax.de> Subject: Re: /usr/share/man/cat* To: rgrimes@GndRsh.aac.dev.com (Rodney W. Grimes) Date: Sun, 12 Nov 1995 22:39:47 +0100 (MET) Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-current@FreeBSD.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199511121755.JAA17034@GndRsh.aac.dev.com> from "Rodney W. Grimes" at Nov 12, 95 09:55:42 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 411 Sender: owner-current@FreeBSD.org Precedence: bulk As Rodney W. Grimes wrote: > > The .keep_me file is to stop cvs co -P or cvs update -P from removing > the compile directory from the source tree, the catman directories do not > live in the source tree :-). Ah, ok, so this one's another problem. -- 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-current Sun Nov 12 14:03:46 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA05875 for current-outgoing; Sun, 12 Nov 1995 14:03:46 -0800 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA05865 for ; Sun, 12 Nov 1995 14:03:41 -0800 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id XAA06357 ; Sun, 12 Nov 1995 23:03:38 +0100 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id XAA21862 ; Sun, 12 Nov 1995 23:03:37 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.7.1/keltia-uucp-2.6) id WAA00970; Sun, 12 Nov 1995 22:34:52 +0100 (MET) From: Ollivier Robert Message-Id: <199511122134.WAA00970@keltia.freenix.fr> Subject: Re: ISP state their FreeBSD concerns To: jgreco@brasil.moneng.mei.com (Joe Greco) Date: Sun, 12 Nov 1995 22:34:51 +0100 (MET) Cc: dyson@freefall.freebsd.org, current@freebsd.org In-Reply-To: <199511121600.KAA26310@brasil.moneng.mei.com> from "Joe Greco" at Nov 12, 95 10:00:34 am X-Operating-System: FreeBSD 2.2-CURRENT ctm#1306 X-Mailer: ELM [version 2.4 PL24 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org Precedence: bulk It seems that Joe Greco said: > FreeBSD 1026-SNAP - ASUS SP3G AMD 486DX4/100 + NCR810 - 48MB (SCSI II, SLOW > drive, fs mounted -o async) > > 10000 files in 569 seconds - first run :-( :-( > 10000 files in 207 seconds - second run :-( :-( :-( !! I just tried your program and after 3000 or so files, it hangs forever in the following state: 0 924 412 4 -6 0 160 464 getblk D+ p6 0:06.30 /tmp/foo 207 [22:27] root@keltia:/var/tmp# /tmp/foo 0..100..200..300..400..500..600..700..800..900..1000..1100..1200..1300..1400..1500..1600..1700..1800..1900..2000..2100..2200..2300..2400..2500..2600..2700..2800..2900..3000..^C^Z^Z^Z^Z^C^Z^C^Z /dev/sd2e on /var (asynchronous, local) Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/sd2e 68735 15407 47829 24% /var FreeBSD keltia.freenix.fr 2.2-CURRENT FreeBSD 2.2-CURRENT #1: Sun Nov 12 16:47:05 MET 1995 roberto@keltia.freenix.fr:/src/src/sys/compile/KELTIA i386 /var is on a Seagate ST-31200N on a AHA-1740A. 32 MB RAM, 486DX-33 EISA. John, any idea ? -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia.freenix.fr 2.2-CURRENT #7: Mon Nov 6 21:08:06 MET 1995 From owner-freebsd-current Sun Nov 12 14:08:01 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA06192 for current-outgoing; Sun, 12 Nov 1995 14:08:01 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA06180 for ; Sun, 12 Nov 1995 14:07:52 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id JAA24105; Mon, 13 Nov 1995 09:04:23 +1100 Date: Mon, 13 Nov 1995 09:04:23 +1100 From: Bruce Evans Message-Id: <199511122204.JAA24105@godzilla.zeta.org.au> To: dyson@freefall.freebsd.org, jgreco@brasil.moneng.mei.com Subject: Re: ISP state their FreeBSD concerns Cc: current@freebsd.org Sender: owner-current@freebsd.org Precedence: bulk >> > 8. File creation (particularly directories) appears to be slow compared >> > to other BSD-like systems. They say the stats for INN and CNEWS >> >... >> >> I am working on this stuff right now. Give me benchmarks!!!! I'll >> do what I can. Almost anything that creates files and writes to them takes several times longer to write the metadata than to write the files. E.g., (1) time cp -pR /usr/src /usr/src~ time rm -rf /usr/src~ (2) mount /dev/fd0 /mnt cp -pR /dev /mnt/dev >I have a little suite of programs I use for performance testing. The tests >are absolutely slanted towards news server type applications. The one in >particular I will quote is "small-file-write.c", a program that writes 10000 >files in subdirectories, creating the subdirectories if needed (much like a >news server would do). So the "first run" numbers include the time needed >to make dirs: >Slowaris 5.4 - SS10/30 - 64MB RAM (SCSI II, reasonable drive) >10000 files in 332 seconds - first run >10000 files in 20 !!! seconds - second run >... >FreeBSD 2.0.5R - ASUS SP3G AMD 486DX2/66 + NCR810 - 8MB (SCSI II, reasonable >drive) >10000 files in 620 seconds - first run :-( :-( >10000 files in 310 seconds - second run :-( :-( :-( !! >FreeBSD 1026-SNAP - ASUS SP3G AMD 486DX4/100 + NCR810 - 48MB (SCSI II, SLOW >drive, fs mounted -o async) >10000 files in 569 seconds - first run :-( :-( >10000 files in 207 seconds - second run :-( :-( :-( !! You need fast drives to get such high speeds for the first run :-]. I tried with only 1000 files because 10000 would take too long and my file systems are small: FreeBSD current - no-name 486DX/33 + no-name IDE - 8MB (SLOW Samsung IDE drive): 1000 files in 161 seconds - first run (161.00 real 0.25 user 6.96 sys) :-( 1000 files in 19 seconds - second run ( 18.92 real 0.22 user 1.52 sys) :-( Same except mounted async: 1000 files in 66 seconds - first run (66.09 real 0.20 user 5.26 sys) :-( 1000 files in 20 seconds - second run (19.93 real 0.20 user 1.58 sys) :-( Same except running my 1991-ish version of Minix (fs last changed Dec 17 1994) (Minix v1 fs, inherently async) 1000 files in 4 seconds - first run (4 real 0.20 user 3.06 sys) :-> 1000 files in 1 seconds - second run (1 real 0.20 user 0.86 sys) :-> The times under Linux with the Minix (v1) fs should be similar. Linux 1.2.13 - unknown 486DX2/66 + unknown SCSI - >32MB (unknown drive) - ext2fs (inherently async), high load average: 1000 files in 16 seconds - first run (16.19 real 0.19 user 3.18 sys) :-| 1000 files in 2 seconds - second run ( 2.37 real 0.19 user 2.06 sys) :-| It's interesting that your times for the second run are relatively worse than mine. Perhaps the larger number of files makes the caches ineffective. --- Even for reading and writing normal files on a much better system, FreeBSD is slower than Minix :->. For reading and writing `bin', where bin is a copy of /usr/src/bin (created on a new file system in the case of FreeBSD): System Machine Bus/Controller Drive ------ ------- -------------- ----- FreeBSD-cur-a 486DX2/66 16MB VLB/BT445C SCSI Quantum XPG34301 (5.3MB/sec) FreeBSD-cur-b 486DX/33 8MB ISA/no-name IDE slow IDE (1.4MB/sec) Minix-old same as for FreeBSD-cur-b System fs fs state ------ -- -------- Minix-old Minix v1 48MB, old, nearly full FreeBSD-cur-a ffs 1.2GB, new, nearly empty FreeBSD-cur-a-a ffs async same except for mount option FreeBSD-cur-b ffs 75MB, old, nearly full FreeBSD-cur-b-a ffs async same except for mount option times and (data) throughputs (cold buffer cache) ------------------------------------------------ System cp -pR bin bin~ rm -rf bin~ tar cf /dev/null bin ------ --------------- ----------- -------------------- Minix-old 15 171K/sec 3 6 428K/sec FreeBSD-cur-a-a 17.04 150K/sec 2.58 6.54 393K/sec FreeBSD-cur-a 31.50 81K/sec 13.36 6.62 388K/sec FreeBSD-cur-b-a 31.76 80K/sec 1.97 8.68 296K/sec FreeBSD-cur-b 76.87 33K/sec 25.94 21.16 121K/sec (!!) I thought I left throughputs of 25K/sec on my XT with its 20MB hard disk and 105 ms seek time. Reading really is 2.5 times slower for the sync tar test. Something must be thrashing. Bruce From owner-freebsd-current Sun Nov 12 14:12:25 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA06483 for current-outgoing; Sun, 12 Nov 1995 14:12:25 -0800 Received: from lisa.rur.com (G338.257.InterLink.NET [199.202.234.53]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA06469 for ; Sun, 12 Nov 1995 14:12:15 -0800 Received: (from leo@localhost) by lisa.rur.com (8.6.11/8.6.9) id RAA19703; Sun, 12 Nov 1995 17:12:12 -0500 Date: Sun, 12 Nov 1995 17:12:12 -0500 (EST) From: Leo Papandreou To: current@freebsd.org Subject: Re: ISP state their FreeBSD concerns In-Reply-To: <16518.816202770@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk On Sun, 12 Nov 1995, Jordan K. Hubbard wrote: > > On my system at home (486DX4/100, 850MB Western Digital IDE, VLB IDE > > controller, 24MB RAM) the system does seem to freeze up for as much as 5 > > seconds when I start up a large process such as Netscape or cause one of > > the existing processes to greatly expand their RAM usage (for example, > > looking through the 1000 messages that sometimes accumulate in my INBOX > > using pine, or loading a large number of pictures into XV). I think it's > > Huh. Well, all I can say is that this definitely points at IDE > because I can't reproduce it at all, and that includes starting the > most bloated netscape v2.0b1 binaries, systems like KCL and other > notorious memory hogs. Not so fast. I have additional anecdotal evidence. ASUS P54TP4, NCR-810, 32M, 2G Hawk, 2.0.5-RELEASE. After a week of exclusively analog, coffee free activity, I logged in and started pine. Woo-hoo! 3000+ accumulated messages. Good night! I'm talking frequent, _lengthy_ "binds" lasting as long as a minute. Virtual terminal sessions indicated that performance had been sig- nificantly degraded system wide. When i was running X I noticed that programs like Netscape would often choke the system as well. I put it down to X running on a "measly" 32M (sigh.) /Leo From owner-freebsd-current Sun Nov 12 14:16:55 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA06855 for current-outgoing; Sun, 12 Nov 1995 14:16:55 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA06848 for ; Sun, 12 Nov 1995 14:16:48 -0800 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id XAA18346 for ; Sun, 12 Nov 1995 23:16:41 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id XAA10362 for current@freefall.freebsd.org; Sun, 12 Nov 1995 23:16:41 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id XAA22824 for current@freefall.freebsd.org; Sun, 12 Nov 1995 23:10:03 +0100 From: J Wunsch Message-Id: <199511122210.XAA22824@uriah.heep.sax.de> Subject: Re: A couple of things To: current@freefall.freebsd.org Date: Sun, 12 Nov 1995 23:10:02 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <23839.816205152@freefall.freebsd.org> from "Poul-Henning Kamp" at Nov 12, 95 11:39:12 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 578 Sender: owner-current@FreeBSD.org Precedence: bulk As Poul-Henning Kamp wrote: > > 1. The slower sysinstall: we don not use the same scenario > now as in 2.0.5 that's why the exec gzip stuff is so much slower. > in 2.0.5 the MFS disk contained uncompressed binaries, relying > on kzip to compress the entire thing, not the MFS disk contains > gziped bins too. Ah, yes, this explains why my 386sx/16 is _that_ slow. Okay, now that i know why it is, i don't worry. -- 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-current Sun Nov 12 14:28:04 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA07304 for current-outgoing; Sun, 12 Nov 1995 14:28:04 -0800 Received: from rainbow-jr.dreaming.org (hub.org [199.166.238.138]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA07234 ; Sun, 12 Nov 1995 14:26:24 -0800 Received: (from scrappy@localhost) by rainbow-jr.dreaming.org (8.7.1/8.7.1) id QAA00216; Sun, 12 Nov 1995 16:10:48 -0500 (EST) Date: Sun, 12 Nov 1995 16:10:46 -0500 (EST) From: "Marc G. Fournier" X-Sender: scrappy@rainbow-jr.dreaming.org To: freebsd-questions@freebsd.org, freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: FreeBSD 2.0.5R hanging inexplicably... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk Hi... For the second time in two days, my system just hung, in that, essentially, no keyboard input was being permitted. The first time, I'm sure it had to do with PCVT, in that it happened the moment after I had modified /etc/ttys and turned off all the console screens that I'm not using and issued a kill -1 1. Even after reboot, it hung almost immediately. When I booted up into single user mode, and turned those ports back on, it was all fine. Of significance to note in that case, everything ran fine in the background, it was just a console lock. This second time, though, I don't know...it just locked up completely. Of note, it seems that when it locks up, one of the keyboard lights comes on, either NumLock, CapsLock or ScrollLock...this last time, prior to lockup, ScrollLock came on, and after turning it back off, it ran for a little bit befor elockingup completely. That is the symptoms...now the question...are there any known problems with PCVT under 2.0.5R that have been fixed in 2.1.0-*-SNAP? If not...how do I debug something like this? Since it hangs, and doesn't fault itself, getting a core dump, so I'd think, is kind of difficult... Marc G. Fournier | Knowledge, Information and Communications, Inc (ki.net) scrappy@hub.org | soon to be: | scrappy@ki.net | For more information, send me email. From owner-freebsd-current Sun Nov 12 14:39:17 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA08102 for current-outgoing; Sun, 12 Nov 1995 14:39:17 -0800 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA08086 for ; Sun, 12 Nov 1995 14:39:06 -0800 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id XAA06517 ; Sun, 12 Nov 1995 23:38:31 +0100 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id XAA21953 ; Sun, 12 Nov 1995 23:38:24 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.7.1/keltia-uucp-2.6) id XAA01317; Sun, 12 Nov 1995 23:36:49 +0100 (MET) From: Ollivier Robert Message-Id: <199511122236.XAA01317@keltia.freenix.fr> Subject: GNU gmp To: mark@grumble.grondar.za (Mark Murray) Date: Sun, 12 Nov 1995 23:36:49 +0100 (MET) Cc: freebsd-current@FreeBSD.ORG (FreeBSD Current Users' list) X-Operating-System: FreeBSD 2.2-CURRENT ctm#1327 X-Mailer: ELM [version 2.4 PL24 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG Precedence: bulk Hello, Importing gmp is a good thing but generating the library as libmp.* is a bad thing. I think we should have both libgmp.* and libmp.* (as enabled by the -DBERKELEY flag) for compatibility with some packages which use it (like SSH). GNU mp is not the same as Berkeley mp so having the same name is misleading... -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia.freenix.fr 2.2-CURRENT #1: Sun Nov 12 16:47:05 MET 1995 From owner-freebsd-current Sun Nov 12 14:58:45 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA09175 for current-outgoing; Sun, 12 Nov 1995 14:58:45 -0800 Received: from haywire.DIALix.COM (haywire.DIALix.COM [192.203.228.65]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA09161 for ; Sun, 12 Nov 1995 14:58:31 -0800 Received: (from news@localhost) by haywire.DIALix.COM (sendmail) id GAA02610 for freebsd-current@freebsd.org; Mon, 13 Nov 1995 06:58:16 +0800 (WST) Received: from GATEWAY by haywire.DIALix.COM with netnews for freebsd-current@freebsd.org (problems to: usenet@haywire.dialix.com) To: freebsd-current@freebsd.org Date: 13 Nov 1995 06:58:12 +0800 From: peter@haywire.dialix.com (Peter Wemm) Message-ID: <485u64$2he$1@haywire.DIALix.COM> Organization: DIALix Services, Perth, Australia. References: <23839.816205152@freefall.freebsd.org> Subject: Re: A couple of things Sender: owner-current@freebsd.org Precedence: bulk phk@freefall.freebsd.org (Poul-Henning Kamp) writes: >1. The slower sysinstall: we don not use the same scenario >now as in 2.0.5 that's why the exec gzip stuff is so much slower. >in 2.0.5 the MFS disk contained uncompressed binaries, relying >on kzip to compress the entire thing, not the MFS disk contains >gziped bins too. Err.. :-) There's a couple of typos in there that make it a little bit ambiguous.. So, let me get this straight... We're _now_ using a gzipped, crunched executable? If so, isn't that bad? the exec gzip routine makes a copy of the gzipped data in memory, and runs that doesn't it? ie: swap space is allocated because it can't page to the file anymore? I've not looked at the gzip exec code, but what are the odds that each executable launched from the crunched image is using up it's own amount of ram and swap space rather than sharing pages? Or does it try and be smart by associating the the ungzipped pages with the file so that when the crunched image is run, the ungzipped pages are reclaimed? Cheers, -Peter >Poul-Henning From owner-freebsd-current Sun Nov 12 15:37:01 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA12341 for current-outgoing; Sun, 12 Nov 1995 15:37:01 -0800 Received: from linus.demon.co.uk (linus.demon.co.uk [158.152.10.220]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA12295 for ; Sun, 12 Nov 1995 15:36:44 -0800 Received: (from mark@localhost) by linus.demon.co.uk (8.7.1/8.7.1) id WAA00409; Sun, 12 Nov 1995 22:43:32 GMT Date: Sun, 12 Nov 1995 22:43:32 GMT From: Mark Valentine Message-Id: <199511122243.WAA00409@linus.demon.co.uk> In-Reply-To: Richard Wackerbarth's message of Nov 12, 12:19am X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: Getting to the root of building Makefiles Cc: current@FreeBSD.org, root@deadline.snafu.de Sender: owner-current@FreeBSD.org Precedence: bulk > From: rkw@dataplex.net (Richard Wackerbarth) > Date: Sun 12 Nov, 1995 > Subject: Getting to the root of building Makefiles > Mark Valentine writes: > >One way to help make source trees self-sufficient might be to start every > >Makefile with something like: > > > > TOP = ../.. > > > > .MAKEFLAGS: -I${TOP}/share/mk > > > >(where the ../.. varies according to the position in the source tree). > > Generally on the right line of thinking ... > Only you cannot always use ../.. to get back to the correct top of the tree. > If I merge multiple trees with symbolic links, then I cannot follow > the tree up to get to the root of MY tree. I use this scheme with symlinks into multiple source trees all the time* (no obj trees). Granted, you have to symlink everything you need into one symlink tree (no symlinked directories), but I'm happy with that restriction. Am I missing your meaning? > The other problem with this approach is that it is some inconvenience to > move a sub tree. For example, if we wished to merge the gnu tree with the > usr.bin tree, or conversely, if we wished to split a collection out of the > tree and place in its own alternate tree. If the need arises, a fairly simple script can walk a source tree, editing the Makefiles to point TOP at the right level. > My approach would be to establish a ROOT and reference the MAKEFLAGS > relative to that root. After all, we need the same facility for the > includes, etc. Do you mean use an environment variable containing a full path? I've used such a scheme, and it was a pain in the bum when working with multiple trees. I like the makefiles to know where to look by themselves. (And of course, you can't dig the root out of /etc/make.conf, since that also has to move *into* the source tree, say as src/make.conf.) Mark. * Symlink trees are a pain to manage, though! Anyone come up with a useable script to manage a symlink tree pointing at multiple (changing) source trees? From owner-freebsd-current Sun Nov 12 15:44:48 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA13457 for current-outgoing; Sun, 12 Nov 1995 15:44:48 -0800 Received: from linus.demon.co.uk (linus.demon.co.uk [158.152.10.220]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA13410 ; Sun, 12 Nov 1995 15:44:32 -0800 Received: (from mark@localhost) by linus.demon.co.uk (8.7.1/8.7.1) id XAA00478; Sun, 12 Nov 1995 23:04:39 GMT Date: Sun, 12 Nov 1995 23:04:39 GMT From: Mark Valentine Message-Id: <199511122304.XAA00478@linus.demon.co.uk> In-Reply-To: Richard Wackerbarth's message of Nov 11, 4:34pm X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: rkw@dataplex.net (Richard Wackerbarth), Terry Lambert Subject: Re: LKM's still wont compile in -current Cc: current@freebsd.org, root@deadline.snafu.de, hackers@freebsd.org Sender: owner-current@freebsd.org Precedence: bulk > From: rkw@dataplex.net (Richard Wackerbarth) > Date: Sat 11 Nov, 1995 > Subject: Re: LKM's still wont compile in -current > Now can I sell "you" (the holdouts, not you Terry) on getting rid of the > absolute paths? > EVERYTHING needs to be referenced relative to the ROOT of the build tree. > SRC, OBJ location, TOOLS, INCludes, MKfiles, etc. EVERYTHING. I'd draw a line below EVERYTHING, at least for initial bootstrapping. I'd separate out some of the tools, like the compiler and make, just documenting which versions you need to have installed in the host environment to build for your target (point src/make.conf at them if they're not in the standard locations). If you need to, you build the tools you need as part of bootstrapping your build environment. Some stuff, like config, will always be used from the build tree, though. Mark. From owner-freebsd-current Sun Nov 12 18:42:26 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA00179 for current-outgoing; Sun, 12 Nov 1995 18:42:26 -0800 Received: from gaia.coppe.ufrj.br (root@gaia.coppe.ufrj.br [146.164.63.4]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA00141 for ; Sun, 12 Nov 1995 18:42:21 -0800 Received: (from jonny@localhost) by gaia.coppe.ufrj.br (8.6.11/8.6.9) id AAA07777; Mon, 13 Nov 1995 00:42:00 -0200 From: Joao Carlos Mendes Luis Message-Id: <199511130242.AAA07777@gaia.coppe.ufrj.br> Subject: Re: Dual personality crypt. To: current@freefall.freebsd.org Date: Mon, 13 Nov 1995 00:41:59 -0200 (EDT) In-Reply-To: <199511122033.WAA10257@zibbi.mikom.csir.co.za> from "John Hay" at Nov 12, 95 10:33:20 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1081 Sender: owner-current@FreeBSD.org Precedence: bulk > > Mark, Great idea. > > > > I think you should offer an option to make new encryptions > > a) DES > > b) MD5 > > c) "the same as before" > > > > to make it general. I don't know if you can do this without changing > > the passwd program btw. > > > Yes, I like this. I would not like to be forced to have ALL new passwords > using des. Hey everybody... I hope you remember that password entries could be used by other programs rather than login, su and passwd. If we change the crypt(3) function drastically we may have to do lot's of new ports to deal with these new incompatibilities. I think it's better to have the problems we have now rather than making a new incompatibilty when comparing to other systems. Think of this before new "great" ideas. If this change is REALLY transparent, do it. If not, let it be an option, p'p'p'p'pleaaaase. Jonny PS: No, I'm not Roger Rabbit... :) -- Joao Carlos Mendes Luis jonny@coe.ufrj.br +55 21 290-4698 ( Job ) jonny@adc.coppe.ufrj.br Network Manager UFRJ/COPPE/CISI Universidade Federal do Rio de Janeiro From owner-freebsd-current Sun Nov 12 20:14:33 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA09587 for current-outgoing; Sun, 12 Nov 1995 20:14:33 -0800 Received: from jazz.trumpet.com.au (root@jazz.trumpet.com.au [203.5.119.51]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA09545 ; Sun, 12 Nov 1995 20:14:21 -0800 Received: (from paul@localhost) by jazz.trumpet.com.au (8.6.11/8.6.9) id PAA11584; Mon, 13 Nov 1995 15:03:47 +1100 Date: Mon, 13 Nov 1995 15:03:46 +1100 (EST) From: Paul Reece X-Sender: paul@jazz To: "Marc G. Fournier" cc: freebsd-questions@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: Re: FreeBSD 2.0.5R hanging inexplicably... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.org Precedence: bulk On Sun, 12 Nov 1995, Marc G. Fournier wrote: > > Hi... > > For the second time in two days, my system just hung, in that, > essentially, no keyboard input was being permitted. > > The first time, I'm sure it had to do with PCVT, in that it happened > the moment after I had modified /etc/ttys and turned off all the console > screens that I'm not using and issued a kill -1 1. Even after reboot, it > hung almost immediately. When I booted up into single user mode, and > turned those ports back on, it was all fine. > > Of significance to note in that case, everything ran fine in the > background, it was just a console lock. > > This second time, though, I don't know...it just locked up > completely. Of note, it seems that when it locks up, one of the keyboard > lights comes on, either NumLock, CapsLock or ScrollLock...this last time, > prior to lockup, ScrollLock came on, and after turning it back off, it ran > for a little bit befor elockingup completely. > > That is the symptoms...now the question...are there any known > problems with PCVT under 2.0.5R that have been fixed in 2.1.0-*-SNAP? > If not...how do I debug something like this? Since it hangs, and doesn't > fault itself, getting a core dump, so I'd think, is kind of difficult... I had the same problem. Since I disabled the screensavers on the console I've had no further lockups.. Perhaps something that needs to be looked at closely? Rgds, Paul. From owner-freebsd-current Sun Nov 12 20:36:48 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA11668 for current-outgoing; Sun, 12 Nov 1995 20:36:48 -0800 Received: from linus.demon.co.uk (linus.demon.co.uk [158.152.10.220]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA11650 ; Sun, 12 Nov 1995 20:36:31 -0800 Received: (from mark@localhost) by linus.demon.co.uk (8.7.1/8.7.1) id EAA00434; Mon, 13 Nov 1995 04:38:03 GMT Date: Mon, 13 Nov 1995 04:38:03 GMT From: Mark Valentine Message-Id: <199511130438.EAA00434@linus.demon.co.uk> X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: phk@freebsd.org, current@freebsd.org Subject: sethostname() failing with ENOMEM Sender: owner-current@freebsd.org Precedence: bulk I suspect that either I've missed a dependency or CTM has caught a bunch of commits on the middle... or there's a new bug... I've just rebuilt a kernel (not a make world - I did one of those already this weekend...), rebuilt libc, hostname(1) and sysctl(8), but hostname linus.demon.co.uk fails in sethostname() with ENOMEM, whereas sysctl -w kern.hostname=linus.demon.co.uk works just fine. (hostname returns the correct name afterwards) Any ideas? Mark. From owner-freebsd-current Sun Nov 12 20:56:33 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA13738 for current-outgoing; Sun, 12 Nov 1995 20:56:33 -0800 Received: from hutcs.cs.hut.fi (root@hutcs.cs.hut.fi [130.233.192.2]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id UAA13733 for ; Sun, 12 Nov 1995 20:56:27 -0800 Received: from shadows.cs.hut.fi by hutcs.cs.hut.fi with SMTP id AA20441 (5.65c8/HUTCS-S 1.4 for ); Mon, 13 Nov 1995 06:56:07 +0200 Received: (hsu@localhost) by shadows.cs.hut.fi (8.6.10/8.6.10) id GAA15534; Mon, 13 Nov 1995 06:56:22 +0200 Date: Mon, 13 Nov 1995 06:56:22 +0200 Message-Id: <199511130456.GAA15534@shadows.cs.hut.fi> From: Heikki Suonsivu To: michael butler Cc: freebsd-current@freefall.FreeBSD.org In-Reply-To: michael butler's message of 12 Nov 1995 08:44:25 +0200 Subject: Re: cvs commit: src/usr.sbin/pppd RELNOTES Sender: owner-current@FreeBSD.org Precedence: bulk > hsu#hauki.clinet.fi Sun 37: time gzip -1 < csh > /dev/null .. ah .. this is not the default compression method. You should've said :-) It makes no sense to use maximum compression to gain 1-2% better compression at cost of 2-3 times longer compression time, at least in compressing data on tcp/ip links. For comparison and using the default method on a 386DX/40 also running -current .. asstdc:~ % time gzip /dev/null 9.417u 0.109s 0:10.63 89.4% 100+624k 9+0io 10pf+0w ... => mean of ~9.49 user secs. asstdc:~ % time compress /dev/null 3.315u 0.108s 0:03.42 99.7% 19+727k 2+0io 1pf+0w ... => mean of ~2.982 user secs. Without the qualification of not using the default method, ZIP is ~300% more predictor-1 doesn't use default method either, for the same grounds I would use -1 on gzip. The fact is that zip compression with its best configuration options is equal in CPU consumption, but better in compressing, when comparing compress with its best configuration options. Thus zip algorithm is a superior alternative. I wouldn't mind allowing better compression levels of zip algorithm as an option to pppd, though, so that I can configure my links according to the cpu available (I have a 386-16 routing my home into a 57.6k PPP link, 40%-50% of CPU goes into processing interrupts :-). -- Heikki Suonsivu, T{ysikuu 10 C 83/02210 Espoo/FINLAND, hsu@cs.hut.fi home +358-0-8031121 work -4513377 fax -4555276 riippu SN From owner-freebsd-current Sun Nov 12 21:04:04 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA14625 for current-outgoing; Sun, 12 Nov 1995 21:04:04 -0800 Received: from bunyip.cc.uq.oz.au (bunyip.cc.uq.oz.au [130.102.2.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id VAA14612 ; Sun, 12 Nov 1995 21:03:57 -0800 Received: from cc.uq.oz.au by bunyip.cc.uq.oz.au id <02761-0@bunyip.cc.uq.oz.au>; Mon, 13 Nov 1995 14:57:56 +1000 Received: from netfl15a.devetir.qld.gov.au by pandora.devetir.qld.gov.au (8.6.10/DEVETIR-E0.3a) with ESMTP id PAA11388; Mon, 13 Nov 1995 15:03:20 +1000 Received: from localhost by netfl15a.devetir.qld.gov.au (8.6.8.1/DEVETIR-0.1) id FAA29025; Mon, 13 Nov 1995 05:01:51 GMT Message-Id: <199511130501.FAA29025@netfl15a.devetir.qld.gov.au> X-Mailer: exmh version 1.6.4 10/10/95 To: bugs@freebsd.org, current@freebsd.org Subject: sethostname system call doesn't work anymore X-Face: 3}heU+2?b->-GSF-G4T4>jEB9~FR(V9lo&o>kAy=Pj&;oVOc<|pr%I/VSG"ZD32J>5gGC0N 7gj]^GI@M:LlqNd]|(2OxOxy@$6@/!,";-!OlucF^=jq8s57$%qXd/ieC8DhWmIy@J1AcnvSGV\|*! >Bvu7+0h4zCY^]{AxXKsDTlgA2m]fX$W@'8ev-Qi+-;%L'CcZ'NBL!@n?}q!M&Em3*eW7,093nOeV8 M)(u+6D;%B7j\XA/9j4!Gj~&jYzflG[#)E9sI&Xe9~y~Gn%fA7>F:YKr"Wx4cZU*6{^2ocZ!YyR Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 13 Nov 1995 15:01:50 +1000 From: Stephen Hocking Sender: owner-current@freebsd.org Precedence: bulk After the last lot of sysctl changes, hostname foo wont work. However sysctl -w kern.hostname=foo.bar.edu does. Note also domainname appears to be broken. Stephen -- I do not speak for the Worker's Compensation Board of Queensland - They don't pay me enough for that! From owner-freebsd-current Sun Nov 12 21:31:21 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA18517 for current-outgoing; Sun, 12 Nov 1995 21:31:21 -0800 Received: from localhost.lightside.com (user59.lightside.com [198.81.209.59]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA18502 ; Sun, 12 Nov 1995 21:31:18 -0800 Received: (from jehamby@localhost) by localhost.lightside.com (8.6.12/8.6.9) id VAA00258; Sun, 12 Nov 1995 21:32:15 -0800 Date: Sun, 12 Nov 1995 21:31:32 -0800 (PST) From: Jake Hamby X-Sender: jehamby@localhost To: Michael Hendrick cc: Peter Dufault , current@freebsd.org, freebsd-isp@freebsd.org Subject: Re: ISP state their FreeBSD concerns In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk On Sun, 12 Nov 1995, Michael Hendrick wrote: > > On my system at home (486DX4/100, 850MB Western Digital IDE, VLB IDE > > controller, 24MB RAM) the system does seem to freeze up for as much as 5 > > seconds when I start up a large process such as Netscape or cause one of > > When I had IDE drives, this would also happen quite frequently under > Linux, so I would guess a timing problem of some sort with the IDE > controller, not specific to FreeBSD. Perhaps this is the reason behind the common observation that "Linux freezes to a crawl when it starts swapping to disk." I was told this was one big advantage of FreeBSD. Somehow, I'm starting to think that both OS's have this problem, but perhaps this is less noticed under FreeBSD due to: 1) Different paging algorithms between FreeBSD and Linux (?) 2) More Linux users use IDE; more FreeBSD users use SCSI. ------------------------------------------------------------------------------ Jake Hamby | E-Mail: jehamby@lightside.com Student, Cal Poly University, Pomona | System Administrator, JPL ------------------------------------------------------------------------------ From owner-freebsd-current Sun Nov 12 21:54:30 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA22844 for current-outgoing; Sun, 12 Nov 1995 21:54:30 -0800 Received: (from dima@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA22831 ; Sun, 12 Nov 1995 21:54:28 -0800 Message-Id: <199511130554.VAA22831@freefall.freebsd.org> Subject: Re: Dual-personality crypt(3)!! To: davidg@Root.COM Date: Sun, 12 Nov 1995 21:54:28 -0800 (PST) Cc: mark@grondar.za, current@FreeBSD.org In-Reply-To: <199511121459.GAA02175@corbin.Root.COM> from "David Greenman" at Nov 12, 95 06:59:43 am From: dima@FreeBSD.org (Dima Ruban) X-Class: Fast Organization: HackerDome X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 860 Sender: owner-current@FreeBSD.org Precedence: bulk David Greenman writes: > > >What do you think? > > > >I have modified the DES crypt(3) to do an MD5 (exportable-style > >"encryption" if the first three characters are "$1$". (Someone (PHK?) > >gave me the idea _ages_ ago.) This will allow folks to upgrade their > >machines to DES encryption without having to fix all the user passwords > >in master.passwd. > > > >If you want to test it - I'll give you a copy. I am testing it myself, > >and will commit it in a day or two if no-one objects? > > Hmmm... what if my DES password legitimately starts with "$1$"? Wouldn't it > be better to just try the DES password and if that fails (doesn't match), then > try using MD5? Maybe better to check length of crypted password? I think, password encrypted with DES has standart length and always shorter than password, encrypted with MD5 > > -DG > -- dima From owner-freebsd-current Sun Nov 12 21:56:25 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA23272 for current-outgoing; Sun, 12 Nov 1995 21:56:25 -0800 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA23207 ; Sun, 12 Nov 1995 21:56:09 -0800 Received: from grumble.grondar.za (grumble.grondar.za [196.7.18.130]) by grunt.grondar.za (8.6.12/8.6.9) with ESMTP id HAA07363; Mon, 13 Nov 1995 07:56:03 +0200 Received: from localhost (localhost [127.0.0.1]) by grumble.grondar.za (8.6.12/8.6.9) with SMTP id HAA20286; Mon, 13 Nov 1995 07:56:02 +0200 Message-Id: <199511130556.HAA20286@grumble.grondar.za> X-Authentication-Warning: grumble.grondar.za: Host localhost didn't use HELO protocol To: John Hay cc: phk@freefall.freebsd.org (Poul-Henning Kamp), current@freefall.freebsd.org Subject: Re: Dual personality crypt. Date: Mon, 13 Nov 1995 07:56:02 +0200 From: Mark Murray Sender: owner-current@FreeBSD.org Precedence: bulk I just looked at the code. It is a Piece Of Cake (tm). M > > > > Mark, Great idea. > > > > I think you should offer an option to make new encryptions > > a) DES > > b) MD5 > > c) "the same as before" > > > > to make it general. I don't know if you can do this without changing > > the passwd program btw. > > > Yes, I like this. I would not like to be forced to have ALL new passwords > using des. > > John > -- > John Hay -- John.Hay@csir.co.za -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grumble.grondar.za for PGP key From owner-freebsd-current Sun Nov 12 22:04:08 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA24664 for current-outgoing; Sun, 12 Nov 1995 22:04:08 -0800 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA24620 for ; Sun, 12 Nov 1995 22:04:01 -0800 Received: from grumble.grondar.za (grumble.grondar.za [196.7.18.130]) by grunt.grondar.za (8.6.12/8.6.9) with ESMTP id IAA07374; Mon, 13 Nov 1995 08:03:54 +0200 Received: from localhost (localhost [127.0.0.1]) by grumble.grondar.za (8.6.12/8.6.9) with SMTP id IAA20428; Mon, 13 Nov 1995 08:03:53 +0200 Message-Id: <199511130603.IAA20428@grumble.grondar.za> X-Authentication-Warning: grumble.grondar.za: Host localhost didn't use HELO protocol To: Ollivier Robert cc: mark@grumble.grondar.za (Mark Murray), freebsd-current@FreeBSD.ORG (FreeBSD Current Users' list) Subject: Re: GNU gmp Date: Mon, 13 Nov 1995 08:03:52 +0200 From: Mark Murray Sender: owner-current@FreeBSD.ORG Precedence: bulk > Hello, Hi > Importing gmp is a good thing but generating the library as libmp.* is a > bad thing. I think we should have both libgmp.* and libmp.* (as enabled by > the -DBERKELEY flag) for compatibility with some packages which use it > (like SSH). GNU mp is not the same as Berkeley mp so having the same name > is misleading... I am planning to do that, as soon as I can figure out a clean way. Any hints about a cute way to have one makefile generate two libraries from one directory of source? I was palnning on getting cute with the before*: targets... M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grumble.grondar.za for PGP key From owner-freebsd-current Sun Nov 12 22:13:58 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA26142 for current-outgoing; Sun, 12 Nov 1995 22:13:58 -0800 Received: from jhome.DIALix.COM (jhome.DIALix.COM [192.203.228.69]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA25110 for ; Sun, 12 Nov 1995 22:06:36 -0800 Received: (from peter@localhost) by jhome.DIALix.COM (8.6.12/8.6.9) id OAA00313; Mon, 13 Nov 1995 14:05:23 +0800 Date: Mon, 13 Nov 1995 14:05:23 +0800 (WST) From: Peter Wemm To: current@freebsd.org Subject: possible sysctl fix Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk I think poor Poul-Henning must have broken a few mirrors, walked under ladders and crossed 17 black cat's paths lately to have this much bad luck... The following patch against -current fixes things for me, but I have not run it for long enough to see for sure. If you try it, make sure you can back out if you need to. Beware, I'm tired and quite possibly have screwed it.... There's a lot of changes here, some un-needed. Your mileage may vary. But it just may get you out of a jam until phk wakes up and commits a proper fix. -Peter Index: kern_sysctl.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_sysctl.c,v retrieving revision 1.38 diff -u -r1.38 kern_sysctl.c --- kern_sysctl.c 1995/11/12 19:51:51 1.38 +++ kern_sysctl.c 1995/11/13 05:30:04 @@ -300,18 +300,22 @@ { int error = 0; - if (arg1) - error = SYSCTL_OUT(req, arg1, sizeof(int)); - else if (arg2) - error = SYSCTL_OUT(req, &arg2, sizeof(int)); + if (req->oldlen) { + if (arg1) + error = SYSCTL_OUT(req, arg1, sizeof(int)); + else if (arg2) + error = SYSCTL_OUT(req, &arg2, sizeof(int)); + } - if (error || !req->newptr) + if (error) return (error); - if (!arg1) - error = EPERM; - else - error = SYSCTL_IN(req, arg1, sizeof(int)); + if (req->newptr) { + if (!arg1) + error = EPERM; + else + error = SYSCTL_IN(req, arg1, sizeof(int)); + } return (error); } @@ -327,20 +331,29 @@ { int error=0; - if (arg2) - error = SYSCTL_OUT(req, arg1, arg2); - else - error = SYSCTL_OUT(req, arg1, strlen((char *)arg1)+1); + if (req->oldlen) { +#if 0 +/* this breaks gethostname(buf, 64) (eg: gated) */ + if (arg2) + error = SYSCTL_OUT(req, arg1, arg2); + else +#endif + error = SYSCTL_OUT(req, arg1, strlen((char *)arg1)+1); + } - if (error || !req->newptr) + if (error) return (error); - if ((req->newlen - req->newidx) > arg2) { - error = E2BIG; - } else { - arg2 = (req->newlen - req->newidx); - error = SYSCTL_IN(req, arg1, arg2); - ((char *)arg1)[arg2] = '\0'; + if (req->newptr) { + if (!arg2) { + error = EPERM; + } else if ((req->newlen - req->newidx) > arg2) { + error = E2BIG; + } else { + arg2 = (req->newlen - req->newidx); + error = SYSCTL_IN(req, arg1, arg2); + ((char *)arg1)[arg2] = '\0'; + } } return (error); @@ -354,14 +367,16 @@ int sysctl_handle_opaque SYSCTL_HANDLER_ARGS { - int error; + int error = 0; - error = SYSCTL_OUT(req, arg1, arg2); + if (req->oldlen) + error = SYSCTL_OUT(req, arg1, arg2); - if (error || !req->newptr) + if (error) return (error); - error = SYSCTL_IN(req, arg1, arg2); + if (req->newptr) + error = SYSCTL_IN(req, arg1, arg2); return (error); } @@ -395,8 +410,14 @@ int sysctl_old_user(struct sysctl_req *req, void *p, int l) { - int error , i = min(req->oldlen - req->oldidx, l); + int error, i; + if (!req->oldptr) { + req->oldidx += l; + return 0; + } + + i = min(req->oldlen - req->oldidx, l); error = copyout(p, req->oldptr + req->oldidx, i); req->oldidx += i; if (error) @@ -575,6 +596,8 @@ error = sysctl_root(0, name, namelen, &req); if (!error || error == ENOMEM) { + if (req.oldptr == NULL && oldlenp) + req.oldlen = req.oldidx; if (retval) *retval = req.oldlen; if (oldlenp) { From owner-freebsd-current Sun Nov 12 23:40:11 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA14080 for current-outgoing; Sun, 12 Nov 1995 23:40:11 -0800 Received: (from dyson@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA14060 ; Sun, 12 Nov 1995 23:40:08 -0800 From: John Dyson Message-Id: <199511130740.XAA14060@freefall.freebsd.org> Subject: Re: ISP state their FreeBSD concerns To: jehamby@lightside.com (Jake Hamby) Date: Sun, 12 Nov 1995 23:40:07 -0800 (PST) Cc: mlh@poe.b2.org, dufault@hda.com, current@freebsd.org, freebsd-isp@freebsd.org In-Reply-To: from "Jake Hamby" at Nov 12, 95 09:31:32 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1425 Sender: owner-current@freebsd.org Precedence: bulk > > Perhaps this is the reason behind the common observation that "Linux > freezes to a crawl when it starts swapping to disk." I was told this was > one big advantage of FreeBSD. Somehow, I'm starting to think that both > OS's have this problem, but perhaps this is less noticed under FreeBSD > due to: > > 1) Different paging algorithms between FreeBSD and Linux (?) > 2) More Linux users use IDE; more FreeBSD users use SCSI. > The paging algorithms on both stable versions of Linux and versions through 1.3.20 (the last one that I tested) are much slower than FreeBSD.. Also, sequential I/O is slower on EXT2FS. The problem that has been seen with FreeBSD with directory lookups is due to several items, the biggest is the limited number of vnodes that FreeBSD can cache. I am actively looking at it, quantifying the problem. The benchmarks that Joe Greco has shown us actually demonstrates a worst case clash with the name/vnode caching. It *does* represent a problem and if the files are opened in the inverse order with my new async changes, it runs MUCH faster. I am NOT belittling the problem, just trying to explain that the problem is being worked and studied. The problem with going to sleep is probably due to the 30 second sync interval and all of the modified vnodes (creation, modification, usage) times and other things like that. I have been looking at that also. John dyson@freebsd.org From owner-freebsd-current Sun Nov 12 23:43:14 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA15117 for current-outgoing; Sun, 12 Nov 1995 23:43:14 -0800 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA15050 for ; Sun, 12 Nov 1995 23:42:54 -0800 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id IAA08766 ; Mon, 13 Nov 1995 08:42:00 +0100 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id IAA22821 ; Mon, 13 Nov 1995 08:41:59 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.7.1/keltia-uucp-2.6) id IAA01455; Mon, 13 Nov 1995 08:40:52 +0100 (MET) From: Ollivier Robert Message-Id: <199511130740.IAA01455@keltia.freenix.fr> Subject: Re: GNU gmp To: mark@grondar.za (Mark Murray) Date: Mon, 13 Nov 1995 08:40:51 +0100 (MET) Cc: mark@grumble.grondar.za, freebsd-current@FreeBSD.ORG In-Reply-To: <199511130603.IAA20428@grumble.grondar.za> from "Mark Murray" at Nov 13, 95 08:03:52 am X-Operating-System: FreeBSD 2.2-CURRENT ctm#1327 X-Mailer: ELM [version 2.4 PL24 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG Precedence: bulk It seems that Mark Murray said: > hints about a cute way to have one makefile generate two libraries from > one directory of source? I was palnning on getting cute with the before*: > targets... Look at how bsd.lib.mk makes the profiled libraries. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia.freenix.fr 2.2-CURRENT #1: Sun Nov 12 16:47:05 MET 1995 From owner-freebsd-current Sun Nov 12 23:56:04 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA19075 for current-outgoing; Sun, 12 Nov 1995 23:56:04 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA18982 for ; Sun, 12 Nov 1995 23:55:47 -0800 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id IAA29984; Mon, 13 Nov 1995 08:54:08 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id IAA13409; Mon, 13 Nov 1995 08:54:08 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id IAA24875; Mon, 13 Nov 1995 08:26:01 +0100 From: J Wunsch Message-Id: <199511130726.IAA24875@uriah.heep.sax.de> Subject: Re: Dual personality crypt. To: jonny@gaia.coppe.ufrj.br (Joao Carlos Mendes Luis) Date: Mon, 13 Nov 1995 08:26:00 +0100 (MET) Cc: current@freefall.freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199511130242.AAA07777@gaia.coppe.ufrj.br> from "Joao Carlos Mendes Luis" at Nov 13, 95 00:41:59 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 755 Sender: owner-current@FreeBSD.org Precedence: bulk As Joao Carlos Mendes Luis wrote: > > > Yes, I like this. I would not like to be forced to have ALL new passwords > > using des. > I hope you remember that password entries could be used by other > programs rather than login, su and passwd. If we change the crypt(3) > function drastically we may have to do lot's of new ports to deal > with these new incompatibilities. Huh? All our ports already have to be aware of the longer MD5 passwords, and that's the only implication for them. Everything else is handled transparently by crypt(3), in the shared lib case even without relinking. -- 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-current Mon Nov 13 00:01:01 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA20415 for current-outgoing; Mon, 13 Nov 1995 00:01:01 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA20251 for ; Mon, 13 Nov 1995 00:00:32 -0800 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id IAA00134; Mon, 13 Nov 1995 08:54:38 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id IAA13421; Mon, 13 Nov 1995 08:54:37 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id IAA24941; Mon, 13 Nov 1995 08:38:42 +0100 From: J Wunsch Message-Id: <199511130738.IAA24941@uriah.heep.sax.de> Subject: Re: FreeBSD 2.0.5R hanging inexplicably... To: paul@trumpet.net.au (Paul Reece) Date: Mon, 13 Nov 1995 08:38:41 +0100 (MET) Cc: scrappy@hub.org, freebsd-current@FreeBSD.org (FreeBSD-current users) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from "Paul Reece" at Nov 13, 95 03:03:46 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 464 Sender: owner-current@FreeBSD.org Precedence: bulk As Paul Reece wrote: > > I had the same problem. Since I disabled the screensavers on the console > I've had no further lockups.. > > Perhaps something that needs to be looked at closely? But that's not with pcvt, is it? The standard screensavers are not usable under pcvt (it's got its own one). -- 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-current Mon Nov 13 00:30:14 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA28647 for current-outgoing; Mon, 13 Nov 1995 00:30:14 -0800 Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id AAA28634 ; Mon, 13 Nov 1995 00:30:10 -0800 Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0tEuHH-0003w3C; Mon, 13 Nov 95 00:30 PST Received: from localhost (localhost [127.0.0.1]) by critter.tfs.com (8.6.11/8.6.9) with SMTP id JAA05216; Mon, 13 Nov 1995 09:30:05 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost didn't use HELO protocol To: Mark Murray cc: Poul-Henning Kamp , current@freefall.freebsd.org Subject: Re: Dual personality crypt. In-reply-to: Your message of "Sun, 12 Nov 1995 22:13:24 +0200." <199511122013.WAA16847@grumble.grondar.za> Date: Mon, 13 Nov 1995 09:30:05 +0100 Message-ID: <5214.816251405@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@FreeBSD.org Precedence: bulk > > Mark, Great idea. > > I think the idea may have been yours... Well, I made sure we wouldn't have problems doing it, but I had no intention of doing it myself... > > I think you should offer an option to make new encryptions > > a) DES > > b) MD5 > > c) "the same as before" > > > > to make it general. I don't know if you can do this without changing > > the passwd program btw. > > Hmm. Passwd will definitely have to co-operate. Environment variable? > Option? What? /etc/default/passwd ? -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Mon Nov 13 00:35:15 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA00177 for current-outgoing; Mon, 13 Nov 1995 00:35:15 -0800 Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id AAA00159 for ; Mon, 13 Nov 1995 00:35:11 -0800 Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0tEuLw-0003wMC; Mon, 13 Nov 95 00:34 PST Received: from localhost (localhost [127.0.0.1]) by critter.tfs.com (8.6.11/8.6.9) with SMTP id JAA05249; Mon, 13 Nov 1995 09:34:55 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost didn't use HELO protocol To: peter@haywire.dialix.com (Peter Wemm) cc: freebsd-current@freebsd.org Subject: Re: A couple of things In-reply-to: Your message of "13 Nov 1995 06:58:12 +0800." <485u64$2he$1@haywire.DIALix.COM> Date: Mon, 13 Nov 1995 09:34:55 +0100 Message-ID: <5247.816251695@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@freebsd.org Precedence: bulk > I've not looked at the gzip exec code, but what are the odds that each > executable launched from the crunched image is using up it's own > amount of ram and swap space rather than sharing pages? Or does it > try and be smart by associating the the ungzipped pages with the file > so that when the crunched image is run, the ungzipped pages are reclaimed? No, it doesn't do any kind of optimizations, what it really should do was to create a vnode for the unzipped file, and share the text as usual. Nobody I have talked to finds it worth doing. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Mon Nov 13 02:03:49 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA18756 for current-outgoing; Mon, 13 Nov 1995 02:03:49 -0800 Received: from sasami.jurai.net (root@sasami.jurai.net [205.218.122.51]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id CAA18742 ; Mon, 13 Nov 1995 02:03:44 -0800 Received: (from winter@localhost) by sasami.jurai.net (8.6.11/8.6.9) id EAA04088; Mon, 13 Nov 1995 04:03:38 -0600 Date: Mon, 13 Nov 1995 04:03:35 -0600 (CST) From: "Matthew N. Dodd" X-Sender: winter@sasami To: "Jonathan M. Bresler" cc: current@freebsd.org, freebsd-isp@freebsd.org Subject: Re: ISP state their FreeBSD concerns In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk On Sun, 12 Nov 1995, Jonathan M. Bresler wrote: > these points|perceptions are important. XXX has evidently talked > with a number of isp's and expended some effort to identify the > characteristics of FreeBSD that isp's free are most lacking. let's call > it a call-for-dialog. freebsd-isp@freebsd.org can provide the forum. > > from the initial post and the responses, i gather > > 0. more dialog between isp's and the freebsd development team. I'm not going to say anything until 2.1 comes out. At that point we will be able to make a distinction betweent our kludges and freebsd problems. I think that if everything is examined you will find that most things people want are packaging. FreeBSD allows me to do just about everything, however, for a good deal of it, I had to actually figure something out. (I rather prefer this method, but for turnkey solutions, this isn't going to work) How much time does FreeBSD project want to sink in making this happen (I'm very impressed with the package management stuff so far. Its really nice to be able to get the base os and utils installed in 45 minutes.) > 1. there is a desperate need for additional documentation of the > tutorial + example form > > 2. we need suggested configurations for specific tasks: news spool, > dial-in box, web server.... This really will depend on what software packages are going to be used. I think a better topic would be high end hardware configurations. (what disk, scsi cards, motherboards etc...) Of course this is a bigger project. :) > 3. problem reports need to provide information on how to reproduce > the problem. system configuration. system activity. log file > output. Thats only natural. > 4. isp's need to be willing to test bug fixes Well, I'm not going to test stuff on production hardware, but I do have machines that are for that express purpose. Have a good one. | Matthew N. Dodd | winter@jurai.net | http://www.jurai.net/~winter | | Technical Manager | mdodd@intersurf.net | http://www.intersurf.net | | InterSurf Online | "Welcome to the net Sir, would you like a handbasket?"| From owner-freebsd-current Mon Nov 13 05:51:49 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA23224 for current-outgoing; Mon, 13 Nov 1995 05:51:49 -0800 Received: from hutcs.cs.hut.fi (root@hutcs.cs.hut.fi [130.233.192.2]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id FAA23214 for ; Mon, 13 Nov 1995 05:51:40 -0800 Received: from shadows.cs.hut.fi by hutcs.cs.hut.fi with SMTP id AA28174 (5.65c8/HUTCS-S 1.4 for ); Mon, 13 Nov 1995 15:51:33 +0200 Received: (hsu@localhost) by shadows.cs.hut.fi (8.6.10/8.6.10) id PAA20135; Mon, 13 Nov 1995 15:51:48 +0200 Date: Mon, 13 Nov 1995 15:51:48 +0200 Message-Id: <199511131351.PAA20135@shadows.cs.hut.fi> From: Heikki Suonsivu To: current@FreeBSD.org Cc: freebsd-current@freefall.FreeBSD.org In-Reply-To: owner-freebsd-current@FreeBSD.org's message of 12 Nov 1995 07:35:31 +0200 Subject: ISP state their FreeBSD concerns Sender: owner-current@FreeBSD.org Precedence: bulk These are generally ordered with the highest concerns first: 1. A concern that FreeBSD tends to "bind" for brief periods when loaded. Here is how it was described to me: You will be doing something (like skimming news articles in trn or tin) that is hitting the hard disk perhaps once every five seconds and you are getting instant response. Then something else starts up, like tind, and the hard disk is now extremely busy (it was practically idle before tind started). Now, your disk requests aren't getting Doing a sync on our news server causes something like this, the system gets really sticky for a couple of seconds. Of course update is doing a sync every n seconds... We use -o async for the news spool, so there probably are lots of dirty pages in memory. There was a lessor complaint of mystery panics and lockups but this only came from someone who played with 2.0.0. We get panics, sometimes lockups, at pace of 1-2 machines per day (from a pool of approximately ~5 servers and ~15 routers or terminal servers built on top of FreeBSD. I'm running -current. On servers the problems seem often to be scsi related. On routers panics seem very rare, on terminal (modem) servers and routers with serial ports panic about once a week. 2. A concern that disk I/O on large (4GB or bigger) hard disks or large numbers of hard disks is not reliable, particularly on The troubling disks for us seem to be seagate hawks, but I have also had problems with an ibm 0662 (but it could be seagates in the same bus). I have tried a 2G barracuda and 4G hawk for news spool, both with same results, disk gets confused and scsi driver returns I/O errors for all accesses or the system panics. 5. Not at all obvious what system resources to increase for large and/or heavily loaded systems, and what ratios of parameter settings are best. Apparently SUN, SCO and even Linux have a lot of documentation in this area and FreeBSDs is limited, missing or not obvious. I know SCO used to have little tables that said "if you increase this, this other value should be probably increased according to this formula...". FreeBSD is different enough apparently that the rules of thumb for BSD 4.x aren't valid here. Tatu Yl|nen filed a PR about this a while ago. Better than document this would be make it easy to configure and defaults high enough. Tuning maxusers should tune everything necessary, and everything which you don't know for sure, oversize it. Now it seems that installing a FreeBSD system has defaults so small that it can't be used even for a single-user system, not to speak of a large server. 6. Multi-port serial support and even single-port serial support. cyclades driver sort-of works, if a panic approximately once a week is tolerated (could be something else than cyclades driver). Seems they feel hardware flow control doesn't work or isn't enabled when it should be (or can't be) or both. This may actually be an issue with the 16550 drivers not setting silo depth to a reasonable level. Most of these guys use terminal servers for the actual users where these local serial ports are used for UPS, router control, serial printers, and other in-house controls. They complain of seeing problems with lost data outbound when flow control was in use, including during UUCP sessions. I have complained about this several times, but gave up after I realized noone was listening. I have been including these in all our kernels: *** sys/i386/isa/sio.c.orig Thu Aug 24 21:56:48 1995 --- sys/i386/isa/sio.c Thu Aug 24 21:57:13 1995 *************** *** 71,77 **** --- 71,79 ---- #define LOTS_OF_EVENTS 64 /* helps separate urgent events from input */ #define RB_I_HIGH_WATER (TTYHOG - 2 * RS_IBUFSIZE) + #ifndef RS_IBUFSIZE #define RS_IBUFSIZE 256 + #endif #define CALLOUT_MASK 0x80 #define CONTROL_MASK 0x60 *** sys/i386/isa/cy.c.orig Thu Aug 24 21:57:50 1995 --- sys/i386/isa/cy.c Thu Aug 24 21:58:17 1995 *************** *** 153,159 **** --- 153,161 ---- #define LOTS_OF_EVENTS 64 /* helps separate urgent events from input */ #define RB_I_HIGH_WATER (TTYHOG - 2 * RS_IBUFSIZE) + #ifndef RS_IBUFSIZE #define RS_IBUFSIZE 256 + #endif #define CALLOUT_MASK 0x80 #define CONTROL_MASK 0x60 and these in my configuration files maxusers 128 options "NMBCLUSTERS=4096" options "TTYHOG=8192" options "RS_IBUFSIZE=2048" Without increasing TTYHOG I could not get even 38.4k through reliably. This was on 386-40, 486-40 and a 386-16. Curiously the 486-40 was loosing the most data, 386-40 was the best. I have oversized these, I got good results at 1k/4k, so I decided that doubling them should be enough. We use AST4's with sio (one per machine) and cyclades 16 port cards (one or two per machine). Notice that the problems don't show up with dialup modems, only with leased line stuff which really does not have any flow control. You are slowing up normal dialup modems also, but it does not show up in other than occasional inability to receive data at full 115.2k speed. Growing these values also reduces number of crashes, I do not know why. feel FreeBSD has to have a "stable" version followed by an unstable one, just because the next "." number is even and someone did releases that way accidentally ten years ago. The primary reason I use FreeBSD in our servers is better release scheme and more controlled management, gnats, cvs and such things. Also I do have the knowledge to install the missing pieces, which Linux distributions usually include. I also can deal with supping, make worlding and such things. I can also deal with panics and bugs. But I can't see how our computer-illiterated customers could do that, not even close. They want something which is complete, includes everything in sight, and never crashes. On the other hand, I understand why these ISPs want a stable core. Tweaking a few microseconds out of memory allocation or something is not interesting or relevant to them since they can get a faster system by spending money on faster hardware. What they want from the software is robustness. Code speed is secondary. Also, apps, utilities and higher-level stuff that is flakey can be worked-around, but only if that stuff exists at all. Yes! 8. File creation (particularly directories) appears to be slow compared to other BSD-like systems. They say the stats for INN and CNEWS for articles processed per second are quite a bit lower than that on some "other" systems. They say that file deletion seems to be a bit slower than BSDI, but not by much. I think they are talking 2.0.5 on this item, although one ISP was experimenting with 1026 SNAP. Generic BSD fs problem, to my knowledge. Has anyone tried to use the ext2fs in -current for this heavy problem? Could help a lot, but is it stable enough? 9. A concern that man pages don't stay formatted. They would rather chew disk space than have newbies constantly reformatting 'ls' and 'cat'. They seem to want the old BSD-style arrangement where the first time a page is accessed it gets formatted and then that copy hangs around for future reference. This seemed like something they could fix themselves, but they responded that there are dozens of things like this that they would have to re-tweak everytime the system was updated. To me this didn't seem to important, but they mentioned it. Listen to your customer... Any work is costly. You need to pro to find out why the manual pages aren't formatted, and even he will spend half an hour for every little thing like this. They probably would like to keep the pro's doing things they can bill customers at $100-$200 per hour. Another irritating thing are the des libraries, it really should work, no matter where you live. The "geometry is incorrect" when installing is something which I know would scare most unexperienced users away. Correct way to report this is "Your disk drive geometry will not work with FreeBSD. Please use values ccc/hh/ss instead." or better "Your disk drive geometry will not work with FreeBSD. Do you wish to replace the values with ccc/hh/ss (y/n) ?". BTW, Out-of-box Slackware installation doesn't format the manual pages either, at least it was like that some time ago. 10. More support for high-end hardware. I put this last because it is one of the harder things for FreeBSD to do much about since hardware vendors don't always want to tell us the tricks to making their hardware work. They aren't just talking about plug-in cards. These guys are interested in multiple-processors, things that make load scale nicely, extremely fast interconnects between systems, shared disk farms, Video-delivery bandwidths, etc. Having Support the latest whizzo video cards aren't a big deal to them, but support for disk controllers, CPUs and network interfaces are. This makes their priorities different in general from those that the average FreeBSD user probably has. Most of us aren't ready to pop down and buy a four-processor P6 system with 256Meg of RAM and three 100Mbit network interfaces, but these guys are. I agree with Jordan; this is an issue where ISP's (in addition to manufacturers) should come forward to support things by either providing hardware or, better yet, also providing money to support creating free drivers. BTW, donating for "generic BSD/Linux driver" is a lot easier to get through in management than donating for a "FreeBSD driver". But don't call it donating, call it "custom driver development" or something like that :-) A commercial support provider for *BSD* would also do a lot of good. I don't mean one-man shops. There are people who will never buy anything without a support contract. -- Heikki Suonsivu, T{ysikuu 10 C 83/02210 Espoo/FINLAND, hsu@cs.hut.fi home +358-0-8031121 work -4513377 fax -4555276 riippu SN From owner-freebsd-current Mon Nov 13 05:51:57 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA23248 for current-outgoing; Mon, 13 Nov 1995 05:51:57 -0800 Received: from hutcs.cs.hut.fi (root@hutcs.cs.hut.fi [130.233.192.2]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id FAA23231 for ; Mon, 13 Nov 1995 05:51:51 -0800 Received: from shadows.cs.hut.fi by hutcs.cs.hut.fi with SMTP id AA28174 (5.65c8/HUTCS-S 1.4 for ); Mon, 13 Nov 1995 15:51:33 +0200 Received: (hsu@localhost) by shadows.cs.hut.fi (8.6.10/8.6.10) id PAA20135; Mon, 13 Nov 1995 15:51:48 +0200 Date: Mon, 13 Nov 1995 15:51:48 +0200 Message-Id: <199511131351.PAA20135@shadows.cs.hut.fi> From: Heikki Suonsivu To: current@FreeBSD.org Cc: freebsd-current@freefall.FreeBSD.org In-Reply-To: owner-freebsd-current@FreeBSD.org's message of 12 Nov 1995 07:35:31 +0200 Subject: ISP state their FreeBSD concerns Sender: owner-current@FreeBSD.org Precedence: bulk These are generally ordered with the highest concerns first: 1. A concern that FreeBSD tends to "bind" for brief periods when loaded. Here is how it was described to me: You will be doing something (like skimming news articles in trn or tin) that is hitting the hard disk perhaps once every five seconds and you are getting instant response. Then something else starts up, like tind, and the hard disk is now extremely busy (it was practically idle before tind started). Now, your disk requests aren't getting Doing a sync on our news server causes something like this, the system gets really sticky for a couple of seconds. Of course update is doing a sync every n seconds... We use -o async for the news spool, so there probably are lots of dirty pages in memory. There was a lessor complaint of mystery panics and lockups but this only came from someone who played with 2.0.0. We get panics, sometimes lockups, at pace of 1-2 machines per day (from a pool of approximately ~5 servers and ~15 routers or terminal servers built on top of FreeBSD. I'm running -current. On servers the problems seem often to be scsi related. On routers panics seem very rare, on terminal (modem) servers and routers with serial ports panic about once a week. 2. A concern that disk I/O on large (4GB or bigger) hard disks or large numbers of hard disks is not reliable, particularly on The troubling disks for us seem to be seagate hawks, but I have also had problems with an ibm 0662 (but it could be seagates in the same bus). I have tried a 2G barracuda and 4G hawk for news spool, both with same results, disk gets confused and scsi driver returns I/O errors for all accesses or the system panics. 5. Not at all obvious what system resources to increase for large and/or heavily loaded systems, and what ratios of parameter settings are best. Apparently SUN, SCO and even Linux have a lot of documentation in this area and FreeBSDs is limited, missing or not obvious. I know SCO used to have little tables that said "if you increase this, this other value should be probably increased according to this formula...". FreeBSD is different enough apparently that the rules of thumb for BSD 4.x aren't valid here. Tatu Yl|nen filed a PR about this a while ago. Better than document this would be make it easy to configure and defaults high enough. Tuning maxusers should tune everything necessary, and everything which you don't know for sure, oversize it. Now it seems that installing a FreeBSD system has defaults so small that it can't be used even for a single-user system, not to speak of a large server. 6. Multi-port serial support and even single-port serial support. cyclades driver sort-of works, if a panic approximately once a week is tolerated (could be something else than cyclades driver). Seems they feel hardware flow control doesn't work or isn't enabled when it should be (or can't be) or both. This may actually be an issue with the 16550 drivers not setting silo depth to a reasonable level. Most of these guys use terminal servers for the actual users where these local serial ports are used for UPS, router control, serial printers, and other in-house controls. They complain of seeing problems with lost data outbound when flow control was in use, including during UUCP sessions. I have complained about this several times, but gave up after I realized noone was listening. I have been including these in all our kernels: *** sys/i386/isa/sio.c.orig Thu Aug 24 21:56:48 1995 --- sys/i386/isa/sio.c Thu Aug 24 21:57:13 1995 *************** *** 71,77 **** --- 71,79 ---- #define LOTS_OF_EVENTS 64 /* helps separate urgent events from input */ #define RB_I_HIGH_WATER (TTYHOG - 2 * RS_IBUFSIZE) + #ifndef RS_IBUFSIZE #define RS_IBUFSIZE 256 + #endif #define CALLOUT_MASK 0x80 #define CONTROL_MASK 0x60 *** sys/i386/isa/cy.c.orig Thu Aug 24 21:57:50 1995 --- sys/i386/isa/cy.c Thu Aug 24 21:58:17 1995 *************** *** 153,159 **** --- 153,161 ---- #define LOTS_OF_EVENTS 64 /* helps separate urgent events from input */ #define RB_I_HIGH_WATER (TTYHOG - 2 * RS_IBUFSIZE) + #ifndef RS_IBUFSIZE #define RS_IBUFSIZE 256 + #endif #define CALLOUT_MASK 0x80 #define CONTROL_MASK 0x60 and these in my configuration files maxusers 128 options "NMBCLUSTERS=4096" options "TTYHOG=8192" options "RS_IBUFSIZE=2048" Without increasing TTYHOG I could not get even 38.4k through reliably. This was on 386-40, 486-40 and a 386-16. Curiously the 486-40 was loosing the most data, 386-40 was the best. I have oversized these, I got good results at 1k/4k, so I decided that doubling them should be enough. We use AST4's with sio (one per machine) and cyclades 16 port cards (one or two per machine). Notice that the problems don't show up with dialup modems, only with leased line stuff which really does not have any flow control. You are slowing up normal dialup modems also, but it does not show up in other than occasional inability to receive data at full 115.2k speed. Growing these values also reduces number of crashes, I do not know why. feel FreeBSD has to have a "stable" version followed by an unstable one, just because the next "." number is even and someone did releases that way accidentally ten years ago. The primary reason I use FreeBSD in our servers is better release scheme and more controlled management, gnats, cvs and such things. Also I do have the knowledge to install the missing pieces, which Linux distributions usually include. I also can deal with supping, make worlding and such things. I can also deal with panics and bugs. But I can't see how our computer-illiterated customers could do that, not even close. They want something which is complete, includes everything in sight, and never crashes. On the other hand, I understand why these ISPs want a stable core. Tweaking a few microseconds out of memory allocation or something is not interesting or relevant to them since they can get a faster system by spending money on faster hardware. What they want from the software is robustness. Code speed is secondary. Also, apps, utilities and higher-level stuff that is flakey can be worked-around, but only if that stuff exists at all. Yes! 8. File creation (particularly directories) appears to be slow compared to other BSD-like systems. They say the stats for INN and CNEWS for articles processed per second are quite a bit lower than that on some "other" systems. They say that file deletion seems to be a bit slower than BSDI, but not by much. I think they are talking 2.0.5 on this item, although one ISP was experimenting with 1026 SNAP. Generic BSD fs problem, to my knowledge. Has anyone tried to use the ext2fs in -current for this heavy problem? Could help a lot, but is it stable enough? 9. A concern that man pages don't stay formatted. They would rather chew disk space than have newbies constantly reformatting 'ls' and 'cat'. They seem to want the old BSD-style arrangement where the first time a page is accessed it gets formatted and then that copy hangs around for future reference. This seemed like something they could fix themselves, but they responded that there are dozens of things like this that they would have to re-tweak everytime the system was updated. To me this didn't seem to important, but they mentioned it. Listen to your customer... Any work is costly. You need to pro to find out why the manual pages aren't formatted, and even he will spend half an hour for every little thing like this. They probably would like to keep the pro's doing things they can bill customers at $100-$200 per hour. Another irritating thing are the des libraries, it really should work, no matter where you live. The "geometry is incorrect" when installing is something which I know would scare most unexperienced users away. Correct way to report this is "Your disk drive geometry will not work with FreeBSD. Please use values ccc/hh/ss instead." or better "Your disk drive geometry will not work with FreeBSD. Do you wish to replace the values with ccc/hh/ss (y/n) ?". BTW, Out-of-box Slackware installation doesn't format the manual pages either, at least it was like that some time ago. 10. More support for high-end hardware. I put this last because it is one of the harder things for FreeBSD to do much about since hardware vendors don't always want to tell us the tricks to making their hardware work. They aren't just talking about plug-in cards. These guys are interested in multiple-processors, things that make load scale nicely, extremely fast interconnects between systems, shared disk farms, Video-delivery bandwidths, etc. Having Support the latest whizzo video cards aren't a big deal to them, but support for disk controllers, CPUs and network interfaces are. This makes their priorities different in general from those that the average FreeBSD user probably has. Most of us aren't ready to pop down and buy a four-processor P6 system with 256Meg of RAM and three 100Mbit network interfaces, but these guys are. I agree with Jordan; this is an issue where ISP's (in addition to manufacturers) should come forward to support things by either providing hardware or, better yet, also providing money to support creating free drivers. BTW, donating for "generic BSD/Linux driver" is a lot easier to get through in management than donating for a "FreeBSD driver". But don't call it donating, call it "custom driver development" or something like that :-) A commercial support provider for *BSD* would also do a lot of good. I don't mean one-man shops. There are people who will never buy anything without a support contract. -- Heikki Suonsivu, T{ysikuu 10 C 83/02210 Espoo/FINLAND, hsu@cs.hut.fi home +358-0-8031121 work -4513377 fax -4555276 riippu SN From owner-freebsd-current Mon Nov 13 06:22:40 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA25385 for current-outgoing; Mon, 13 Nov 1995 06:22:40 -0800 Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA25371 for ; Mon, 13 Nov 1995 06:22:34 -0800 Received: from vanuata.dcs.gla.ac.uk (vanuata.dcs.gla.ac.uk [130.209.240.50]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id GAA06017 for ; Mon, 13 Nov 1995 06:22:21 -0800 Message-Id: <199511131422.GAA06017@who.cdrom.com> Received: from savage-gw.dcs.gla.ac.uk by vanuata.dcs.gla.ac.uk with LOCAL SMTP (PP); Mon, 13 Nov 1995 13:43:52 +0000 To: uhclem (Frank Durda IV) <@fw.ast.com:uhclem@nemesis> cc: current@freebsd.org Subject: Re: Disk I/O that binds In-reply-to: Your message of "Sun, 12 Nov 1995 13:13:00 +0700." Date: Mon, 13 Nov 1995 13:42:45 +0000 From: Simon Marlow Sender: owner-current@freebsd.org Precedence: bulk > My system where I have seen something that somewhat resembles his > description is a mixed IDE SCSI system, and when things bog, the hog > process and the binding process are both trying to get to the same > SCSI drive. The IDE is for swap and root and is idle during these events. > > And in answer to someone elses' question, there was no tape I/O or > CD-ROM I/O active during these events on either system. Only SCSI disk. Just a guess, but could this be caused by the disk request sorting done by FreeBSD? New requests get entered into the queue possibly before old ones, and it could be a long time before a request finally gets serviced. Cheers, Simon -- Simon Marlow simonm@dcs.gla.ac.uk Research Assistant http://www.dcs.gla.ac.uk/~simonm/ finger for PGP public key From owner-freebsd-current Mon Nov 13 06:25:49 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA25764 for current-outgoing; Mon, 13 Nov 1995 06:25:49 -0800 Received: from ns0.netcraft.co.uk (ns0.netcraft.co.uk [194.72.238.4]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA25719 ; Mon, 13 Nov 1995 06:25:38 -0800 Received: (from paul@localhost) by ns0.netcraft.co.uk (8.6.12/8.6.9) id OAA08697; Mon, 13 Nov 1995 14:19:37 GMT From: Paul Richards Message-Id: <199511131419.OAA08697@ns0.netcraft.co.uk> Subject: Re: FreeBSD 2.0.5R hanging inexplicably... To: paul@trumpet.net.au (Paul Reece) Date: Mon, 13 Nov 1995 14:19:37 +0000 (GMT) Cc: scrappy@hub.org, freebsd-questions@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-hackers@FreeBSD.org In-Reply-To: from "Paul Reece" at Nov 13, 95 03:03:46 pm Reply-to: paul@netcraft.co.uk X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 2991 Sender: owner-current@FreeBSD.org Precedence: bulk In reply to Paul Reece who said > > On Sun, 12 Nov 1995, Marc G. Fournier wrote: > > > For the second time in two days, my system just hung, in that, > > essentially, no keyboard input was being permitted. > > Which version are you running? I had this happen a lot with 2.0.5 since it didn't handle keyboard disconnection and unplugging and putting the keyboard back made it dissappear. I also had it happen "randomly" quite frequently but I put that down to the some quirk triggering the same problem. When I upgraded to stable the problem went away BUT I did have it happen to me once about three days ago shortly after reboot (5 mins say) just after upgrading to stable again. That's the only time it's happened in the last 6 weeks or so but there may be a problem lurking in there somewhere. This is with PCVT. I've had worse problems with syscons. There's something wrong with syscons vt switching, it's not completely reproducable but it happens frequently enough that I've now switched all our machines to pcvt. The symptom is that when you switch VT the screen goes completely blank and further attempts to switch VT just gets a beep (as though no VT was configured). Everything is still running (getty etc) but the screen is just totally blank. Only way to recover the console is to reboot. > > The first time, I'm sure it had to do with PCVT, in that it happened > > the moment after I had modified /etc/ttys and turned off all the console > > screens that I'm not using and issued a kill -1 1. Even after reboot, it > > hung almost immediately. When I booted up into single user mode, and > > turned those ports back on, it was all fine. > > > > Of significance to note in that case, everything ran fine in the > > background, it was just a console lock. The keyboard lock problems I've seen have been purely keyboard problems. I can start X terms on other machines and have them appear on the locked console so the display is still working fine. > > That is the symptoms...now the question...are there any known > > problems with PCVT under 2.0.5R that have been fixed in 2.1.0-*-SNAP? > > If not...how do I debug something like this? Since it hangs, and doesn't > > fault itself, getting a core dump, so I'd think, is kind of difficult... I'd say yes, I had this keyboard problem happen regularly with 2.0.5 and apart from this one lockup I had a few days ago everythings been fine since upgrading to 2.1-stable. I doubt the lockup I had a few days ago is the same problem since the old problem would happen every few hours, for the moment I'm putting this last lockup down to the phase of the moon :-) A nice feature would be an ioctl that caused the console driver to reset itself so that you can log in across the net and run some user-land util to reset the console driver without having to reboot. -- Paul Richards, Netcraft Ltd. Internet: paul@netcraft.co.uk, http://www.netcraft.co.uk Phone: 0370 462071 (Mobile), +44 1225 447500 (work) From owner-freebsd-current Mon Nov 13 08:25:04 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA07932 for current-outgoing; Mon, 13 Nov 1995 08:25:04 -0800 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA07924 for ; Mon, 13 Nov 1995 08:25:00 -0800 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id IAA26752; Mon, 13 Nov 1995 08:24:59 -0800 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id IAA04109; Mon, 13 Nov 1995 08:21:10 -0800 Message-Id: <199511131621.IAA04109@corbin.Root.COM> To: Heikki Suonsivu cc: current@freebsd.org Subject: Re: ISP state their FreeBSD concerns In-reply-to: Your message of "Mon, 13 Nov 95 15:51:48 +0200." <199511131351.PAA20135@shadows.cs.hut.fi> From: David Greenman Reply-To: davidg@Root.COM Date: Mon, 13 Nov 1995 08:21:09 -0800 Sender: owner-current@freebsd.org Precedence: bulk >The troubling disks for us seem to be seagate hawks, but I have also had >problems with an ibm 0662 (but it could be seagates in the same bus). I >have tried a 2G barracuda and 4G hawk for news spool, both with same >results, disk gets confused and scsi driver returns I/O errors for all >accesses or the system panics. We've been having similar problems with Seagate Hawks on wcarchive. I plan to switch them out for 4GB Quantum Grand Prixs in the near term. -DG From owner-freebsd-current Mon Nov 13 08:30:57 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA08364 for current-outgoing; Mon, 13 Nov 1995 08:30:57 -0800 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA08352 for ; Mon, 13 Nov 1995 08:30:53 -0800 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id IAA26756; Mon, 13 Nov 1995 08:30:48 -0800 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id IAA04123; Mon, 13 Nov 1995 08:26:58 -0800 Message-Id: <199511131626.IAA04123@corbin.Root.COM> To: Simon Marlow cc: uhclem (Frank Durda IV) <@fw.ast.com:uhclem@nemesis>, current@freebsd.org Subject: Re: Disk I/O that binds In-reply-to: Your message of "Mon, 13 Nov 95 13:42:45 GMT." <199511131422.GAA06017@who.cdrom.com> From: David Greenman Reply-To: davidg@Root.COM Date: Mon, 13 Nov 1995 08:26:53 -0800 Sender: owner-current@freebsd.org Precedence: bulk > >> My system where I have seen something that somewhat resembles his >> description is a mixed IDE SCSI system, and when things bog, the hog >> process and the binding process are both trying to get to the same >> SCSI drive. The IDE is for swap and root and is idle during these events. >> >> And in answer to someone elses' question, there was no tape I/O or >> CD-ROM I/O active during these events on either system. Only SCSI disk. > >Just a guess, but could this be caused by the disk request sorting >done by FreeBSD? New requests get entered into the queue possibly >before old ones, and it could be a long time before a request finally >gets serviced. Yes, and this does contribute to the problem. This was the topic of a recent discussion between myself and John Dyson. Our disksort could use a little work. One thing I'd like to do is make it possible for the driver to request that no sorting be done. This would allow controllers that can do tagged queuing to pass the I/O off to the drive unordered - allowing the drive to use superior sorting algorithms. -DG From owner-freebsd-current Mon Nov 13 09:00:48 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA11214 for current-outgoing; Mon, 13 Nov 1995 09:00:48 -0800 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA11175 for ; Mon, 13 Nov 1995 09:00:35 -0800 Received: from grumble.grondar.za (grumble.grondar.za [196.7.18.130]) by grunt.grondar.za (8.6.12/8.6.9) with ESMTP id TAA07987; Mon, 13 Nov 1995 19:00:25 +0200 Received: from localhost (localhost [127.0.0.1]) by grumble.grondar.za (8.6.12/8.6.9) with SMTP id TAA22739; Mon, 13 Nov 1995 19:00:24 +0200 Message-Id: <199511131700.TAA22739@grumble.grondar.za> X-Authentication-Warning: grumble.grondar.za: Host localhost didn't use HELO protocol To: Ollivier Robert cc: freebsd-current@FreeBSD.ORG Subject: Re: GNU gmp Date: Mon, 13 Nov 1995 19:00:24 +0200 From: Mark Murray Sender: owner-current@FreeBSD.ORG Precedence: bulk > It seems that Mark Murray said: > > hints about a cute way to have one makefile generate two libraries from > > one directory of source? I was palnning on getting cute with the before*: > > targets... > > Look at how bsd.lib.mk makes the profiled libraries. :-( That seems a little hard-coded towards lib*.a, lib*_p.a and lib*.so.m.n. Are there any precedents in the code where this has been done before? (This does not mean I have not looked - It means I have not found) M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grumble.grondar.za for PGP key From owner-freebsd-current Mon Nov 13 10:22:11 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA16195 for current-outgoing; Mon, 13 Nov 1995 10:22:11 -0800 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA16184 for ; Mon, 13 Nov 1995 10:22:08 -0800 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA16915; Mon, 13 Nov 1995 11:15:05 -0700 From: Terry Lambert Message-Id: <199511131815.LAA16915@phaeton.artisoft.com> Subject: Re: ISP state their FreeBSD concerns To: jgreco@brasil.moneng.mei.com (Joe Greco) Date: Mon, 13 Nov 1995 11:15:05 -0700 (MST) Cc: dyson@freefall.freebsd.org, current@FreeBSD.org In-Reply-To: <199511120717.BAA25951@brasil.moneng.mei.com> from "Joe Greco" at Nov 12, 95 01:17:11 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1844 Sender: owner-current@FreeBSD.org Precedence: bulk > > I am working on this stuff right now. Give me benchmarks!!!! I'll > > do what I can. > > This noted as well. I am frustrated that I cannot seem to hit more than a > PEAK of 4 arts/sec without MMAP, or around 5.5-6 with MMAP. My pet Solaris > news server, with PrestoServe and 128MB RAM, and only 4 disks, can peak out > at around 15. I do know that with only 48MB of RAM, news.sol.net takes more > of a hit on history lookups (expected), but with the I/O load spread over a > dozen disks, I would expect that would compensate somewhat... PrestoServe does striping. Striping is a win for concurrency of access; probably not nearly the win kernel reentrancy would be in effective concurrency, but still a major win. I would like to see striping, volume spanning, and other technologies integrated by way of devfs. This requires a cleanup/reworking of the way that volumes and media perfection, etc. are handled in BSD in general, and the whole idea of logical drives in specific. > Test code that breaks, problematic - at least as far as MMAP goes. MMAP > appears to work fine at first glance, but the panic rate of the system goes > from once every few weeks to once every two or three days. I have no idea > what tickles it. Any way to get a traceback? Any particular panic message? Can you force the panic to happen? > I can probably get you some numbers in terms of file creation/removal rates > on both Solaris x86 and FreeBSD 2.1R (well, SNAP). I don't know what they > will look like so it would be a doubly interesting test for me to perform. Unless the Solaris volumes are mounted async, I expect them to be on the same order as FreeBSD numbers if taken from similar drives. 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-current Mon Nov 13 10:25:18 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA16446 for current-outgoing; Mon, 13 Nov 1995 10:25:18 -0800 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA16426 for ; Mon, 13 Nov 1995 10:25:10 -0800 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA16930; Mon, 13 Nov 1995 11:19:05 -0700 From: Terry Lambert Message-Id: <199511131819.LAA16930@phaeton.artisoft.com> Subject: Re: ISP state their FreeBSD concerns To: dufault@hda.com (Peter Dufault) Date: Mon, 13 Nov 1995 11:19:05 -0700 (MST) Cc: current@FreeBSD.org In-Reply-To: <199511121350.IAA00279@hda.com> from "Peter Dufault" at Nov 12, 95 08:50:57 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1217 Sender: owner-current@FreeBSD.org Precedence: bulk > > 1. A concern that FreeBSD tends to "bind" for brief periods when > > loaded... > > Can this is an IDE issue? I never saw anything like this until > I configured an IDE mail server. That system pauses for seconds > sometimes, and then continues. This is running -stable, syscons > only (no X), no messages logged, etc. The echo stops going to > the display, the ethernet activity is stopped, all in all it seems > to be locked up for three or four seconds. > > We have three SCSI only systems and haven't ever seen this, and > one IDE system that pauses. I have seen pauses on the order of a second or two on a SCSI system with PCI + NCR controller. Typically, there are no console messages associated, as one would expect with timeouts (which the IDE theory implies). When the pauses start happening, they will continue happening with a moderate frequency. Typing "sync" will cure the problem for a short period of time, after which it will recurr. Generally, I type "sync" often enough from my V6 background that it doesn't hit me. When it does, it's obvious. 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-current Mon Nov 13 10:28:35 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA16707 for current-outgoing; Mon, 13 Nov 1995 10:28:35 -0800 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA16698 for ; Mon, 13 Nov 1995 10:28:31 -0800 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA16943; Mon, 13 Nov 1995 11:23:01 -0700 From: Terry Lambert Message-Id: <199511131823.LAA16943@phaeton.artisoft.com> Subject: Re: ISP state their FreeBSD concerns To: karl@mcs.com (Karl Denninger, MCSNet) Date: Mon, 13 Nov 1995 11:23:01 -0700 (MST) Cc: current@FreeBSD.org In-Reply-To: from "Karl Denninger, MCSNet" at Nov 12, 95 09:59:26 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 940 Sender: owner-current@FreeBSD.org Precedence: bulk > The only other issue we have here is the nasty NFS-write problem that makes > shared access to remote resources tricky at best. If *THAT* was fixed we > would be running FreeBSD exclusively here. Is this the "write with no permission truncate" or what? What is this NFS write problem? > I've been using FreeBSD exclusively for news service for quite a while > (some clients use NFS, others NNTP to read) and its been fine. What we > have a problem with is using it for our web server and general user system > farm; the small NFS writes that the httpds do to the log disks cause system > lockups and hundreds of processes in a hung state. The problem is understood, > but there is no immediate path to a fix from what I've been told. Who understands this problem, so I can talk to them? 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-current Mon Nov 13 10:59:26 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA18699 for current-outgoing; Mon, 13 Nov 1995 10:59:26 -0800 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA18692 for ; Mon, 13 Nov 1995 10:59:21 -0800 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA17000; Mon, 13 Nov 1995 11:52:43 -0700 From: Terry Lambert Message-Id: <199511131852.LAA17000@phaeton.artisoft.com> Subject: Re: ISP state their FreeBSD concerns To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Mon, 13 Nov 1995 11:52:43 -0700 (MST) Cc: current@FreeBSD.org In-Reply-To: <14486.816158986@time.cdrom.com> from "Jordan K. Hubbard" at Nov 11, 95 10:49:46 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 8065 Sender: owner-current@FreeBSD.org Precedence: bulk > > First off, I really have to wonder why Frank Durda went to what was > obviously a considerable effort to be anonymous. The message had no > signature and has been sent with a "From" of -current. C'mon Frank, > we don't bite! Valid criticism always has a place in these lists and > going out of your way to mask its origin only calls its validity into > question unnecessarily. If I didn't know you were the only poster > we've ever had from fw.ast.com, I might have thought this was > something with a deeper political agenda from one of the other *BSD > advocates and ignored it. Frank obviously includes his signiture manually, and simply did the incantation as the last thing before sending -- and happened to be in insert mode. I don't think he was hiding. > > 1. A concern that FreeBSD tends to "bind" for brief periods when > > loaded. Here is how it was described to me: You will be doing > > something (like skimming news articles in trn or tin) that is > > This one really needs some additional context. Suffice it to say that > I've not experienced such behavior myself, and that's about all one > can say with a fairly subjective report like this. That's not to say > that it's totally lacking in validity, but consider what you yourself > would do with a user report that "the system seemed slow." Try "the system appears to halt for a few seconds". To repeat: Build a system with: P90 with ASUS motherboard 16M of physical memory or less A lot of swap An NCR SCSI controller 1G or more of disk Then: Build a bunch of kernels Build world once or twice (get that cache nice and full and fragmented) Pop up an xterm Run Elm on a couple of large mailboxes It's infinitely repeatable. I do it 3-4 times a week. Typing "sync" fixes the problem for a while, as does rebooting. I believe it to be an over-caching issue. Maybe there needs to be a high/low watermarking on how much of memory is allowed to be used vor buffer cache vs. VM. Or a page reserver for VM that is not allowed to be allocated for buffers. Etc. It seems to be a starvation deadlock. > > 4. A concern about problems related to filesystem stacks, such as > > ISO9660 and DOS. (They may be talking about Samba, and not > > the actual mounting of DOS filesystems.) One of the ISO9660 > > issues is the one I reported last week where a plain user > > can easily break all mounted ISO9660 access and hang all processes > > that attempt to access the ISO filesystems. (We discovered this > > on one of the local ISPs archive server - they were not pleased.) > > These guys with lots of CD-ROMs mounted on their systems don't > > like the sound of that remaining broken for any period of time, > > particularly when it ripples to other systems via NFS. > > DOS filesystem support is broken. I would not be surprised to learn that > the ISO9660 support was full of mice as well. Neither of these things > will be fixed until either: > > 1. Somebody volunteers the time. I would be happy to fix this. Unfortunately, the relookup() is the main failure mode for this (from my investigations), and it seems that there are some indeterminate states that the VFS can get into because of the layering abstraction being broken. Ultimately, I'd like to get rid of relookup() entirely by propagating the lock mechanism up and allowing lock reentrancy in other than the ffs_readwrite.c case. > > 6. Multi-port serial support and even single-port serial support. > > Seems they feel hardware flow control doesn't work or isn't enabled > > when it should be (or can't be) or both. This may actually be > > an issue with the 16550 drivers not setting silo depth to a > > reasonable level. Most of these guys use terminal servers for > > the actual users where these local serial ports are used for UPS, > > router control, serial printers, and other in-house controls. They > > complain of seeing problems with lost data outbound when flow > > control was in use, including during UUCP sessions. > > I use a standard serial port for a 115.2K ISDN connection and it works > *great*, even better than a friend of mine who's using a Cisco for the > purpose and looks enviously at my 10.5K/sec FTP transfer rates when > he's only getting 7K. Not to say that this scales to hundreds of > serial ports or anything, but it does work! He didn't identify hardware vs. software flow control. If software, then his observation about SILO depth is well taken. Your ^S could be in limbo for quite some time before it is seen. A ^Q in limbo is a much worse problem, actually. > > They point to Linux, where the core seems to be going through > > few changes (what about the "FT" guys?), or a purchased system > > (SUN/SCO) which sees a maintenance release that only alters a small > > 1. Linux is hardly unchanging, the FT effort being still mostly on the > drawing board. This was a counterexample of "tinkering under the hood" on Linux. > 2. SCO doesn't change because it's been *moribund* for years! They started > with a mediocre system and enshrined it. You won't get very far with > me by holding them up as any sort of paragon to be emulated. I've done > my time with SCO, from both ends of the picture, and all of it was > unilaterally horrible. Commercial release processes have advantages and disadvantages. The BSD release processes are nowhere near commercial quality on QA/QC, but they frequently include much more than a typical commercial release, which is simply a different tradeoff between sureity and stagnation than that which SCO makes. > > 8. File creation (particularly directories) appears to be slow compared > > to other BSD-like systems. They say the stats for INN and CNEWS > > for articles processed per second are quite a bit lower than that > > on some "other" systems. They say that file deletion seems to be > > a bit slower than BSDI, but not by much. I think they are talking > > 2.0.5 on this item, although one ISP was experimenting with 1026 SNAP. > > It would help if they could percolate this down to some benchmarks > that could be easily run by the people responsible for enhancing said > performance. It's hard to speed up what you can't reproduce without > being on-site with the ISP. I think the University of Michigan EECS's paper on "Metadata Update Performance in File Systems" (USENIX Symposium on Operating Systems Design and Implementation, November 1994, pp. 49-60) is well taken in this regard. They used BSDI as their base platform, so their code will need rewriting before they can release it. It wants ~1500 lines of changes to the buffer cache code. > > 10. More support for high-end hardware. I put this last because > > it is one of the harder things for FreeBSD to do much about > > since hardware vendors don't always want to tell us the tricks > > We're working on it, though if some people want to DONATE said > high-end hardware to us so that we have a better chance of actually > doing it, it would be a great help.w These people don't expect us to > go out of pocket for $8K multi-CPU P6 machines now do they? Your ISPs > seem to expect a lot if so! :-) Depending on the hardware you insist on having with it, a 2 CPU P90 box costs on the order of $2000. A 2 CPU PPC-66 box costs on the order of $2600. That said, there does not seem to be much interest in integrating changes that move toward SMP and other high end hardware support. Full on SMP support will require many incremental moves in the direction of kernel multithreading before high grain parallelism can be put into place. One of the main issues here is enabling the code for subsystem level mutex based locking by simplifying the task of maintaining lock state; the best was to achieve this is to enable the code for routine entrancy/exit locking to allow incremental enabling of reentrancy at the system call layer. 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-current Mon Nov 13 11:28:31 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA20949 for current-outgoing; Mon, 13 Nov 1995 11:28:31 -0800 Received: from kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA20943 for ; Mon, 13 Nov 1995 11:28:25 -0800 Received: from venus.mcs.com (root@Venus.mcs.com [192.160.127.92]) by kitten.mcs.com (8.6.10/8.6.9) with SMTP id NAA15348; Mon, 13 Nov 1995 13:28:18 -0600 Received: by venus.mcs.com (/\==/\ Smail3.1.28.1 #28.5) id ; Mon, 13 Nov 95 13:28 CST Message-Id: Subject: Re: ISP state their FreeBSD concerns To: terry@lambert.org (Terry Lambert) Date: Mon, 13 Nov 1995 13:28:18 -0600 (CST) From: "Karl Denninger, MCSNet" Cc: current@FreeBSD.org In-Reply-To: <199511131823.LAA16943@phaeton.artisoft.com> from "Terry Lambert" at Nov 13, 95 11:23:01 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1462 Sender: owner-current@FreeBSD.org Precedence: bulk > > > The only other issue we have here is the nasty NFS-write problem that makes > > shared access to remote resources tricky at best. If *THAT* was fixed we > > would be running FreeBSD exclusively here. > > Is this the "write with no permission truncate" or what? What is this > NFS write problem? The symptom is that processes block while waiting for writes to complete, sometimes for as long as several *minutes*. For a system which is taking hundreds of hits per minute, this quickly blows the system sky-high. > > I've been using FreeBSD exclusively for news service for quite a while > > (some clients use NFS, others NNTP to read) and its been fine. What we > > have a problem with is using it for our web server and general user system > > farm; the small NFS writes that the httpds do to the log disks cause system > > lockups and hundreds of processes in a hung state. The problem is understood, > > but there is no immediate path to a fix from what I've been told. > > Who understands this problem, so I can talk to them? Mr. Dyson has some ideas... -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity Modem: [+1 312 248-0900] | (shell, PPP, SLIP, leased) in Chicagoland Voice: [+1 312 803-MCS1] | 7 Chicagoland POPs, ISDN, 28.8, much more Fax: [+1 312 248-9865] | Email to "info@mcs.net" WWW: http://www.mcs.net ISDN - Get it here TODAY! | Home of Chicago's *Three STAR A* Clarinet feed! - From owner-freebsd-current Mon Nov 13 11:34:04 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA21384 for current-outgoing; Mon, 13 Nov 1995 11:34:04 -0800 Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id LAA21378 ; Mon, 13 Nov 1995 11:34:02 -0800 Received: from gemini.sdsp.mc.xerox.com ([13.231.132.20]) by alpha.xerox.com with SMTP id <16873(9)>; Mon, 13 Nov 1995 11:12:04 PST Received: from gnu.mc.xerox.com (gnu.sdsp.mc.xerox.com) by gemini.sdsp.mc.xerox.com (4.1/SMI-4.1) id AA27201; Mon, 13 Nov 95 14:11:26 EST Received: by gnu.mc.xerox.com (4.1/SMI-4.1) id AA13107; Mon, 13 Nov 95 14:11:24 EST Message-Id: <9511131911.AA13107@gnu.mc.xerox.com> X-Mailer: exmh version 1.6.4 10/10/95 To: michael butler Cc: hsu@cs.hut.fi (Heikki Suonsivu), peter@freefall.freebsd.org, freebsd-current@freefall.freebsd.org, brad@fcr.com, paulus@cs.anu.edu.au Subject: Re: cvs commit: src/usr.sbin/pppd RELNOTES In-Reply-To: Your message of "Sat, 11 Nov 1995 02:52:54 PST." <199511111052.VAA09030@asstdc.scgt.oz.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 13 Nov 1995 11:11:16 PST From: "Marty Leisner" Sender: owner-current@FreeBSD.org Precedence: bulk > Heikki Suonsivu writes: > > > Has anyone looked at it, if it could be modified to do zip compression > > instead. > > ZIP is computationally expensive .. you'll speed most of your time in the > kernel and little doing much else. The "predictor-1" algorithm already in > use by iij-ppp is a lightweight alternative, > > michael > >From experience, I've seen zip compresses somewhat slower and decompresses somewhat faster... In fact, the gzip decompression of compress archives is faster than compress (I don't know quite what they're doing, but it what I've seen...) It also compresses better than compress... With the least amount of compression, you get better compression than compress, and the cycle times (decompression/compression) may be close to a wash. -- marty leisner@sdsp.mc.xerox.com Member of the League for Programming Freedom From owner-freebsd-current Mon Nov 13 11:50:00 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA22619 for current-outgoing; Mon, 13 Nov 1995 11:50:00 -0800 Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.20.4]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA22612 for ; Mon, 13 Nov 1995 11:49:57 -0800 Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id NAA27664; Mon, 13 Nov 1995 13:49:08 -0600 From: Joe Greco Message-Id: <199511131949.NAA27664@brasil.moneng.mei.com> Subject: Re: ISP state their FreeBSD concerns To: terry@lambert.org (Terry Lambert) Date: Mon, 13 Nov 1995 13:49:08 -0600 (CST) Cc: dyson@freefall.freebsd.org, current@FreeBSD.org In-Reply-To: <199511131815.LAA16915@phaeton.artisoft.com> from "Terry Lambert" at Nov 13, 95 11:15:05 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@FreeBSD.org Precedence: bulk > > This noted as well. I am frustrated that I cannot seem to hit more than a > > PEAK of 4 arts/sec without MMAP, or around 5.5-6 with MMAP. My pet Solaris > > news server, with PrestoServe and 128MB RAM, and only 4 disks, can peak out > > at around 15. I do know that with only 48MB of RAM, news.sol.net takes more > > of a hit on history lookups (expected), but with the I/O load spread over a > > dozen disks, I would expect that would compensate somewhat... > > PrestoServe does striping. Striping is a win for concurrency of access; > probably not nearly the win kernel reentrancy would be in effective > concurrency, but still a major win. PrestoServe does not do striping. PrestoServe does writeback caching. This helps by a large margin on things like metadata updates (because you can write to cache and have a change queued to be written to the drive, and make several more changes before the write actually gets scheduled to hit the physical disk). On-Line Disk Suite does striping, concatenation, mirroring, and logging filesystems. It and PrestoServe are only somewhat compatible :-/ The other factor is that for effective concurrency, you need multiple processes. INN is a monolithic news processing engine, and you cannot get the kind of concurrency needed to increase article processing performance even on a multi-CPU Solaris box. (well, this is an oversimplification of the problem, but the point is that it is a single process which needs to be able to do many hundreds of disk I/Os per second). > I would like to see striping, volume spanning, and other technologies > integrated by way of devfs. This requires a cleanup/reworking of the > way that volumes and media perfection, etc. are handled in BSD in general, > and the whole idea of logical drives in specific. I would like to see this as well :-) > > Test code that breaks, problematic - at least as far as MMAP goes. MMAP > > appears to work fine at first glance, but the panic rate of the system goes > > from once every few weeks to once every two or three days. I have no idea > > what tickles it. > > Any way to get a traceback? Any particular panic message? I hadn't tried recently (post-2.0.5). I am more than willing to try things iff there is any interest by qualified parties (that would most likely be the VM gods) to try to analyze the dumps to determine what happened. > Can you force the panic to happen? Yeah, I can run the system with MMAP. :-) (well, as noted, I haven't tried under the latest SNAP to cause this behaviour, but I AM willing to put my feet in those fires again if it will be USEFUL). > > I can probably get you some numbers in terms of file creation/removal rates > > on both Solaris x86 and FreeBSD 2.1R (well, SNAP). I don't know what they > > will look like so it would be a doubly interesting test for me to perform. > > Unless the Solaris volumes are mounted async, I expect them to be on > the same order as FreeBSD numbers if taken from similar drives. Taken from THE SAME drive, Slowaris 5.4 - SS10/30 - 64MB RAM (SCSI II, reasonable drive) 10000 files in 332 seconds - first run 10000 files in 20 !!! seconds - second run FreeBSD 2.0.5R - ASUS SP3G AMD 486DX2/66 + NCR810 - 8MB (SCSI II, reasonable drive) 10000 files in 620 seconds - first run :-( :-( 10000 files in 310 seconds - second run :-( :-( :-( !! That does not appear to be "the same order as" :-( I haven't yet tried Solaris x86 - we just got gcc installed on our "test box" today. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 From owner-freebsd-current Mon Nov 13 12:46:59 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA26929 for current-outgoing; Mon, 13 Nov 1995 12:46:59 -0800 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA26920 for ; Mon, 13 Nov 1995 12:46:56 -0800 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA17961; Mon, 13 Nov 1995 13:41:13 -0700 From: Terry Lambert Message-Id: <199511132041.NAA17961@phaeton.artisoft.com> Subject: Re: ISP state their FreeBSD concerns To: karl@mcs.com (Karl Denninger, MCSNet) Date: Mon, 13 Nov 1995 13:41:13 -0700 (MST) Cc: terry@lambert.org, current@FreeBSD.org In-Reply-To: from "Karl Denninger, MCSNet" at Nov 13, 95 01:28:18 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2041 Sender: owner-current@FreeBSD.org Precedence: bulk > > > The only other issue we have here is the nasty NFS-write problem that makes > > > shared access to remote resources tricky at best. If *THAT* was fixed we > > > would be running FreeBSD exclusively here. > > > > Is this the "write with no permission truncate" or what? What is this > > NFS write problem? > > The symptom is that processes block while waiting for writes to complete, > sometimes for as long as several *minutes*. For a system which is taking > hundreds of hits per minute, this quickly blows the system sky-high. Ah. So the hangs are on the client. The NFS protocol definition is that the writes must complete before the call returns to the user process. There are three ways to solve this problem: 1) Client caching. The operation writes local cache and then starts an async event with a completion routine. The async event waits for the ack from the NFS server and releases the page hold. This is dangerous, since the data pretends to be committed when in fact it only exists in the local systems memory. Not a problem for news servers, but a real problem for transaction oriented databases. Client caching is disallowed by the NFS design document. 2) Server caching. The operation is returned completed by the server, which then starts an async event, but no completion routine is associated with the event. This is dangerous for similar reasons of data integrity. Server caching is disallowed by the NFS design document unless the state can be maintained across a server failure. This means log structuring with log data sotred in non volatile memory (ala Auspex, etc.) so the transaction may be rolled forward. 3) Increase the number of nfsiod's on the server. This will allow more concurrent operations to be outstanding at one time. This is allowed (encouraged) by the NFS design document. Number 3 is well within your control. 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-current Mon Nov 13 12:52:59 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA27462 for current-outgoing; Mon, 13 Nov 1995 12:52:59 -0800 Received: from kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA27454 for ; Mon, 13 Nov 1995 12:52:57 -0800 Received: from venus.mcs.com (root@Venus.mcs.com [192.160.127.92]) by kitten.mcs.com (8.6.10/8.6.9) with SMTP id OAA19025; Mon, 13 Nov 1995 14:52:56 -0600 Received: by venus.mcs.com (/\==/\ Smail3.1.28.1 #28.5) id ; Mon, 13 Nov 95 14:52 CST Message-Id: Subject: Re: ISP state their FreeBSD concerns To: terry@lambert.org (Terry Lambert) Date: Mon, 13 Nov 1995 14:52:54 -0600 (CST) From: "Karl Denninger, MCSNet" Cc: terry@lambert.org, current@FreeBSD.org In-Reply-To: <199511132041.NAA17961@phaeton.artisoft.com> from "Terry Lambert" at Nov 13, 95 01:41:13 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 2195 Sender: owner-current@FreeBSD.org Precedence: bulk > > > Is this the "write with no permission truncate" or what? What is this > > > NFS write problem? > > > > The symptom is that processes block while waiting for writes to complete, > > sometimes for as long as several *minutes*. For a system which is taking > > hundreds of hits per minute, this quickly blows the system sky-high. > > Ah. So the hangs are on the client. > > The NFS protocol definition is that the writes must complete before the > call returns to the user process. Yes, yes, I know. That's not the problem. > There are three ways to solve this problem: You're assuming the server is too slow. Demonstrably NOT TRUE -- a BSDI machine on the same network with 10x the I/O load of the FreeBSD machine does *NOT* exhibit the problem. > 2) Server caching. The operation is returned completed by the > server, which then starts an async event, but no completion > routine is associated with the event. > > This is dangerous for similar reasons of data integrity. > > Server caching is disallowed by the NFS design document unless > the state can be maintained across a server failure. This > means log structuring with log data sotred in non volatile > memory (ala Auspex, etc.) so the transaction may be rolled > forward. > > 3) Increase the number of nfsiod's on the server. This will allow > more concurrent operations to be outstanding at one time. > > This is allowed (encouraged) by the NFS design document. > > Number 3 is well within your control. Number 3 is irrelavent (the number of NFSIODs), as is the setting of NFS_ASYNC in the kernel (which SHOULD make a difference). Again, there is a *bug* here which causes these deadlocks. It is not a server performance issue, and is readily reproducable in a large web server environment such as we have here. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity Modem: [+1 312 248-0900] | (shell, PPP, SLIP, leased) in Chicagoland Voice: [+1 312 803-MCS1] | 7 Chicagoland POPs, ISDN, 28.8, much more Fax: [+1 312 248-9865] | Email to "info@mcs.net" WWW: http://www.mcs.net ISDN - Get it here TODAY! | Home of Chicago's *Three STAR A* Clarinet feed! From owner-freebsd-current Mon Nov 13 12:55:33 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA27659 for current-outgoing; Mon, 13 Nov 1995 12:55:33 -0800 Received: from covina.lightside.com (covina.lightside.com [198.81.209.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id MAA27648 for ; Mon, 13 Nov 1995 12:55:30 -0800 Received: by covina.lightside.com (Smail3.1.28.1 #6) id m0tF5uF-0009Z5C; Mon, 13 Nov 95 12:55 PST Date: Mon, 13 Nov 1995 12:55:06 -0800 (PST) From: Jake Hamby To: Heikki Suonsivu cc: current@FreeBSD.org, freebsd-current@freefall.FreeBSD.ORG Subject: Re: ISP state their FreeBSD concerns In-Reply-To: <199511131351.PAA20135@shadows.cs.hut.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.org Precedence: bulk On Mon, 13 Nov 1995, Heikki Suonsivu wrote: > We get panics, sometimes lockups, at pace of 1-2 machines per day (from a > pool of approximately ~5 servers and ~15 routers or terminal servers built > on top of FreeBSD. I'm running -current. On servers the problems seem > often to be scsi related. On routers panics seem very rare, on terminal > (modem) servers and routers with serial ports panic about once a week. I'm sure you're aware that -current is considered "Bleeding Edge" and should definitely NOT be used in a production environment unless you're willing to deal with crashes, broken-ness in the source tree, etc! Really, -stable or even RELEASE is a much better choice. > BTW, Out-of-box Slackware installation doesn't format the manual pages > either, at least it was like that some time ago. I seem to recall that Slackware ONLY came with preformatted (and gzipped) man pages for most commands. ---Jake From owner-freebsd-current Mon Nov 13 12:55:32 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA27654 for current-outgoing; Mon, 13 Nov 1995 12:55:32 -0800 Received: from covina.lightside.com (covina.lightside.com [198.81.209.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id MAA27641 for ; Mon, 13 Nov 1995 12:55:29 -0800 Received: by covina.lightside.com (Smail3.1.28.1 #6) id m0tF5uF-0009Z5C; Mon, 13 Nov 95 12:55 PST Date: Mon, 13 Nov 1995 12:55:06 -0800 (PST) From: Jake Hamby To: Heikki Suonsivu cc: current@FreeBSD.org, freebsd-current@freefall.FreeBSD.ORG Subject: Re: ISP state their FreeBSD concerns In-Reply-To: <199511131351.PAA20135@shadows.cs.hut.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.org Precedence: bulk On Mon, 13 Nov 1995, Heikki Suonsivu wrote: > We get panics, sometimes lockups, at pace of 1-2 machines per day (from a > pool of approximately ~5 servers and ~15 routers or terminal servers built > on top of FreeBSD. I'm running -current. On servers the problems seem > often to be scsi related. On routers panics seem very rare, on terminal > (modem) servers and routers with serial ports panic about once a week. I'm sure you're aware that -current is considered "Bleeding Edge" and should definitely NOT be used in a production environment unless you're willing to deal with crashes, broken-ness in the source tree, etc! Really, -stable or even RELEASE is a much better choice. > BTW, Out-of-box Slackware installation doesn't format the manual pages > either, at least it was like that some time ago. I seem to recall that Slackware ONLY came with preformatted (and gzipped) man pages for most commands. ---Jake From owner-freebsd-current Mon Nov 13 13:07:33 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA28546 for current-outgoing; Mon, 13 Nov 1995 13:07:33 -0800 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA28540 ; Mon, 13 Nov 1995 13:07:29 -0800 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA18039; Mon, 13 Nov 1995 14:00:50 -0700 From: Terry Lambert Message-Id: <199511132100.OAA18039@phaeton.artisoft.com> Subject: Re: ISP state their FreeBSD concerns To: jmb@kryten.Atinc.COM (Jonathan M. Bresler) Date: Mon, 13 Nov 1995 14:00:50 -0700 (MST) Cc: hackers@freebsd.org, current@freebsd.org In-Reply-To: from "Jonathan M. Bresler" at Nov 13, 95 02:58:20 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1038 Sender: owner-current@freebsd.org Precedence: bulk > On Mon, 13 Nov 1995, Terry Lambert wrote: > > I think the University of Michigan EECS's paper on "Metadata Update > > Performance in File Systems" (USENIX Symposium on Operating Systems > > Design and Implementation, November 1994, pp. 49-60) is well taken in > > this regard. They used BSDI as their base platform, so their code > > will need rewriting before they can release it. It wants ~1500 lines > > of changes to the buffer cache code. > > terry, do you have an ftp pointer for this paper? I've been asked this several times so far. Here is the pointer for everyone at once: ftp:ftp.eecs.umich.edu:/techreports/cse/1995/CSE-TR-254-95-cover.ps.Z ftp:ftp.eecs.umich.edu:/techreports/cse/1995/CSE-TR-254-95.ps.Z There are also a number of good papers on performance analysis and optimization for multiprocessing architectures on this site. I believe this is Peter Chen's home site. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Mon Nov 13 13:18:47 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA29301 for current-outgoing; Mon, 13 Nov 1995 13:18:47 -0800 Received: from jhome.DIALix.COM (jhome.DIALix.COM [192.203.228.69]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA29137 for ; Mon, 13 Nov 1995 13:17:48 -0800 Received: (from peter@localhost) by jhome.DIALix.COM (8.6.12/8.6.9) id FAA01074; Tue, 14 Nov 1995 05:16:48 +0800 Date: Tue, 14 Nov 1995 05:16:48 +0800 (WST) From: Peter Wemm To: current@freebsd.org Subject: A program for launching daemons? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk I've written a small program, which is basically does a getopt(), daemon() and execv(). I find this useful for launching shell scripts like /usr/local/etc/rc.news which hang around in the background. Is anybody going to get upset if I import it into -current? (I call it "daemon" on my systems, perhaps an alternative name might be "launch"?) Cheers, -Peter From owner-freebsd-current Mon Nov 13 13:21:07 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA29506 for current-outgoing; Mon, 13 Nov 1995 13:21:07 -0800 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA29457 for ; Mon, 13 Nov 1995 13:20:39 -0800 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA18081; Mon, 13 Nov 1995 14:12:50 -0700 From: Terry Lambert Message-Id: <199511132112.OAA18081@phaeton.artisoft.com> Subject: Re: ISP state their FreeBSD concerns To: bde@zeta.org.au (Bruce Evans) Date: Mon, 13 Nov 1995 14:12:50 -0700 (MST) Cc: dufault@hda.com, terry@lambert.org, current@FreeBSD.org In-Reply-To: <199511132054.HAA06582@godzilla.zeta.org.au> from "Bruce Evans" at Nov 14, 95 07:54:30 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2891 Sender: owner-current@FreeBSD.org Precedence: bulk > >I have seen pauses on the order of a second or two on a SCSI system > >with PCI + NCR controller. > > Another one: > > char buf[1024*1024]; main() { write(1, x, sizeof x); } > > When fd 1 is connected to /dev/ttyv3 (syscons), the write() syscall > takes 6.71 seconds to complete, during which time no other processes can > run. Writing 16MB would take 100 seconds. (To kill the process, type > ^S^C. ^C alone doesn't work because signal handling is delayed until > the process goes to sleep or returns from the syscall.) No disks are > involved. OK, we can rule out the console here. I am running the machine headless using an Xterm from another box. > System: 486DX2/66 VLB ET4000/W32i (video write bandwidth = 25MB/sec; > efficiency = 0.25% :-(). > > When fd 1 is connected to a disk file and the array size is increased to > 32MB, the i/o takes about 11 seconds to complete, during which time the > system seems to be frozen. `iozone 32 65536' reports a write time of > about 8 seconds. The vm system is doing a good job of handling about > 20MB of the array that doesn't fit in memory. I thought that there was a working set quota on either a per process or a per vnode basis at one time? The per vnode working set is easy to implement; change the LRU insertion order for pages the are forced out by the working set to cause them to be reused first. This will result in a bit of thrashing for the pages involved, but the rest of the system will operate efficiently. A per process working set quota will fix the problem more cleanly in theory, even if the code is more complex. A good "half measure" soloution is to establish a per vnode high water mark and track the cache pages on a per vnode basis. The second half of this is to only enforce the watermark if the amount of free VM is below a certain amount -- a low watermark. This interaction should cause a balanced hysteresis to keep the quota from adversly affecting process timing by causing undue cache thrashing for the oitherwise cache-trashing process until a high system load is reached, at which point there will be a minimum free reserve on reuse (the sleeps are waiting for pages at this point). This is exactly the problem that UnixWare has with ld mmap'ing everything it is linking together and (effectively) forcing everything else out of the cache. They don't have a quota. I hacked the code on UnixWare once as a proof of concept, but you wouldn't believe how hard it is to get code into the UnixWare source tree. > All these problems are essentially the same: i/o's are done synchronously > if possible and large synchronous i/o's cause long freezes. 8-(. Maybe better to split them up, then, favoring response time over absolute efficiency? 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-current Mon Nov 13 13:23:03 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA29669 for current-outgoing; Mon, 13 Nov 1995 13:23:03 -0800 Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.20.4]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA29658 for ; Mon, 13 Nov 1995 13:22:57 -0800 Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id PAA27837; Mon, 13 Nov 1995 15:21:35 -0600 From: Joe Greco Message-Id: <199511132121.PAA27837@brasil.moneng.mei.com> Subject: Re: ISP state their FreeBSD concerns To: terry@lambert.org (Terry Lambert) Date: Mon, 13 Nov 1995 15:21:34 -0600 (CST) Cc: dyson@freefall.freebsd.org, current@FreeBSD.org In-Reply-To: <199511132047.NAA17982@phaeton.artisoft.com> from "Terry Lambert" at Nov 13, 95 01:47:06 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@FreeBSD.org Precedence: bulk > > PrestoServe does not do striping. PrestoServe does writeback caching. This > > helps by a large margin on things like metadata updates (because you can > > write to cache and have a change queued to be written to the drive, and make > > several more changes before the write actually gets scheduled to hit the > > physical disk). > > > > On-Line Disk Suite does striping, concatenation, mirroring, and logging > > filesystems. It and PrestoServe are only somewhat compatible :-/ > > Damn. I always get those products confused. 8-(. :-) > The use of server caching is discouraged without some type of log forward > mechanism that can't be implemented without additonal hardware. > > NFS server caching sucks, almost as bad as NFS client caching. PrestoServe is a battery-backed RAM cache. This is the way you wanna do NFS server caching, if you do it at all. ;-) Of course, while it works *best* for NFS server caching, it is also a good general purpose writeback cache, which is why it is a win on a news server. > > The other factor is that for effective concurrency, you need multiple > > processes. INN is a monolithic news processing engine, and you cannot get > > the kind of concurrency needed to increase article processing performance > > even on a multi-CPU Solaris box. (well, this is an oversimplification of > > the problem, but the point is that it is a single process which needs to be > > able to do many hundreds of disk I/Os per second). > > Or async I/O. Or auto-thread generation for blocking oprations. Etc. > > This is a design problem with the news server, and we aren't going to > fix it here. 8-(. Realize that. But that's not to say that it's not a good reason to improve what is really suprisingly abysmal performance in the filesystem. :-( > > Taken from THE SAME drive, > > > > Slowaris 5.4 - SS10/30 - 64MB RAM (SCSI II, reasonable drive) > > > > 10000 files in 332 seconds - first run > > 10000 files in 20 !!! seconds - second run > > > > FreeBSD 2.0.5R - ASUS SP3G AMD 486DX2/66 + NCR810 - 8MB (SCSI II, reasonable > > drive) > > > > 10000 files in 620 seconds - first run :-( :-( > > 10000 files in 310 seconds - second run :-( :-( :-( !! > > > > That does not appear to be "the same order as" :-( > > > > I haven't yet tried Solaris x86 - we just got gcc installed on our "test > > box" today. > > Is the Sun running with PrestoServe or OLDS installed? This would be > an unfair comparison... Of course it would :-) The PrestoServe numbers were also posted in my original benchmark posting, but this is a pure Solaris system with no additional garbage. The systems quoted above are functionally equivalent and I would expect to perform similarly - except that the ASUS had much less memory. This could be partly a caching issue of some sort, in which case I would notice a difference if I put another 8MB RAM in, but I have yet to try that. And it does not explain the difference between 332 and 620 seconds (in my mind). ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 From owner-freebsd-current Mon Nov 13 14:00:07 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA02479 for current-outgoing; Mon, 13 Nov 1995 14:00:07 -0800 Received: from jazz.trumpet.com.au (root@jazz.trumpet.com.au [203.5.119.51]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA02447 ; Mon, 13 Nov 1995 13:59:50 -0800 Received: (from paul@localhost) by jazz.trumpet.com.au (8.6.11/8.6.9) id IAA13577; Tue, 14 Nov 1995 08:59:42 +1100 Date: Tue, 14 Nov 1995 08:59:42 +1100 (EST) From: Paul Reece X-Sender: paul@jazz To: scrappy@hub.org, freebsd-questions@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: Re: FreeBSD 2.0.5R hanging inexplicably... In-Reply-To: <199511131419.OAA08697@ns0.netcraft.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.org Precedence: bulk On Mon, 13 Nov 1995, Paul Richards wrote: > In reply to Paul Reece who said > > > > On Sun, 12 Nov 1995, Marc G. Fournier wrote: > > > > > For the second time in two days, my system just hung, in that, > > > essentially, no keyboard input was being permitted. > > > > > Which version are you running? > > I had this happen a lot with 2.0.5 since it didn't handle keyboard > disconnection and unplugging and putting the keyboard back made it > dissappear. I also had it happen "randomly" quite frequently but > I put that down to the some quirk triggering the same problem. > > When I upgraded to stable the problem went away BUT I did have it happen > to me once about three days ago shortly after reboot (5 mins say) just > after upgrading to stable again. That's the only time it's happened in the > last 6 weeks or so but there may be a problem lurking in there somewhere. > > This is with PCVT. > > I've had worse problems with syscons. There's something wrong with syscons > vt switching, it's not completely reproducable but it happens frequently > enough that I've now switched all our machines to pcvt. The symptom is that > when you switch VT the screen goes completely blank and further attempts > to switch VT just gets a beep (as though no VT was configured). Everything > is still running (getty etc) but the screen is just totally blank. Only way > to recover the console is to reboot. well, my problem is a full lockup on the whole machine - no core dumps etc etc.. A reset is the only thing that will fix it :( Turn off screen savers - no problems (this is with syscons btw) - P From owner-freebsd-current Mon Nov 13 14:36:57 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA03902 for current-outgoing; Mon, 13 Nov 1995 14:36:57 -0800 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA03895 for ; Mon, 13 Nov 1995 14:36:51 -0800 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id OAA22190; Mon, 13 Nov 1995 14:35:07 -0800 To: uhclem%nemesis@fw.ast.com (Frank Durda IV) cc: current@freebsd.org Subject: Re: ISP state their FreeBSD concerns In-reply-to: Your message of "Sun, 12 Nov 1995 13:03:00 +0700." Date: Mon, 13 Nov 1995 14:35:06 -0800 Message-ID: <22188.816302106@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org Precedence: bulk > Uh, sorry it wasn't meant to be *that* way. I was playing with some > options of xmail for re-routing replies and this was the result. > I see I also botched the sig inclusion. > Serves me right for composing at goofy hours of the night, but I got > going and wanted to finish before the scribbled notes on resturant > napkins became a useless jumble. Sorry to jump to the wrong conclusion. It's been a bad week! :-( Jordan From owner-freebsd-current Mon Nov 13 14:38:02 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA03956 for current-outgoing; Mon, 13 Nov 1995 14:38:02 -0800 Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA03951 for ; Mon, 13 Nov 1995 14:37:59 -0800 Received: (from henrich@localhost) by crh.cl.msu.edu (8.6.12/8.6.12) id RAA17770; Mon, 13 Nov 1995 17:37:58 -0500 Date: Mon, 13 Nov 1995 17:37:58 -0500 From: Charles Henrich Message-Id: <199511132237.RAA17770@crh.cl.msu.edu> To: terry@lambert.org, freebsd-current@freebsd.org Subject: Re: ISP state their FreeBSD concerns Newsgroups: lists.freebsd.current References: <48839e$nhm@msunews.cl.msu.edu> X-Newsreader: NN version 6.5.0 #3 (NOV) Sender: owner-current@freebsd.org Precedence: bulk In lists.freebsd.current you write: >> > 1. A concern that FreeBSD tends to "bind" for brief periods when >> > loaded... >> >> Can this is an IDE issue? I never saw anything like this until >> I configured an IDE mail server. That system pauses for seconds >> sometimes, and then continues. This is running -stable, syscons >> only (no X), no messages logged, etc. The echo stops going to >> the display, the ethernet activity is stopped, all in all it seems >> to be locked up for three or four seconds. >> >> We have three SCSI only systems and haven't ever seen this, and >> one IDE system that pauses. >I have seen pauses on the order of a second or two on a SCSI system >with PCI + NCR controller. >Typically, there are no console messages associated, as one would >expect with timeouts (which the IDE theory implies). >When the pauses start happening, they will continue happening with >a moderate frequency. Typing "sync" will cure the problem for a short >period of time, after which it will recurr. Generally, I type "sync" >often enough from my V6 background that it doesn't hit me. When it >does, it's obvious. A couple of months back Matt Dillion was here (-hackers actually) talking about this same (similar?) problem which he had tracked down to the VM system, and even provided a solution, that seems to have been sat on. Matt is a really really sharp guy, perhaps we should take a closer look at what he has done? -Crh -- Charles Henrich Michigan State University henrich@crh.cl.msu.edu http://rs560.msu.edu/~henrich/ From owner-freebsd-current Mon Nov 13 16:27:01 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA08121 for current-outgoing; Mon, 13 Nov 1995 16:27:01 -0800 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA08115 for ; Mon, 13 Nov 1995 16:26:57 -0800 Received: (from julian@localhost) by ref.tfs.com (8.6.12/8.6.9) id QAA25869; Mon, 13 Nov 1995 16:26:25 -0800 From: Julian Elischer Message-Id: <199511140026.QAA25869@ref.tfs.com> Subject: Re: ISP state their FreeBSD concerns To: henrich@crh.cl.msu.edu (Charles Henrich) Date: Mon, 13 Nov 1995 16:26:25 -0800 (PST) Cc: terry@lambert.org, freebsd-current@freebsd.org In-Reply-To: <199511132237.RAA17770@crh.cl.msu.edu> from "Charles Henrich" at Nov 13, 95 05:37:58 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 499 Sender: owner-current@freebsd.org Precedence: bulk > > A couple of months back Matt Dillion was here (-hackers actually) talking about > this same (similar?) problem which he had tracked down to the VM system, and > even provided a solution, that seems to have been sat on. Matt is a really > really sharp guy, perhaps we should take a closer look at what he has done? I don't think it was 'Sat on'.. 2.1 was happenning.... hopefully there is a backlog of such things that will now happen now that the main vm people can breath again.... julian From owner-freebsd-current Mon Nov 13 16:31:54 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA08331 for current-outgoing; Mon, 13 Nov 1995 16:31:54 -0800 Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA08326 for ; Mon, 13 Nov 1995 16:31:49 -0800 Received: (from henrich@localhost) by crh.cl.msu.edu (8.6.12/8.6.12) id TAA18412; Mon, 13 Nov 1995 19:31:30 -0500 From: Charles Henrich Message-Id: <199511140031.TAA18412@crh.cl.msu.edu> Subject: Re: ISP state their FreeBSD concerns To: julian@ref.tfs.com (Julian Elischer) Date: Mon, 13 Nov 1995 19:31:29 -0500 (EST) Cc: terry@lambert.org, freebsd-current@freebsd.org In-Reply-To: <199511140026.QAA25869@ref.tfs.com> from "Julian Elischer" at Nov 13, 95 04:26:25 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 699 Sender: owner-current@freebsd.org Precedence: bulk > I don't think it was 'Sat on'.. 2.1 was happenning.... > hopefully there is a backlog of such things that will now happen now that > the main vm people can breath again.... Maybe im talking out of turn here (hell, I am) but it seems to me that if there is something this significantly "broken", we should have at least attempted to see how valid it was and move it into 2.2. It seems that our target it the high-performance, high-reliability ISP service, and bugs that cause the entire system to freeze every n seconds for many seconds is a serious problem. -Crh Charles Henrich Michigan State University henrich@crh.cl.msu.edu http://rs560.msu.edu/~henrich/ From owner-freebsd-current Mon Nov 13 16:56:30 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA09465 for current-outgoing; Mon, 13 Nov 1995 16:56:30 -0800 Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA09460 for ; Mon, 13 Nov 1995 16:56:28 -0800 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id RAA00978; Mon, 13 Nov 1995 17:57:32 -0700 Date: Mon, 13 Nov 1995 17:57:32 -0700 From: Nate Williams Message-Id: <199511140057.RAA00978@rocky.sri.MT.net> To: Charles Henrich Cc: freebsd-current@freebsd.org Subject: Re: ISP state their FreeBSD concerns In-Reply-To: <199511140031.TAA18412@crh.cl.msu.edu> References: <199511140026.QAA25869@ref.tfs.com> <199511140031.TAA18412@crh.cl.msu.edu> Sender: owner-current@freebsd.org Precedence: bulk Charles Henrich writes: > > I don't think it was 'Sat on'.. 2.1 was happenning.... > > hopefully there is a backlog of such things that will now happen now that > > the main vm people can breath again.... > > Maybe im talking out of turn here (hell, I am) but it seems to me that > if there is something this significantly "broken", we should have at > least attempted to see how valid it was and move it into 2.2. It > seems that our target it the high-performance, high-reliability ISP > service, and bugs that cause the entire system to freeze every n > seconds for many seconds is a serious problem. Is it any more serious that the other problems the VM guys spent hours fixing? I'd consider it *less* serious that most of the other problems that were fixed in 2.1. There are only so many hours in a day, and those 24 were spent making 2.1 as good as it could get. If this means that the system still has a 'feature' of pausing under certain conditions I don't mind it as much as rebooting and/or panicing under more common scenarios. Either you get a release out the door, or you wait indefinately and fix all known bugs while the system stagnates because of lack of features. I think all involved would prefer the former to the latter. :) Nate From owner-freebsd-current Mon Nov 13 16:59:30 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA09683 for current-outgoing; Mon, 13 Nov 1995 16:59:30 -0800 Received: from wiley.muc.ditec.de (wiley.muc.ditec.de [194.120.126.9]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA09670 for ; Mon, 13 Nov 1995 16:59:26 -0800 Received: from vector.eikon.e-technik.tu-muenchen.de (vector.eikon.e-technik.tu-muenchen.de [129.187.142.36]) by wiley.muc.ditec.de (8.6.12/8.6.9) with ESMTP id BAA21013; Tue, 14 Nov 1995 01:59:11 +0100 Received: from localhost (localhost [127.0.0.1]) by vector.eikon.e-technik.tu-muenchen.de (8.6.12/8.6.9) with SMTP id BAA00603; Tue, 14 Nov 1995 01:48:05 +0100 Message-Id: <199511140048.BAA00603@vector.eikon.e-technik.tu-muenchen.de> X-Authentication-Warning: vector.eikon.e-technik.tu-muenchen.de: Host localhost didn't use HELO protocol To: Heikki Suonsivu cc: current@freebsd.org, freebsd-current@freefall.freebsd.org Subject: Re: ISP state their FreeBSD concerns Reply-To: "Julian H. Stacey" In-reply-to: Your message of "Mon, 13 Nov 1995 15:51:48 +0200." <199511131351.PAA20135@shadows.cs.hut.fi> Date: Tue, 14 Nov 1995 01:48:05 +0100 From: "Julian H. Stacey" Sender: owner-current@freebsd.org Precedence: bulk > From: Heikki Suonsivu > A commercial support provider for *BSD* would also do a lot of good. I > don't mean one-man shops. There are people who will never buy anything > without a support contract. This theme was mentioned a couple of months back. At some stage it _may_ make hard business sense to spend time incorporating a company, & spend money marketing support services, however it will cost serious money & time to start, & I think it'll probably be best not to be formally linked to the before-discussed FreeBSD Inc, as it will likely have divergent/divisive aims from most FreeBSD people, (like not having fun, doing lots of tedious work, making money, & even using other OS's too where business dictates). Running a company is not a democratic process, & involves much tedious filling with the authorities, Oh, & we have a world wide presence, world wide spread of laws, & a world of currencies. If/when it happens, I think it may likely evolve from geographically co-located small groups of fellow FreeBSDers, ( because remote working over the Internet on development & debug tasks is not that easy, many customer systems hide behind firewalls). Those of us seriously interested in this minority topic might be best off having our own mail list, maybe commercial@freebsd.org it'd be a register & litmus test of interest. PS No way should it be called support@freebsd.org else we'd be flooded with people who want free support, & one can't pay the rent on free support. Julian H. Stacey EMAIL: jhs@freebsd.org WEB: http://www.freebsd.org/~jhs/ TEL: +49.89.268616 FAX: +49.89.2608126 CONSULTANT: Internet, Unix, C POST: Vector Systems Ltd, Holz Strasse 27d, 80469 Munich, Germany. From owner-freebsd-current Mon Nov 13 16:59:34 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA09707 for current-outgoing; Mon, 13 Nov 1995 16:59:34 -0800 Received: from wiley.muc.ditec.de (wiley.muc.ditec.de [194.120.126.9]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA09690 for ; Mon, 13 Nov 1995 16:59:31 -0800 Received: from vector.eikon.e-technik.tu-muenchen.de (vector.eikon.e-technik.tu-muenchen.de [129.187.142.36]) by wiley.muc.ditec.de (8.6.12/8.6.9) with ESMTP id BAA21013; Tue, 14 Nov 1995 01:59:11 +0100 Received: from localhost (localhost [127.0.0.1]) by vector.eikon.e-technik.tu-muenchen.de (8.6.12/8.6.9) with SMTP id BAA00603; Tue, 14 Nov 1995 01:48:05 +0100 Message-Id: <199511140048.BAA00603@vector.eikon.e-technik.tu-muenchen.de> X-Authentication-Warning: vector.eikon.e-technik.tu-muenchen.de: Host localhost didn't use HELO protocol To: Heikki Suonsivu cc: current@freebsd.org, freebsd-current@freefall.freebsd.org Subject: Re: ISP state their FreeBSD concerns Reply-To: "Julian H. Stacey" In-reply-to: Your message of "Mon, 13 Nov 1995 15:51:48 +0200." <199511131351.PAA20135@shadows.cs.hut.fi> Date: Tue, 14 Nov 1995 01:48:05 +0100 From: "Julian H. Stacey" Sender: owner-current@freebsd.org Precedence: bulk > From: Heikki Suonsivu > A commercial support provider for *BSD* would also do a lot of good. I > don't mean one-man shops. There are people who will never buy anything > without a support contract. This theme was mentioned a couple of months back. At some stage it _may_ make hard business sense to spend time incorporating a company, & spend money marketing support services, however it will cost serious money & time to start, & I think it'll probably be best not to be formally linked to the before-discussed FreeBSD Inc, as it will likely have divergent/divisive aims from most FreeBSD people, (like not having fun, doing lots of tedious work, making money, & even using other OS's too where business dictates). Running a company is not a democratic process, & involves much tedious filling with the authorities, Oh, & we have a world wide presence, world wide spread of laws, & a world of currencies. If/when it happens, I think it may likely evolve from geographically co-located small groups of fellow FreeBSDers, ( because remote working over the Internet on development & debug tasks is not that easy, many customer systems hide behind firewalls). Those of us seriously interested in this minority topic might be best off having our own mail list, maybe commercial@freebsd.org it'd be a register & litmus test of interest. PS No way should it be called support@freebsd.org else we'd be flooded with people who want free support, & one can't pay the rent on free support. Julian H. Stacey EMAIL: jhs@freebsd.org WEB: http://www.freebsd.org/~jhs/ TEL: +49.89.268616 FAX: +49.89.2608126 CONSULTANT: Internet, Unix, C POST: Vector Systems Ltd, Holz Strasse 27d, 80469 Munich, Germany. From owner-freebsd-current Mon Nov 13 17:19:25 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA10310 for current-outgoing; Mon, 13 Nov 1995 17:19:25 -0800 Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA10305 for ; Mon, 13 Nov 1995 17:19:22 -0800 Received: (from henrich@localhost) by crh.cl.msu.edu (8.6.12/8.6.12) id UAA00359; Mon, 13 Nov 1995 20:19:12 -0500 From: Charles Henrich Message-Id: <199511140119.UAA00359@crh.cl.msu.edu> Subject: Re: ISP state their FreeBSD concerns To: nate@rocky.sri.MT.net (Nate Williams) Date: Mon, 13 Nov 1995 20:19:11 -0500 (EST) Cc: freebsd-current@freebsd.org In-Reply-To: <199511140057.RAA00978@rocky.sri.MT.net> from "Nate Williams" at Nov 13, 95 05:57:32 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1783 Sender: owner-current@freebsd.org Precedence: bulk > > Maybe im talking out of turn here (hell, I am) but it seems to me that > > if there is something this significantly "broken", we should have at > > least attempted to see how valid it was and move it into 2.2. It > > seems that our target it the high-performance, high-reliability ISP > > service, and bugs that cause the entire system to freeze every n > > seconds for many seconds is a serious problem. > > Is it any more serious that the other problems the VM guys spent hours > fixing? I'd consider it *less* serious that most of the other problems > that were fixed in 2.1. > > There are only so many hours in a day, and those 24 were spent making > 2.1 as good as it could get. If this means that the system still has a > 'feature' of pausing under certain conditions I don't mind it as much as > rebooting and/or panicing under more common scenarios. I tend to agree with that, however if Im not mistaken (I could be, its been awhile) Matt provided source patches at the time that fixed the problems, would it have been that difficult to review the patches and apply them? > Either you get a release out the door, or you wait indefinately and fix > all known bugs while the system stagnates because of lack of features. > I think all involved would prefer the former to the latter. :) I agree wholeheartedly, im not trying to point fingers here. The original reply was to assist in the solution of a problem that has again arisen in the list, with a completed source-patch (which I assumed would be better than just saying "hey Its broke!"). I agree that this cant go into 2.1 now, I'm just hoping it gets looked at before 2.2 -Crh Charles Henrich Michigan State University henrich@crh.cl.msu.edu http://rs560.msu.edu/~henrich/ From owner-freebsd-current Mon Nov 13 17:23:06 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA10438 for current-outgoing; Mon, 13 Nov 1995 17:23:06 -0800 Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA10433 for ; Mon, 13 Nov 1995 17:23:02 -0800 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id SAA01060; Mon, 13 Nov 1995 18:25:22 -0700 Date: Mon, 13 Nov 1995 18:25:22 -0700 From: Nate Williams Message-Id: <199511140125.SAA01060@rocky.sri.MT.net> To: Charles Henrich Cc: nate@rocky.sri.MT.net (Nate Williams), freebsd-current@freebsd.org Subject: Re: ISP state their FreeBSD concerns In-Reply-To: <199511140119.UAA00359@crh.cl.msu.edu> References: <199511140057.RAA00978@rocky.sri.MT.net> <199511140119.UAA00359@crh.cl.msu.edu> Sender: owner-current@freebsd.org Precedence: bulk Charles Henrich writes: [ Why didn't the 'pause' bug get fixed ] Nate > There are only so many hours in a day, and those 24 were spent Nate > making 2.1 as good as it could get. If this means that the Nate > system still has a 'feature' of pausing under certain conditions Nate > I don't mind it as much as rebooting and/or panicing under more Nate > common scenarios. > I tend to agree with that, however if Im not mistaken (I could be, its > been awhile) Matt provided source patches at the time that fixed the > problems, would it have been that difficult to review the patches and > apply them? Since the VM system is *very* sensitive to even minor modifications, I suspect it would have taken a *very* long to review the patches, apply them to the system, and then test them. Even very simple errors can cause *massive* corruptions, and I'm sure both David and John would rather avoid that for something as critical as the 2.1 release. I think you underestimate the time needed to test something so critical as this. Nate From owner-freebsd-current Mon Nov 13 17:26:32 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA10553 for current-outgoing; Mon, 13 Nov 1995 17:26:32 -0800 Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA10547 for ; Mon, 13 Nov 1995 17:26:30 -0800 Received: (from henrich@localhost) by crh.cl.msu.edu (8.6.12/8.6.12) id UAA00419; Mon, 13 Nov 1995 20:26:21 -0500 From: Charles Henrich Message-Id: <199511140126.UAA00419@crh.cl.msu.edu> Subject: Re: ISP state their FreeBSD concerns To: nate@rocky.sri.MT.net (Nate Williams) Date: Mon, 13 Nov 1995 20:26:20 -0500 (EST) Cc: nate@rocky.sri.MT.net, freebsd-current@freebsd.org In-Reply-To: <199511140125.SAA01060@rocky.sri.MT.net> from "Nate Williams" at Nov 13, 95 06:25:22 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1464 Sender: owner-current@freebsd.org Precedence: bulk > Charles Henrich writes: > [ Why didn't the 'pause' bug get fixed ] > > Nate > There are only so many hours in a day, and those 24 were spent > Nate > making 2.1 as good as it could get. If this means that the > Nate > system still has a 'feature' of pausing under certain conditions > Nate > I don't mind it as much as rebooting and/or panicing under more > Nate > common scenarios. > > > I tend to agree with that, however if Im not mistaken (I could be, its > > been awhile) Matt provided source patches at the time that fixed the > > problems, would it have been that difficult to review the patches and > > apply them? > > Since the VM system is *very* sensitive to even minor modifications, I > suspect it would have taken a *very* long to review the patches, apply > them to the system, and then test them. Even very simple errors can > cause *massive* corruptions, and I'm sure both David and John would > rather avoid that for something as critical as the 2.1 release. > > I think you underestimate the time needed to test something so critical > as this. I find it hard to believe it would have taken longer than the 3 or 4 months its been since he posted them. Even if there truly was no time to review the patches for 2.1 since then, would it have not made sense to pull them into 2.2 to get the ball rolling? -Crh Charles Henrich Michigan State University henrich@crh.cl.msu.edu http://rs560.msu.edu/~henrich/ From owner-freebsd-current Mon Nov 13 17:34:32 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA10768 for current-outgoing; Mon, 13 Nov 1995 17:34:32 -0800 Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA10762 for ; Mon, 13 Nov 1995 17:34:26 -0800 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id SAA01103; Mon, 13 Nov 1995 18:36:15 -0700 Date: Mon, 13 Nov 1995 18:36:15 -0700 From: Nate Williams Message-Id: <199511140136.SAA01103@rocky.sri.MT.net> To: Charles Henrich Cc: nate@rocky.sri.MT.net (Nate Williams), freebsd-current@freebsd.org Subject: Re: ISP state their FreeBSD concerns In-Reply-To: <199511140126.UAA00419@crh.cl.msu.edu> References: <199511140125.SAA01060@rocky.sri.MT.net> <199511140126.UAA00419@crh.cl.msu.edu> Sender: owner-current@freebsd.org Precedence: bulk Charles Henrich writes: > > I think you underestimate the time needed to test something so critical > > as this. > > I find it hard to believe it would have taken longer than the 3 or 4 > months its been since he posted them. This assumes that the folks have *nothing* else to work on. There have been plenty of other 'show stopper' bugs in the 2.1 tree that have taken up lots of their time. Heck, I'll bet they could re-write the entire VM system from scratch in 3-4 months. :) > Even if there truly was no time to review the patches for 2.1 since > then, would it have not made sense to pull them into 2.2 to get the > ball rolling? I would never commit a patch that haven't been reviewed or at least tested on my own machines. Just because something 'looks like it solves' a problem doesn't mean it's a correct solution. It may simply hide the problem or move it to somewhere else. There is *nothing* worse than a poor fix. This is NOT to say that Matt's solution was poor, but until it is reviewed and tested it *shouldn't* go into the tree. I've been bitten too many times by committing bad patches to the CVS tree that fix a 'critical' bug,when in fact the fix was worse than the original problem. :( Nate From owner-freebsd-current Mon Nov 13 17:37:15 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA10870 for current-outgoing; Mon, 13 Nov 1995 17:37:15 -0800 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA10864 for ; Mon, 13 Nov 1995 17:37:10 -0800 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id SAA18501; Mon, 13 Nov 1995 18:30:59 -0700 From: Terry Lambert Message-Id: <199511140130.SAA18501@phaeton.artisoft.com> Subject: Re: ISP state their FreeBSD concerns To: henrich@crh.cl.msu.edu (Charles Henrich) Date: Mon, 13 Nov 1995 18:30:59 -0700 (MST) Cc: nate@rocky.sri.MT.net, freebsd-current@FreeBSD.ORG In-Reply-To: <199511140126.UAA00419@crh.cl.msu.edu> from "Charles Henrich" at Nov 13, 95 08:26:20 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1229 Sender: owner-current@FreeBSD.ORG Precedence: bulk > > Since the VM system is *very* sensitive to even minor modifications, I > > suspect it would have taken a *very* long to review the patches, apply > > them to the system, and then test them. Even very simple errors can > > cause *massive* corruptions, and I'm sure both David and John would > > rather avoid that for something as critical as the 2.1 release. > > > > I think you underestimate the time needed to test something so critical > > as this. > > I find it hard to believe it would have taken longer than the 3 or 4 months its > been since he posted them. Even if there truly was no time to review the > patches for 2.1 since then, would it have not made sense to pull them into 2.2 > to get the ball rolling? I find it hard to believe too, since all that is required is that you understand the code. Matt clearly had to do this to generate the patches in the first place, and we must assume that the people who wrote it understand it enough to predict the results. It's not like this is magic or anything... it's complex, yes, but that doesn't make it beyond mortal ken. 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-current Mon Nov 13 17:38:10 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA10956 for current-outgoing; Mon, 13 Nov 1995 17:38:10 -0800 Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA10951 for ; Mon, 13 Nov 1995 17:38:09 -0800 Received: (from henrich@localhost) by crh.cl.msu.edu (8.6.12/8.6.12) id UAA00517; Mon, 13 Nov 1995 20:38:05 -0500 From: Charles Henrich Message-Id: <199511140138.UAA00517@crh.cl.msu.edu> Subject: Re: ISP state their FreeBSD concerns To: nate@rocky.sri.MT.net (Nate Williams) Date: Mon, 13 Nov 1995 20:38:04 -0500 (EST) Cc: nate@rocky.sri.MT.net, freebsd-current@freebsd.org In-Reply-To: <199511140136.SAA01103@rocky.sri.MT.net> from "Nate Williams" at Nov 13, 95 06:36:15 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1117 Sender: owner-current@freebsd.org Precedence: bulk > Heck, I'll bet they could re-write the entire VM system from scratch in > 3-4 months. :) I'll be they can do it in 1.5! > I would never commit a patch that haven't been reviewed or at least > tested on my own machines. Just because something 'looks like it > solves' a problem doesn't mean it's a correct solution. It may simply > hide the problem or move it to somewhere else. There is *nothing* worse > than a poor fix. This is NOT to say that Matt's solution was poor, but > until it is reviewed and tested it *shouldn't* go into the tree. Ack, I concur as well. What I meant was do a quick review instead of a massive review for 2.2. Part of the problem I think is that Matt doesnt have a track record here. I know (of) Matt from my Amiga days, where he has done incredible amounts of work, including porting Unix to the damn thing. He also had (is?) been running it on his heavily loaded ISP company at the time if I'm not mistaken, lending it some credibility. -Crh Charles Henrich Michigan State University henrich@crh.cl.msu.edu http://rs560.msu.edu/~henrich/ From owner-freebsd-current Mon Nov 13 17:43:28 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA11182 for current-outgoing; Mon, 13 Nov 1995 17:43:28 -0800 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA11175 ; Mon, 13 Nov 1995 17:43:23 -0800 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id SAA18528; Mon, 13 Nov 1995 18:37:53 -0700 From: Terry Lambert Message-Id: <199511140137.SAA18528@phaeton.artisoft.com> Subject: Re: ISP state their FreeBSD concerns To: jhs@FreeBSD.ORG Date: Mon, 13 Nov 1995 18:37:52 -0700 (MST) Cc: hsu@cs.hut.fi, current@FreeBSD.ORG, freebsd-current@freefall.freebsd.org In-Reply-To: <199511140048.BAA00603@vector.eikon.e-technik.tu-muenchen.de> from "Julian H. Stacey" at Nov 14, 95 01:48:05 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1585 Sender: owner-current@FreeBSD.ORG Precedence: bulk > > A commercial support provider for *BSD* would also do a lot of good. I > > don't mean one-man shops. There are people who will never buy anything > > without a support contract. > > This theme was mentioned a couple of months back. > At some stage it _may_ make hard business sense to spend time > incorporating a company, & spend money marketing support services, > however it will cost serious money & time to start, & I think it'll probably > be best not to be formally linked to the before-discussed FreeBSD Inc, > as it will likely have divergent/divisive aims from most FreeBSD people, > (like not having fun, doing lots of tedious work, making money, & even using > other OS's too where business dictates). I don't think this will *ever* be possible *without* a formal linkage to the "FreeBSD Inc." organization. Clearly, without a commitment on the part of "core", there will be no mechanism whereby the support issues will not grow expotentially. The *only* way around that is to have a guarantee of some kind that your commercial support organizations patches will get rolled into the main line tree. Otherwise, you have just invented a commercial BSD based on FreeBSD. It will be less expensive for the commercial organization to maintain their own source tree seperately unless there is some guarantee that they will not have to reapply "rejected" patches when they attempt to synchronize source trees. My opinion, 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-current Mon Nov 13 17:44:24 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA11240 for current-outgoing; Mon, 13 Nov 1995 17:44:24 -0800 Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA11234 for ; Mon, 13 Nov 1995 17:44:21 -0800 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id SAA01144; Mon, 13 Nov 1995 18:46:41 -0700 Date: Mon, 13 Nov 1995 18:46:41 -0700 From: Nate Williams Message-Id: <199511140146.SAA01144@rocky.sri.MT.net> To: Charles Henrich Cc: nate@rocky.sri.MT.net (Nate Williams), freebsd-current@freebsd.org Subject: Re: ISP state their FreeBSD concerns In-Reply-To: <199511140138.UAA00517@crh.cl.msu.edu> References: <199511140136.SAA01103@rocky.sri.MT.net> <199511140138.UAA00517@crh.cl.msu.edu> Sender: owner-current@freebsd.org Precedence: bulk > > I would never commit a patch that haven't been reviewed or at least > > tested on my own machines. Just because something 'looks like it > > solves' a problem doesn't mean it's a correct solution. It may simply > > hide the problem or move it to somewhere else. There is *nothing* worse > > than a poor fix. This is NOT to say that Matt's solution was poor, but > > until it is reviewed and tested it *shouldn't* go into the tree. > > Ack, I concur as well. What I meant was do a quick review instead of > a massive review for 2.2. Part of the problem I think is that Matt > doesnt have a track record here. I know (of) Matt from my Amiga days, > where he has done incredible amounts of work, including porting Unix > to the damn thing. He also had (is?) been running it on his heavily > loaded ISP company at the time if I'm not mistaken, lending it some > credibility. You have more information that the folks responsible for that part of the system. In any case, I'm going home now to watch football, and will shutup and not post anything else on this subject. In summary, I think the VM folks are doing a good job, and posting like 'Why didn't you do this, you had plenty of time' can sometimes come out wrong when you are the receiving end. This is a fun project, and the release folks are pretty stressed out right now. Wait until the release is out before pointing fingers at over-worked folks. :) Nate From owner-freebsd-current Mon Nov 13 17:44:59 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA11282 for current-outgoing; Mon, 13 Nov 1995 17:44:59 -0800 Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA11277 for ; Mon, 13 Nov 1995 17:44:55 -0800 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id SAA01129; Mon, 13 Nov 1995 18:44:15 -0700 Date: Mon, 13 Nov 1995 18:44:15 -0700 From: Nate Williams Message-Id: <199511140144.SAA01129@rocky.sri.MT.net> To: Terry Lambert Cc: henrich@crh.cl.msu.edu (Charles Henrich), nate@rocky.sri.MT.net, freebsd-current@FreeBSD.ORG Subject: Re: ISP state their FreeBSD concerns In-Reply-To: <199511140130.SAA18501@phaeton.artisoft.com> References: <199511140126.UAA00419@crh.cl.msu.edu> <199511140130.SAA18501@phaeton.artisoft.com> Sender: owner-current@FreeBSD.ORG Precedence: bulk [ Reviewing the VM patch and not bringing it into 2.1 ] > I find it hard to believe too, since all that is required is that you > understand the code. Matt clearly had to do this to generate the > patches in the first place, and we must assume that the people who > wrote it understand it enough to predict the results. Gee, and I suspect you've never written a bad patch before. Geeze folks, let's get real now. > It's not like this is magic or anything... it's complex, yes, but that > doesn't make it beyond mortal ken. It also doesn't mean that the patch is bad, but *BECAUSE* it is complex it is often difficult to miss subtle features (as you have shown in the past :]) and necessary code to get things working right. Even your FS patches were missing some critical things. If they would have been committed as submitted, FS corruption and/or panics *would* have occurred. Does this mean you didn't understand all of the issues? Maybe *grin*, but I'll bet it means you're human more than anything else. Why do you think I avoid the kernel so much? If I break 'man', people's machines won't blow up in their faces and cause them to re-install all the while cursing name. :) :) :) :) Nate From owner-freebsd-current Mon Nov 13 17:45:14 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA11326 for current-outgoing; Mon, 13 Nov 1995 17:45:14 -0800 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA11321 for ; Mon, 13 Nov 1995 17:45:10 -0800 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id SAA18528; Mon, 13 Nov 1995 18:37:53 -0700 From: Terry Lambert Message-Id: <199511140137.SAA18528@phaeton.artisoft.com> Subject: Re: ISP state their FreeBSD concerns To: jhs@FreeBSD.ORG Date: Mon, 13 Nov 1995 18:37:52 -0700 (MST) Cc: hsu@cs.hut.fi, current@FreeBSD.ORG, freebsd-current@freefall.freebsd.org In-Reply-To: <199511140048.BAA00603@vector.eikon.e-technik.tu-muenchen.de> from "Julian H. Stacey" at Nov 14, 95 01:48:05 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1585 Sender: owner-current@FreeBSD.ORG Precedence: bulk > > A commercial support provider for *BSD* would also do a lot of good. I > > don't mean one-man shops. There are people who will never buy anything > > without a support contract. > > This theme was mentioned a couple of months back. > At some stage it _may_ make hard business sense to spend time > incorporating a company, & spend money marketing support services, > however it will cost serious money & time to start, & I think it'll probably > be best not to be formally linked to the before-discussed FreeBSD Inc, > as it will likely have divergent/divisive aims from most FreeBSD people, > (like not having fun, doing lots of tedious work, making money, & even using > other OS's too where business dictates). I don't think this will *ever* be possible *without* a formal linkage to the "FreeBSD Inc." organization. Clearly, without a commitment on the part of "core", there will be no mechanism whereby the support issues will not grow expotentially. The *only* way around that is to have a guarantee of some kind that your commercial support organizations patches will get rolled into the main line tree. Otherwise, you have just invented a commercial BSD based on FreeBSD. It will be less expensive for the commercial organization to maintain their own source tree seperately unless there is some guarantee that they will not have to reapply "rejected" patches when they attempt to synchronize source trees. My opinion, 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-current Mon Nov 13 17:54:45 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA11710 for current-outgoing; Mon, 13 Nov 1995 17:54:45 -0800 Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA11703 for ; Mon, 13 Nov 1995 17:54:43 -0800 Received: (from henrich@localhost) by crh.cl.msu.edu (8.6.12/8.6.12) id UAA00592; Mon, 13 Nov 1995 20:54:38 -0500 From: Charles Henrich Message-Id: <199511140154.UAA00592@crh.cl.msu.edu> Subject: Re: ISP state their FreeBSD concerns To: nate@rocky.sri.MT.net (Nate Williams) Date: Mon, 13 Nov 1995 20:54:38 -0500 (EST) Cc: nate@rocky.sri.MT.net, freebsd-current@freebsd.org In-Reply-To: <199511140146.SAA01144@rocky.sri.MT.net> from "Nate Williams" at Nov 13, 95 06:46:41 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 881 Sender: owner-current@freebsd.org Precedence: bulk > In summary, I think the VM folks are doing a good job, and posting like > 'Why didn't you do this, you had plenty of time' can sometimes come out > wrong when you are the receiving end. This is a fun project, and the > release folks are pretty stressed out right now. Wait until the release > is out before pointing fingers at over-worked folks. :) :) I agree, Again let me state my original intentions as to not be lynched when the VM crew gets back :) I was attempting to help them by pointing out a that a patch already existed that may help solve the problem. I bow at the feet of those people who can and do muck around in the kernel, I know I dont want to be touching ANYTHING down in VM land, I know what irate users are like :) -Crh Charles Henrich Michigan State University henrich@crh.cl.msu.edu http://rs560.msu.edu/~henrich/ From owner-freebsd-current Mon Nov 13 18:02:54 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA12134 for current-outgoing; Mon, 13 Nov 1995 18:02:54 -0800 Received: from hub.org (hub.org [199.166.238.138]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA12112 ; Mon, 13 Nov 1995 18:02:46 -0800 Received: (from scrappy@localhost) by hub.org (8.7.1/8.7.1) id VAA04247; Mon, 13 Nov 1995 21:02:01 -0500 (EST) Date: Mon, 13 Nov 1995 21:01:52 -0500 (EST) From: "Marc G. Fournier" To: paul@netcraft.co.uk cc: Paul Reece , freebsd-questions@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: Re: FreeBSD 2.0.5R hanging inexplicably... In-Reply-To: <199511131419.OAA08697@ns0.netcraft.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.org Precedence: bulk On Mon, 13 Nov 1995, Paul Richards wrote: > In reply to Paul Reece who said > > > > On Sun, 12 Nov 1995, Marc G. Fournier wrote: > > > > > For the second time in two days, my system just hung, in that, > > > essentially, no keyboard input was being permitted. > > > > > Which version are you running? > 2.0.5R > I had this happen a lot with 2.0.5 since it didn't handle keyboard > disconnection and unplugging and putting the keyboard back made it > dissappear. I also had it happen "randomly" quite frequently but > I put that down to the some quirk triggering the same problem. > Hrm...one way to reproduce the bug seems to be to exit from screen...not sure if that is related or not though. What happens is that when I exit from screen, usually my NumLock will light up on the keyboard, and that is end of story until I hit the reset button > When I upgraded to stable the problem went away BUT I did have it happen > to me once about three days ago shortly after reboot (5 mins say) just > after upgrading to stable again. That's the only time it's happened in the > last 6 weeks or so but there may be a problem lurking in there somewhere. > > This is with PCVT. > Same here... > I've had worse problems with syscons. There's something wrong with syscons > vt switching, it's not completely reproducable but it happens frequently > enough that I've now switched all our machines to pcvt. The symptom is that > when you switch VT the screen goes completely blank and further attempts > to switch VT just gets a beep (as though no VT was configured). Everything > is still running (getty etc) but the screen is just totally blank. Only way > to recover the console is to reboot. > And someone out there was wondering why more ISPs aren't using FreeBSD? :) Sounds like a big problem to worry about :( > I'd say yes, I had this keyboard problem happen regularly with > 2.0.5 and apart from this one lockup I had a few days ago everythings > been fine since upgrading to 2.1-stable. I doubt the lockup I had > a few days ago is the same problem since the old problem would > happen every few hours, for the moment I'm putting this last lockup > down to the phase of the moon :-) > Ah, then hopefully when 2.1.0R comes out, I won't have this problem again :) Marc G. Fournier | Knowledge, Information and Communications, Inc (ki.net) scrappy@hub.org | soon to be: | scrappy@ki.net | For more information, send me email. From owner-freebsd-current Mon Nov 13 18:58:45 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA13939 for current-outgoing; Mon, 13 Nov 1995 18:58:45 -0800 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA13934 for ; Mon, 13 Nov 1995 18:58:42 -0800 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id TAA18662; Mon, 13 Nov 1995 19:52:25 -0700 From: Terry Lambert Message-Id: <199511140252.TAA18662@phaeton.artisoft.com> Subject: Re: ISP state their FreeBSD concerns To: nate@rocky.sri.MT.net (Nate Williams) Date: Mon, 13 Nov 1995 19:52:24 -0700 (MST) Cc: terry@lambert.org, henrich@crh.cl.msu.edu, nate@rocky.sri.MT.net, freebsd-current@FreeBSD.ORG In-Reply-To: <199511140144.SAA01129@rocky.sri.MT.net> from "Nate Williams" at Nov 13, 95 06:44:15 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2511 Sender: owner-current@FreeBSD.ORG Precedence: bulk > [ Reviewing the VM patch and not bringing it into 2.1 ] > > > I find it hard to believe too, since all that is required is that you > > understand the code. Matt clearly had to do this to generate the > > patches in the first place, and we must assume that the people who > > wrote it understand it enough to predict the results. > > Gee, and I suspect you've never written a bad patch before. Geeze > folks, let's get real now. We were discussing the difficulty of reviewing a patch, not whether or not the results of that review would be "bad patch' or "good patch". > > It's not like this is magic or anything... it's complex, yes, but that > > doesn't make it beyond mortal ken. > > It also doesn't mean that the patch is bad, but *BECAUSE* it is complex > it is often difficult to miss subtle features (as you have shown in the > past :]) and necessary code to get things working right. Even your FS > patches were missing some critical things. If they would have been > committed as submitted, FS corruption and/or panics *would* have > occurred. > > Does this mean you didn't understand all of the issues? Maybe *grin*, > but I'll bet it means you're human more than anything else. I'll bet it's because I initially did them against 2.0.5 and the code changed sufficiently going to -current that I missed some of the patch changes that were necessary because of the code changes to -current. And then I'll bet I screwed up hand-applying the patches to the patches for -current (*that* showed I was human). And it's quite questionable whether the *way* in which read-only FS handling changed (and broke application of my patches) is actually the precise fix for the problem that it attmpted to address (though I readily admit something like it was necessary for translucent/union FS operation with one R/O and one R/W FS overlaid. And I'll bet that I've taken steps to allow me to maintain correct CVS revisions so that that won't happen ever again. The patches I make from now on will cleanly apply against the files whose ID's match the files from which the patches were generated (the same was true before, but now I will be submitting whole files with intact tags so an integrator can 'cvs merge' against the correct tags). The level of abstraction in the two patch sets is definitely not equal; the Dillon patches touch far, far fewer files. 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-current Mon Nov 13 20:09:58 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA19909 for current-outgoing; Mon, 13 Nov 1995 20:09:58 -0800 Received: from server.icon-stl.net (server.icon-stl.net [199.217.153.1]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA19885 ; Mon, 13 Nov 1995 20:09:52 -0800 Received: from gwydion.HNS.St-Louis.Mo.US (dialup-83.icon-stl.net [199.217.153.83]) by server.icon-stl.net (8.6.11/8.6.11) with ESMTP id WAA09968; Mon, 13 Nov 1995 22:09:55 -0600 Received: (from kenth@localhost) by gwydion.HNS.St-Louis.Mo.US (8.6.12/8.6.12) id VAA21443; Mon, 13 Nov 1995 21:13:11 -0600 From: Kent Hamilton Message-Id: <199511140313.VAA21443@gwydion.HNS.St-Louis.Mo.US> Subject: Re: FreeBSD 2.0.5R hanging inexplicably... To: paul@trumpet.net.au (Paul Reece) Date: Mon, 13 Nov 1995 21:13:10 -0600 (CST) Cc: scrappy@hub.org, freebsd-questions@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-hackers@FreeBSD.org In-Reply-To: from "Paul Reece" at Nov 13, 95 03:03:46 pm Reply-To: Kent.Hamilton@HNS.St-Louis.Mo.US Organization: HNS Consulting X-Location: St. Peters, MO USA X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 872 Sender: owner-current@FreeBSD.org Precedence: bulk According to Paul Reece: > > On Sun, 12 Nov 1995, Marc G. Fournier wrote: > > > > > Hi... > > > > For the second time in two days, my system just hung, in that, > > essentially, no keyboard input was being permitted. > > [deleted] > I had the same problem. Since I disabled the screensavers on the console > I've had no further lockups.. > > Perhaps something that needs to be looked at closely? I've seen the same one here. I thought it was just the fact that I had a new machine and it was exhibiting some "odd" behavior. -- Kent Hamilton Work: KHamilton@Hunter.COM URL: http://www.icon-stl.net/~khamilto Play: KentH@HNS.St-Louis.Mo.US "The cop already knows what the sysadmin has yet to learn: The best way to manage a thousand users is at gunpoint. :)" - Mike O'Connor on systems security From owner-freebsd-current Mon Nov 13 20:30:43 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA22250 for current-outgoing; Mon, 13 Nov 1995 20:30:43 -0800 Received: from moa.cc.monash.edu.au (george@moa.cc.monash.edu.au [130.194.40.50]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA22235 for ; Mon, 13 Nov 1995 20:30:36 -0800 Received: (george@localhost) by moa.cc.monash.edu.au (8.6.10/8.6.4) id PAA17007 for freebsd-current@freebsd.org; Tue, 14 Nov 1995 15:29:58 +1100 Date: Tue, 14 Nov 1995 15:29:58 +1100 From: George Scott Message-Id: <199511140429.PAA17007@moa.cc.monash.edu.au> To: freebsd-current@freebsd.org Subject: Problem with wd0 Sender: owner-current@freebsd.org Precedence: bulk On my machine the boot time probes show: > wdc0 at 0x1f0-0x1f7 irq 14 on isa > wdc0: unit 0 (wd0): > wd0: 80MB (164050 sectors), 965 cyls, 10 heads, 17 S/T, 512 B/S The first time I try to use wd0 (eg, using dd if=/dev/wd0 of=/dev/null) I get a pause and then: > wd0: wdcontrol: wdcommand failed reading fsbn 0wd0: status ff error 0 There seems to be two problems here: 1) Shouldn't this message be split over two lines? and, more importantly, 2) What is causing it? This machine is primarily an MS DOS machine; this drive is it's C:, and MS DOS has no problems with it. I boot FreeBSD diskless off another machine. It's running -CURRENT (delta 1174) though I have had this problem ever since I started playing with -CURRENT about 2 months ago. Does anyone have any pointers? George. --------------------------------------------------------------------- George Scott Senior Systems Programmer Caulfield Computer Centre Email: George.Scott@cc.monash.edu.au Monash University Fax : +61 3 9903 2100 900 Dandenong Road Voice: +61 3 9903 2248 Caulfield East, 3145 Victoria, Australia From owner-freebsd-current Mon Nov 13 20:30:57 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA22308 for current-outgoing; Mon, 13 Nov 1995 20:30:57 -0800 Received: from hq.icb.chel.su (icb-rich-gw.icb.chel.su [193.125.10.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA22119 for ; Mon, 13 Nov 1995 20:30:00 -0800 Received: from localhost (babkin@localhost) by hq.icb.chel.su (8.6.5/8.6.5) id JAA19554; Tue, 14 Nov 1995 09:11:49 +0500 From: "Serge A. Babkin" Message-Id: <199511140411.JAA19554@hq.icb.chel.su> Subject: Re: ISP state their FreeBSD concerns To: hsu@cs.hut.fi (Heikki Suonsivu) Date: Tue, 14 Nov 1995 09:11:48 +0500 (GMT+0500) Cc: current@FreeBSD.org, freebsd-current@freefall.FreeBSD.ORG In-Reply-To: <199511131351.PAA20135@shadows.cs.hut.fi> from "Heikki Suonsivu" at Nov 13, 95 03:51:48 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 994 Sender: owner-current@FreeBSD.org Precedence: bulk > Seems they feel hardware flow control doesn't work or isn't enabled > when it should be (or can't be) or both. This may actually be > an issue with the 16550 drivers not setting silo depth to a > reasonable level. Most of these guys use terminal servers for > the actual users where these local serial ports are used for UPS, > router control, serial printers, and other in-house controls. They > complain of seeing problems with lost data outbound when flow > control was in use, including during UUCP sessions. > > I have complained about this several times, but gave up after I realized > noone was listening. I have been including these in all our kernels: There was a bug in TTY line discipline (more precisely, in cblock allocation). Bruce Evans has fixed it in -current (and I think in -stable too) nearly a month ago. Serge Babkin ! (babkin@hq.icb.chel.su) ! Headquarter of Joint Stock Commercial Bank "Chelindbank" ! Chelyabinsk, Russia From owner-freebsd-current Mon Nov 13 20:31:58 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA22534 for current-outgoing; Mon, 13 Nov 1995 20:31:58 -0800 Received: from hq.icb.chel.su (icb-rich-gw.icb.chel.su [193.125.10.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA22355 for ; Mon, 13 Nov 1995 20:31:03 -0800 Received: from localhost (babkin@localhost) by hq.icb.chel.su (8.6.5/8.6.5) id JAA19554; Tue, 14 Nov 1995 09:11:49 +0500 From: "Serge A. Babkin" Message-Id: <199511140411.JAA19554@hq.icb.chel.su> Subject: Re: ISP state their FreeBSD concerns To: hsu@cs.hut.fi (Heikki Suonsivu) Date: Tue, 14 Nov 1995 09:11:48 +0500 (GMT+0500) Cc: current@FreeBSD.org, freebsd-current@freefall.FreeBSD.ORG In-Reply-To: <199511131351.PAA20135@shadows.cs.hut.fi> from "Heikki Suonsivu" at Nov 13, 95 03:51:48 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 994 Sender: owner-current@FreeBSD.org Precedence: bulk > Seems they feel hardware flow control doesn't work or isn't enabled > when it should be (or can't be) or both. This may actually be > an issue with the 16550 drivers not setting silo depth to a > reasonable level. Most of these guys use terminal servers for > the actual users where these local serial ports are used for UPS, > router control, serial printers, and other in-house controls. They > complain of seeing problems with lost data outbound when flow > control was in use, including during UUCP sessions. > > I have complained about this several times, but gave up after I realized > noone was listening. I have been including these in all our kernels: There was a bug in TTY line discipline (more precisely, in cblock allocation). Bruce Evans has fixed it in -current (and I think in -stable too) nearly a month ago. Serge Babkin ! (babkin@hq.icb.chel.su) ! Headquarter of Joint Stock Commercial Bank "Chelindbank" ! Chelyabinsk, Russia From owner-freebsd-current Mon Nov 13 20:40:47 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA23419 for current-outgoing; Mon, 13 Nov 1995 20:40:47 -0800 Received: from hq.icb.chel.su (icb-rich-gw.icb.chel.su [193.125.10.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA23338 for ; Mon, 13 Nov 1995 20:39:55 -0800 Received: from localhost (babkin@localhost) by hq.icb.chel.su (8.6.5/8.6.5) id JAA19967; Tue, 14 Nov 1995 09:39:04 +0500 From: "Serge A. Babkin" Message-Id: <199511140439.JAA19967@hq.icb.chel.su> Subject: Re: ISP state their FreeBSD concerns To: terry@lambert.org (Terry Lambert) Date: Tue, 14 Nov 1995 09:39:03 +0500 (GMT+0500) Cc: karl@mcs.com, terry@lambert.org, current@FreeBSD.org In-Reply-To: <199511132041.NAA17961@phaeton.artisoft.com> from "Terry Lambert" at Nov 13, 95 01:41:13 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1723 Sender: owner-current@FreeBSD.org Precedence: bulk > > The symptom is that processes block while waiting for writes to complete, > > sometimes for as long as several *minutes*. For a system which is taking > > hundreds of hits per minute, this quickly blows the system sky-high. > > Ah. So the hangs are on the client. > > The NFS protocol definition is that the writes must complete before the > call returns to the user process. > > There are three ways to solve this problem: > > 1) Client caching. The operation writes local cache and then > starts an async event with a completion routine. The async > event waits for the ack from the NFS server and releases the > page hold. > > This is dangerous, since the data pretends to be committed > when in fact it only exists in the local systems memory. Not > a problem for news servers, but a real problem for transaction > oriented databases. I personally see a database on NFS absolutely not worth because it is much less effective than running SQL requests. For non-transaction oriented databases like dBASE this crash would be a "normal work". :-) > Client caching is disallowed by the NFS design document. :-( > 3) Increase the number of nfsiod's on the server. This will allow > more concurrent operations to be outstanding at one time. > > This is allowed (encouraged) by the NFS design document. > > Number 3 is well within your control. It can help for multiple processes accessing the files over NFS. If you have single process creating the main load this will not help. And this is one of the problems that make running NFS from DOS machines very ineffective. Serge Babkin ! (babkin@hq.icb.chel.su) ! Headquarter of Joint Stock Commercial Bank "Chelindbank" ! Chelyabinsk, Russia From owner-freebsd-current Mon Nov 13 20:45:09 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA23570 for current-outgoing; Mon, 13 Nov 1995 20:45:09 -0800 Received: from ast.com (irvine.ast.com [165.164.128.2]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id UAA23565 for ; Mon, 13 Nov 1995 20:45:04 -0800 Received: from fw.ast.com by ast.com with SMTP id AA29693 (5.67b/IDA-1.5 for ); Mon, 13 Nov 1995 20:46:11 -0800 Received: from nemesis by fw.ast.com with uucp (Smail3.1.29.1 #4) id m0tFD8u-00008RC; Mon, 13 Nov 95 22:38 CST Received: by nemesis.lonestar.org (Smail3.1.27.1 #19) id m0tFD4o-000J7hC; Mon, 13 Nov 95 22:34 WET Message-Id: Date: Mon, 13 Nov 95 22:34 WET To: simonm@dcs.gla.ac.uk, davidg@root.com From: uhclem%nemesis@fw.ast.com (Frank Durda IV) Sent: Mon Nov 13 1995, 22:34:29 CST Subject: Re: Disk I/O that binds Cc: current@freebsd.org Sender: owner-current@freebsd.org Precedence: bulk [1]Just a guess, but could this be caused by the disk request sorting [1]done by FreeBSD? New requests get entered into the queue possibly [1]before old ones, and it could be a long time before a request finally [1]gets serviced. [2] Yes, and this does contribute to the problem. This was the topic of a [2]recent discussion between myself and John Dyson. Our disksort could use [2]a little work. One thing I'd like to do is make it possible for the driver [2]to request that no sorting be done. This would allow controllers that can [2]do tagged queuing to pass the I/O off to the drive unordered - allowing [2]the drive to use superior sorting algorithms. [2]-DG [3]Frank writes: [3]Are you saying that the disksort is not performing an elevator sort [3]or some other type of sort designed for multi-tasking disk operations? [3]Interesting. [3] [3]That would certainly explain the symptom I see. We wrote an elevator sort [3]years ago for Tandy 6000 XENIX because the one that came in the AT&T V7 and [3]Microsoft XENIX port code did would end up favoring the process doing a [3]copy of large items from one place to another (such as article archiving [3]in news), and other processes that were doing simple stats of files would [3]hang waiting until the other process gulped. The end result of the MS [3]scheme was a sort that did pretty good in the sequential read/write [3]benchmark, but killed multiuser operations. We replaced it. [3]It never occurred to me that this sort of problem would still be around. I have just run a few tests and have found a way to get a bind to occur in just a few tries. All I/O was on SCSI drives (NO IDE). Hard disk was 2GB Seagate Baracuda and SCSI was 1540B Adaptec. 1104 stock kernel (also done on a 2.0.5 with driver deletions kernel), 8MB RAM. 1. Kill any processes that might be doing a lot of writes in background, such as tind, kick off UUCP, the users, etc. It seems OK to leave update, sendmail and other intermittent items running, although it may fail faster with them eliminated too. 2. cd /usr/spool/news (assuming you have news) on one multiscreen. Type cp history /dev/null (or you can use some other extremely large file. My copy of history was 29Meg. History is usually a bit fragmented, although I don't know if that is a factor.) 3. On a different multiscreen, do a ls -alR of *ANY* filesystem located on the same drive. (It can be a different slice). Now watch the ls progress. It will probably run fast for 40 to 80 seconds and then it will slow and stop. Each time it pauses, start counting and note where you are path-wise. Then when it resumes, note how many files were in the directory it took a long time on. When you hit a directory that has less than ten files in it and it takes 20 seconds or more to display it, you are seeing the problem. If you can't get it to happen right away, do a few "!!"s on the screen with the cp so that it won't run out of things to do and give you false results. You may note when the ls pauses, the hard disk seems to go quiet also (less seeking), although the SCSI controller light remains on solid. I did a ps -alx on a third screen while the ls was stuck (in my case, the directory it was stuck on had six files, one subdirectory, and took 27 seconds to resume and display. (The subdirectory contained one file.) It also paused on the next three or four directories for excessive amounts of time vs the number of files present in the directories. The ps shows that the cp was in "getblk D+" while the ls was in "biowai D+". Note that there is no disk writing going on here in the test commands. I was able to get it to fail with disk writing, such as changing the cp history /dev/null to cp history xyzzy, but it seemed to take a lot longer to fail. I also didn't kill update or any of the basic services, so there was someone doing a write once in a while, even during the first example. This smells like a disksort implementation flaw that resets direction each time an item is added to the queue, rather than completely exhausting the queue in one direction before reversing direction. Something like an elevator sort should be done. Frank Durda IV |"The Knights who say "LETNi" or uhclem%nemesis@fw.ast.com (Fastest Route)| demand... A SEGMENT REGISTER!!!" ...letni!rwsys!nemesis!uhclem |"A what?" ...decvax!fw.ast.com!nemesis!uhclem |"LETNi! LETNi! LETNi!" - 1983 From owner-freebsd-current Mon Nov 13 21:31:21 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA26777 for current-outgoing; Mon, 13 Nov 1995 21:31:21 -0800 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA26768 for ; Mon, 13 Nov 1995 21:31:12 -0800 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id VAA27689; Mon, 13 Nov 1995 21:31:10 -0800 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id VAA04287; Mon, 13 Nov 1995 21:25:39 -0800 Message-Id: <199511140525.VAA04287@corbin.Root.COM> To: Charles Henrich cc: nate@rocky.sri.mt.net (Nate Williams), freebsd-current@freebsd.org Subject: Re: ISP state their FreeBSD concerns In-reply-to: Your message of "Mon, 13 Nov 95 20:19:11 EST." <199511140119.UAA00359@crh.cl.msu.edu> From: David Greenman Reply-To: davidg@Root.COM Date: Mon, 13 Nov 1995 21:25:38 -0800 Sender: owner-current@freebsd.org Precedence: bulk >> There are only so many hours in a day, and those 24 were spent making >> 2.1 as good as it could get. If this means that the system still has a >> 'feature' of pausing under certain conditions I don't mind it as much as >> rebooting and/or panicing under more common scenarios. > >I tend to agree with that, however if Im not mistaken (I could be, its been >awhile) Matt provided source patches at the time that fixed the problems, would >it have been that difficult to review the patches and apply them? My memory is fuzzy on this, but my recollection is that people tried them and they didn't solve the problem. >I agree that this cant go into 2.1 now, I'm just hoping it gets looked at >before 2.2 I think the problems are fairly well understood and the solutions are complex. We will be working on this issue for 2.2. -DG From owner-freebsd-current Mon Nov 13 21:36:02 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA27070 for current-outgoing; Mon, 13 Nov 1995 21:36:02 -0800 Received: from hutcs.cs.hut.fi (root@hutcs.cs.hut.fi [130.233.192.2]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id VAA27058 for ; Mon, 13 Nov 1995 21:35:54 -0800 Received: from shadows.cs.hut.fi by hutcs.cs.hut.fi with SMTP id AA07726 (5.65c8/HUTCS-S 1.4 for ); Tue, 14 Nov 1995 07:35:49 +0200 Received: (hsu@localhost) by shadows.cs.hut.fi (8.6.10/8.6.10) id HAA27798; Tue, 14 Nov 1995 07:36:05 +0200 Date: Tue, 14 Nov 1995 07:36:05 +0200 Message-Id: <199511140536.HAA27798@shadows.cs.hut.fi> From: Heikki Suonsivu To: Bruce Evans Cc: current@FreeBSD.org Subject: Re: ISP state their FreeBSD concerns In-Reply-To: <199511132237.JAA10845@godzilla.zeta.org.au> References: <199511132237.JAA10845@godzilla.zeta.org.au> Sender: owner-current@FreeBSD.org Precedence: bulk Bruce Evans writes: > >+ #ifndef RS_IBUFSIZE > > #define RS_IBUFSIZE 256 > >+ #endif > >... > >and these in my configuration files > > >maxusers 128 > >options "NMBCLUSTERS=4096" > >options "TTYHOG=8192" > >options "RS_IBUFSIZE=2048" > Your setup is very special. Hardware flow control is required to handle > transient high loads. If you can't use it and can't handle dropped input > then you have to do a lot of work to guarantee that there are no transient > high loads. Processes doing serial i/o must run often enough to read I don't mind your opinion, and will continue inserting my patch in my systems to make FreeBSD work. But I do think FreeBSD might gain more popularity by being able to receive PPP at 115.2k, even without flow control and without kernel patches. -- Heikki Suonsivu, T{ysikuu 10 C 83/02210 Espoo/FINLAND, hsu@cs.hut.fi home +358-0-8031121 work -4513377 fax -4555276 riippu SN From owner-freebsd-current Mon Nov 13 21:36:21 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA27107 for current-outgoing; Mon, 13 Nov 1995 21:36:21 -0800 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA27094 for ; Mon, 13 Nov 1995 21:36:13 -0800 Received: (from julian@localhost) by ref.tfs.com (8.6.12/8.6.9) id VAA26450; Mon, 13 Nov 1995 21:34:17 -0800 From: Julian Elischer Message-Id: <199511140534.VAA26450@ref.tfs.com> Subject: Re: Disk I/O that binds To: uhclem%nemesis@fw.ast.com (Frank Durda IV) Date: Mon, 13 Nov 1995 21:34:16 -0800 (PST) Cc: simonm@dcs.gla.ac.uk, davidg@Root.COM, current@freebsd.org In-Reply-To: from "Frank Durda IV" at Nov 13, 95 10:34:00 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 4666 Sender: owner-current@freebsd.org Precedence: bulk Last I checked it was a double que elevator sort... any block requewsted that is behind you gets put in the "next pass" queue, and anything in front of you get's put in front of you in the "present pass" queue.. direction of travel never changes.. (I just checked again, it hasn't changed) It's possible that if one process has started reading a large file that was read onto the disk sequentially, then otehr processes may starve.. it goes like this: process 1 reads block x, and the readahead puts in a request for block x+1 process 1 reads plock x+1, readahead inserts block x+2 etc. as the disk is walking slowely forwards along the disk, any process looking for a block BEFORE x is missing out.. this should only be a problem for systems where the cpu is fast enough to deal with the present block and put it's request for the next one in before the disk has completed transfer of the readahead block. In effect the faster the system, the more problem you're going to have... however, a 5 Second wait would imply reading about 25MB of data! (though I guess a process that neads to do 10 reads needs to get past this hog 10 times before being able to proceed (it might be getting little bits of disk at a time. It's possibly the only way to fix this might be a 'fair share' stricture, in which a system volintarily puts the lookahead block in the second queue after a certain number of successful read-aheads.. Certainly the disk clustering code must have effected this.. Anyone with a linux machine care to check what they have as a disk-sort? I bet they have something similar... > > I have just run a few tests and have found a way to get a bind to occur > in just a few tries. All I/O was on SCSI drives (NO IDE). Hard disk > was 2GB Seagate Baracuda and SCSI was 1540B Adaptec. 1104 stock kernel > (also done on a 2.0.5 with driver deletions kernel), 8MB RAM. > > 1. Kill any processes that might be doing a lot of writes in > background, such as tind, kick off UUCP, the users, etc. It seems > OK to leave update, sendmail and other intermittent items running, > although it may fail faster with them eliminated too. > > 2. cd /usr/spool/news (assuming you have news) on one multiscreen. > Type cp history /dev/null > (or you can use some other extremely large file. My copy of history > was 29Meg. History is usually a bit fragmented, although I don't > know if that is a factor.) > > 3. On a different multiscreen, do a ls -alR of *ANY* filesystem > located on the same drive. (It can be a different slice). > > Now watch the ls progress. It will probably run fast for 40 to 80 seconds > and then it will slow and stop. Each time it pauses, start counting > and note where you are path-wise. Then when it resumes, note how > many files were in the directory it took a long time on. > > When you hit a directory that has less than ten files in it and it > takes 20 seconds or more to display it, you are seeing the problem. If > you can't get it to happen right away, do a few "!!"s on the screen > with the cp so that it won't run out of things to do and give you false > results. > > You may note when the ls pauses, the hard disk seems to go quiet also > (less seeking), although the SCSI controller light remains on solid. > > I did a ps -alx on a third screen while the ls was stuck (in my case, > the directory it was stuck on had six files, one subdirectory, and took > 27 seconds to resume and display. (The subdirectory contained one file.) > It also paused on the next three or four directories for excessive > amounts of time vs the number of files present in the directories. > The ps shows that the cp was in "getblk D+" while the ls was in "biowai D+". > > Note that there is no disk writing going on here in the test commands. > I was able to get it to fail with disk writing, such as changing the > cp history /dev/null to cp history xyzzy, but it seemed to take a lot longer > to fail. I also didn't kill update or any of the basic services, so there > was someone doing a write once in a while, even during the first example. > > This smells like a disksort implementation flaw that resets direction each > time an item is added to the queue, rather than completely exhausting the > queue in one direction before reversing direction. Something like an > elevator sort should be done. > > Frank Durda IV |"The Knights who say "LETNi" > or uhclem%nemesis@fw.ast.com (Fastest Route)| demand... A SEGMENT REGISTER!!!" > ...letni!rwsys!nemesis!uhclem |"A what?" > ...decvax!fw.ast.com!nemesis!uhclem |"LETNi! LETNi! LETNi!" - 1983 > > From owner-freebsd-current Mon Nov 13 21:55:31 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA28299 for current-outgoing; Mon, 13 Nov 1995 21:55:31 -0800 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA28292 for ; Mon, 13 Nov 1995 21:55:25 -0800 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id VAA27737; Mon, 13 Nov 1995 21:55:24 -0800 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id VAA04329; Mon, 13 Nov 1995 21:49:49 -0800 Message-Id: <199511140549.VAA04329@corbin.Root.COM> To: Julian Elischer cc: uhclem%nemesis@fw.ast.com (Frank Durda IV), simonm@dcs.gla.ac.uk, current@freebsd.org Subject: Re: Disk I/O that binds In-reply-to: Your message of "Mon, 13 Nov 95 21:34:16 PST." <199511140534.VAA26450@ref.tfs.com> From: David Greenman Reply-To: davidg@Root.COM Date: Mon, 13 Nov 1995 21:49:48 -0800 Sender: owner-current@freebsd.org Precedence: bulk >however, a 5 Second wait would imply reading about 25MB of data! >(though I guess a process that neads to do 10 reads needs to get past this hog >10 times before being able to proceed (it might be getting little bits >of disk at a time. Only if you have very fast disks...which explains why people like me don't see the problem very often, and when I do see it, it's not serious enough to be a "problem". People with slow disks (IDE) will see the problem magnified significantly. For fairness, I think the queue depth for each chunk needs to be limited to less than 10 requests. It should be tuneable so that we can experiment with different values. For the moment I can write a patch that will disable the sorting in disksort - people experiancing the "hang" problem should try the patch when I make it available and see if the problem goes away. ...Of course disk performance will suffer unless you're using SCSI with tagged queueing (in which case the drive does the ordering - usually much more intelligently). -DG From owner-freebsd-current Mon Nov 13 22:48:35 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA02266 for current-outgoing; Mon, 13 Nov 1995 22:48:35 -0800 Received: from hutcs.cs.hut.fi (root@hutcs.cs.hut.fi [130.233.192.2]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id WAA02257 for ; Mon, 13 Nov 1995 22:48:32 -0800 Received: from shadows.cs.hut.fi by hutcs.cs.hut.fi with SMTP id AA08114 (5.65c8/HUTCS-S 1.4 for ); Tue, 14 Nov 1995 08:48:27 +0200 Received: (hsu@localhost) by shadows.cs.hut.fi (8.6.10/8.6.10) id IAA28625; Tue, 14 Nov 1995 08:48:42 +0200 Date: Tue, 14 Nov 1995 08:48:42 +0200 Message-Id: <199511140648.IAA28625@shadows.cs.hut.fi> From: Heikki Suonsivu To: davidg@root.com Cc: Heikki Suonsivu , current@freebsd.org Subject: Re: ISP state their FreeBSD concerns In-Reply-To: <199511131621.IAA04109@corbin.Root.COM> References: <199511131351.PAA20135@shadows.cs.hut.fi> <199511131621.IAA04109@corbin.Root.COM> Sender: owner-current@freebsd.org Precedence: bulk David Greenman writes: > >The troubling disks for us seem to be seagate hawks, but I have also had > >problems with an ibm 0662 (but it could be seagates in the same bus). I > >have tried a 2G barracuda and 4G hawk for news spool, both with same > >results, disk gets confused and scsi driver returns I/O errors for all > >accesses or the system panics. > > We've been having similar problems with Seagate Hawks on wcarchive. I plan > to switch them out for 4GB Quantum Grand Prixs in the near term. Have you discussed about this with seagate? With sparcs they seem to work just fine. -- Heikki Suonsivu, T{ysikuu 10 C 83/02210 Espoo/FINLAND, hsu@cs.hut.fi home +358-0-8031121 work -4513377 fax -4555276 riippu SN From owner-freebsd-current Mon Nov 13 23:00:41 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA02877 for current-outgoing; Mon, 13 Nov 1995 23:00:41 -0800 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA02871 for ; Mon, 13 Nov 1995 23:00:37 -0800 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id XAA27864; Mon, 13 Nov 1995 23:00:36 -0800 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id XAA00132; Mon, 13 Nov 1995 23:00:35 -0800 Message-Id: <199511140700.XAA00132@corbin.Root.COM> To: Heikki Suonsivu cc: current@freebsd.org Subject: Re: ISP state their FreeBSD concerns In-reply-to: Your message of "Tue, 14 Nov 95 08:48:42 +0200." <199511140648.IAA28625@shadows.cs.hut.fi> From: David Greenman Reply-To: davidg@Root.COM Date: Mon, 13 Nov 1995 23:00:34 -0800 Sender: owner-current@freebsd.org Precedence: bulk >David Greenman writes: > > >The troubling disks for us seem to be seagate hawks, but I have also had > > >problems with an ibm 0662 (but it could be seagates in the same bus). I > > >have tried a 2G barracuda and 4G hawk for news spool, both with same > > >results, disk gets confused and scsi driver returns I/O errors for all > > >accesses or the system panics. > > > > We've been having similar problems with Seagate Hawks on wcarchive. I plan > > to switch them out for 4GB Quantum Grand Prixs in the near term. > >Have you discussed about this with seagate? With sparcs they seem to work >just fine. No, I haven't. I think the Hawks have firmware bug(s) that only show up after days of heavy disk I/O and/or when interacting with drives from other manufacturers. I have very little patience for this this kind of thing which is why I have no plans to mess around with Seagate tech support. Of course it's also possible that there is a problem with the Adaptec 2940 sequencer code that's in FreeBSD, but I'm beginning to seriously doubt that. -DG From owner-freebsd-current Mon Nov 13 23:13:29 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA03628 for current-outgoing; Mon, 13 Nov 1995 23:13:29 -0800 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA03617 for ; Mon, 13 Nov 1995 23:13:27 -0800 Received: (from julian@localhost) by ref.tfs.com (8.6.12/8.6.9) id XAA26748; Mon, 13 Nov 1995 23:11:53 -0800 From: Julian Elischer Message-Id: <199511140711.XAA26748@ref.tfs.com> Subject: Re: Disk I/O that binds To: davidg@Root.COM Date: Mon, 13 Nov 1995 23:11:51 -0800 (PST) Cc: uhclem%nemesis@fw.ast.com, simonm@dcs.gla.ac.uk, current@freebsd.org In-Reply-To: <199511140549.VAA04329@corbin.Root.COM> from "David Greenman" at Nov 13, 95 09:49:48 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1263 Sender: owner-current@freebsd.org Precedence: bulk Another answer may be in the way we allocate blocks on the disk.. maybe we should allocate less on any particular cylinder group and jump around more often??? (might be an easier answer :) > >however, a 5 Second wait would imply reading about 25MB of data! > >(though I guess a process that neads to do 10 reads needs to get past this hog > >10 times before being able to proceed (it might be getting little bits > >of disk at a time. > > Only if you have very fast disks...which explains why people like me don't > see the problem very often, and when I do see it, it's not serious enough to > be a "problem". People with slow disks (IDE) will see the problem magnified > significantly. > For fairness, I think the queue depth for each chunk needs to be limited to > less than 10 requests. It should be tuneable so that we can experiment with > different values. For the moment I can write a patch that will disable the > sorting in disksort - people experiancing the "hang" problem should try the > patch when I make it available and see if the problem goes away. ...Of course > disk performance will suffer unless you're using SCSI with tagged queueing (in > which case the drive does the ordering - usually much more intelligently). > > -DG > From owner-freebsd-current Mon Nov 13 23:15:01 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA03758 for current-outgoing; Mon, 13 Nov 1995 23:15:01 -0800 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA03751 for ; Mon, 13 Nov 1995 23:14:58 -0800 Received: (from julian@localhost) by ref.tfs.com (8.6.12/8.6.9) id XAA26764; Mon, 13 Nov 1995 23:13:25 -0800 From: Julian Elischer Message-Id: <199511140713.XAA26764@ref.tfs.com> Subject: Re: Disk I/O that binds To: julian@ref.tfs.com (Julian Elischer) Date: Mon, 13 Nov 1995 23:13:24 -0800 (PST) Cc: uhclem%nemesis@fw.ast.com, simonm@dcs.gla.ac.uk, davidg@Root.COM, current@freebsd.org In-Reply-To: <199511140534.VAA26450@ref.tfs.com> from "Julian Elischer" at Nov 13, 95 09:34:16 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 4947 Sender: owner-current@freebsd.org Precedence: bulk David.. this is something I think Kirk might have useful input on.. wanna forward it? > > Last I checked it was a double que elevator sort... > any block requewsted that is behind you gets put in the "next pass" > queue, and anything in front of you get's put in front of you in the > "present pass" queue.. direction of travel never changes.. > (I just checked again, it hasn't changed) > > It's possible that if one process has started reading a large file that was > read onto the disk sequentially, then otehr processes may starve.. > it goes like this: > > process 1 reads block x, and the readahead puts in a request for block x+1 > process 1 reads plock x+1, readahead inserts block x+2 > > etc. > > > as the disk is walking slowely forwards along the disk, any process looking for a block BEFORE x is missing out.. > this should only be a problem for systems where the cpu is fast enough > to deal with the present block and put it's request for the next one in before the disk has completed transfer of the readahead block. > In effect the faster the system, the more problem you're going to have... > > however, a 5 Second wait would imply reading about 25MB of data! > (though I guess a process that neads to do 10 reads needs to get past this hog > 10 times before being able to proceed (it might be getting little bits > of disk at a time. > > It's possibly the only way to fix this might be a 'fair share' stricture, > in which a system volintarily puts the lookahead block in the second > queue after a certain number of successful read-aheads.. > Certainly the disk clustering code must have effected this.. > > Anyone with a linux machine care to check what they have as a disk-sort? > I bet they have something similar... > > > > > I have just run a few tests and have found a way to get a bind to occur > > in just a few tries. All I/O was on SCSI drives (NO IDE). Hard disk > > was 2GB Seagate Baracuda and SCSI was 1540B Adaptec. 1104 stock kernel > > (also done on a 2.0.5 with driver deletions kernel), 8MB RAM. > > > > 1. Kill any processes that might be doing a lot of writes in > > background, such as tind, kick off UUCP, the users, etc. It seems > > OK to leave update, sendmail and other intermittent items running, > > although it may fail faster with them eliminated too. > > > > 2. cd /usr/spool/news (assuming you have news) on one multiscreen. > > Type cp history /dev/null > > (or you can use some other extremely large file. My copy of history > > was 29Meg. History is usually a bit fragmented, although I don't > > know if that is a factor.) > > > > 3. On a different multiscreen, do a ls -alR of *ANY* filesystem > > located on the same drive. (It can be a different slice). > > > > Now watch the ls progress. It will probably run fast for 40 to 80 seconds > > and then it will slow and stop. Each time it pauses, start counting > > and note where you are path-wise. Then when it resumes, note how > > many files were in the directory it took a long time on. > > > > When you hit a directory that has less than ten files in it and it > > takes 20 seconds or more to display it, you are seeing the problem. If > > you can't get it to happen right away, do a few "!!"s on the screen > > with the cp so that it won't run out of things to do and give you false > > results. > > > > You may note when the ls pauses, the hard disk seems to go quiet also > > (less seeking), although the SCSI controller light remains on solid. > > > > I did a ps -alx on a third screen while the ls was stuck (in my case, > > the directory it was stuck on had six files, one subdirectory, and took > > 27 seconds to resume and display. (The subdirectory contained one file.) > > It also paused on the next three or four directories for excessive > > amounts of time vs the number of files present in the directories. > > The ps shows that the cp was in "getblk D+" while the ls was in "biowai D+". > > > > Note that there is no disk writing going on here in the test commands. > > I was able to get it to fail with disk writing, such as changing the > > cp history /dev/null to cp history xyzzy, but it seemed to take a lot longer > > to fail. I also didn't kill update or any of the basic services, so there > > was someone doing a write once in a while, even during the first example. > > > > This smells like a disksort implementation flaw that resets direction each > > time an item is added to the queue, rather than completely exhausting the > > queue in one direction before reversing direction. Something like an > > elevator sort should be done. > > > > Frank Durda IV |"The Knights who say "LETNi" > > or uhclem%nemesis@fw.ast.com (Fastest Route)| demand... A SEGMENT REGISTER!!!" > > ...letni!rwsys!nemesis!uhclem |"A what?" > > ...decvax!fw.ast.com!nemesis!uhclem |"LETNi! LETNi! LETNi!" - 1983 > > > > > > From owner-freebsd-current Mon Nov 13 23:26:02 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA04369 for current-outgoing; Mon, 13 Nov 1995 23:26:02 -0800 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA04364 for ; Mon, 13 Nov 1995 23:25:59 -0800 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id XAA27929; Mon, 13 Nov 1995 23:25:57 -0800 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id XAA00188; Mon, 13 Nov 1995 23:25:53 -0800 Message-Id: <199511140725.XAA00188@corbin.Root.COM> To: uhclem%nemesis@fw.ast.com (Frank Durda IV) cc: simonm@dcs.gla.ac.uk, davidg@root.com, current@freebsd.org Subject: Re: Disk I/O that binds In-reply-to: Your message of "Mon, 13 Nov 95 22:34:00 +0700." From: David Greenman Reply-To: davidg@root.com Date: Mon, 13 Nov 1995 23:25:53 -0800 Sender: owner-current@freebsd.org Precedence: bulk Attached is the patch to disable disk block sorting. It's interesting - I've been doing some tests here with disksort disabled and I'm actually seeing a performance increase. I'm sure the algorithm is doing what it was written to do...but... My (SCSI) drive supports tagged queueing, but even with that disabled things seem to be a bit faster. Hmmm. -DG Index: ufs_disksubr.c =================================================================== RCS file: /home/ncvs/src/sys/ufs/ufs/ufs_disksubr.c,v retrieving revision 1.19 diff -c -r1.19 ufs_disksubr.c *** 1.19 1995/09/16 17:04:06 --- ufs_disksubr.c 1995/11/14 06:30:43 *************** *** 81,86 **** --- 81,87 ---- return; } + #if 0 /* * If we lie after the first (currently active) request, then we * must locate the second request list and add ourselves to it. *************** *** 135,140 **** --- 136,146 ---- * Neither a second list nor a larger request... we go at the end of * the first list, which is the same as the end of the whole schebang. */ + #endif + + bq = ap->b_actf; + while (bq->b_actf) + bq = bq->b_actf; insert: bp->b_actf = bq->b_actf; bq->b_actf = bp; From owner-freebsd-current Mon Nov 13 23:26:54 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA04414 for current-outgoing; Mon, 13 Nov 1995 23:26:54 -0800 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA04408 for ; Mon, 13 Nov 1995 23:26:50 -0800 Received: (from julian@localhost) by ref.tfs.com (8.6.12/8.6.9) id XAA26807; Mon, 13 Nov 1995 23:25:13 -0800 From: Julian Elischer Message-Id: <199511140725.XAA26807@ref.tfs.com> Subject: Re: Disk I/O that binds To: davidg@Root.COM Date: Mon, 13 Nov 1995 23:25:12 -0800 (PST) Cc: uhclem%nemesis@fw.ast.com, simonm@dcs.gla.ac.uk, current@freebsd.org In-Reply-To: <199511140715.XAA00155@corbin.Root.COM> from "David Greenman" at Nov 13, 95 11:15:00 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1292 Sender: owner-current@freebsd.org Precedence: bulk Actually here's an answer that might tackle it from another point.. if the raised priority that a process get's after getting a block is lower that the raised priority that a process gets after being suspended for a second or two, then in a busy system, whenever processes start getting held up the hog process will start to lose out a little more.. and maybe if it get's its read of the read-ahead buffer in just a little later, the head might have got a chance to get past it in which case it will have to go all the way around again.. at least in this method, an un busy system has less degradation.. processes that read a lot are constantly cycling into high priority after every read, but the sleeps are so short that these processes are basically permanently at raised priority.. especially with read-ahead and track caches making the disks so dammed fast > > >Another answer may be in the way we allocate blocks on the disk.. > >maybe we should allocate less on any particular cylinder group and > >jump around more often??? > > > >(might be an easier answer :) > > Oh, I know, let's allocate all the blocks in reverse order - 7219 7218 7217, > etc. ...or better yet, let's use the new /dev/random driver to generate a > block list. Yeah, I *like* that idea. :-) > > -DG > From owner-freebsd-current Mon Nov 13 23:38:15 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA05490 for current-outgoing; Mon, 13 Nov 1995 23:38:15 -0800 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA05485 for ; Mon, 13 Nov 1995 23:38:12 -0800 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id XAA27972; Mon, 13 Nov 1995 23:38:11 -0800 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id XAA00133; Mon, 13 Nov 1995 23:38:10 -0800 Message-Id: <199511140738.XAA00133@corbin.Root.COM> To: Julian Elischer cc: uhclem%nemesis@fw.ast.com, simonm@dcs.gla.ac.uk, current@freebsd.org Subject: Re: Disk I/O that binds In-reply-to: Your message of "Mon, 13 Nov 95 23:25:12 PST." <199511140725.XAA26807@ref.tfs.com> From: David Greenman Reply-To: davidg@Root.COM Date: Mon, 13 Nov 1995 23:38:10 -0800 Sender: owner-current@freebsd.org Precedence: bulk >Actually here's an answer that might tackle it from another point.. >if the raised priority that a process get's after getting a block >is lower that the raised priority that a process gets after being suspended > for a second or two, then >in a busy system, whenever processes start getting held up the hog process >will start to lose out a little more.. and maybe if it get's its read of the >read-ahead buffer in just a little later, the head might have got a chance to >get past it in which case it will have to go all the way around again.. >at least in this method, an un busy system has less degradation.. > > >processes that read a lot are constantly cycling >into high priority after every read, but the sleeps are so short that >these processes are basically permanently at raised priority.. >especially with read-ahead and track caches making the disks so dammed fast Yes, this was the theory behind Matt Dillon's patches if my memory is correct (it might very well not be :-)). I think the problem is a composite of a variety of things. -DG From owner-freebsd-current Mon Nov 13 23:38:52 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA05560 for current-outgoing; Mon, 13 Nov 1995 23:38:52 -0800 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA05555 for ; Mon, 13 Nov 1995 23:38:49 -0800 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id XAA26338; Mon, 13 Nov 1995 23:38:01 -0800 To: Nate Williams cc: Charles Henrich , freebsd-current@freebsd.org Subject: Re: ISP state their FreeBSD concerns In-reply-to: Your message of "Mon, 13 Nov 1995 18:25:22 MST." <199511140125.SAA01060@rocky.sri.MT.net> Date: Mon, 13 Nov 1995 23:38:00 -0800 Message-ID: <26335.816334680@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org Precedence: bulk > Since the VM system is *very* sensitive to even minor modifications, I > suspect it would have taken a *very* long to review the patches, apply > them to the system, and then test them. Even very simple errors can > cause *massive* corruptions, and I'm sure both David and John would > rather avoid that for something as critical as the 2.1 release. There's another issue, which is that David and John have been the entire VM system development team for awhile, not to mention actively involved in many other areas. To put it succinctly: They need help. We (the project) need more kernel hackers willing to go into the labyrintian depths of the code and carefully follow all the little chains of cause and effect that make things happen the way they happen (or occasionally not happen, which is when serious debugging skills are required). This is not easy work, and I've sat on the phone with David a number of times while he's chased a bug, listening to some of the steps required. Writing dozens of little test programs, carefully engineered to cause one bug or another, loading a system to the gills and watching it very very carefully at a number of different "test points" to see just how it's working. For those who've done any serious hardware work on complex pieces of hardware, you'll know the picture well. You end up with the equivalent of frankenstein's lab - various multi-channel logic analysers plugged in at different points, an oscilloscope or two, jumpers running hither and yon. It's not something for the faint of heart, and being able to *read* all those signals and say "aha!" from the faintest twitch of line A522 on some obscure multi-channel oscilloscope trace, thus knowing the problem and fixing it, is not a skill that grows on trees. Maybe we should try to make the project an accredited university, then at least those who gained such skills here could earn some recognition for the fact in the marketplace. CS majors could "intern" with us for awhile. :-) Jordan From owner-freebsd-current Mon Nov 13 23:40:16 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA05675 for current-outgoing; Mon, 13 Nov 1995 23:40:16 -0800 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA05668 for ; Mon, 13 Nov 1995 23:40:14 -0800 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id XAA26349; Mon, 13 Nov 1995 23:39:39 -0800 To: Charles Henrich cc: nate@rocky.sri.MT.net (Nate Williams), freebsd-current@freebsd.org Subject: Re: ISP state their FreeBSD concerns In-reply-to: Your message of "Mon, 13 Nov 1995 20:26:20 EST." <199511140126.UAA00419@crh.cl.msu.edu> Date: Mon, 13 Nov 1995 23:39:39 -0800 Message-ID: <26347.816334779@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org Precedence: bulk > I find it hard to believe it would have taken longer than the 3 or 4 months i ts > been since he posted them. Even if there truly was no time to review the > patches for 2.1 since then, would it have not made sense to pull them into 2. 2 > to get the ball rolling? See my previous comments. Say you do pull them into 2.2. Now who's going to LOOK at them? We have 10 emergency patients sitting in the waiting room and only 2 doctors on duty. Which 8 patients should we let die first? Jordan From owner-freebsd-current Mon Nov 13 23:41:42 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA05810 for current-outgoing; Mon, 13 Nov 1995 23:41:42 -0800 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA05803 for ; Mon, 13 Nov 1995 23:41:38 -0800 Received: (from julian@localhost) by ref.tfs.com (8.6.12/8.6.9) id XAA26852; Mon, 13 Nov 1995 23:39:53 -0800 From: Julian Elischer Message-Id: <199511140739.XAA26852@ref.tfs.com> Subject: Re: Disk I/O that binds To: davidg@Root.COM Date: Mon, 13 Nov 1995 23:39:53 -0800 (PST) Cc: uhclem%nemesis@fw.ast.com, simonm@dcs.gla.ac.uk, current@freebsd.org In-Reply-To: <199511140715.XAA00155@corbin.Root.COM> from "David Greenman" at Nov 13, 95 11:15:00 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1272 Sender: owner-current@freebsd.org Precedence: bulk hmm a little radical but it'd be very fair.. SLOW, but very fair :) I was thinking that the disksort might be convinced to not put the next block at the start of the queue if the 3rd entry has seen more than (say) 10 blocks queuejumped in front of it.. hmmm we would add a pointer to the "one after next" every time something gets put in front of it, a counter is incremented. if the counter reaches some value, we don't do that any more... when it finally gets run, we reset the pointer and counter (add glue logic for startup and boundary conditions etc..) it could be implimented pretty simply.. (and would be quick) I may wander off and see what it would take.... unfortunatly we don't have a generic 'take it off the disk queue' routine, just one for puting it on.. :( (damn!) I guess we would have to change sd.c and wd.c too (oh poo) > > >Another answer may be in the way we allocate blocks on the disk.. > >maybe we should allocate less on any particular cylinder group and > >jump around more often??? > > > >(might be an easier answer :) > > Oh, I know, let's allocate all the blocks in reverse order - 7219 7218 7217, > etc. ...or better yet, let's use the new /dev/random driver to generate a > block list. Yeah, I *like* that idea. :-) > > -DG > From owner-freebsd-current Mon Nov 13 23:46:26 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA06192 for current-outgoing; Mon, 13 Nov 1995 23:46:26 -0800 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA06187 for ; Mon, 13 Nov 1995 23:46:24 -0800 Received: (from julian@localhost) by ref.tfs.com (8.6.12/8.6.9) id XAA26872; Mon, 13 Nov 1995 23:44:51 -0800 From: Julian Elischer Message-Id: <199511140744.XAA26872@ref.tfs.com> Subject: Re: Disk I/O that binds To: davidg@Root.COM Date: Mon, 13 Nov 1995 23:44:50 -0800 (PST) Cc: uhclem%nemesis@fw.ast.com, simonm@dcs.gla.ac.uk, current@freebsd.org In-Reply-To: <199511140725.XAA00188@corbin.Root.COM> from "David Greenman" at Nov 13, 95 11:25:53 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 432 Sender: owner-current@freebsd.org Precedence: bulk > > Attached is the patch to disable disk block sorting. It's interesting - > I've been doing some tests here with disksort disabled and I'm actually seeing > a performance increase. I'm sure the algorithm is doing what it was written > to do...but... > My (SCSI) drive supports tagged queueing, but even with that disabled > things seem to be a bit faster. Hmmm. > > -DG yeah but you are hardly 25 users all on your own :) From owner-freebsd-current Mon Nov 13 23:58:58 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA07181 for current-outgoing; Mon, 13 Nov 1995 23:58:58 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA07012 for ; Mon, 13 Nov 1995 23:56:16 -0800 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id IAA29213; Tue, 14 Nov 1995 08:54:18 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id IAA25580; Tue, 14 Nov 1995 08:52:56 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id IAA00502; Tue, 14 Nov 1995 08:51:47 +0100 From: J Wunsch Message-Id: <199511140751.IAA00502@uriah.heep.sax.de> Subject: Re: ISP state their FreeBSD concerns To: hsu@cs.hut.fi (Heikki Suonsivu) Date: Tue, 14 Nov 1995 08:51:46 +0100 (MET) Cc: bde@zeta.org.au, current@FreeBSD.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199511140536.HAA27798@shadows.cs.hut.fi> from "Heikki Suonsivu" at Nov 14, 95 07:36:05 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 571 Sender: owner-current@FreeBSD.org Precedence: bulk I've missed Bruce's response: > Bruce Evans writes: > > >+ #ifndef RS_IBUFSIZE > > > #define RS_IBUFSIZE 256 > > >+ #endif > > Your setup is very special. Yes, but Bruce, why can't we insert the simple #ifndef? It doesn't break anything, but would allow interested people (with a `very special setup') to override it from the config file instead of hacking the sources over and over again. -- 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-current Tue Nov 14 00:11:25 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA08250 for current-outgoing; Tue, 14 Nov 1995 00:11:25 -0800 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA08243 for ; Tue, 14 Nov 1995 00:11:20 -0800 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id AAA28027; Tue, 14 Nov 1995 00:11:19 -0800 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id AAA00156; Tue, 14 Nov 1995 00:11:17 -0800 Message-Id: <199511140811.AAA00156@corbin.Root.COM> To: Julian Elischer cc: uhclem%nemesis@fw.ast.com, simonm@dcs.gla.ac.uk, current@freebsd.org Subject: Re: Disk I/O that binds In-reply-to: Your message of "Mon, 13 Nov 95 23:42:23 PST." <199511140742.XAA26864@ref.tfs.com> From: David Greenman Reply-To: davidg@Root.COM Date: Tue, 14 Nov 1995 00:11:17 -0800 Sender: owner-current@freebsd.org Precedence: bulk >shouldn't that be an #else, >with a #endif later? Leave me alone Julian - I'm not trying to make this pretty. :-) -DG From owner-freebsd-current Tue Nov 14 00:12:28 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA08341 for current-outgoing; Tue, 14 Nov 1995 00:12:28 -0800 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA08333 for ; Tue, 14 Nov 1995 00:12:25 -0800 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id AAA26523; Tue, 14 Nov 1995 00:11:38 -0800 To: Terry Lambert cc: jhs@FreeBSD.ORG, hsu@cs.hut.fi, freebsd-current@freefall.freebsd.org Subject: Re: ISP state their FreeBSD concerns In-reply-to: Your message of "Mon, 13 Nov 1995 18:37:52 MST." <199511140137.SAA18528@phaeton.artisoft.com> Date: Tue, 14 Nov 1995 00:11:37 -0800 Message-ID: <26521.816336697@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.ORG Precedence: bulk > I don't think this will *ever* be possible *without* a formal linkage > to the "FreeBSD Inc." organization. I agree. > The *only* way around that is to have a guarantee of some kind that your > commercial support organizations patches will get rolled into the main > line tree. Otherwise, you have just invented a commercial BSD based > on FreeBSD. It will be less expensive for the commercial organization > to maintain their own source tree seperately unless there is some > guarantee that they will not have to reapply "rejected" patches when > they attempt to synchronize source trees. I don't actually see where a commercially based BSD is bad, just so long as it remains friendly to the project that spawned it and has a liberal number of feet solidly planted in both camps. I also think that once any organization starts doing *serious* support for customers who won't take "it's broken" for an answer, the question of separate source trees isn't even a topic of discussion. *Of course* you'll have separate source trees, the ability to be "accountable" to your customers being otherwise lost. Is that such a bad thing? Not actually, no. If you look at it emotionally, it seems like you've split the project somehow. If you look at it pragmatically, you see that it's simply the cost of doing business and what you'll get in return will be the large donations of *tested* bug fixes and whatnot back from the support org that you just couldn't do yourself without a similar number of paid programmers (e.g. not at all). In the final analysis, who cares which source tree the bug fix came from, just so long as it comes from somewhere. I'd still like to set something like this up sometoday, but I won't if it'll simply make me the target for more flames from people who can't or won't see the complete picture and instead fall instant victim to their endocrine systems and start flailing before they've even heard me out. Like all things, the real potential for "good or evil" where such a system is concerned is more down to the *implementation* rather than the design. An organization started for the most purely altruistic reasons and run according to a strict religious code would probably impale itself on its own bureaucratic rigidity, no matter how fond the intentions of the founders. On the flip side, you could have a company with the most mercenary sharks at the helm yelling "sell sell sell! market market market!" but still have an sympathetic (and wise) engineering team who donated many of their weekends to fold in the best fixes generated that week and maybe even helped out at release times, resulting in a far stronger project. I'm not saying that either model is the one I'd pick, in fact almost certainly not, but a number of people in the past have gotten religious about this where pragmatism was called for and I won't work in an atmosphere of religious zealots throwing spears. Life is too short. Jordan P.S. Please watch those cc lines guys, you're getting sloppy. -current was on there *twice*! From owner-freebsd-current Tue Nov 14 00:18:02 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA08706 for current-outgoing; Tue, 14 Nov 1995 00:18:02 -0800 Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id AAA08693 for ; Tue, 14 Nov 1995 00:17:52 -0800 Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0tFGYs-0003vkC; Tue, 14 Nov 95 00:17 PST Received: from localhost (localhost [127.0.0.1]) by critter.tfs.com (8.6.11/8.6.9) with SMTP id JAA00175; Tue, 14 Nov 1995 09:17:44 +0100 X-Authentication-Warning: localhost.tfs.com: Host localhost didn't use HELO protocol To: davidg@Root.COM cc: current@freebsd.org Date: Tue, 14 Nov 1995 09:17:43 +0100 Message-ID: <173.816337063@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@freebsd.org Precedence: bulk > Attached is the patch to disable disk block sorting. It's interesting - > I've been doing some tests here with disksort disabled and I'm actually seein Another thing we should >seriously< consider is to make the update do 10% of the job every 3 seconds rather than 100% every 30 seconds. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Tue Nov 14 00:23:05 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA09273 for current-outgoing; Tue, 14 Nov 1995 00:23:05 -0800 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA09241 for ; Tue, 14 Nov 1995 00:22:51 -0800 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id AAA28042; Tue, 14 Nov 1995 00:22:47 -0800 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id AAA00179; Tue, 14 Nov 1995 00:22:43 -0800 Message-Id: <199511140822.AAA00179@corbin.Root.COM> To: Poul-Henning Kamp cc: current@freebsd.org In-reply-to: Your message of "Tue, 14 Nov 95 09:17:43 +0100." <173.816337063@critter.tfs.com> From: David Greenman Reply-To: davidg@Root.COM Date: Tue, 14 Nov 1995 00:22:43 -0800 Sender: owner-current@freebsd.org Precedence: bulk >> Attached is the patch to disable disk block sorting. It's interesting - >> I've been doing some tests here with disksort disabled and I'm actually seein > >Another thing we should >seriously< consider is to make the update do 10% >of the job every 3 seconds rather than 100% every 30 seconds. Been there, done that. It results in a large increase in the amount of disk I/O due to the way that delayed writes work and file access times are updated. "Fixing" this is very difficult and would require a rewrite of the code involved. -DG From owner-freebsd-current Tue Nov 14 00:23:38 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA09332 for current-outgoing; Tue, 14 Nov 1995 00:23:38 -0800 Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id AAA09314 for ; Tue, 14 Nov 1995 00:23:28 -0800 Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0tFGe4-0003vyC; Tue, 14 Nov 95 00:23 PST Received: from localhost (localhost [127.0.0.1]) by critter.tfs.com (8.6.11/8.6.9) with SMTP id JAA00197; Tue, 14 Nov 1995 09:23:04 +0100 X-Authentication-Warning: localhost.tfs.com: Host localhost didn't use HELO protocol To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) cc: hsu@cs.hut.fi (Heikki Suonsivu), bde@zeta.org.au, current@FreeBSD.org Subject: Re: ISP state their FreeBSD concerns In-reply-to: Your message of "Tue, 14 Nov 1995 08:51:46 +0100." <199511140751.IAA00502@uriah.heep.sax.de> Date: Tue, 14 Nov 1995 09:23:03 +0100 Message-ID: <195.816337383@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@FreeBSD.org Precedence: bulk > I've missed Bruce's response: > > > Bruce Evans writes: > > > >+ #ifndef RS_IBUFSIZE > > > > #define RS_IBUFSIZE 256 > > > >+ #endif > > > > Your setup is very special. > > Yes, but Bruce, why can't we insert the simple #ifndef? It doesn't > break anything, but would allow interested people (with a `very > special setup') to override it from the config file instead of hacking > the sources over and over again. I agree all of these kind of manifest #defines should be #ifdef'ed. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Tue Nov 14 00:33:32 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA09995 for current-outgoing; Tue, 14 Nov 1995 00:33:32 -0800 Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id AAA09978 for ; Tue, 14 Nov 1995 00:33:19 -0800 Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0tFGnr-0003vyC; Tue, 14 Nov 95 00:33 PST Received: from localhost (localhost [127.0.0.1]) by critter.tfs.com (8.6.11/8.6.9) with SMTP id JAA00254; Tue, 14 Nov 1995 09:33:12 +0100 X-Authentication-Warning: localhost.tfs.com: Host localhost didn't use HELO protocol To: davidg@Root.COM cc: current@freebsd.org In-reply-to: Your message of "Tue, 14 Nov 1995 00:22:43 PST." <199511140822.AAA00179@corbin.Root.COM> Date: Tue, 14 Nov 1995 09:33:11 +0100 Message-ID: <252.816337991@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@freebsd.org Precedence: bulk > >> Attached is the patch to disable disk block sorting. It's interesting - > >> I've been doing some tests here with disksort disabled and I'm actually se ein > > > >Another thing we should >seriously< consider is to make the update do 10% > >of the job every 3 seconds rather than 100% every 30 seconds. > > Been there, done that. It results in a large increase in the amount of dis k > I/O due to the way that delayed writes work and file access times are updated From owner-freebsd-current Tue Nov 14 00:43:37 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA10757 for current-outgoing; Tue, 14 Nov 1995 00:43:37 -0800 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA10721 for ; Tue, 14 Nov 1995 00:43:22 -0800 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id AAA28085; Tue, 14 Nov 1995 00:43:18 -0800 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id AAA00206; Tue, 14 Nov 1995 00:43:12 -0800 Message-Id: <199511140843.AAA00206@corbin.Root.COM> To: Poul-Henning Kamp cc: current@freebsd.org In-reply-to: Your message of "Tue, 14 Nov 95 09:33:11 +0100." <252.816337991@critter.tfs.com> From: David Greenman Reply-To: davidg@Root.COM Date: Tue, 14 Nov 1995 00:43:12 -0800 Sender: owner-current@freebsd.org Precedence: bulk >> "Fixing" this is very difficult and would require a rewrite of the code >> involved. > >Why would this: > > void > update_every_3_sec() > { > static int i; > > for all buffers { > if ((blockno % 10) == i) > write it > } > i = ++i % 10; > } > >give more io traffic ? Because delayed write buffers are delayed for a reason. It's the expectation that additional data/changes will be made to the buffer before it is written out. In the case where stuff is being appended to files via small writes (like log files, for instance), doing an update 10 times more often may very well increase the number of writes by 10 times. -DG From owner-freebsd-current Tue Nov 14 00:51:42 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA11520 for current-outgoing; Tue, 14 Nov 1995 00:51:42 -0800 Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id AAA11498 for ; Tue, 14 Nov 1995 00:51:32 -0800 Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0tFH5V-0003wQC; Tue, 14 Nov 95 00:51 PST Received: from localhost (localhost [127.0.0.1]) by critter.tfs.com (8.6.11/8.6.9) with SMTP id JAA00338; Tue, 14 Nov 1995 09:51:26 +0100 X-Authentication-Warning: localhost.tfs.com: Host localhost didn't use HELO protocol To: davidg@Root.COM cc: current@freebsd.org In-reply-to: Your message of "Tue, 14 Nov 1995 00:43:12 PST." <199511140843.AAA00206@corbin.Root.COM> Date: Tue, 14 Nov 1995 09:51:26 +0100 Message-ID: <336.816339086@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@freebsd.org Precedence: bulk > >> "Fixing" this is very difficult and would require a rewrite of the code > >> involved. > > > >Why would this: > > > > void > > update_every_3_sec() > > { > > static int i; > > > > for all buffers { > > if ((blockno % 10) == i) > > write it > > } > > i = ++i % 10; > > } > > > >give more io traffic ? > > Because delayed write buffers are delayed for a reason. It's the > expectation that additional data/changes will be made to the buffer before > it is written out. In the case where stuff is being appended to files via > small writes (like log files, for instance), doing an update 10 times more > often may very well increase the number of writes by 10 times. I still don't follow you. Are we talking about the same thing ? The mean time between updates for any one particular buffer is still 30 seconds, so how can this change so much ? We just stage the writes instead of doing them all at the same time. Unless you can show me where we prefer buffers with a particular last decimal digit in their block-numbers then I have a hard time beliving your results... I had a patch (crude hack really) for this back in Pleasant Hill but I have no idea where to find it now, but it didn't show any adverse effects for me, quite the contrary... It cured the hangs I had, which was the kind which would be signalled by a significant rattle from the disks... -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Tue Nov 14 01:08:32 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA13758 for current-outgoing; Tue, 14 Nov 1995 01:08:32 -0800 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA13717 for ; Tue, 14 Nov 1995 01:08:20 -0800 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id BAA28141; Tue, 14 Nov 1995 01:08:16 -0800 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id BAA00238; Tue, 14 Nov 1995 01:08:06 -0800 Message-Id: <199511140908.BAA00238@corbin.Root.COM> To: Poul-Henning Kamp cc: current@freebsd.org In-reply-to: Your message of "Tue, 14 Nov 95 09:51:26 +0100." <336.816339086@critter.tfs.com> From: David Greenman Reply-To: davidg@Root.COM Date: Tue, 14 Nov 1995 01:08:06 -0800 Sender: owner-current@freebsd.org Precedence: bulk >> > update_every_3_sec() >> > { >> > static int i; >> > >> > for all buffers { >> > if ((blockno % 10) == i) >> > write it >> > } >> > i = ++i % 10; >> > } >> > >> >give more io traffic ? >> >> Because delayed write buffers are delayed for a reason. It's the >> expectation that additional data/changes will be made to the buffer before >> it is written out. In the case where stuff is being appended to files via >> small writes (like log files, for instance), doing an update 10 times more >> often may very well increase the number of writes by 10 times. > >I still don't follow you. > >Are we talking about the same thing ? Perhaps not. >The mean time between updates for any one particular buffer is still >30 seconds, so how can this change so much ? We just stage the >writes instead of doing them all at the same time. > >Unless you can show me where we prefer buffers with a particular last >decimal digit in their block-numbers then I have a hard time beliving >your results... Umm, this isn't desired - you'll lose the ability to do write clustering. The scheme I implemented did buffer aging. >I had a patch (crude hack really) for this back in Pleasant Hill but I have >no idea where to find it now, but it didn't show any adverse effects for me, >quite the contrary... It cured the hangs I had, which was the kind >which would be signalled by a significant rattle from the disks... What can I say. I tried it and it increased the disk I/O and worse, introduced some unpleasant side-effects. My analysis of the increased disk I/O showed that most (all?) of it was caused by additional inode updates. For delayed writes the inodes are normally updated only after all of the blocks have been written out - in other words, after the sync. A general analysis of the disk I/O that occurs during a sync showed that most of it was due to updating access times on files. Doing the slow dribble increased the frequency of the access time updates. I tried various different approaches - including aging things at different rates, etc, but finally gave up in disgust and threw out the code. -DG From owner-freebsd-current Tue Nov 14 01:12:52 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA14242 for current-outgoing; Tue, 14 Nov 1995 01:12:52 -0800 Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id BAA14222 for ; Tue, 14 Nov 1995 01:12:42 -0800 Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0tFHPy-0003vkC; Tue, 14 Nov 95 01:12 PST Received: from localhost (localhost [127.0.0.1]) by critter.tfs.com (8.6.11/8.6.9) with SMTP id KAA00419; Tue, 14 Nov 1995 10:12:36 +0100 X-Authentication-Warning: localhost.tfs.com: Host localhost didn't use HELO protocol To: davidg@Root.COM cc: current@freebsd.org In-reply-to: Your message of "Tue, 14 Nov 1995 01:08:06 PST." <199511140908.BAA00238@corbin.Root.COM> Date: Tue, 14 Nov 1995 10:12:35 +0100 Message-ID: <417.816340355@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@freebsd.org Precedence: bulk > >> > update_every_3_sec() > >> > { > >> > static int i; > >> > > >> > for all buffers { > >> > if ((blockno % 10) == i) > >> > write it > >> > } > >> > i = ++i % 10; > >> > } > >> > > >> >give more io traffic ? > >> > >> Because delayed write buffers are delayed for a reason. It's the > >> expectation that additional data/changes will be made to the buffer before > >> it is written out. In the case where stuff is being appended to files via > >> small writes (like log files, for instance), doing an update 10 times more > >> often may very well increase the number of writes by 10 times. > > > >I still don't follow you. > > > >Are we talking about the same thing ? > > Perhaps not. > > >The mean time between updates for any one particular buffer is still > >30 seconds, so how can this change so much ? We just stage the > >writes instead of doing them all at the same time. > > > >Unless you can show me where we prefer buffers with a particular last > >decimal digit in their block-numbers then I have a hard time beliving > >your results... > > Umm, this isn't desired - you'll lose the ability to do write clustering. > The scheme I implemented did buffer aging. Hmm, that would make a difference I guess... Well, I'll make some experiemnts with it again, some time... :-) -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Tue Nov 14 06:23:13 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA02018 for current-outgoing; Tue, 14 Nov 1995 06:23:13 -0800 Received: from asstdc.scgt.oz.au (root@asstdc.scgt.oz.au [202.14.234.65]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA02011 for ; Tue, 14 Nov 1995 06:23:10 -0800 Received: (from imb@localhost) by asstdc.scgt.oz.au (8.6.12/BSD-4.4) id BAA15830 for current@freebsd.org; Wed, 15 Nov 1995 01:23:06 +1100 From: michael butler Message-Id: <199511141423.BAA15830@asstdc.scgt.oz.au> Subject: kern_sysctl.c To: current@freebsd.org Date: Wed, 15 Nov 1995 01:23:06 +1100 (EST) X-Mailer: ELM [version 2.4 PL24beta] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 277 Sender: owner-current@freebsd.org Precedence: bulk The recent changes to kern_sysctl.c appear to have broken (at least) mountd, mount_nfs, rwhod and gated. The last two fail on reboot with a warning message: "gethostname: Cannot allocate memory". gated, mountd and mount_nfs also core dump into the root directory :-( michael From owner-freebsd-current Tue Nov 14 07:14:28 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA07663 for current-outgoing; Tue, 14 Nov 1995 07:14:28 -0800 Received: from plains.nodak.edu (89@plains.NoDak.edu [134.129.111.64]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA07643 for ; Tue, 14 Nov 1995 07:14:23 -0800 Received: (from tinguely@localhost) by plains.nodak.edu (8.7.1/8.7.1) id JAA28481 for current@freebsd.org; Tue, 14 Nov 1995 09:14:18 -0600 (CST) Date: Tue, 14 Nov 1995 09:14:18 -0600 (CST) From: Mark Tinguely Message-Id: <199511141514.JAA28481@plains.nodak.edu> To: current@freebsd.org Subject: Re: ISP state their FreeBSD concerns Sender: owner-current@freebsd.org Precedence: bulk If we do keep a list of devices that have problems, add our two DEC Pentiums with NCR SCSI and Seagate Hawk drives that totally lock typically doing operations such as untarring from the same drive. I have changed the PCI priority but that does not solve the problem. --mark. From owner-freebsd-current Tue Nov 14 08:16:09 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA17447 for current-outgoing; Tue, 14 Nov 1995 08:16:09 -0800 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id IAA17438 for ; Tue, 14 Nov 1995 08:16:06 -0800 Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA23508; Tue, 14 Nov 1995 11:16:03 -0500 Date: Tue, 14 Nov 1995 11:16:03 -0500 From: "Garrett A. Wollman" Message-Id: <9511141616.AA23508@halloran-eldar.lcs.mit.edu> To: Poul-Henning Kamp Cc: current@freebsd.org Subject: Re: cvs commit: src/sys/kern kern_sysctl.c In-Reply-To: <570.816343308@critter.tfs.com> References: <570.816343308@critter.tfs.com> Sender: owner-current@freebsd.org Precedence: bulk < said: >> If you dont do the above change, gethostname(buf, 64) will fail with >> ENOMEM, and cause gated, amd and mountd to fail. > Well, what if the hostname actually WAS 255 bytes long then ? Then you return an error. > I would rather it fail all the time and we can get the code fixed, > than having a mismatch between expectations like this... I would prefer for it to obey the standard. Digital UNIX 3.2: The gethostname() function retrieves the standard host name of the local host. If sufficient space is provided, the returned address parameter is null-terminated. System hostnames are limited to MAXHOSTNAMELEN as defined in the /usr/include/sys/param.h file. Ultrix 4.2: The gethostname system call returns the standard host name for the current processor, as previously set by sethostname. The namelen param- eter specifies the size of the name array. The returned name is null- terminated unless insufficient space is provided. SunOS 4.1.1: gethostname() returns the standard host name for the current processor, as previously set by sethostname(). The parame- ter namelen specifies the size of the array pointed to by name. The returned name is null-terminated unless insuffi- cient space is provided. FreeBSD 2.2: Gethostname() returns the standard host name for the current processor, as previously set by sethostname(). The parameter namelen specifies the size of the name array. The returned name is null-terminated unless in- sufficient space is provided. > get some variable > old buffer too small, > new buffer correct. > it should return ENOMEM because it cannot copyout, but should the > new value be installed ? No. > I'm seriously considering allowing only a "get" or a "set" per syscall, > not both. > But then again, that is too draconian isn't it ? Yes. It defeats the whole purpose of having `new' and `old' parameters in one call, which presently allow you to atomically get-and-set the value of a variable. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-current Tue Nov 14 08:27:13 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA18657 for current-outgoing; Tue, 14 Nov 1995 08:27:13 -0800 Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA18649 for ; Tue, 14 Nov 1995 08:27:06 -0800 Received: (from henrich@localhost) by crh.cl.msu.edu (8.6.12/8.6.12) id LAA03439; Tue, 14 Nov 1995 11:26:58 -0500 From: Charles Henrich Message-Id: <199511141626.LAA03439@crh.cl.msu.edu> Subject: Re: ISP state their FreeBSD concerns To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Tue, 14 Nov 1995 11:26:58 -0500 (EST) Cc: nate@rocky.sri.MT.net, freebsd-current@freebsd.org In-Reply-To: <26347.816334779@time.cdrom.com> from "Jordan K. Hubbard" at Nov 13, 95 11:39:39 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 598 Sender: owner-current@freebsd.org Precedence: bulk > See my previous comments. Say you do pull them into 2.2. Now who's > going to LOOK at them? We have 10 emergency patients sitting in the > waiting room and only 2 doctors on duty. Which 8 patients should we > let die first? Been watching ER have we? :) Regarding your previous post, if we never (rarely) allow other folks work to actually be made part of the OS, how can that person develop into a full-fledged kernel hacker who can help in the future? -Crh Charles Henrich Michigan State University henrich@crh.cl.msu.edu http://rs560.msu.edu/~henrich/ From owner-freebsd-current Tue Nov 14 08:27:36 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA18700 for current-outgoing; Tue, 14 Nov 1995 08:27:36 -0800 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA18691 for ; Tue, 14 Nov 1995 08:27:31 -0800 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA20025; Tue, 14 Nov 1995 09:19:45 -0700 From: Terry Lambert Message-Id: <199511141619.JAA20025@phaeton.artisoft.com> Subject: Re: ISP state their FreeBSD concerns To: davidg@root.com Date: Tue, 14 Nov 1995 09:19:45 -0700 (MST) Cc: hsu@cs.hut.fi, current@FreeBSD.ORG In-Reply-To: <199511140700.XAA00132@corbin.Root.COM> from "David Greenman" at Nov 13, 95 11:00:34 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1197 Sender: owner-current@FreeBSD.ORG Precedence: bulk > > > We've been having similar problems with Seagate Hawks on > > > wcarchive. I plan > > > to switch them out for 4GB Quantum Grand Prixs in the near term. > > > >Have you discussed about this with seagate? With sparcs they seem to work > >just fine. > > No, I haven't. I think the Hawks have firmware bug(s) that only show up > after days of heavy disk I/O and/or when interacting with drives from other > manufacturers. I have very little patience for this this kind of thing which > is why I have no plans to mess around with Seagate tech support. Of course > it's also possible that there is a problem with the Adaptec 2940 sequencer > code that's in FreeBSD, but I'm beginning to seriously doubt that. have you attempted to verify this by replacing the Adaptec controllers with, say, NCR in a similar environment? Sequencer code written in the face of manufacturer opposition simply does not give me the warm fuzzies (no slight on the Adaptec driver intended -- though if you want to view it as a slight on Adaptec, feel free to do so 8-)). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Tue Nov 14 08:34:39 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA19378 for current-outgoing; Tue, 14 Nov 1995 08:34:39 -0800 Received: from ast.com (irvine.ast.com [165.164.128.2]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id IAA19370 for ; Tue, 14 Nov 1995 08:34:36 -0800 Received: from fw.ast.com by ast.com with SMTP id AA08560 (5.67b/IDA-1.5 for ); Tue, 14 Nov 1995 08:35:54 -0800 Received: from nemesis by fw.ast.com with uucp (Smail3.1.29.1 #4) id m0tFOH2-00008SC; Tue, 14 Nov 95 10:31 CST Received: by nemesis.lonestar.org (Smail3.1.27.1 #19) id m0tFODF-000J1BC; Tue, 14 Nov 95 10:27 WET Message-Id: Date: Tue, 14 Nov 95 10:27 WET To: current@freebsd.org From: uhclem%nemesis@fw.ast.com (Frank Durda IV) Sent: Tue Nov 14 1995, 10:27:57 CST Subject: Serial HW flow control [was ISP state their FreeBSD concerns] Sender: owner-current@freebsd.org Precedence: bulk [0]6. Multi-port serial support and even single-port serial support. [0] Seems they feel hardware flow control doesn't work or isn't enabled [0] when it should be (or can't be) or both. This may actually be [0] an issue with the 16550 drivers not setting silo depth to a [0] reasonable level. Most of these guys use terminal servers for [0] the actual users where these local serial ports are used for UPS, [0] router control, serial printers, and other in-house controls. They [0] complain of seeing problems with lost data outbound when flow [0] control was in use, including during UUCP sessions. [1]I use a standard serial port for a 115.2K ISDN connection and it works [1]*great*, even better than a friend of mine who's using a Cisco for the [1]purpose and looks enviously at my 10.5K/sec FTP transfer rates when [1]he's only getting 7K. Not to say that this scales to hundreds of [1]serial ports or anything, but it does work! [2]He didn't identify hardware vs. software flow control. If software, then [2]his observation about SILO depth is well taken. Your ^S could be in limbo [2]for quite some time before it is seen. A ^Q in limbo is a much worse [2]problem, actually. Actually, I thought I did. It is HARDWARE flow control they were talking about that they say isn't working completely right. I have personally not seen the precise problem with outgoing flow control as the ISPs report, but I certainly have seen it with incoming, particularly with modems with BIG buffers, such as the Telebit WorldBlazer in UUCP Spoof mode under Turbo PEP. The fix for me was in 1.1.5.1 (and still is in 2.1) to apply a patch to uucico so that it enables hardware flow control - by default it does not, nor does it seem to have a way to activate it from the config files as was claimed when my suggested patch was pooh-poohed a year or so ago. Patching uucico IS NOT a total fix: even with FreeBSD hardware flow control enabled (verified by stty), I can't set the modem DTE faster than 38400 without overruns in both directions. This is on a 486DX33 8MB system doing little else. (UUCICO speeds are up to 2200CPS on 100K files according to the Stats file. WIthout the patch, speeds fall to 300-400CPS.) Anyway, these guys are seeing overruns driving serial postscript printers and such, which tend to flush the entire job and print a page saying "OFFENDING COMMAND" when an overrun occurs. One of the ISPs is trying to let me borrow his communications monitor so I can see exactly what they are talking about. They claim it will show that they drop CTS and the processor has sent as many as 14 additional characters after CTS was deasserted. If true, it sounds like our hardware flow control does not "call-back" bytes already in the 16550 FIFO like it should. The EIA rules for CTS allow you one more full character plus any partial character to be transmitted before the data must cease (it's been a long time since I read that stuff so that may not be phrased exactly right). I know I have a Terminet printer in the shop at my office (its OLD) and it is completely unforgiving on the issue of flow control. Extra characters overwrite the ones in its buffer when a line is being printed. Frank Durda IV |"The Knights who say "LETNi" or uhclem%nemesis@fw.ast.com (Fastest Route)| demand... A SEGMENT REGISTER!!!" ...letni!rwsys!nemesis!uhclem |"A what?" ...decvax!fw.ast.com!nemesis!uhclem |"LETNi! LETNi! LETNi!" - 1983 From owner-freebsd-current Tue Nov 14 09:01:05 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA21624 for current-outgoing; Tue, 14 Nov 1995 09:01:05 -0800 Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA21615 for ; Tue, 14 Nov 1995 09:01:00 -0800 Received: from nanolon.gun.de (nanolon.gun.de [192.109.159.5]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id JAA07952 for ; Tue, 14 Nov 1995 09:00:54 -0800 Received: (from uucp@localhost) by nanolon.gun.de (8.6.8.1/8.6.6) id RAA16252; Tue, 14 Nov 1995 17:55:11 +0100 Received: from knobel.gun.de (localhost [127.0.0.1]) by knobel.gun.de (8.6.12/8.6.12) with SMTP id RAA00612; Mon, 13 Nov 1995 17:58:31 +0100 Date: Mon, 13 Nov 1995 17:58:31 +0100 (MET) From: Andreas Klemm To: Joe Greco cc: John Dyson , current@freebsd.org Subject: Re: ISP state their FreeBSD concerns In-Reply-To: <199511121600.KAA26310@brasil.moneng.mei.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk On Sun, 12 Nov 1995, Joe Greco wrote: > FreeBSD 2.0.5R - ASUS SP3G AMD 486DX2/66 + NCR810 - 8MB (SCSI II, reasonable > drive) > > 10000 files in 620 seconds - first run :-( :-( > 10000 files in 310 seconds - second run :-( :-( :-( !! FreeBSD-stable, ASUS P55TP4XE, 256k b. cache, AHA2940, 32M (Quantum Grand Prix) 10000 files in 316 seconds - 1st run 10000 files in 109 seconds - 2nd run maxuser = 10 -- andreas@knobel.gun.de /\/\___ Wiechers & Partner Datentechnik GmbH Andreas Klemm ___/\/\/ - Support Unix - aklemm@wup.de - \/ ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz apsfilter - magic print filter 4lpd >>> knobel is powered by FreeBSD <<< From owner-freebsd-current Tue Nov 14 09:06:01 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA22104 for current-outgoing; Tue, 14 Nov 1995 09:06:01 -0800 Received: from asstdc.scgt.oz.au (root@asstdc.scgt.oz.au [202.14.234.65]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA22091 for ; Tue, 14 Nov 1995 09:05:53 -0800 Received: (from imb@localhost) by asstdc.scgt.oz.au (8.6.12/BSD-4.4) id EAA17910; Wed, 15 Nov 1995 04:04:28 +1100 From: michael butler Message-Id: <199511141704.EAA17910@asstdc.scgt.oz.au> Subject: Re: Serial HW flow control [was ISP state their FreeBSD concerns] To: uhclem%nemesis@fw.ast.com (Frank Durda IV) Date: Wed, 15 Nov 1995 04:04:26 +1100 (EST) Cc: current@freebsd.org In-Reply-To: from "Frank Durda IV" at Nov 14, 95 10:27:00 am X-Mailer: ELM [version 2.4 PL24beta] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1563 Sender: owner-current@freebsd.org Precedence: bulk Frank Durda IV writes: > One of the ISPs is trying to let me borrow his communications monitor > so I can see exactly what they are talking about. They claim it will > show that they drop CTS and the processor has sent as many as 14 additional > characters after CTS was deasserted. If true, it sounds like our > hardware flow control does not "call-back" bytes already in the 16550 FIFO > like it should. You can't anyway .. once loaded with 16 bytes for transmission, the withdrawal of CTS only generates an interrupt. To quote the NS spec for the device "/CTS has no effect on the transmitter". This is quite different to the behaviour of, say, a Z80 SIO or Z8x30 SCC which disable the transmitter after the current character has been shifted out. There is also absolutely no mechanism provided to discover exactly how many characters were transmitted prior to the modem status interrupt. Ordinarily, an interrupt occurs only when the FIFO and shift-register are (completely) empty. > The EIA rules for CTS allow you one more full character plus any partial > character to be transmitted before the data must cease .. Then the 16550 itself is in breach of this spec. and there's nothing anyone can do about it in software other than to feed it one byte at a time (and you really don't want to do that!). If this actually is the problem, then *every* PC-based O/S must display the same failing with these devices, not just FreeBSD. The only other possible issue in this area is the speed with which FreeBSD's driver responds to CTS changes, michael From owner-freebsd-current Tue Nov 14 09:09:41 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA22531 for current-outgoing; Tue, 14 Nov 1995 09:09:41 -0800 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA22512 for ; Tue, 14 Nov 1995 09:09:34 -0800 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id JAA28800; Tue, 14 Nov 1995 09:09:03 -0800 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id JAA00421; Tue, 14 Nov 1995 09:07:50 -0800 Message-Id: <199511141707.JAA00421@corbin.Root.COM> To: Terry Lambert cc: hsu@cs.hut.fi, current@freebsd.org Subject: Re: ISP state their FreeBSD concerns In-reply-to: Your message of "Tue, 14 Nov 95 09:19:45 MST." <199511141619.JAA20025@phaeton.artisoft.com> From: David Greenman Reply-To: davidg@Root.COM Date: Tue, 14 Nov 1995 09:07:15 -0800 Sender: owner-current@freebsd.org Precedence: bulk >have you attempted to verify this by replacing the Adaptec controllers >with, say, NCR in a similar environment? No. "Experimenting" is not an option here since I have to get on a plane, stay in hotels, etc, to make changes like that. >Sequencer code written in the face of manufacturer opposition simply >does not give me the warm fuzzies (no slight on the Adaptec driver >intended -- though if you want to view it as a slight on Adaptec, feel >free to do so 8-)). Adaptec does not oppose us providing our own sequencer code. -DG From owner-freebsd-current Tue Nov 14 09:14:14 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA22871 for current-outgoing; Tue, 14 Nov 1995 09:14:14 -0800 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA22858 for ; Tue, 14 Nov 1995 09:14:07 -0800 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA20157; Tue, 14 Nov 1995 10:08:13 -0700 From: Terry Lambert Message-Id: <199511141708.KAA20157@phaeton.artisoft.com> Subject: Re: cvs commit: src/sys/kern kern_sysctl.c To: wollman@lcs.mit.edu (Garrett A. Wollman) Date: Tue, 14 Nov 1995 10:08:12 -0700 (MST) Cc: phk@critter.tfs.com, current@FreeBSD.org In-Reply-To: <9511141616.AA23508@halloran-eldar.lcs.mit.edu> from "Garrett A. Wollman" at Nov 14, 95 11:16:03 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 716 Sender: owner-current@FreeBSD.org Precedence: bulk > > I would rather it fail all the time and we can get the code fixed, > > than having a mismatch between expectations like this... > > I would prefer for it to obey the standard. > > Digital UNIX 3.2: > The gethostname() function retrieves the standard host name of the local > host. If sufficient space is provided, the returned address parameter is > null-terminated. So if you provide sufficient space, it *isn't* NULL terminated? How do you find the end of the thing then? I guess you have to call it with steadily decreasing space until you get a NULL. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Tue Nov 14 09:17:23 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA23063 for current-outgoing; Tue, 14 Nov 1995 09:17:23 -0800 Received: from kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA23040 for ; Tue, 14 Nov 1995 09:17:06 -0800 Received: from venus.mcs.com (root@Venus.mcs.com [192.160.127.92]) by kitten.mcs.com (8.6.10/8.6.9) with SMTP id LAA15976; Tue, 14 Nov 1995 11:16:58 -0600 Received: by venus.mcs.com (/\==/\ Smail3.1.28.1 #28.5) id ; Tue, 14 Nov 95 11:16 CST Message-Id: Subject: Re: ISP state their FreeBSD concerns To: terry@lambert.org (Terry Lambert) Date: Tue, 14 Nov 1995 11:16:57 -0600 (CST) From: "Karl Denninger, MCSNet" Cc: davidg@Root.COM, hsu@cs.hut.fi, current@FreeBSD.ORG In-Reply-To: <199511141619.JAA20025@phaeton.artisoft.com> from "Terry Lambert" at Nov 14, 95 09:19:45 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1915 Sender: owner-current@FreeBSD.ORG Precedence: bulk > > > > We've been having similar problems with Seagate Hawks on > > > > wcarchive. I plan > > > > to switch them out for 4GB Quantum Grand Prixs in the near term. > > > > > >Have you discussed about this with seagate? With sparcs they seem to work > > >just fine. > > > > No, I haven't. I think the Hawks have firmware bug(s) that only show up > > after days of heavy disk I/O and/or when interacting with drives from other > > manufacturers. I have very little patience for this this kind of thing which > > is why I have no plans to mess around with Seagate tech support. Of course > > it's also possible that there is a problem with the Adaptec 2940 sequencer > > code that's in FreeBSD, but I'm beginning to seriously doubt that. > > have you attempted to verify this by replacing the Adaptec controllers > with, say, NCR in a similar environment? > > Sequencer code written in the face of manufacturer opposition simply > does not give me the warm fuzzies (no slight on the Adaptec driver > intended -- though if you want to view it as a slight on Adaptec, feel > free to do so 8-)). I will note that we use the 4G Hawks on our news server here, have had no problems with them, and they are on Adaptec 1742A SCSI adapters (EISA Bus). Again -- NO problems have been noted with these disks here, and they get the dickens beat out of them daily. This is on FreeBSD -STABLE. I suspect the sequencer code. The 27xx series adapters have been problematic for us here, and they also require downloaded sequencer code. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity Modem: [+1 312 248-0900] | (shell, PPP, SLIP, leased) in Chicagoland Voice: [+1 312 803-MCS1] | 7 Chicagoland POPs, ISDN, 28.8, much more Fax: [+1 312 248-9865] | Email to "info@mcs.net" WWW: http://www.mcs.net ISDN - Get it here TODAY! | Home of Chicago's *Three STAR A* Clarinet feed! From owner-freebsd-current Tue Nov 14 09:20:35 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA23318 for current-outgoing; Tue, 14 Nov 1995 09:20:35 -0800 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA23291 for ; Tue, 14 Nov 1995 09:20:18 -0800 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA20129; Tue, 14 Nov 1995 10:04:54 -0700 From: Terry Lambert Message-Id: <199511141704.KAA20129@phaeton.artisoft.com> Subject: Re: ISP state their FreeBSD concerns To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Tue, 14 Nov 1995 10:04:53 -0700 (MST) Cc: terry@lambert.org, jhs@FreeBSD.ORG, hsu@cs.hut.fi, freebsd-current@freefall.freebsd.org In-Reply-To: <26521.816336697@time.cdrom.com> from "Jordan K. Hubbard" at Nov 14, 95 00:11:37 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 7592 Sender: owner-current@FreeBSD.ORG Precedence: bulk > I don't actually see where a commercially based BSD is bad, just so > long as it remains friendly to the project that spawned it and has a > liberal number of feet solidly planted in both camps. Uh, that would be the BSDI/CSRG relationship you are talking about, right? 8-). > I also think that once any organization starts doing *serious* support > for customers who won't take "it's broken" for an answer, the question > of separate source trees isn't even a topic of discussion. *Of course* > you'll have separate source trees, the ability to be "accountable" to > your customers being otherwise lost. I think you have confused "commercial support" with "commercial Q/A and support vis-a-vis specification compliance". The concept of a commercial support organization does not necessitate concommitant release engineering and product definition. You can fix problems without setting policy or arbitrating product direction. The difference is the one between a spinoff vs. a symbiotic relationship. The problem is that a support organization requires the ability to influence tree contents, but a tree does not require a support organization to exist. Without some control handoff, the relationship can only be parisitic or schizmatic. The question is how can control handoff occur? The easiest way would be to seperate the responsibility for -stable and -current into two groups, and place the release engineering and support services (which would take the form of control of the -stable branch) into the support organizations hands. And keeping the -current and other developement work seperate. An even cleaner relationship would be to seperate further into -dev (the new name for -current), -release, and -supported (the new name for -stable), and keep the net/Walnut Creek release engineering process intact. Hopefully, the support organization would be discouraged from breaking away into a purely commercial release that vectors off on the line of commercial goals, to slowly degrade into the common six month business horizon that has resulted in such mediocre offerings from commercial ventures. Not having the ability to do release engineering directly would aid this. > Is that such a bad thing? Not > actually, no. If you look at it emotionally, it seems like you've > split the project somehow. If you look at it pragmatically, you see > that it's simply the cost of doing business and what you'll get in > return will be the large donations of *tested* bug fixes and whatnot > back from the support org that you just couldn't do yourself without a > similar number of paid programmers (e.g. not at all). In the final > analysis, who cares which source tree the bug fix came from, just so > long as it comes from somewhere. The problem is what happens the first time there is a conflict between the support organization and the developement organization. In a pure business model, the result would be a reduction in the developement horizon. In a "volunteer developer" model, the result is a NetBSD/FreeBSD-like schism whenever visions are split in a highly polarized way. It's a setup for trouble. Linux avoids this because Linus is the 400 pound gorilla: he is not overruled. It's a fine line, though. There must be a commitment on the part of the developers to incorporate fixes from support. And thus there must be force in the relationship to take the place of a boss who can play 400 pound gorilla and say "you *will* do this" to the developers. This is the reason I don't believe it can work as a seperate entity. You *can't* operate a support organization without the consent of core. Multiple competing support organizations would fall victim to politics and favoritism. But then there is the problem of expediency. A support soloution may be (and in fact, frequently *will* be) expedient rather than technically correct. This is a business reality based on the fact that what a customer buys is really the right to make demands of the business. This is a bad example of technical incorrectness -- I believe it is actually the technically correct way to go, but at least it demonstrates a possible clash. Consider the ISP that want's to use Brian Litzinger's driver, and wants it to "just work" when he gets his FreeBSD. Will core allow an expedient soloution, or a conflicting soloution? Not without some mechanism in place to force it on them, since they are volunteers. You might as well attemptto force a merge of Net and Free; you will have similar "success". > I'd still like to set something like this up sometoday, but I won't if ^^^^^^^^^ Your Freudian slip is showing... 8-). > it'll simply make me the target for more flames from people who can't > or won't see the complete picture and instead fall instant victim to > their endocrine systems and start flailing before they've even heard > me out. I think you are in a unique position to be able to do this, actually. I'd caution against putting release engineering and support in the same organization, however. It would, in my opinion, tip the scales too far in the direction of expediency. > Like all things, the real potential for "good or evil" where such a > system is concerned is more down to the *implementation* rather than > the design. An organization started for the most purely altruistic > reasons and run according to a strict religious code would probably > impale itself on its own bureaucratic rigidity, no matter how fond the > intentions of the founders. On the flip side, you could have a > company with the most mercenary sharks at the helm yelling "sell sell > sell! market market market!" but still have an sympathetic (and wise) > engineering team who donated many of their weekends to fold in the > best fixes generated that week and maybe even helped out at release > times, resulting in a far stronger project. I disagree. An organization can be no other than what it is. The design will dictate the goals. Companies reorganize not to change the organization to meet the defined goals, but to change the organization so that its goals are in line with the defined goals. The distinction is a subtle one. A company that does the first will be constantly reorganizing. A company that does the second will define the organization so that the goals it will naturally pursue are as similar as possible to the goals that the designer wants to accomplish. The point here is that after you wind it up and let it go, a support organization must have as one of its top goals getting its code into the developement tree. That means an avoidance of expediency, and it means making it too expensive for the organization to "go it alone" for it to consider doing so for as long as possible. Don't give it the release engineering. The hardest part is going to be preventing the support organization from doing new developement: diverging. You can't handle this by fiat, you have to handle it by compromise. New developement must imply that the person is not doing the work for the support organization. Which means core membership. I think it would be very hard to impose a fiat that prevented a support organization from causing a schism. Eventually it would be in the interests of any such organisation to assume directional control. Unless they already had it. If you are going to tread this ground, tread carefully. 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-current Tue Nov 14 09:21:46 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA23451 for current-outgoing; Tue, 14 Nov 1995 09:21:46 -0800 Received: from netcom.netcom.com (bugs@netcom.netcom.com [192.100.81.100]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA23444 for ; Tue, 14 Nov 1995 09:21:41 -0800 Received: by netcom.netcom.com (8.6.12/Netcom) id JAA02156; Tue, 14 Nov 1995 09:20:14 -0800 From: bugs@netcom.com (Mark Hittinger) Message-Id: <199511141720.JAA02156@netcom.netcom.com> Subject: Re: ISP state their FreeBSD concerns (fwd) To: current@freebsd.org Date: Tue, 14 Nov 1995 09:20:14 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 547 Sender: owner-current@freebsd.org Precedence: bulk On the primary server at www.win.net I had a Seagate Hawk drive running for about a year without the apparent lockups. This is with the BT946C controller however. The box runs a great deal of stuff - and the only time it seems to die these days is during the news expire run. I am chasing that problem now. The expire run crash occurs about once every two weeks. The hawk is slightly slower than the barracuda and we were considering replacing it for that reason. Regards, Mark Hittinger Senior System Admin Netcom now bugs@netcom.com :-) From owner-freebsd-current Tue Nov 14 09:26:29 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA23975 for current-outgoing; Tue, 14 Nov 1995 09:26:29 -0800 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA23959 for ; Tue, 14 Nov 1995 09:26:23 -0800 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA20197; Tue, 14 Nov 1995 10:18:27 -0700 From: Terry Lambert Message-Id: <199511141718.KAA20197@phaeton.artisoft.com> Subject: Re: ISP state their FreeBSD concerns To: babkin@hq.icb.chel.su (Serge A. Babkin) Date: Tue, 14 Nov 1995 10:18:27 -0700 (MST) Cc: terry@lambert.org, karl@mcs.com, current@FreeBSD.org In-Reply-To: <199511140439.JAA19967@hq.icb.chel.su> from "Serge A. Babkin" at Nov 14, 95 09:39:03 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2253 Sender: owner-current@FreeBSD.org Precedence: bulk > > 1) Client caching. The operation writes local cache and then > > starts an async event with a completion routine. The async > > event waits for the ack from the NFS server and releases the > > page hold. > > > > This is dangerous, since the data pretends to be committed > > when in fact it only exists in the local systems memory. Not > > a problem for news servers, but a real problem for transaction > > oriented databases. > > I personally see a database on NFS absolutely not worth because it is much > less effective than running SQL requests. For non-transaction oriented > databases like dBASE this crash would be a "normal work". :-) I was thinking more in terms of an "email database". It wants the write guarantees to be honored so the locking protocol functions correctly. > > 3) Increase the number of nfsiod's on the server. This will allow > > more concurrent operations to be outstanding at one time. > > > > This is allowed (encouraged) by the NFS design document. > > > > Number 3 is well within your control. > > It can help for multiple processes accessing the files over NFS. If you > have single process creating the main load this will not help. And this > is one of the problems that make running NFS from DOS machines very > ineffective. The other being lack of long file name support and DOS's inability to operate multiple I/O instances and/or drives as multiple session instances and issue async requests. DOS has the same problem with NetWare or SMB, both of which are request/response in nature. Another request can't be issued until the previous one is satisfied. NetWare has fixed windows for binary downloads ("packet burst") to partly alleviate the problem in trade for congesting the bejesus out of your network in certain circumstances. OS/2 fixes this by using seperate sessions. As does NT and Windows95. I think I've seen a Win3.1 client that did this as well. The easy answer is: don't use DOS, it sucks. I think the issue was multple news reader processes and I/O being bottlenecked by requestst being queued for too few service engines. 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-current Tue Nov 14 09:26:44 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA24027 for current-outgoing; Tue, 14 Nov 1995 09:26:44 -0800 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA24002 for ; Tue, 14 Nov 1995 09:26:35 -0800 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA20209; Tue, 14 Nov 1995 10:19:38 -0700 From: Terry Lambert Message-Id: <199511141719.KAA20209@phaeton.artisoft.com> Subject: Re: ISP state their FreeBSD concerns To: davidg@root.com Date: Tue, 14 Nov 1995 10:19:38 -0700 (MST) Cc: terry@lambert.org, hsu@cs.hut.fi, current@FreeBSD.org In-Reply-To: <199511141707.JAA00421@corbin.Root.COM> from "David Greenman" at Nov 14, 95 09:07:15 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 553 Sender: owner-current@FreeBSD.org Precedence: bulk > >Sequencer code written in the face of manufacturer opposition simply > >does not give me the warm fuzzies (no slight on the Adaptec driver > >intended -- though if you want to view it as a slight on Adaptec, feel > >free to do so 8-)). > > Adaptec does not oppose us providing our own sequencer code. No, they oppose us. Or we could use their sequencer code and (potentially) not have problems like this. 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-current Tue Nov 14 09:40:01 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA25702 for current-outgoing; Tue, 14 Nov 1995 09:40:01 -0800 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA25682 for ; Tue, 14 Nov 1995 09:39:47 -0800 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id JAA28637; Tue, 14 Nov 1995 09:38:44 -0800 To: Terry Lambert cc: jhs@FreeBSD.ORG, hsu@cs.hut.fi, freebsd-current@freefall.freebsd.org Subject: Re: ISP state their FreeBSD concerns In-reply-to: Your message of "Tue, 14 Nov 1995 10:04:53 MST." <199511141704.KAA20129@phaeton.artisoft.com> Date: Tue, 14 Nov 1995 09:38:44 -0800 Message-ID: <28635.816370724@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.ORG Precedence: bulk > Uh, that would be the BSDI/CSRG relationship you are talking about, > right? 8-). No. I wasn't aware that BSDI ever actively supported CSRG - they merely profited most heavily from its dissolution. Perhaps you were merely being facetious, but that's not what I was talking about at all. > I think you have confused "commercial support" with "commercial Q/A and > support vis-a-vis specification compliance". No, I don't think so. > The concept of a commercial support organization does not necessitate > concommitant release engineering and product definition. You can fix > problems without setting policy or arbitrating product direction. I never said that it did. I simply said that having commercial responsibilities could and probably would necessitate a certain degree of autonomy. How great that autonomy would be is something that I doubt one could make hard and fast rules about, it would be something you'd have to set on a case by case basis and hence not something that endless discussion could "predetermine." I'm more than aware of the desirability of constructing general frameworks to work within, but there's also no substitute for a healthy dose of pragmatism in evolving such frameworks. > The easiest way would be to seperate the responsibility for -stable > and -current into two groups, and place the release engineering and > support services (which would take the form of control of the -stable > branch) into the support organizations hands. And keeping the -current > and other developement work seperate. That might be one way. I don't think there is only one, however. > polarized way. It's a setup for trouble. Linux avoids this because > Linus is the 400 pound gorilla: he is not overruled. It's a fine > line, though. No, Linus avoids the problem because Linus only concerns himself with a very small piece of the puzzle. He doesn't worry about user land and he doesn't concern himself with releases or support at all. With such a reduced mandate, the possibilies for conflict are significantly reduced. I think if he'd tried to take the whole piece for himself you'd have seen a general revolt long ago. > Will core allow an expedient soloution, or a conflicting soloution? Not > without some mechanism in place to force it on them, since they are > volunteers. You might as well attemptto force a merge of Net and Free; > you will have similar "success". I don't see it as necessary to force anything on anyone. The project *must* control its own code base just as the support organization controls its own. To insist on anything else would corrupt the mission of both organizations, and I don't see that as even remotely desirable. Naturally, this opens the door for divergence and all the other schizoid problems you pointed out, but that's just the breaks. How severe a problem it turns out to be is wholly determined by the reasonableness of the individuals involved, and if they can't be reasonable then we've got deeper problems that need to be addressed before even embarking on such a quest. > I think you are in a unique position to be able to do this, actually. > I'd caution against putting release engineering and support in the > same organization, however. It would, in my opinion, tip the scales > too far in the direction of expediency. Could be. Like I said, this would have to be a "we'll see" situation. You're also not adequately taking into account the fact that release engineering within the project is becoming an increasingly thankless job that has chewed through just about everyone available for the job. It may well reach a crisis point, in which case the arrival of a commercial org willing to take over the job in exchange for the cooperation of the developers ("we'll do the releases and ``donate'' them to the project for free in exchange for being able to turn around and sell those same releases with support") might well represent a heaven-sent salvation. We shall have to see! > I disagree. > > An organization can be no other than what it is. The design will dictate And I disagree in turn: "Stupid is as stupid does" :-) In an ideal world, design dictates events. In this one, design may dictate intention but actual events will follow much less deterministic lines. This isn't a situation where everyone will obediently troop to the little pidgeonholes you've created for them. > If you are going to tread this ground, tread carefully. Really? I would never have thought of that.. :-) Jordan From owner-freebsd-current Tue Nov 14 10:06:01 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA27796 for current-outgoing; Tue, 14 Nov 1995 10:06:01 -0800 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id KAA27781 for ; Tue, 14 Nov 1995 10:05:52 -0800 Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA23801; Tue, 14 Nov 1995 13:05:45 -0500 Date: Tue, 14 Nov 1995 13:05:45 -0500 From: "Garrett A. Wollman" Message-Id: <9511141805.AA23801@halloran-eldar.lcs.mit.edu> To: "Garrett A. Wollman" Cc: current@freebsd.org Subject: Re: cvs commit: src/sys/kern kern_sysctl.c In-Reply-To: <9511141616.AA23508@halloran-eldar.lcs.mit.edu> References: <570.816343308@critter.tfs.com> <9511141616.AA23508@halloran-eldar.lcs.mit.edu> Sender: owner-current@freebsd.org Precedence: bulk <> Well, what if the hostname actually WAS 255 bytes long then ? > Then you return an error. I then later quoted: > FreeBSD 2.2: > Gethostname() returns the standard host name for the current processor, > as previously set by sethostname(). The parameter namelen specifies the > size of the name array. The returned name is null-terminated unless in- > sufficient space is provided. This quotation is what you should do, rather than returning an error. This may require that gethostname() do a little more work than it does now. For example: long /* XXX ??? */ gethostname(char *name, int namelen) { char buf[MAXHOSTNAMELEN]; int mib[2]; size_t size; mib[0] = CTL_KERN; mib[1] = KERN_HOSTNAME; size = sizeof buf; if (sysctl(mib, 2, name, &size, (void *)0, (size_t)0) < 0) return -1; strncpy(name, buf, namelen < (sizeof buf) ? namelen : sizeof buf); return 0; } -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-current Tue Nov 14 10:14:02 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA28624 for current-outgoing; Tue, 14 Nov 1995 10:14:02 -0800 Received: from haywire.DIALix.COM (news@haywire.DIALix.COM [192.203.228.65]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA28592 for ; Tue, 14 Nov 1995 10:13:47 -0800 Received: (from news@localhost) by haywire.DIALix.COM (sendmail) id CAA07636 for freebsd-current@freebsd.org; Wed, 15 Nov 1995 02:12:48 +0800 (WST) Received: from GATEWAY by haywire.DIALix.COM with netnews for freebsd-current@freebsd.org (problems to: usenet@haywire.dialix.com) To: freebsd-current@freebsd.org Date: 15 Nov 1995 02:12:40 +0800 From: peter@haywire.dialix.com (Peter Wemm) Message-ID: <48am6o$7eb$1@haywire.DIALix.COM> Organization: DIALix Services, Perth, Australia. References: <199511141423.BAA15830@asstdc.scgt.oz.au> Subject: Re: kern_sysctl.c Sender: owner-current@freebsd.org Precedence: bulk imb@scgt.oz.au (michael butler) writes: >The recent changes to kern_sysctl.c appear to have broken (at least) mountd, >mount_nfs, rwhod and gated. The last two fail on reboot with a warning >message: "gethostname: Cannot allocate memory". gated, mountd and mount_nfs >also core dump into the root directory :-( > michael The following will fix it completely: Index: kern_sysctl.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_sysctl.c,v retrieving revision 1.49 diff -c -r1.49 kern_sysctl.c *** kern_sysctl.c 1995/11/14 09:42:22 1.49 --- kern_sysctl.c 1995/11/14 15:59:14 *************** *** 293,301 **** --- 293,303 ---- { int error=0; + #if 0 if (arg2) error = SYSCTL_OUT(req, arg1, arg2); else + #endif error = SYSCTL_OUT(req, arg1, strlen((char *)arg1)+1); if (error || !req->newptr || !arg2) Also, beware that mountd's parent (after forking the child into daemon mode) will still core dump after applying this fix. You need to manually kill the mountd child and start it by hand. It'll work from bootup quite happily then. I have not investigated why this is the case, I suspect that mountd is corrupting it's state file when gethostname() is failing, causing it to crash next time, even after the kernel bug is fixed. -Peter From owner-freebsd-current Tue Nov 14 10:44:56 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA01595 for current-outgoing; Tue, 14 Nov 1995 10:44:56 -0800 Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA01581 for ; Tue, 14 Nov 1995 10:44:47 -0800 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id LAA03012; Tue, 14 Nov 1995 11:47:11 -0700 Date: Tue, 14 Nov 1995 11:47:11 -0700 From: Nate Williams Message-Id: <199511141847.LAA03012@rocky.sri.MT.net> To: current@FreeBSD.org Subject: kern_sysctl mods needed in ibcs2 code Sender: owner-current@FreeBSD.org Precedence: bulk Trying to build a kernel with IBCS2 emulation in it gives the following at link time. loading kernel ibcs2_sysi86.o: Undefined symbol `_kern_sysctl' referenced from text segment If I get time I'll track down what needs to be done, but someone more familiar with the code is probably better suited than I. Nate From owner-freebsd-current Tue Nov 14 12:20:52 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA09525 for current-outgoing; Tue, 14 Nov 1995 12:20:52 -0800 Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id MAA09519 ; Tue, 14 Nov 1995 12:20:46 -0800 Message-Id: <199511142020.MAA09519@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: Host localhost.cdrom.com didn't use HELO protocol To: Terry Lambert cc: davidg@Root.COM, hsu@cs.hut.fi, current@FreeBSD.org Subject: Re: ISP state their FreeBSD concerns In-reply-to: Your message of "Tue, 14 Nov 1995 10:19:38 MST." <199511141719.KAA20209@phaeton.artisoft.com> Date: Tue, 14 Nov 1995 12:20:45 -0800 From: "Justin T. Gibbs" Sender: owner-current@FreeBSD.org Precedence: bulk >> >Sequencer code written in the face of manufacturer opposition simply >> >does not give me the warm fuzzies (no slight on the Adaptec driver >> >intended -- though if you want to view it as a slight on Adaptec, feel >> >free to do so 8-)). >> >> Adaptec does not oppose us providing our own sequencer code. > >No, they oppose us. Or we could use their sequencer code and (potentially) >not have problems like this. No, they oppose their competitors. Adaptec's sequencer code works around deficiencies with hundreds of periferals. That information has been gleaned from more than a decade of experience. If you were in Adaptec's position, would you make it publicly availible so that your competitors can become "as compatible" as you are? There has been some talk of releaseing a "stripped down" verison of the sequencer code for "free" development, but they don't have the developer hours to produce it yet. > Terry Lambert > terry@lambert.org >--- >Any opinions in this posting are my own and not those of my present >or previous employers. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Tue Nov 14 13:29:40 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA15154 for current-outgoing; Tue, 14 Nov 1995 13:29:40 -0800 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA15146 for ; Tue, 14 Nov 1995 13:29:20 -0800 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA22117; Tue, 14 Nov 1995 14:21:43 -0700 From: Terry Lambert Message-Id: <199511142121.OAA22117@phaeton.artisoft.com> Subject: Re: ISP state their FreeBSD concerns To: gibbs@freefall.freebsd.org (Justin T. Gibbs) Date: Tue, 14 Nov 1995 14:21:42 -0700 (MST) Cc: terry@lambert.org, davidg@root.com, hsu@cs.hut.fi, current@FreeBSD.org In-Reply-To: <199511142020.MAA09519@freefall.freebsd.org> from "Justin T. Gibbs" at Nov 14, 95 12:20:45 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1824 Sender: owner-current@FreeBSD.org Precedence: bulk > >> Adaptec does not oppose us providing our own sequencer code. > > > >No, they oppose us. Or we could use their sequencer code and (potentially) > >not have problems like this. > > No, they oppose their competitors. Adaptec's sequencer code works around > deficiencies with hundreds of periferals. That information has been > gleaned from more than a decade of experience. If you were in Adaptec's > position, would you make it publicly availible so that your competitors > can become "as compatible" as you are? There has been some talk of > releaseing a "stripped down" verison of the sequencer code for "free" > development, but they don't have the developer hours to produce it yet. On the contrary. If I were a competitor, I'd have their code torn apart withing one week of each new release. The code is useless without an AIC 7770, which you can only buy from Adaptec. The 1742 argument of "we don't want people building rip-offs of our boards and leveraging drivers for our cards to sell their cards instead" only holds water if you can legally use the download code without violating copyright in a competitors card. This has more to do with publication terms and support of developers asking questions than it has to do with them actually having anything of proprietary value that can't be gotten legally or illegally without non-disclosure. The "barrier" to competitors is a small one -- much smaller than the investment of the time to decypher their download code. It's the download interface itself which is proprietary -- I don't know about you, but all the AIC7770 based boards I've seen come with Xenix drivers with the sequencer code download image. 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-current Tue Nov 14 13:36:55 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA15402 for current-outgoing; Tue, 14 Nov 1995 13:36:55 -0800 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA15397 for ; Tue, 14 Nov 1995 13:36:50 -0800 Received: (from julian@localhost) by ref.tfs.com (8.6.12/8.6.9) id NAA28568; Tue, 14 Nov 1995 13:35:16 -0800 From: Julian Elischer Message-Id: <199511142135.NAA28568@ref.tfs.com> Subject: Re: Serial HW flow control [was ISP state their FreeBSD concerns] To: imb@scgt.oz.au (michael butler) Date: Tue, 14 Nov 1995 13:35:16 -0800 (PST) Cc: uhclem%nemesis@fw.ast.com, current@freebsd.org In-Reply-To: <199511141704.EAA17910@asstdc.scgt.oz.au> from "michael butler" at Nov 15, 95 04:04:26 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 2162 Sender: owner-current@freebsd.org Precedence: bulk > > Frank Durda IV writes: > > > One of the ISPs is trying to let me borrow his communications monitor > > so I can see exactly what they are talking about. They claim it will > > show that they drop CTS and the processor has sent as many as 14 additional > > characters after CTS was deasserted. If true, it sounds like our > > hardware flow control does not "call-back" bytes already in the 16550 FIFO > > like it should. > > You can't anyway .. once loaded with 16 bytes for transmission, the > withdrawal of CTS only generates an interrupt. To quote the NS spec for the > device "/CTS has no effect on the transmitter". This is quite different to > the behaviour of, say, a Z80 SIO or Z8x30 SCC which disable the transmitter > after the current character has been shifted out. > > There is also absolutely no mechanism provided to discover exactly how many > characters were transmitted prior to the modem status interrupt. Ordinarily, > an interrupt occurs only when the FIFO and shift-register are (completely) > empty. > > > The EIA rules for CTS allow you one more full character plus any partial > > character to be transmitted before the data must cease .. > > Then the 16550 itself is in breach of this spec. and there's nothing anyone > can do about it in software other than to feed it one byte at a time (and > you really don't want to do that!). > > If this actually is the problem, then *every* PC-based O/S must display the > same failing with these devices, not just FreeBSD. The only other possible > issue in this area is the speed with which FreeBSD's driver responds to CTS > changes, There is I believe no hard definition of how many quickly the dropping of CTS will affect the arrival of data.. Most decent devices have a parameter that is effectively "How much headroom should we allow for characters that arrive after CTS is dropped" If your device doesn't have this it's broken.. 14 characters? most such devices have headroom figures of 128 bytes or 256 bytes.. Once you've filled the fifo on the 16550, you can't stop it, you can only NOT feed it more characters when it says's it's hungry again.. > > michael > From owner-freebsd-current Tue Nov 14 19:22:24 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA06099 for current-outgoing; Tue, 14 Nov 1995 19:22:24 -0800 Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA06067 for ; Tue, 14 Nov 1995 19:22:04 -0800 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.12/8.6.9) id TAA00669; Tue, 14 Nov 1995 19:21:51 -0800 Date: Tue, 14 Nov 1995 19:21:51 -0800 Message-Id: <199511150321.TAA00669@silvia.HIP.Berkeley.EDU> To: current@freebsd.org Subject: Panic while reading CDROM with latest -current From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-current@freebsd.org Precedence: bulk I got a panic while reading from a CDROM. A simple command such as "dd if=/cdrom/packages/printing/mltex-3.1415.tgz of=/dev/null" will cause a panic reliably. I moved the CDROM drive from the Adaptec 2940UW to NCR 53c825 today, and the panic happened after that. But then, I haven't been using the CDROM for anything else than playing audio CD's for a while, so this may just be a coincidence. === Fatal trap 12: page fault while in kernel mode fault virtual address = 0x242 fault code = supervisor read, page not present instruction pointer = 0x8:0x60125000 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL=0 current process = 28 (dd) interrupt mask = bio panic: page fault === nm /kernel | sort gives: === f0124b44 T _vfs_bio_awrite f0124d14 t _getnewbuf f0124fc8 T _incore f012503c T _inmem f01250f0 t _vfs_setdirty f01251bc T _getblk f01254b8 T _geteblk f012556c T _allocbuf f0125b5c T _biowait f0125cec T _biodone === dmesg output: === Direct-Access sd5(ncr0:4:0): FAST SCSI-2 100ns (10 Mb/sec) offset 8. 2007MB (4110480 512 byte sectors) sd5(ncr0:4:0): with 3045 cyls, 16 heads, and an average 84 sectors/track (ncr0:5:0): "DEC RZ28 (C) DEC 441C" type 0 fixed SCSI 2 sd is configured at 6 sd6(ncr0:5:0): Direct-Access sd6(ncr0:5:0): FAST SCSI-2 100ns (10 Mb/sec) offset 8. 2007MB (4110480 512 byte sectors) sd6(ncr0:5:0): with 3045 cyls, 16 heads, and an average 84 sectors/track (ncr0:6:0): "TOSHIBA CD-ROM XM-5301TA 0925" type 5 removable SCSI 2 cd0(ncr0:6:0): CD-ROM cd0(ncr0:6:0): 250ns (4 Mb/sec) offset 8. cd present [264427 x 2048 byte records] vga0 rev 0 on pci0:19 pci0: uses 4224 bytes of memory from 80000010 upto ffffffff. pci0: uses 512 bytes of I/O space from 6000 upto 61ff. sd0s1: type 0x6, start 63, end = 514079, size 514017 : OK sd0s2: type 0xa5, start 528066, end = 4199759, size 3671694 : OK sd0s3: type 0x2, start 4209029, end = 4209029, size 1 : OK WARNING: / was not properly dismounted. sd1s1: type 0xa5, start 63, end = 8385047, size 8384985 : OK sd1s1: type 0xa5, start 63, end = 8385047, size 8384985 : OK sd1s1: type 0xa5, start 63, end = 8385047, size 8384985 : OK sd1s1: type 0xa5, start 63, end = 8385047, size 8384985 : OK sd1s1: type 0xa5, start 63, end = 8385047, size 8384985 : OK FreeBSD 2.2-CURRENT #0: Tue Nov 14 17:03:23 PST 1995 asami@silvia.hip.berkeley.edu:/b/src/sys/compile/SHEEP CPU: 90-MHz Pentium 735\\90 (Pentium-class CPU) Origin = "GenuineIntel" Id = 0x524 Stepping=4 Features=0x1bf real memory = 33554432 (32768K bytes) avail memory = 31379456 (30644K bytes) Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A sio2 not found at 0x3e8 sio3 not found at 0x2e8 pca0 on motherboard pca0: PC speaker audio driver fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 72065B fd0: 1.44MB 3.5in wdc0 not found at 0x1f0 npx0 on motherboard npx0: INT 16 interface gus0 at 0x220 irq 11 drq 1 on isa gus0: gus0: Probing for devices on the PCI bus: chip0 rev 57 on pci0:0 chip1 rev 0 on pci0:1 pci0:12: CMD, device=0x0640, class=storage (ide) [no driver assigned] ahc0 rev 0 int a irq 12 on pci0:13 ahc0: aic7870 Ultra Wide Channel, SCSI Id=7, aic7880, 255 SCBs ahc0 waiting for scsi devices to settle (ahc0:0:0): "Quantum XP32150 576D" type 0 fixed SCSI 2 sd0(ahc0:0:0): Direct-Access 2050MB (4199760 512 byte sectors) (ahc0:8:0): "MICROP 3243-19SC21128K CN06" type 0 fixed SCSI 2 sd1(ahc0:8:0): Direct-Access 4095MB (8388315 512 byte sectors) ncr0 rev 2 int a irq 9 on pci0:15 ncr0 waiting for scsi devices to settle (ncr0:1:0): "DEC RZ28 (C) DEC 441C" type 0 fixed SCSI 2 sd2(ncr0:1:0): Direct-Access sd2(ncr0:1:0): FAST SCSI-2 100ns (10 Mb/sec) offset 8. 2007MB (4110480 512 byte sectors) (ncr0:2:0): "DEC RZ28 (C) DEC 441C" type 0 fixed SCSI 2 sd3(ncr0:2:0): Direct-Access sd3(ncr0:2:0): FAST SCSI-2 100ns (10 Mb/sec) offset 8. 2007MB (4110480 512 byte sectors) (ncr0:3:0): "DEC RZ28 (C) DEC 441C" type 0 fixed SCSI 2 sd4(ncr0:3:0): Direct-Access sd4(ncr0:3:0): FAST SCSI-2 100ns (10 Mb/sec) offset 8. 2007MB (4110480 512 byte sectors) (ncr0:4:0): "DEC RZ28 (C) DEC 441C" type 0 fixed SCSI 2 sd5(ncr0:4:0): Direct-Access sd5(ncr0:4:0): FAST SCSI-2 100ns (10 Mb/sec) offset 8. 2007MB (4110480 512 byte sectors) (ncr0:5:0): "DEC RZ28 (C) DEC 441C" type 0 fixed SCSI 2 sd6(ncr0:5:0): Direct-Access sd6(ncr0:5:0): FAST SCSI-2 100ns (10 Mb/sec) offset 8. 2007MB (4110480 512 byte sectors) (ncr0:6:0): "TOSHIBA CD-ROM XM-5301TA 0925" type 5 removable SCSI 2 cd0(ncr0:6:0): CD-ROM cd0(ncr0:6:0): 250ns (4 Mb/sec) offset 8. cd0(ncr0:6:0): NOT READY asc:3a,0 Medium not present can't get the size vga0 rev 0 on pci0:19 WARNING: / was not properly dismounted. stray irq 7 === Kernel configuration file: === machine "i386" cpu "I486_CPU" cpu "I586_CPU" ident SHEEP maxusers 10 # options MATH_EMULATE #Support for x87 emulation options INET #InterNETworking options FFS #Berkeley Fast Filesystem # options NFS #Network Filesystem options MSDOSFS #MSDOS Filesystem options "CD9660" #ISO 9660 Filesystem options PROCFS #Process filesystem options "COMPAT_43" #Compatible with BSD 4.3 options UCONSOLE #X Console support options "FAT_CURSOR" #block cursor in syscons or pccons options "SCSI_DELAY=15" #Be pessimistic about Joe SCSI device options "NCONS=4" #4 virtual consoles options MFS # Memory file system options SYSVSHM # Shared memory options SYSVSEM # System V semaphores options SYSVMSG # System V message queues config kernel root on sd0 controller isa0 controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr disk fd0 at fdc0 drive 0 disk fd1 at fdc0 drive 1 # tape ft0 at fdc0 drive 2 controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr disk wd0 at wdc0 drive 0 disk wd1 at wdc0 drive 1 # controller wdc1 at isa? port "IO_WD2" bio irq 15 vector wdintr # disk wd2 at wdc1 drive 0 # disk wd3 at wdc1 drive 1 controller pci0 controller ncr0 controller ahc0 #controller ahc0 at isa? bio irq ? vector ahcintr #options AHC_TAGENABLE #options QUEUE_FULL_SUPPORTED controller scbus0 at ahc0 # Adaptec AHA 2940UW controller scbus1 at ncr0 # NCR 53C825 disk sd0 at scbus0 target 0 unit 0 disk sd1 at scbus0 target 8 tape st0 at scbus0 target 5 disk sd2 at scbus1 target 1 disk sd3 at scbus1 target 2 disk sd4 at scbus1 target 3 disk sd5 at scbus1 target 4 disk sd6 at scbus1 target 5 device cd0 device sc0 at isa? port "IO_KBD" tty irq 1 vector scintr device npx0 at isa? port "IO_NPX" irq 13 vector npxintr device sio0 at isa? port "IO_COM1" tty irq 4 vector siointr device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr device sio2 at isa? port "IO_COM3" tty irq 5 vector siointr device sio3 at isa? port "IO_COM4" tty irq 9 vector siointr # device lpt0 at isa? port? tty irq 7 vector lptintr # device lpt1 at isa? port? tty # device lpt2 at isa? port? tty # device ed0 at isa? port 0x300 net irq 10 iomem 0xcc000 vector edintr # device ed1 at isa? port 0x280 net irq 3 iomem 0xd0000 vector edintr pseudo-device loop # pseudo-device ether pseudo-device log pseudo-device sl 1 # SLIP pseudo-device tun 1 # Tunnel driver(user process ppp) pseudo-device pty 32 pseudo-device speaker pseudo-device gzip # Exec gzipped a.out's # pcaudio device device pca0 at isa? port IO_TIMER1 tty # GUS Max controller snd0 device gus0 at isa? port 0x220 irq 11 drq 1 vector gusintr === lsdev -vc output: === >> lsdev -vc # This listing automatically generated by lsdev(1) 1: # CPU cpu0 2: controller scbus0 3: controller isa0 4: sc0 at isa? tty (id 4) port 0x60 irq 1 5: sio0 at isa? tty (id 5) port 0x3f8 irq 4 6: sio1 at isa? tty (id 6) port 0x2f8 irq 3 7: sio2 at isa? tty (id 7) port 0x3e8 irq 5 8: sio3 at isa? tty (id 8) port 0x2e8 irq 9 9: pca0 at isa? tty (id 9) port 0x40 10: fdc0 at isa? bio (id 2) port 0x3f0 irq 6 drq 2 11: fd0 at fdc0 drive 0 12: wdc0 at isa? (id 3) port 0x1f0 irq 14 13: npx0 at isa? (id 10) port 0xf0 14: chip0 at pci0:0 15: chip1 at pci0:1 16: ahc0 at pci0:13 # int a irq 12 17: sd0 at SCSI bus 0:0:0 (ready) (open) 18: sd1 at SCSI bus 0:8:0 (ready) (open) 19: ncr0 at pci0:15 # int a irq 9 20: sd2 at SCSI bus 1:1:0 (ready) 21: sd3 at SCSI bus 1:2:0 (ready) 22: sd4 at SCSI bus 1:3:0 (ready) 23: sd5 at SCSI bus 1:4:0 (ready) 24: sd6 at SCSI bus 1:5:0 (ready) 25: cd0 at SCSI bus 1:6:0 (ready) (open) 26: vga0 at pci0:19 === Please let me know if I forgot to include anything. :) Satoshi From owner-freebsd-current Tue Nov 14 19:57:14 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA07315 for current-outgoing; Tue, 14 Nov 1995 19:57:14 -0800 Received: from hq.icb.chel.su (icb-rich-gw.icb.chel.su [193.125.10.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA07308 for ; Tue, 14 Nov 1995 19:57:02 -0800 Received: from localhost (babkin@localhost) by hq.icb.chel.su (8.6.5/8.6.5) id IAA01506; Wed, 15 Nov 1995 08:59:39 +0500 From: "Serge A. Babkin" Message-Id: <199511150359.IAA01506@hq.icb.chel.su> Subject: Re: ISP state their FreeBSD concerns To: terry@lambert.org (Terry Lambert) Date: Wed, 15 Nov 1995 08:59:39 +0500 (GMT+0500) Cc: terry@lambert.org, karl@mcs.com, current@FreeBSD.ORG In-Reply-To: <199511141718.KAA20197@phaeton.artisoft.com> from "Terry Lambert" at Nov 14, 95 10:18:27 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 3571 Sender: owner-current@FreeBSD.ORG Precedence: bulk > > > > 1) Client caching. The operation writes local cache and then > > > starts an async event with a completion routine. The async > > > event waits for the ack from the NFS server and releases the > > > page hold. > > > > > > This is dangerous, since the data pretends to be committed > > > when in fact it only exists in the local systems memory. Not > > > a problem for news servers, but a real problem for transaction > > > oriented databases. > > > > I personally see a database on NFS absolutely not worth because it is much > > less effective than running SQL requests. For non-transaction oriented > > databases like dBASE this crash would be a "normal work". :-) > > I was thinking more in terms of an "email database". It wants the write > guarantees to be honored so the locking protocol functions correctly. The closing of file may be used as an implicit "sync" request for this file, IMHO it should help for UUCP-like locking. Or if they use fsync() it is an explicit request to "sync" the file. Are there some other locking methods ? > > > 3) Increase the number of nfsiod's on the server. This will allow > > > more concurrent operations to be outstanding at one time. > > > > > > This is allowed (encouraged) by the NFS design document. > > > > > > Number 3 is well within your control. > > > > It can help for multiple processes accessing the files over NFS. If you > > have single process creating the main load this will not help. And this > > is one of the problems that make running NFS from DOS machines very > > ineffective. > > The other being lack of long file name support and DOS's inability to > operate multiple I/O instances and/or drives as multiple session > instances and issue async requests. Async requests need more buffers and the main DOS idea is "save this 1K or die". > DOS has the same problem with NetWare or SMB, both of which are > request/response in nature. Another request can't be issued until the > previous one is satisfied. NetWare has fixed windows for binary downloads > ("packet burst") to partly alleviate the problem in trade for congesting > the bejesus out of your network in certain circumstances. But the syncronous writes in NFS makes wery big overhead. The write throughput for DOS and different networking systems is like (on empty network): Netware - about 700 K/s (may be Netware client has more buffers ? but it takes less of memory than NFS client) BSDI NFS - about 300K/s HP/UX 9.04 NFS - about 200K/s SCO NFS - about 80K/s FreeBSD NFS - about 12K/s FreeBSD immediately writes every block it gets from DOS and reports about it only after write is completed. > OS/2 fixes this by using seperate sessions. As does NT and Windows95. > I think I've seen a Win3.1 client that did this as well. Most of time Windows has only one active task with which the user works, all other tasks are often just waiting until the user switches to them. So the problem is the same as in DOS, although, obviously it is not so big. > The easy answer is: don't use DOS, it sucks. Yes :-( But the numbers above is one of reasons why people are using Netware, not NFS. > I think the issue was multple news reader processes and I/O being > bottlenecked by requestst being queued for too few service engines. OK, sorry... The low DOS+NFS performance is one of my problems and I ask about it when I see something about NFS performance. :-) Serge Babkin ! (babkin@hq.icb.chel.su) ! Headquarter of Joint Stock Commercial Bank "Chelindbank" ! Chelyabinsk, Russia From owner-freebsd-current Tue Nov 14 20:36:51 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA09146 for current-outgoing; Tue, 14 Nov 1995 20:36:51 -0800 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA09138 for ; Tue, 14 Nov 1995 20:36:49 -0800 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id VAA00712; Tue, 14 Nov 1995 21:34:53 -0700 From: Terry Lambert Message-Id: <199511150434.VAA00712@phaeton.artisoft.com> Subject: Re: ISP state their FreeBSD concerns To: babkin@hq.icb.chel.su (Serge A. Babkin) Date: Tue, 14 Nov 1995 21:34:53 -0700 (MST) Cc: terry@lambert.org, karl@mcs.com, current@FreeBSD.ORG In-Reply-To: <199511150359.IAA01506@hq.icb.chel.su> from "Serge A. Babkin" at Nov 15, 95 08:59:39 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3516 Sender: owner-current@FreeBSD.ORG Precedence: bulk > > I was thinking more in terms of an "email database". It wants the write > > guarantees to be honored so the locking protocol functions correctly. > > The closing of file may be used as an implicit "sync" request for this file, > IMHO it should help for UUCP-like locking. > Or if they use fsync() it is an explicit request to "sync" the file. Are > there some other locking methods ? Well, NFS lockd, for one. > > The other being lack of long file name support and DOS's inability to > > operate multiple I/O instances and/or drives as multiple session > > instances and issue async requests. > > Async requests need more buffers and the main DOS idea is "save this 1K > or die". Tell that to Novell; they do client caching. 8-). > > DOS has the same problem with NetWare or SMB, both of which are > > request/response in nature. Another request can't be issued until the > > previous one is satisfied. NetWare has fixed windows for binary downloads > > ("packet burst") to partly alleviate the problem in trade for congesting > > the bejesus out of your network in certain circumstances. > > But the syncronous writes in NFS makes wery big overhead. The write throughput > for DOS and different networking systems is like (on empty network): > > Netware - about 700 K/s (may be Netware client has more buffers ? but it takes > less of memory than NFS client) Nope. Packet-burst. Effectively, async writes for 32 or 64k. Fixed window, needs an ack every burst run. > BSDI NFS - about 300K/s > HP/UX 9.04 NFS - about 200K/s > SCO NFS - about 80K/s > FreeBSD NFS - about 12K/s One wonders what BSDI does... maybe implements pcnfsd in kernel code? > FreeBSD immediately writes every block it gets from DOS and reports about it > only after write is completed. Yep. File-based IPC won't work any other way. Consider a print job that you cause the file to be deleted after it's put in the queue -- a lot of email systems, like CC:Mail, do this. > > OS/2 fixes this by using seperate sessions. As does NT and Windows95. > > I think I've seen a Win3.1 client that did this as well. > > Most of time Windows has only one active task with which the user works, > all other tasks are often just waiting until the user switches to them. > So the problem is the same as in DOS, although, obviously it is not so big. > > > The easy answer is: don't use DOS, it sucks. > > Yes :-( But the numbers above is one of reasons why people are using Netware, > not NFS. Well, these figures were current as of last year... You can license NUC (NetWare UNIX Client) source code for $100,000. You can license NWU (NetWare 4.x for UNIX Server) source code for $150,000. Or you can license both + UnixWare source code for $250,000 (hmmmm... I wonder what value UNIX source code has... $250,000 - $150,000 - $100,000. 8-) 8-)). With IPX stack latency corrected (mostly an artifact of the Streams implementation on UnixWare), NWU will outperform Native NetWare on identical hardware. By as much as 30%. > > I think the issue was multple news reader processes and I/O being > > bottlenecked by requestst being queued for too few service engines. > > OK, sorry... The low DOS+NFS performance is one of my problems and I ask > about it when I see something about NFS performance. :-) Change the PCNFS server, and if possible, the PCNFS client. 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-current Tue Nov 14 21:38:08 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA15955 for current-outgoing; Tue, 14 Nov 1995 21:38:08 -0800 Received: from hq.icb.chel.su (icb-rich-gw.icb.chel.su [193.125.10.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA15877 for ; Tue, 14 Nov 1995 21:37:23 -0800 Received: from localhost (babkin@localhost) by hq.icb.chel.su (8.6.5/8.6.5) id KAA03475; Wed, 15 Nov 1995 10:30:05 +0500 From: "Serge A. Babkin" Message-Id: <199511150530.KAA03475@hq.icb.chel.su> Subject: Re: ISP state their FreeBSD concerns To: terry@lambert.org (Terry Lambert) Date: Wed, 15 Nov 1995 10:30:04 +0500 (GMT+0500) Cc: terry@lambert.org, karl@mcs.com, current@FreeBSD.ORG In-Reply-To: <199511150434.VAA00712@phaeton.artisoft.com> from "Terry Lambert" at Nov 14, 95 09:34:53 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 4697 Sender: owner-current@FreeBSD.ORG Precedence: bulk > > > I was thinking more in terms of an "email database". It wants the write > > > guarantees to be honored so the locking protocol functions correctly. > > > > The closing of file may be used as an implicit "sync" request for this file, > > IMHO it should help for UUCP-like locking. > > Or if they use fsync() it is an explicit request to "sync" the file. Are > > there some other locking methods ? > > Well, NFS lockd, for one. I'm sorry, I said unclear. I meant the file-based "implicit" locking methods. I think lockd must make synchronization anyway and it must flush the caches. > > > The other being lack of long file name support and DOS's inability to > > > operate multiple I/O instances and/or drives as multiple session > > > instances and issue async requests. > > > > Async requests need more buffers and the main DOS idea is "save this 1K > > or die". > > Tell that to Novell; they do client caching. 8-). > > > > DOS has the same problem with NetWare or SMB, both of which are > > > request/response in nature. Another request can't be issued until the > > > previous one is satisfied. NetWare has fixed windows for binary downloads > > > ("packet burst") to partly alleviate the problem in trade for congesting > > > the bejesus out of your network in certain circumstances. > > > > But the syncronous writes in NFS makes wery big overhead. The write throughput > > for DOS and different networking systems is like (on empty network): > > > > Netware - about 700 K/s (may be Netware client has more buffers ? but it takes > > less of memory than NFS client) > > Nope. Packet-burst. Effectively, async writes for 32 or 64k. Fixed > window, needs an ack every burst run. OK, why it is good for Netware and bad for NFS ? > > BSDI NFS - about 300K/s > > HP/UX 9.04 NFS - about 200K/s > > SCO NFS - about 80K/s > > FreeBSD NFS - about 12K/s > > One wonders what BSDI does... maybe implements pcnfsd in kernel code? Nope, I have experimented with pcnfsd from BSDI compiled in FreeBSD. I know no details of PCNFS protocol, but if every request neeeds additional request to pcnfsd it's IMHO strange. BTW, I have experimented without pcnfsd at all, with -n key of mountd and results were the same. May be BSDI uses asyncronous mode by default. > > FreeBSD immediately writes every block it gets from DOS and reports about it > > only after write is completed. > > Yep. File-based IPC won't work any other way. > > Consider a print job that you cause the file to be deleted after it's put > in the queue -- a lot of email systems, like CC:Mail, do this. Explain me please where is the problem ? I see none. You run printing, it gets vnode of file, opens it and starts copying into its spool. After this you gat the same vnode and issue an "unlink" request. The vnode gets unlinked but it is still in-core with nonzero number of "opens" and thus it will not be removed until the print system closes it. I see no place here where immediate reporting or windowed writes can crash anything. > > > The easy answer is: don't use DOS, it sucks. > > > > Yes :-( But the numbers above is one of reasons why people are using Netware, > > not NFS. > > Well, these figures were current as of last year... > > You can license NUC (NetWare UNIX Client) source code for $100,000. > You can license NWU (NetWare 4.x for UNIX Server) source code for $150,000. > > Or you can license both + UnixWare source code for $250,000 (hmmmm... I > wonder what value UNIX source code has... $250,000 - $150,000 - $100,000. > 8-) 8-)). >From the point of view of end-user the cost of binary licence is much different from these numbers. The licence per 1 user for NW 3.12 costs about $50. For example SCO is not cheaper. > With IPX stack latency corrected (mostly an artifact of the Streams > implementation on UnixWare), NWU will outperform Native NetWare on > identical hardware. By as much as 30%. BTW will UnixWare+NWU binary license be comparable with native NetWare by cost ? > > > I think the issue was multple news reader processes and I/O being > > > bottlenecked by requestst being queued for too few service engines. > > > > OK, sorry... The low DOS+NFS performance is one of my problems and I ask > > about it when I see something about NFS performance. :-) > > Change the PCNFS server, and if possible, the PCNFS client. I know that different PCNFS clients make difference in performance but I never throught that pcnfsd may change the performance. Its manual page says that it is used for logging in and out only. Serge Babkin ! (babkin@hq.icb.chel.su) ! Headquarter of Joint Stock Commercial Bank "Chelindbank" ! Chelyabinsk, Russia From owner-freebsd-current Tue Nov 14 22:05:13 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA19033 for current-outgoing; Tue, 14 Nov 1995 22:05:13 -0800 Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id WAA19028 ; Tue, 14 Nov 1995 22:05:10 -0800 Message-Id: <199511150605.WAA19028@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: Host localhost.cdrom.com didn't use HELO protocol To: Terry Lambert cc: davidg@root.com, hsu@cs.hut.fi, current@FreeBSD.org Subject: Re: ISP state their FreeBSD concerns In-reply-to: Your message of "Tue, 14 Nov 1995 14:21:42 MST." <199511142121.OAA22117@phaeton.artisoft.com> Date: Tue, 14 Nov 1995 22:05:10 -0800 From: "Justin T. Gibbs" Sender: owner-current@FreeBSD.org Precedence: bulk >On the contrary. If I were a competitor, I'd have their code torn apart >withing one week of each new release. > >The code is useless without an AIC 7770, which you can only buy from >Adaptec. This just isn't true. You act like you've read the code (in FreeBSD), know how it works, what it does and its scope, but the more you say, the more obvious it becomes that none of the above is true. To get the information that I'm talking about out of Adaptec's drivers, you would have to write a disassebler for aic7xxx code, figure out what portion of the driver is the sequecner code, then disasemble the x86 kernel code, then figure out what portion of the x86 code is the HIM (Hardware Interface Module), then understand the HIM, the sequencer code, the aic7xxx and how they interract. This would tell you exactly how Adaptec responds to all SCSI phases, messages, and errors including all of their work arounds. The end result is hardware independant data that gives Adaptec a competitive edge. Extracting the information from a binary is much harder than looking through a well documented piece of source code. >The 1742 argument of "we don't want people building rip-offs of our >boards and leveraging drivers for our cards to sell their cards instead" >only holds water if you can legally use the download code without >violating copyright in a competitors card. They don't need to use Adaptec's code. They can use the information in any design they want. Again is *hardware independant* information. >This has more to do with publication terms and support of developers >asking questions than it has to do with them actually having anything >of proprietary value that can't be gotten legally or illegally without >non-disclosure. What does it have to do with "publication terms"? As I've said in the past they give you all the information you need to program the cards except for their implementation. They're not hiding anything about there hardware. >The "barrier" to competitors is a small one -- much smaller than the >investment of the time to decypher their download code. I think it would take you a couple man months to fully decifer the HIM and sequencer code. Either is little good without the other for the type of information I'm talking about since the API they communicate with is defined by the downloaded code, not the hardware. >It's the download interface itself which is proprietary -- I don't know The download interface is "rep outsb" and is not proprietary at all. The code you download is. >about you, but all the AIC7770 based boards I've seen come with Xenix >drivers with the sequencer code download image. If you really think that its that easy, I'd love to get the information from you. Let me know when you have Adaptec's HIM and their sequencer code all worked out. > Terry Lambert > terry@lambert.org >--- >Any opinions in this posting are my own and not those of my present >or previous employers. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Tue Nov 14 22:05:52 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA19126 for current-outgoing; Tue, 14 Nov 1995 22:05:52 -0800 Received: from jhome.DIALix.COM (root@jhome.DIALix.COM [192.203.228.69]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA18996 for ; Tue, 14 Nov 1995 22:04:58 -0800 Received: (from peter@localhost) by jhome.DIALix.COM (8.6.12/8.6.9) id NAA04769; Wed, 15 Nov 1995 13:57:55 +0800 Date: Wed, 15 Nov 1995 13:57:54 +0800 (WST) From: Peter Wemm To: current@freebsd.org Subject: netstat has been broken for a long time.. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk Hi all... I thought netstat was deliberately leaving off the unix^H^H^H^Hlocal domain sockets unless a switch was specified. I couldn't find which option it was from the man page, so I looked at the source. To my (not so) great suprise, I discovered netstat was accidently broken... it's nlist()ing the kernel looking for "_unixsw" which was replaced with "_localsw" and netstat not updated. The only problem is that I've grown used to netstat without the unix domain sockets at the bottom. I'm reluctant to fix it for that reason. ....However.... Perhaps it would be an acceptable compromise to fix inetd so that it does not display AF_UNIX sockets unless specifically requested with "netstat -f unix". Best of both worlds? What's the verdict? Is the complete (long) version better? The short one? is "-f unix" an acceptable compromise? (-f is an existing switch). So, the combined patch would become: Index: main.c =================================================================== RCS file: /home/ncvs/src/usr.bin/netstat/main.c,v retrieving revision 1.8 diff -u -r1.8 main.c --- main.c 1995/10/26 20:31:55 1.8 +++ main.c 1995/11/15 05:54:20 @@ -84,7 +84,7 @@ #define N_RTSTAT 9 { "_rtstat" }, #define N_UNIXSW 10 - { "_unixsw" }, + { "_localsw" }, #define N_IDP 11 { "_nspcb"}, #define N_IDPSTAT 12 @@ -414,7 +414,7 @@ if (af == AF_ISO || af == AF_UNSPEC) for (tp = isoprotox; tp->pr_name; tp++) printproto(tp, tp->pr_name); - if ((af == AF_UNIX || af == AF_UNSPEC) && !sflag) + if (af == AF_UNIX && !sflag) unixpr(nl[N_UNIXSW].n_value); exit(0); } Opinions? -Peter From owner-freebsd-current Tue Nov 14 22:11:00 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA19638 for current-outgoing; Tue, 14 Nov 1995 22:11:00 -0800 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA19631 for ; Tue, 14 Nov 1995 22:10:57 -0800 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id XAA00327; Tue, 14 Nov 1995 23:08:41 -0700 From: Terry Lambert Message-Id: <199511150608.XAA00327@phaeton.artisoft.com> Subject: Re: ISP state their FreeBSD concerns To: babkin@hq.icb.chel.su (Serge A. Babkin) Date: Tue, 14 Nov 1995 23:08:41 -0700 (MST) Cc: terry@lambert.org, karl@mcs.com, current@FreeBSD.ORG In-Reply-To: <199511150530.KAA03475@hq.icb.chel.su> from "Serge A. Babkin" at Nov 15, 95 10:30:04 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4279 Sender: owner-current@FreeBSD.ORG Precedence: bulk > > Well, NFS lockd, for one. > > I'm sorry, I said unclear. I meant the file-based "implicit" locking methods. > I think lockd must make synchronization anyway and it must flush the caches. No, no, evil, no! > > Nope. Packet-burst. Effectively, async writes for 32 or 64k. Fixed > > window, needs an ack every burst run. > > OK, why it is good for Netware and bad for NFS ? Because the async is on the client; if it fails, it can retry. The average system call overhead in SVR4 is 20uS. The average packet turnaround on a NetWare server is on the order of 60uS. Obvious UNIX will have a hell of a time turning a packet around as fast as a NetWare server. The loss for NFS is that the async writes are not performed by the client. If the client did a "window" worth of async writes an did an fsync() before letting go, then it would work. Basically, it fails because the client is stupid and NFS is not a connection oriented protocol. > > > BSDI NFS - about 300K/s > > > FreeBSD NFS - about 12K/s > > > > One wonders what BSDI does... maybe implements pcnfsd in kernel code? > > Nope, I have experimented with pcnfsd from BSDI compiled in FreeBSD. I know > no details of PCNFS protocol, but if every request neeeds additional request > to pcnfsd it's IMHO strange. BTW, I have experimented without pcnfsd at all, > with -n key of mountd and results were the same. How else are you going to support findfirst/findnext and short name semantics?!? PCNFS protocol is a bad thing. The ability to use it on tof of NFS with no penalty comes from the fact that typically you *don't* double up on requests, and sinces it's connectionless, it really doesn't matter which server software you go to to make the request. > May be BSDI uses asyncronous mode by default. I don't know. It's a big lose on reliability under adverse conditions if they do. I find it hard to believe they'ed do this, though SGI does and (I think) SVR4 now does (it didn't, formerly). > > Consider a print job that you cause the file to be deleted after it's put > > in the queue -- a lot of email systems, like CC:Mail, do this. > > Explain me please where is the problem ? I see none. You run printing, > it gets vnode of file, opens it and starts copying into its spool. After > this you gat the same vnode and issue an "unlink" request. The vnode gets > unlinked but it is still in-core with nonzero number of "opens" and thus > it will not be removed until the print system closes it. I see no place here > where immediate reporting or windowed writes can crash anything. Depends on how you implement the spooling services. It was just an example of the kind of thing you can screw up. The DOS has no concept of a link. And if it did, you couldn't allow the unlink until after it had been committed. > > Well, these figures were current as of last year... > > > > You can license NUC (NetWare UNIX Client) source code for $100,000. > > You can license NWU (NetWare 4.x for UNIX Server) source code for $150,000. > > > > Or you can license both + UnixWare source code for $250,000 (hmmmm... I > > wonder what value UNIX source code has... $250,000 - $150,000 - $100,000. > > 8-) 8-)). > > From the point of view of end-user the cost of binary licence is much > different from these numbers. The licence per 1 user for NW 3.12 costs > about $50. For example SCO is not cheaper. Depends on how many copies you think you can sell. > > With IPX stack latency corrected (mostly an artifact of the Streams > > implementation on UnixWare), NWU will outperform Native NetWare on > > identical hardware. By as much as 30%. > > BTW will UnixWare+NWU binary license be comparable with native NetWare > by cost ? I dunno. Probably not. Novell is unloading UNIX on SCO, and they really don't want a competitor to their main cash cow. > > Change the PCNFS server, and if possible, the PCNFS client. > > I know that different PCNFS clients make difference in performance but I > never throught that pcnfsd may change the performance. Its manual page > says that it is used for logging in and out only. Look at the source. The manual page lies. 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-current Tue Nov 14 22:13:34 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA19911 for current-outgoing; Tue, 14 Nov 1995 22:13:34 -0800 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA19896 for ; Tue, 14 Nov 1995 22:13:31 -0800 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id XAA00367; Tue, 14 Nov 1995 23:12:10 -0700 From: Terry Lambert Message-Id: <199511150612.XAA00367@phaeton.artisoft.com> Subject: Re: netstat has been broken for a long time.. To: peter@jhome.DIALix.COM (Peter Wemm) Date: Tue, 14 Nov 1995 23:12:10 -0700 (MST) Cc: current@FreeBSD.org In-Reply-To: from "Peter Wemm" at Nov 15, 95 01:57:54 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 663 Sender: owner-current@FreeBSD.org Precedence: bulk > Hi all... > > I thought netstat was deliberately leaving off the unix^H^H^H^Hlocal > domain sockets unless a switch was specified. I couldn't find which > option it was from the man page, so I looked at the source. > > To my (not so) great suprise, I discovered netstat was accidently > broken... it's nlist()ing the kernel looking for "_unixsw" which was > replaced with "_localsw" and netstat not updated. I thought Garret had renamed this AF_POSIX at one time? I like AF_POSIX -- AF_LOCAL is a letdown. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Tue Nov 14 22:39:17 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA22129 for current-outgoing; Tue, 14 Nov 1995 22:39:17 -0800 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA22120 for ; Tue, 14 Nov 1995 22:39:15 -0800 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id XAA00411; Tue, 14 Nov 1995 23:39:02 -0700 From: Terry Lambert Message-Id: <199511150639.XAA00411@phaeton.artisoft.com> Subject: Re: ISP state their FreeBSD concerns To: gibbs@freefall.freebsd.org (Justin T. Gibbs) Date: Tue, 14 Nov 1995 23:39:02 -0700 (MST) Cc: terry@lambert.org, davidg@root.com, hsu@cs.hut.fi, current@FreeBSD.org In-Reply-To: <199511150605.WAA19028@freefall.freebsd.org> from "Justin T. Gibbs" at Nov 14, 95 10:05:10 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 6660 Sender: owner-current@FreeBSD.org Precedence: bulk > >On the contrary. If I were a competitor, I'd have their code torn apart > >withing one week of each new release. > > > >The code is useless without an AIC 7770, which you can only buy from > >Adaptec. > > This just isn't true. You act like you've read the code (in FreeBSD), know > how it works, what it does and its scope, but the more you say, the more > obvious it becomes that none of the above is true. > > To get the information that I'm talking about out of Adaptec's drivers, > you would have to write a disassebler for aic7xxx code, figure > out what portion of the driver is the sequecner code, then disasemble > the x86 kernel code, then figure out what portion of the x86 code > is the HIM (Hardware Interface Module), then understand the HIM, the > sequencer code, the aic7xxx and how they interract. This would tell you > exactly how Adaptec responds to all SCSI phases, messages, and errors > including all of their work arounds. The end result is hardware > independant data that gives Adaptec a competitive edge. Extracting the > information from a binary is much harder than looking through a well > documented piece of source code. OK. I viewed the sequencer code as the most important thing, which you could write a disassembler for with documentation that's publically available. For the SCO HIM based code, V Communications "Sourcer" product will work to pull the code to (semi-documented) assembly code and identify the HIM code. I admit that I hadn't considered that some of the workarounds would be in the HIM, since it seemed "obviously silly", but that's probably an omission on my part. Either way you cut it, even if it takes me 4 weeks, it's a hell of a lot cheaper than going out and doing the work Adaptec did to get the same information. The only thing they've accomplished is increased the inconvenience factor. I still maintain that the inconvenience would be less than the reward, so they really haven't done anything in terms of making it less attractive to rip their stuff off if I'm serious about throwing money at the problem (and less money than I'd have to throw at a "ground-up" verion of my own -- the savings in disk hardware alone would be worth a lot). > >The 1742 argument of "we don't want people building rip-offs of our > >boards and leveraging drivers for our cards to sell their cards instead" > >only holds water if you can legally use the download code without > >violating copyright in a competitors card. > > They don't need to use Adaptec's code. They can use the information in any > design they want. Again is *hardware independant* information. No... what I meant was that people will find it much harder to clone Adaptec's controllers when they own the sequencer and the driver expects to download to it. The 1742 was cloned because it had a fairly well abstracted interface, and all you had to do (as a controller manufacturer) is pretend you were a 1742 (or 1542) and you were in. You didn't have to spend money developing drivers for your board for most popular commercial OS's because they all came with Adaptec drivers, and those drivers worked with your card. It's much harder, just by having the download interface in all the OS's, to clone a 7770 based card, and even then, you have to imitate a patented chipset. So they have protection by device patent, which is a hell of a lot stronger than trying to assert an interface patent. Effectively, they've got proprietary hardware and proprietary boot code and they are worrying about the boot code. > >This has more to do with publication terms and support of developers > >asking questions than it has to do with them actually having anything > >of proprietary value that can't be gotten legally or illegally without > >non-disclosure. > > What does it have to do with "publication terms"? As I've said in the > past they give you all the information you need to program the cards > except for their implementation. They're not hiding anything about > there hardware. They ship firmware on the floppies with the controllers, but you can't use it without the HIM. They are hiding the HIM -- the boot code. Though you may be right that they are attempting to hide the hardware specific knowledge in the HIM itself. Without looking at their code, I can't say for sure. 8-(. > >The "barrier" to competitors is a small one -- much smaller than the > >investment of the time to decypher their download code. > > I think it would take you a couple man months to fully decifer the > HIM and sequencer code. Either is little good without the other for > the type of information I'm talking about since the API they communicate > with is defined by the downloaded code, not the hardware. I think you could do better than that. If you are a competitor who manufactures SCSI controllers, you have engineers on staff who would have a lot of inside knowledge already. And if you threw five of them at it, you could have it apart pretty quickly. The point is that it isn't "protection", it's "nuisance factor". > >It's the download interface itself which is proprietary -- I don't know > > The download interface is "rep outsb" and is not proprietary at all. > The code you download is. But you get a license for it when you buy the controller. But you can't use it with BSD, even though you have a perfectly legal copy on your SCO or UnixWare drivers disk. > >about you, but all the AIC7770 based boards I've seen come with Xenix > >drivers with the sequencer code download image. > > If you really think that its that easy, I'd love to get the information > from you. Let me know when you have Adaptec's HIM and their sequencer code > all worked out. Well, I'm not in the business of doing SCSI controllers, so I don't really feel it's worth the effort to throw the money (time) at the problem. Getting WINE working is the same class of problem. A group that was deadly serious about something like that would divide into two groups, have one group disassemble all of Windows and document it, and the other group would code based on the documentation. It's not an insoluable problem (after all, Insignia solved it, and so did Sun). Which I guess exactly illustrates the point that it's a barrier for the free UNIX community, but not a barrier a competitor that's going to have to spend money on the problem one way or another. I think "nuisance factor" went out of style in software protection schemes when people quit "laser-lock"ing their floppies. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Tue Nov 14 23:55:16 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA03053 for current-outgoing; Tue, 14 Nov 1995 23:55:16 -0800 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA03023 for ; Tue, 14 Nov 1995 23:55:09 -0800 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id IAA25382 ; Wed, 15 Nov 1995 08:52:44 +0100 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id IAA29854 ; Wed, 15 Nov 1995 08:52:36 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.7.1/keltia-uucp-2.6) id IAA13665; Wed, 15 Nov 1995 08:41:00 +0100 (MET) From: Ollivier Robert Message-Id: <199511150741.IAA13665@keltia.freenix.fr> Subject: Re: netstat has been broken for a long time.. To: peter@jhome.DIALix.COM (Peter Wemm) Date: Wed, 15 Nov 1995 08:41:00 +0100 (MET) Cc: current@freebsd.org In-Reply-To: from "Peter Wemm" at Nov 15, 95 01:57:54 pm X-Operating-System: FreeBSD 2.2-CURRENT ctm#1327 X-Mailer: ELM [version 2.4 PL24 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org Precedence: bulk It seems that Peter Wemm said: > I thought netstat was deliberately leaving off the unix^H^H^H^Hlocal > domain sockets unless a switch was specified. I couldn't find which > option it was from the man page, so I looked at the source. Oh dear, I thought exactly the same thing... (and I was wondering why NetBSD hasn't implemented it as well when using a friend's machine :-)) > The only problem is that I've grown used to netstat without the unix > domain sockets at the bottom. I'm reluctant to fix it for that reason. I agree, the "short" form is much better. An option is the way to go IMO. It is change from traditional behaviour but for here for the better. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia.freenix.fr 2.2-CURRENT #1: Sun Nov 12 16:47:05 MET 1995 From owner-freebsd-current Wed Nov 15 00:21:35 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA05928 for current-outgoing; Wed, 15 Nov 1995 00:21:35 -0800 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA05917 for ; Wed, 15 Nov 1995 00:21:32 -0800 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id IAA04333 for current@freebsd.org; Wed, 15 Nov 1995 08:15:21 GMT From: Michael Smith Message-Id: <199511150815.IAA04333@genesis.atrad.adelaide.edu.au> Subject: Removing crufty code To: current@freebsd.org Date: Wed, 15 Nov 1995 08:15:21 +0000 () MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 944 Sender: owner-current@freebsd.org Precedence: bulk While the purge is on (re: phk/bde on support.s) how about diking this snippet out of /sys/net/if.c? Whilst I _do_ have some Unibus cards kicking around, the last time I tried putting one in a PC was a calculated attempt to make the onlookers puke. It failed 8) #ifdef vax /* * Call each interface on a Unibus reset. */ void ifubareset(uban) int uban; { register struct ifnet *ifp; for (ifp = ifnet; ifp; ifp = ifp->if_next) if (ifp->if_reset) (*ifp->if_reset)(ifp->if_unit, uban); } #endif -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 041-122-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] My car has "demand start" -Terry Lambert UNIX: live FreeBSD or die! [[ From owner-freebsd-current Wed Nov 15 00:43:56 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA07478 for current-outgoing; Wed, 15 Nov 1995 00:43:56 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA07098 for ; Wed, 15 Nov 1995 00:40:26 -0800 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id JAA27551; Wed, 15 Nov 1995 09:38:39 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id JAA06614; Wed, 15 Nov 1995 09:38:39 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id JAA05590; Wed, 15 Nov 1995 09:27:02 +0100 From: J Wunsch Message-Id: <199511150827.JAA05590@uriah.heep.sax.de> Subject: Re: Panic while reading CDROM with latest -current To: asami@cs.berkeley.edu (Satoshi Asami) Date: Wed, 15 Nov 1995 09:27:02 +0100 (MET) Cc: current@freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199511150321.TAA00669@silvia.HIP.Berkeley.EDU> from "Satoshi Asami" at Nov 14, 95 07:21:51 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 2735 Sender: owner-current@freebsd.org Precedence: bulk As Satoshi Asami wrote: > > I got a panic while reading from a CDROM. A simple command such as > "dd if=/cdrom/packages/printing/mltex-3.1415.tgz of=/dev/null" will > cause a panic reliably. > > I moved the CDROM drive from the Adaptec 2940UW to NCR 53c825 today, > and the panic happened after that. But then, I haven't been using the > CDROM for anything else than playing audio CD's for a while, so this > may just be a coincidence. > > === > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x242 > fault code = supervisor read, page not present > instruction pointer = 0x8:0x60125000 0xf0125000 ...i assume. > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL=0 > current process = 28 (dd) > interrupt mask = bio > panic: page fault > === > > nm /kernel | sort gives: > > === > f0124b44 T _vfs_bio_awrite > f0124d14 t _getnewbuf > f0124fc8 T _incore > f012503c T _inmem Argl! This is the incore() panic again. At least Hellmuth Michaelis and somebody else who's name i forgot have been reporting this one, but it only occured for the last (highest ID #) CD drive of a multi-CD environment for them. So it's never been tracked down to the bitter end. If i look at your configuration: > 19: ncr0 at pci0:15 # int a irq 9 > 20: sd2 at SCSI bus 1:1:0 (ready) > 21: sd3 at SCSI bus 1:2:0 (ready) > 22: sd4 at SCSI bus 1:3:0 (ready) > 23: sd5 at SCSI bus 1:4:0 (ready) > 24: sd6 at SCSI bus 1:5:0 (ready) > 25: cd0 at SCSI bus 1:6:0 (ready) (open) there's some resemblance to their environment however: the CD is the highest ID#, only the lower numbered devices are sd ones. Dunno if this is an incidence only. FWIW, the problem happens: struct buf * incore(struct vnode * vp, daddr_t blkno) { struct buf *bp; struct bufhashhdr *bh; int s = splbio(); bh = BUFHASH(vp, blkno); bp = bh->lh_first; ^^^^ <<================ here /* Search hash chain */ while (bp != NULL) { /* hit */ if (bp->b_vp == vp && bp->b_lblkno == blkno && (bp->b_flags & B_INVAL) == 0) { break; } bp = bp->b_hash.le_next; } splx(s); return (bp); } Somehow, BUFHASH() returns a bogus value (but is apparently believed to always return valid pointers /* CANTHAPPEN */). -- 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-current Wed Nov 15 00:56:04 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA08457 for current-outgoing; Wed, 15 Nov 1995 00:56:04 -0800 Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA08450 for ; Wed, 15 Nov 1995 00:55:54 -0800 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.12/8.6.9) id AAA02753; Wed, 15 Nov 1995 00:52:22 -0800 Date: Wed, 15 Nov 1995 00:52:22 -0800 Message-Id: <199511150852.AAA02753@silvia.HIP.Berkeley.EDU> To: joerg_wunsch@uriah.heep.sax.de CC: current@freebsd.org In-reply-to: <199511150827.JAA05590@uriah.heep.sax.de> (message from J Wunsch on Wed, 15 Nov 1995 09:27:02 +0100 (MET)) Subject: Re: Panic while reading CDROM with latest -current From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-current@freebsd.org Precedence: bulk * > instruction pointer = 0x8:0x60125000 * 0xf0125000 * * ...i assume. Sorry, typo (`6' is next to `f' on my Dvorak keyboard). * If i look at your configuration: * * > 19: ncr0 at pci0:15 # int a irq 9 * > 20: sd2 at SCSI bus 1:1:0 (ready) * > 21: sd3 at SCSI bus 1:2:0 (ready) * > 22: sd4 at SCSI bus 1:3:0 (ready) * > 23: sd5 at SCSI bus 1:4:0 (ready) * > 24: sd6 at SCSI bus 1:5:0 (ready) * > 25: cd0 at SCSI bus 1:6:0 (ready) (open) * * there's some resemblance to their environment however: the CD is the * highest ID#, only the lower numbered devices are sd ones. Dunno if * this is an incidence only. That might be why it didn't happen (or at least I didn't notice -- the last time I used the CDROM to read files (not play music) was last Friday, I think) before when I had it on the Adaptec bus. The CDROM drive was on ID 6 where sd0 is ID 0 and sd1 is ID 8. * Somehow, BUFHASH() returns a bogus value (but is apparently believed * to always return valid pointers /* CANTHAPPEN */). Hmm.... Satoshi From owner-freebsd-current Wed Nov 15 01:05:34 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA09275 for current-outgoing; Wed, 15 Nov 1995 01:05:34 -0800 Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id BAA09266 for ; Wed, 15 Nov 1995 01:05:29 -0800 Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0tFdmZ-0003wIC; Wed, 15 Nov 95 01:05 PST Received: from localhost (localhost [127.0.0.1]) by critter.tfs.com (8.6.11/8.6.9) with SMTP id KAA02509; Wed, 15 Nov 1995 10:05:26 +0100 X-Authentication-Warning: localhost.tfs.com: Host localhost didn't use HELO protocol To: michael butler cc: current@freebsd.org Subject: Re: kern_sysctl.c In-reply-to: Your message of "Wed, 15 Nov 1995 01:23:06 +1100." <199511141423.BAA15830@asstdc.scgt.oz.au> Date: Wed, 15 Nov 1995 10:05:25 +0100 Message-ID: <2507.816426325@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@freebsd.org Precedence: bulk > The recent changes to kern_sysctl.c appear to have broken (at least) mountd, > mount_nfs, rwhod and gated. The last two fail on reboot with a warning > message: "gethostname: Cannot allocate memory". gated, mountd and mount_nfs > also core dump into the root directory :-( Hopefully this works again now. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Wed Nov 15 01:22:36 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA10611 for current-outgoing; Wed, 15 Nov 1995 01:22:36 -0800 Received: from hq.icb.chel.su (icb-rich-gw.icb.chel.su [193.125.10.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA10585 for ; Wed, 15 Nov 1995 01:22:22 -0800 Received: from localhost (babkin@localhost) by hq.icb.chel.su (8.6.5/8.6.5) id OAA05961; Wed, 15 Nov 1995 14:24:58 +0500 From: "Serge A. Babkin" Message-Id: <199511150924.OAA05961@hq.icb.chel.su> Subject: Re: ISP state their FreeBSD concerns To: terry@lambert.org (Terry Lambert) Date: Wed, 15 Nov 1995 14:24:57 +0500 (GMT+0500) Cc: terry@lambert.org, karl@mcs.com, current@FreeBSD.ORG In-Reply-To: <199511150608.XAA00327@phaeton.artisoft.com> from "Terry Lambert" at Nov 14, 95 11:08:41 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 5231 Sender: owner-current@FreeBSD.ORG Precedence: bulk > > > Well, NFS lockd, for one. > > > > I'm sorry, I said unclear. I meant the file-based "implicit" locking methods. > > I think lockd must make synchronization anyway and it must flush the caches. > > No, no, evil, no! Even the _client_ cache (if it is present) of the file on which this lock is executed ? I think that file locking is the simplest example of [limited] transaction processing. IMHO when the file (or its part) gets unlocked everyone who tries to read from it must get the updated data, not old. And when the file (or its part) gets locked it means that the process wants to see the current state of locked data and change it without any intervention. > > > Nope. Packet-burst. Effectively, async writes for 32 or 64k. Fixed > > > window, needs an ack every burst run. > > > > OK, why it is good for Netware and bad for NFS ? > > Because the async is on the client; if it fails, it can retry. The average > system call overhead in SVR4 is 20uS. The average packet turnaround on > a NetWare server is on the order of 60uS. Obvious UNIX will have a hell > of a time turning a packet around as fast as a NetWare server. > > The loss for NFS is that the async writes are not performed by the client. As I can understand they are even explicitly prohibited (your original "1)" paragraph). But why ? Is there some principial problem or just nobody had implemented async NFS client (or simply I never saw it) yet ? > If the client did a "window" worth of async writes an did an fsync() before > letting go, then it would work. How about this algorithm : client_nfs_fsync(): If the file is marked as "write failed" return ERROR; Make a local simple lock of file to prevent write()s during fsync(); Wait until all outstanding write() requests are completed; Unlock the file; Return OK; client_nfs_lock/unlock(): If the file is marked as "write failed" return ERROR; Make a local simple lock of file to prevent write()s during fsync(); Wait until all outstanding write() requests are completed; Issue an NFS lock/unlock request and wait until it completes; Unlock the file; Return OK; client_nfs_close(): If the file is marked as "write failed" Do anything needed to close the file; Return ERROR; Make a local simple lock of file to prevent write()s during fsync(); Wait until all outstanding write() requests are completed; Do anything needed to close the file; Unlock the file; Return OK; client_nfs_write(): If the file is marked as "write failed" return ERROR; If the file is locally locked for synch. purposes wait until it gets unlocked; If there is no free block in write pool or this file has too many outstanding write requests wait until there will be free block and the number of outstanding requests will be less than "many"; Write user data into this block; Issue an NFS write request; Start timer on this block; Return OK; acknowledgement_on_written_block_arrived(): Disable timer for this block; Return this block into the free blocks pool; timeout_on_block(): If too many retries Mark file as "write failed"; Disable timers of all outstanding write requests for this file and free their blocks; return; Else Issue an NFS write request; Restart timer on this block; Increase number of retries; Of course it is simple and obvious, but what can you, Unix Wizards, say about it ? Is it wrong ? > Basically, it fails because the client is stupid and NFS is not a connection > oriented protocol. Client can be made clever :-) and the connectionless nature of NFS prtocol should not disallow this buffering. > > > > > BSDI NFS - about 300K/s > > > > FreeBSD NFS - about 12K/s > > > > > > One wonders what BSDI does... maybe implements pcnfsd in kernel code? > > > > Nope, I have experimented with pcnfsd from BSDI compiled in FreeBSD. I know > > no details of PCNFS protocol, but if every request neeeds additional request > > to pcnfsd it's IMHO strange. BTW, I have experimented without pcnfsd at all, > > with -n key of mountd and results were the same. > > How else are you going to support findfirst/findnext and short name > semantics?!? I have experimented with short-named files :-) Really it is not a big problem if you will put only files with dos-formatted names in the PCNFS-mounted directories. I don't know about findfirst/findnext problem, Tsofts's PCNFS with which I experimented worked well with "auth=none" option. > > > Change the PCNFS server, and if possible, the PCNFS client. > > > > I know that different PCNFS clients make difference in performance but I > > never throught that pcnfsd may change the performance. Its manual page > > says that it is used for logging in and out only. > > Look at the source. The manual page lies. I have looked at pcnfsd.x and most of request types I saw are printer-related, only two of them are PCNFSD[2]_AUTH that checks user name and password and returns uid, gid and other related information and PCNFSD2_MAPID that performs translations between names and IDs. I see no need to send these requests every time we do some NFS operation. Serge Babkin ! (babkin@hq.icb.chel.su) ! Headquarter of Joint Stock Commercial Bank "Chelindbank" ! Chelyabinsk, Russia From owner-freebsd-current Wed Nov 15 03:21:24 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA20219 for current-outgoing; Wed, 15 Nov 1995 03:21:24 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id DAA20183 for ; Wed, 15 Nov 1995 03:21:16 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id WAA00366; Wed, 15 Nov 1995 22:17:24 +1100 Date: Wed, 15 Nov 1995 22:17:24 +1100 From: Bruce Evans Message-Id: <199511151117.WAA00366@godzilla.zeta.org.au> To: imb@scgt.oz.au, julian@ref.tfs.com Subject: Re: Serial HW flow control [was ISP state their FreeBSD concerns] Cc: current@freebsd.org, uhclem%nemesis@fw.ast.com Sender: owner-current@freebsd.org Precedence: bulk >> > One of the ISPs is trying to let me borrow his communications monitor >> > so I can see exactly what they are talking about. They claim it will >> > show that they drop CTS and the processor has sent as many as 14 additional >> > characters after CTS was deasserted. If true, it sounds like our >> > hardware flow control does not "call-back" bytes already in the 16550 FIFO >> > like it should. Up to 17 characters may be received after CTS is deasserted (1 currently in flight and up to 16 in the FIFO). >> You can't anyway .. once loaded with 16 bytes for transmission, the >> withdrawal of CTS only generates an interrupt. To quote the NS spec for the >> device "/CTS has no effect on the transmitter". This is quite different to >> the behaviour of, say, a Z80 SIO or Z8x30 SCC which disable the transmitter >> after the current character has been shifted out. >> >> There is also absolutely no mechanism provided to discover exactly how many >> characters were transmitted prior to the modem status interrupt. Ordinarily, >> an interrupt occurs only when the FIFO and shift-register are (completely) >> empty. An interrupt normally occurs when the FIFO becomes empty. This allows one character time for the interrupt handler (if any) to refill the FIFO without loss of transmission time. Since there is no way to tell how many characters are in the FIFO, it isn't useful to flush the FIFO and backtrack when a CTS drop is detected. >> > The EIA rules for CTS allow you one more full character plus any partial >> > character to be transmitted before the data must cease .. >> >> Then the 16550 itself is in breach of this spec. and there's nothing anyone >> can do about it in software other than to feed it one byte at a time (and >> you really don't want to do that!). Well, disabling the FIFO is sort of supported (set 0x0002 in the driver flags) and has "only" 4 times as much overhead for output on a 486DX2/66 (12% vs 3% for 115200 bps) and only 2.5 times as much overhead for input (16% vs 6.5%). It would be easy to change the effective output FIFO size in software (change tx_fifo_size in sio.c from 16 to a smaller value). >There is I believe no hard definition of how many quickly the dropping of CTS >will affect the arrival of data.. >Most decent devices have a parameter that is effectively >"How much headroom should we allow for characters that arrive after CTS >is dropped" >If your device doesn't have this it's broken.. I learned how to write serial drivers on old Televideo terminals. They had a 256 byte buffer with 64 bytes headroom IIRC. >14 characters? >most such devices have headroom figures of 128 bytes or 256 bytes.. The Televideo's couldn't handle much faster than 9600 bps. 128 or 256 is about right for 115200 bps. sio itself (as a receiver) allows for 64 (worst case) and (256 - speed_in_cps / 100) (usual case). Bruce From owner-freebsd-current Wed Nov 15 03:48:39 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA22408 for current-outgoing; Wed, 15 Nov 1995 03:48:39 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id DAA22394 for ; Wed, 15 Nov 1995 03:48:27 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id WAA01311; Wed, 15 Nov 1995 22:47:40 +1100 Date: Wed, 15 Nov 1995 22:47:40 +1100 From: Bruce Evans Message-Id: <199511151147.WAA01311@godzilla.zeta.org.au> To: current@freebsd.org, uhclem%nemesis@fw.ast.com Subject: Re: Serial HW flow control [was ISP state their FreeBSD concerns] Sender: owner-current@freebsd.org Precedence: bulk >I have personally not seen the precise problem with outgoing flow control >as the ISPs report, but I certainly have seen it with incoming, >particularly with modems with BIG buffers, such as the >Telebit WorldBlazer in UUCP Spoof mode under Turbo PEP. >The fix for me was in 1.1.5.1 (and still is in 2.1) to apply a patch to >uucico so that it enables hardware flow control - by default it does not, If you need hardware flow control of input, then you would have seen problems in 2.0 and 2.0.5 because hardware flow of input wasn't implemented in those releases. >nor does it seem to have a way to activate it from the config files as >was claimed when my suggested patch was pooh-poohed a year or so ago. See /etc/rc.serial. The modem() function gives reasonable settings for old modems. Change 57600 to 115200 for most current modems. >One of the ISPs is trying to let me borrow his communications monitor >so I can see exactly what they are talking about. They claim it will >show that they drop CTS and the processor has sent as many as 14 additional >characters after CTS was deasserted. If true, it sounds like our >hardware flow control does not "call-back" bytes already in the 16550 FIFO >like it should. As discussed in other mail you should see as many as 16 or 17 additional characters and an average of >= 8 while output is in progress (< 8 would mean that output is not streaming properly). Bruce From owner-freebsd-current Wed Nov 15 04:43:21 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id EAA25724 for current-outgoing; Wed, 15 Nov 1995 04:43:21 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id EAA25717 for ; Wed, 15 Nov 1995 04:43:10 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id XAA03378; Wed, 15 Nov 1995 23:42:39 +1100 Date: Wed, 15 Nov 1995 23:42:39 +1100 From: Bruce Evans Message-Id: <199511151242.XAA03378@godzilla.zeta.org.au> To: freebsd-current@FreeBSD.org, george@moa.cc.monash.edu.au Subject: Re: Problem with wd0 Sender: owner-current@FreeBSD.org Precedence: bulk >On my machine the boot time probes show: >> wdc0 at 0x1f0-0x1f7 irq 14 on isa >> wdc0: unit 0 (wd0): >> wd0: 80MB (164050 sectors), 965 cyls, 10 heads, 17 S/T, 512 B/S >The first time I try to use wd0 (eg, using dd if=/dev/wd0 of=/dev/null) I get a >pause and then: >> wd0: wdcontrol: wdcommand failed reading fsbn 0wd0: status ff error 0 >There seems to be two problems here: >1) Shouldn't this message be split over two lines? This topic has a long history, like that of `echo -n' :-). The message was originally written all on one line, correctly formatted without the `wd0' in the middle. Some broken driver(s) neglected to print a newline after calling diskerr(). This was "fixed" by always printing a newline in diskerr(). Now the above messages was misformatted. This was "fixed" by adding the second `wd0'. Then the 4.4lite version of ufs_disksubr.c blew away the bogus changes to diskerr(). Everyone was tired of changes in this area and/or the messages rarely gets printed now so no one noticed the problem and it hasn't been fixed. >and, more importantly, >2) What is causing it? >This machine is primarily an MS DOS machine; this drive is it's C:, and MS DOS >has no problems with it. I boot FreeBSD diskless off another machine. It's >running -CURRENT (delta 1174) though I have had this problem ever since I >started playing with -CURRENT about 2 months ago. The driver tries to do a WDCC_RESTORE command early and this fails. Perhaps the BIOS doesn't initialize the drive for your diskless boot and the wd driver doesn't completely initialize at first either. After the failure, the driver retries and/or resets the controller and/or drive and then the WDCC_RESTORE command apparently works. I think there is no problem if this is the only error. Bruce From owner-freebsd-current Wed Nov 15 05:05:21 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA26441 for current-outgoing; Wed, 15 Nov 1995 05:05:21 -0800 Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA26436 for ; Wed, 15 Nov 1995 05:05:16 -0800 Received: from relay-4.mail.demon.net (relay-4.mail.demon.net [158.152.1.64]) by who.cdrom.com (8.6.12/8.6.11) with SMTP id FAA16506 for ; Wed, 15 Nov 1995 05:05:12 -0800 Received: from post.demon.co.uk by relay-4.mail.demon.net id msg.aa12392; 15 Nov 95 13:00 GMT Received: from linus.demon.co.uk by relay-3.mail.demon.net id msg.aa12390; 15 Nov 95 12:59 GMT Received: (from mark@localhost) by linus.demon.co.uk (8.7.1/8.7.1) id MAA01654; Wed, 15 Nov 1995 12:56:15 GMT Date: Wed, 15 Nov 1995 12:56:15 GMT From: Mark Valentine Message-Id: <199511151256.MAA01654@linus.demon.co.uk> In-Reply-To: Peter Wemm's message of Nov 15, 1:57pm X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Peter Wemm , current@freebsd.org Subject: Re: netstat has been broken for a long time.. Sender: owner-current@freebsd.org Precedence: bulk > From: Peter Wemm > Date: Wed 15 Nov, 1995 > Subject: netstat has been broken for a long time.. > To my (not so) great suprise, I discovered netstat was accidently > broken... it's nlist()ing the kernel looking for "_unixsw" which was > replaced with "_localsw" and netstat not updated. You mean I've been typing "netstat -f inet" unnecessarily all this time? :-( > ....However.... Perhaps it would be an acceptable compromise to fix > inetd so that it does not display AF_UNIX sockets unless specifically > requested with "netstat -f unix". Best of both worlds? Why pick on "unix"? No -f options means "all protocols". If you did restrict the default display to an arbitrary subset, you'd have to invent a way of specifying "all protocols" again without enumerating them. Annoying though it may be, I think the current behaviour (when fixed) is most flexible; invent an alias for ``netstat -f inet'' if you really it: inetstat() { netstat -f inet ${1+"$@"}; } Mark. -- "Tigers will do ANYTHING for a tuna fish sandwich." "We're kind of stupid that way." *munch* *munch* From owner-freebsd-current Wed Nov 15 05:28:28 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA27545 for current-outgoing; Wed, 15 Nov 1995 05:28:28 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA27540 for ; Wed, 15 Nov 1995 05:28:20 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id AAA05338; Thu, 16 Nov 1995 00:27:23 +1100 Date: Thu, 16 Nov 1995 00:27:23 +1100 From: Bruce Evans Message-Id: <199511151327.AAA05338@godzilla.zeta.org.au> To: hsu@cs.hut.fi, j@uriah.heep.sax.de Subject: Re: ISP state their FreeBSD concerns Cc: bde@zeta.org.au, current@FreeBSD.org Sender: owner-current@FreeBSD.org Precedence: bulk >> Bruce Evans writes: >> > >+ #ifndef RS_IBUFSIZE >> > > #define RS_IBUFSIZE 256 >> > >+ #endif >> > Your setup is very special. >Yes, but Bruce, why can't we insert the simple #ifndef? It doesn't >break anything, but would allow interested people (with a `very >special setup') to override it from the config file instead of hacking >the sources over and over again. Because ifdefs are evil and simply changing RS_IBUFSIZE is not sufficient. It must satisfy the following: TTYHOG - 2*RS_IBUFSIZE > 0 (much greater, < TTYHOG/2 would be silly) RS_IBUFSIZE - 11520 * (1.0/hz + max_softtty_interrupt_latency) >= 0 Bruce From owner-freebsd-current Wed Nov 15 06:15:51 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA01683 for current-outgoing; Wed, 15 Nov 1995 06:15:51 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA01643 for ; Wed, 15 Nov 1995 06:15:46 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id BAA06956; Thu, 16 Nov 1995 01:11:31 +1100 Date: Thu, 16 Nov 1995 01:11:31 +1100 From: Bruce Evans Message-Id: <199511151411.BAA06956@godzilla.zeta.org.au> To: davidg@Root.COM, phk@critter.tfs.com Subject: disksort Cc: current@freebsd.org Sender: owner-current@freebsd.org Precedence: bulk >> >> > update_every_3_sec() >> >> > { >> >> > static int i; >> >> > >> >> > for all buffers { >> >> > if ((blockno % 10) == i) >> >> > write it >> >> > } >> >> > i = ++i % 10; >> >> > } >> >> > >> >> >give more io traffic ? >> >> >> >> Because delayed write buffers are delayed for a reason. It's the >> >> expectation that additional data/changes will be made to the buffer before >> >> it is written out. In the case where stuff is being appended to files via >> >> small writes (like log files, for instance), doing an update 10 times more >> >> often may very well increase the number of writes by 10 times. And because the above strategy is sort of like unclustering by a factor of 10, or an interleave of 10. It guarantees that the efficiency is most 1/10 of the maximum possible efficiency. >> >The mean time between updates for any one particular buffer is still >> >30 seconds, so how can this change so much ? We just stage the >> >writes instead of doing them all at the same time. >> > >> >Unless you can show me where we prefer buffers with a particular last >> >decimal digit in their block-numbers then I have a hard time beliving >> >your results... >> >> Umm, this isn't desired - you'll lose the ability to do write clustering. >> The scheme I implemented did buffer aging. I think clustering at the file system level would still work. I think the basic scheme should be: 1) almost never write a buffer that hasn't been dirty for a long time (30 seconds or so). 2) write 1/N of the data to be written (not necessarily 1/N of the dirty buffers) every full_update_period/N seconds. Normally seek across about 1/N of the disk each time. 3) somehow stop synchronous updates from interfering with (1). 4) somehow stop reads/readahead from intefering with the seeks in (2). Bruce From owner-freebsd-current Wed Nov 15 07:51:53 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA13451 for current-outgoing; Wed, 15 Nov 1995 07:51:53 -0800 Received: from pilhuhn.de (pilhuhn.de [193.141.89.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id HAA13442 for ; Wed, 15 Nov 1995 07:51:48 -0800 Received: by pilhuhn.de id ; Wed, 15 Nov 95 16:51 MET Message-Id: From: hwr@pilhuhn.de (Heiko W.Rupp) Subject: 2.1-stable bombs at umount To: current@freebsd.org Date: Wed, 15 Nov 1995 16:50:47 +0100 (MET) X-Mailer: ELM [version 2.4 PL20] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 817 Sender: owner-current@freebsd.org Precedence: bulk Hi, I had that box under 2.1-stable running and did a umount -f /news ; mount /news the result was: | Fatal trap 12: page fault while in kernel mode | fault virtual address = 0x80 | fault code = supervisor read, page not present | instruction pointer = 0x8:0xf0172ee8 | code segment = base 0x0, limit 0xfffff, type 0x1b | = DPL 0, pres 1, def32 1, gran 1 | processor eflags = interrupt enabled, resume, IOPL = 0 | current process = 7171 (umount) | interrupt mask = | panic: page fault I know that unmounting a filesystem which is not the best idea ... but I think this should only lead to errors , not to panics .. -- Heiko W.Rupp Gerwigstr.5 D-76131 Karlsruhe +49 721 9661524 Ein glueckliches Huhn dank neg ... From owner-freebsd-current Wed Nov 15 08:13:24 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA16395 for current-outgoing; Wed, 15 Nov 1995 08:13:24 -0800 Received: from ast.com (irvine.ast.com [165.164.128.2]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id IAA16374 for ; Wed, 15 Nov 1995 08:13:12 -0800 Received: from fw.ast.com by ast.com with SMTP id AA29800 (5.67b/IDA-1.5 for ); Wed, 15 Nov 1995 08:14:31 -0800 Received: from nemesis by fw.ast.com with uucp (Smail3.1.29.1 #4) id m0tFkOP-00008RC; Wed, 15 Nov 95 10:08 CST Received: by nemesis.lonestar.org (Smail3.1.27.1 #19) id m0tFk9b-000J7fC; Wed, 15 Nov 95 09:53 WET Message-Id: Date: Wed, 15 Nov 95 09:53 WET To: current@freebsd.org From: uhclem@nemesis.lonestar.org (Frank Durda IV) Sent: Wed Nov 15 1995, 09:53:39 CST Subject: Novell pricing [was Re: ISP state their FreeBSD concerns] Sender: owner-current@freebsd.org Precedence: bulk [0]Well, these figures were current as of last year... [0] [0]You can license NUC (NetWare UNIX Client) source code for $100,000. [0]You can license NWU (NetWare 4.x for UNIX Server) source code for $150,000. [0] [0]Or you can license both + UnixWare source code for $250,000 (hmmmm... I [0]wonder what value UNIX source code has... $250,000 - $150,000 - $100,000. [0]8-) 8-)). [0] Or you can just buy the entire company, now that Novell has announced that they are willing to sell themselves. AT&T and IBM are the likely buyers. Above prices subject to change (read: increase) without notice. :-) Frank Durda IV |"The Knights who say "LETNi" or uhclem%nemesis@fw.ast.com (Fastest Route)| demand... A SEGMENT REGISTER!!!" ...letni!rwsys!nemesis!uhclem |"A what?" ...decvax!fw.ast.com!nemesis!uhclem |"LETNi! LETNi! LETNi!" - 1983 From owner-freebsd-current Wed Nov 15 08:54:31 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA22570 for current-outgoing; Wed, 15 Nov 1995 08:54:31 -0800 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id IAA22559 for ; Wed, 15 Nov 1995 08:54:23 -0800 Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA26197; Wed, 15 Nov 1995 11:53:34 -0500 Date: Wed, 15 Nov 1995 11:53:34 -0500 From: "Garrett A. Wollman" Message-Id: <9511151653.AA26197@halloran-eldar.lcs.mit.edu> To: davidg@root.com Cc: current@freebsd.org Subject: Re: cvs commit: src/usr.sbin/syslogd syslogd.c In-Reply-To: <199511151354.FAA00756@corbin.Root.COM> References: <199511151341.AAA05911@godzilla.zeta.org.au> <199511151354.FAA00756@corbin.Root.COM> Sender: owner-current@freebsd.org Precedence: bulk < said: > The sysctl crap in the Makefile is bogus and should be removed. My kernel > is often not called "/kernel" and pretending that it was is wrong. The bootfile > name should be read-only and the Makefile should not be messing with it. No, the bootfile name should not be read-only; I knew what I was doing when I wrote that code. Yes, the Makefile should not be messing with it. The reason for making the bootfile name not be read-only is to allow LKMs to leave their symbol-files in some convenient place and set kern.bootfile to point there, so that other programs like `modload' and `netstat' are able to find it. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-current Wed Nov 15 09:09:02 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA24504 for current-outgoing; Wed, 15 Nov 1995 09:09:02 -0800 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id JAA24488 for ; Wed, 15 Nov 1995 09:08:54 -0800 Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA26231; Wed, 15 Nov 1995 12:08:47 -0500 Date: Wed, 15 Nov 1995 12:08:47 -0500 From: "Garrett A. Wollman" Message-Id: <9511151708.AA26231@halloran-eldar.lcs.mit.edu> To: Poul-Henning Kamp Cc: current@freebsd.org Subject: Re: cvs commit: src/sys/kern kern_sysctl.c In-Reply-To: <3126.816454522@critter.tfs.com> References: <9511151641.AA26165@halloran-eldar.lcs.mit.edu> <3126.816454522@critter.tfs.com> Sender: owner-current@freebsd.org Precedence: bulk < said: >> The purpose of this is to prevent race conditions even in a >> uniprocessor system. > what race-conditions ? Say process 1 and process 2 are both trying to change some variable. Process 1 gets the old value, but blocks before the new value is changed. Process 2 then gets the old value, sets the new value, and returns success. Process 1 then wakes up, and sets its new value, thereby obliterating what process 2 had done, with neither process 1 nor process 2 aware of what happened (unless they go back and check again), because they will see the same `old' result. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-current Wed Nov 15 09:11:22 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA24819 for current-outgoing; Wed, 15 Nov 1995 09:11:22 -0800 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id JAA24787 for ; Wed, 15 Nov 1995 09:11:10 -0800 Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA26242; Wed, 15 Nov 1995 12:10:55 -0500 Date: Wed, 15 Nov 1995 12:10:55 -0500 From: "Garrett A. Wollman" Message-Id: <9511151710.AA26242@halloran-eldar.lcs.mit.edu> To: Bruce Evans Cc: current@FreeBSD.org Subject: Re: ISP state their FreeBSD concerns In-Reply-To: <199511151327.AAA05338@godzilla.zeta.org.au> References: <199511151327.AAA05338@godzilla.zeta.org.au> Sender: owner-current@FreeBSD.org Precedence: bulk < said: > Because ifdefs are evil and simply changing RS_IBUFSIZE is not sufficient. > It must satisfy the following: > TTYHOG - 2*RS_IBUFSIZE > 0 (much greater, < TTYHOG/2 would be silly) > RS_IBUFSIZE - 11520 * (1.0/hz + max_softtty_interrupt_latency) >= 0 This is not a sufficient reason to keep intelligent users from changing these parameters on their own. Try again. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-current Wed Nov 15 09:17:33 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA25528 for current-outgoing; Wed, 15 Nov 1995 09:17:33 -0800 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id JAA25513 for ; Wed, 15 Nov 1995 09:17:28 -0800 Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA26179; Wed, 15 Nov 1995 12:16:57 -0500 Date: Wed, 15 Nov 1995 12:16:57 -0500 From: "Garrett A. Wollman" Message-Id: <9511151716.AA26179@halloran-eldar.lcs.mit.edu> To: Terry Lambert Cc: current@FreeBSD.org Subject: Re: netstat has been broken for a long time.. In-Reply-To: <199511150612.XAA00367@phaeton.artisoft.com> References: <199511150612.XAA00367@phaeton.artisoft.com> Sender: owner-current@FreeBSD.org Precedence: bulk < said: > I thought Garret had renamed this AF_POSIX at one time? First of all, check your spelling next time. Secondly, you thought wrong. POSIX has not yet standardized sockets, and I would not be at all surprised if they didn't include local-domain sockets in any case. > I like AF_POSIX -- AF_LOCAL is a letdown. 8-). Too bad. PF_LOCAL is CSRG's name, and unlike `PF_UNIX' or `PF_POSIX', it is actually descriptive. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-current Wed Nov 15 12:13:23 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA17827 for current-outgoing; Wed, 15 Nov 1995 12:13:23 -0800 Received: from hutcs.cs.hut.fi (root@hutcs.cs.hut.fi [130.233.192.2]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id MAA17818 for ; Wed, 15 Nov 1995 12:13:17 -0800 Received: from shadows.cs.hut.fi by hutcs.cs.hut.fi with SMTP id AA06371 (5.65c8/HUTCS-S 1.4 for ); Wed, 15 Nov 1995 22:11:45 +0200 Received: (hsu@localhost) by shadows.cs.hut.fi (8.6.10/8.6.10) id WAA05574; Wed, 15 Nov 1995 22:11:44 +0200 Date: Wed, 15 Nov 1995 22:11:44 +0200 Message-Id: <199511152011.WAA05574@shadows.cs.hut.fi> From: Heikki Suonsivu To: Bruce Evans Cc: hsu@cs.hut.fi, j@uriah.heep.sax.de, current@FreeBSD.org Subject: Re: ISP state their FreeBSD concerns In-Reply-To: <199511151327.AAA05338@godzilla.zeta.org.au> References: <199511151327.AAA05338@godzilla.zeta.org.au> Sender: owner-current@FreeBSD.org Precedence: bulk Bruce Evans writes: > >Yes, but Bruce, why can't we insert the simple #ifndef? It doesn't > >break anything, but would allow interested people (with a `very > >special setup') to override it from the config file instead of hacking > >the sources over and over again. > > Because ifdefs are evil and simply changing RS_IBUFSIZE is not sufficient. > It must satisfy the following: > > TTYHOG - 2*RS_IBUFSIZE > 0 (much greater, < TTYHOG/2 would be silly) Could it be sensible to make RS_IBUFSIZE ((TTYHOG)/4) ? This would allow tuning TTYHOG value only. It would be a kludge, though. Maybe serial input should be handled differently from other typical tty processing. I do not know enough of the tty code to know whether it is useful to increase TTYHOG value anyway (to me 1k sounds small for any purpose). > RS_IBUFSIZE - 11520 * (1.0/hz + max_softtty_interrupt_latency) >= 0 Btw, lots of ISDN "modems" like ZyXEL's are connected with overclocked 16650/16550 serial ports. I have one at 460.8k. -- Heikki Suonsivu, T{ysikuu 10 C 83/02210 Espoo/FINLAND, hsu@cs.hut.fi home +358-0-8031121 work -4513377 fax -4555276 riippu SN From owner-freebsd-current Wed Nov 15 12:29:00 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA20500 for current-outgoing; Wed, 15 Nov 1995 12:29:00 -0800 Received: from hutcs.cs.hut.fi (root@hutcs.cs.hut.fi [130.233.192.2]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id MAA20479 for ; Wed, 15 Nov 1995 12:28:56 -0800 Received: from shadows.cs.hut.fi by hutcs.cs.hut.fi with SMTP id AA06542 (5.65c8/HUTCS-S 1.4 for ); Wed, 15 Nov 1995 22:28:16 +0200 Received: (hsu@localhost) by shadows.cs.hut.fi (8.6.10/8.6.10) id WAA05614; Wed, 15 Nov 1995 22:28:16 +0200 Date: Wed, 15 Nov 1995 22:28:16 +0200 Message-Id: <199511152028.WAA05614@shadows.cs.hut.fi> From: Heikki Suonsivu To: davidg@root.com Cc: Terry Lambert , hsu@cs.hut.fi, current@freebsd.org Subject: Re: ISP state their FreeBSD concerns In-Reply-To: <199511141707.JAA00421@corbin.Root.COM> References: <199511141619.JAA20025@phaeton.artisoft.com> <199511141707.JAA00421@corbin.Root.COM> Sender: owner-current@freebsd.org Precedence: bulk David Greenman writes: > >have you attempted to verify this by replacing the Adaptec controllers > >with, say, NCR in a similar environment? > > No. "Experimenting" is not an option here since I have to get on a plane, > stay in hotels, etc, to make changes like that. We get the same problems with NCR's and a Buslogic PCI controller. -- Heikki Suonsivu, T{ysikuu 10 C 83/02210 Espoo/FINLAND, hsu@cs.hut.fi home +358-0-8031121 work -4513377 fax -4555276 riippu SN From owner-freebsd-current Wed Nov 15 12:39:54 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA22610 for current-outgoing; Wed, 15 Nov 1995 12:39:54 -0800 Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA22581 for ; Wed, 15 Nov 1995 12:39:49 -0800 Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id MAA19557; Wed, 15 Nov 1995 12:39:22 -0800 From: "Rodney W. Grimes" Message-Id: <199511152039.MAA19557@GndRsh.aac.dev.com> Subject: Re: cvs commit: src/usr.sbin/syslogd syslogd.c To: wollman@lcs.mit.edu (Garrett A. Wollman) Date: Wed, 15 Nov 1995 12:39:22 -0800 (PST) Cc: davidg@Root.COM, current@freebsd.org In-Reply-To: <9511151653.AA26197@halloran-eldar.lcs.mit.edu> from "Garrett A. Wollman" at Nov 15, 95 11:53:34 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1479 Sender: owner-current@freebsd.org Precedence: bulk > > < said: > > > The sysctl crap in the Makefile is bogus and should be removed. My kernel > > is often not called "/kernel" and pretending that it was is wrong. The bootfile > > name should be read-only and the Makefile should not be messing with it. > > No, the bootfile name should not be read-only; I knew what I was doing > when I wrote that code. Agree. > Yes, the Makefile should not be messing with > it. Disagree, but it should be very carefull about messing with it: mv /kernel /kernel.old kernel=`sysctl kern.bootfile` if [ "X${kernel}" = "X/kernel" ]; then sysctl -w kern.bootfile=/kernel.old fi > The reason for making the bootfile name not be read-only is to allow > LKMs to leave their symbol-files in some convenient place and set > kern.bootfile to point there, so that other programs like `modload' > and `netstat' are able to find it. Likewise if make install does overwrite the running kernel but saves a copy of it first kern.bootfile should point to this saved copy, otherwise strange things can and _DO_ happen. A lot of code now gets the running kernel name from sysctl, and to screw this over due to lack of dilligenance in the kernel install: target is just silly. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Wed Nov 15 13:04:17 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA25923 for current-outgoing; Wed, 15 Nov 1995 13:04:17 -0800 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA25857 for ; Wed, 15 Nov 1995 13:03:56 -0800 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA01590; Wed, 15 Nov 1995 13:58:27 -0700 From: Terry Lambert Message-Id: <199511152058.NAA01590@phaeton.artisoft.com> Subject: Re: ISP state their FreeBSD concerns To: babkin@hq.icb.chel.su (Serge A. Babkin) Date: Wed, 15 Nov 1995 13:58:27 -0700 (MST) Cc: terry@lambert.org, karl@mcs.com, current@FreeBSD.ORG In-Reply-To: <199511150924.OAA05961@hq.icb.chel.su> from "Serge A. Babkin" at Nov 15, 95 02:24:57 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 6783 Sender: owner-current@FreeBSD.ORG Precedence: bulk > > > > Well, NFS lockd, for one. > > > > > > I'm sorry, I said unclear. I meant the file-based "implicit" locking methods. > > > I think lockd must make synchronization anyway and it must flush the caches. > > > > No, no, evil, no! > > Even the _client_ cache (if it is present) of the file on which this lock > is executed ? I think that file locking is the simplest example of > [limited] transaction processing. IMHO when the file (or its part) gets > unlocked everyone who tries to read from it must get the updated data, > not old. And when the file (or its part) gets locked it means that the > process wants to see the current state of locked data and change it > without any intervention. The lockd can't sync data in client cache. Only the client can do that. > As I can understand they are even explicitly prohibited (your original > "1)" paragraph). But why ? Is there some principial problem or just > nobody had implemented async NFS client (or simply I never saw it) yet ? The principle that a server is like a disk: when the write returns, you are guaranteed that a read several days later will return the same data by virtue of the semantics. Caching breaks this because cache commit order is not guaranteed to be the same as write order, and a series of idempotent operations will not result in the same ordering on cache commits. Unless you put a lot of work into the cache code to make it so. > > If the client did a "window" worth of async writes an did an fsync() before > > letting go, then it would work. > > How about this algorithm : > > client_nfs_fsync(): > If the file is marked as "write failed" return ERROR; > Make a local simple lock of file to prevent write()s during > fsync(); > Wait until all outstanding write() requests are completed; > Unlock the file; > Return OK; An "fsync()" implies a cache. What gets synced is the client cache contents, not any server contents. The writes at fsync() time are as synchronous as the writes without caching. Like I said, you'd have to put a lot of work into the cache for this. The problem is implied state in the update. Consider the case of a data file and an index file for that data. The relationship between the files is based on implied state in the application. For simplicity, we'll assume a two stage commit so we can make the write ordering requirement on the cache, and we can make the requirement that the client update not be cached across the transaction. Caching across the transaction will incorrectly allow the commit state to advance in the client application. It thinks it is OK to do a write because it thinks the previous write in the staged transaction has gone to permanent media. DOS has an "fsync()" mechanism to handle this: INT 21, AH=0x0d. And Win32 has a similar mechanism implemented at the IFS layer using FS_CloseFile() with flags values of CLOSE_HANDLE or CLOSE_FOR_PROCESS, both of which aren't real resource deallocations and cause the buffers to be flushed. But most progams do not expect a cache and thus do not use these functions. If they aren't called, hooking them does no good. > client_nfs_lock/unlock(): > If the file is marked as "write failed" return ERROR; > Make a local simple lock of file to prevent write()s during > fsync(); > Wait until all outstanding write() requests are completed; > Issue an NFS lock/unlock request and wait until it completes; > Unlock the file; > Return OK; I believe that if you are to use locking as the trigger and the guard, you have to have the lock asserted during the entire cache cycle, and you must flush/invalidate the (write/read) cache when you deassert the lock. A local lock is insufficient. The problem comes when some other client updates the same block before you do. [ ... ] > Of course it is simple and obvious, but what can you, Unix Wizards, say about > it ? Is it wrong ? Distributed cache coherency is a hard problem. You can only partially leverage lock state to implement a coherency mechanism. The biggest pain in the rear is that we have the UNIX side source code, but the DOS client source code is proprietary. > > Basically, it fails because the client is stupid and NFS is not a connection > > oriented protocol. > > Client can be made clever :-) and the connectionless nature of NFS prtocol > should not disallow this buffering. Distributed cache coherency, again. > > How else are you going to support findfirst/findnext and short name > > semantics?!? > > I have experimented with short-named files :-) Really it is not a big > problem if you will put only files with dos-formatted names in the > PCNFS-mounted directories. I don't know about findfirst/findnext problem, > Tsofts's PCNFS with which I experimented worked well with "auth=none" > option. I've experimented with having the short name as an attribute of the file in an attributed file system, though I did the storage in the directory instead of the metadata proper. You still need to know what kind of client you have to enforce the semantics. My personal favorite is a CDROM with RR extensions that you want turned off because the consumer is a DOS client. A file server can be considered as exporting file system interfaces that are views on a single file syste. The local users of the file system, from that point of view, are just another client type. It pays to really support the nameing and name translation coherency between multiple name spaces. The PCNFSD does this with on the fly generation of short names. But limiting the names by convention instead of by semantic is a poor substitute. The first time you drop a long file name into an exported directory, you are screwed. > I have looked at pcnfsd.x and most of request types I saw are printer-related, > only two of them are PCNFSD[2]_AUTH that checks user name and password and > returns uid, gid and other related information and PCNFSD2_MAPID that > performs translations between names and IDs. I see no need to send these > requests every time we do some NFS operation. You're misunderstanding. They take the place of corresponding UNIX client requests, they are not in addition to them. I believe the Sun PCNFSD actually supports NFSv3 style multiple directory entry+stat information per directory traversal request. This is a big win because of the way DOS uses directory lookups. Actually, I need to talk to the two guys here (at Artisoft) who are doing the Win95 NFS client code to ensure that it's optimal for a UNIX server as well as an NT/Win95 server. They might also be able to give me some information on the Sun and B&W PCNFS client 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-current Wed Nov 15 13:32:13 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA00355 for current-outgoing; Wed, 15 Nov 1995 13:32:13 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA00267 for ; Wed, 15 Nov 1995 13:31:28 -0800 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id WAA24375; Wed, 15 Nov 1995 22:31:04 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id WAA04683; Wed, 15 Nov 1995 22:31:03 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id VAA08698; Wed, 15 Nov 1995 21:49:03 +0100 From: J Wunsch Message-Id: <199511152049.VAA08698@uriah.heep.sax.de> Subject: Re: 2.1-stable bombs at umount To: hwr@pilhuhn.de (Heiko W.Rupp) Date: Wed, 15 Nov 1995 21:49:02 +0100 (MET) Cc: current@freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from "Heiko W.Rupp" at Nov 15, 95 04:50:47 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 486 Sender: owner-current@freebsd.org Precedence: bulk As Heiko W.Rupp wrote: > > | Fatal trap 12: page fault while in kernel mode > | fault virtual address = 0x80 > | fault code = supervisor read, page not present > | instruction pointer = 0x8:0xf0172ee8 Please, run ``nm `sysctl -n kern.bootfile` | sort | more'', and examine the region around 0xf0172ee8. -- 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-current Wed Nov 15 13:32:20 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA00380 for current-outgoing; Wed, 15 Nov 1995 13:32:20 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA00277 for ; Wed, 15 Nov 1995 13:31:34 -0800 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id WAA24395; Wed, 15 Nov 1995 22:31:14 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id WAA04688; Wed, 15 Nov 1995 22:31:13 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id WAA09160; Wed, 15 Nov 1995 22:24:07 +0100 From: J Wunsch Message-Id: <199511152124.WAA09160@uriah.heep.sax.de> Subject: Re: Panic while reading CDROM with latest -current To: asami@cs.berkeley.edu (Satoshi Asami) Date: Wed, 15 Nov 1995 22:24:07 +0100 (MET) Cc: freebsd-current@FreeBSD.org (FreeBSD-current users) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199511150852.AAA02753@silvia.HIP.Berkeley.EDU> from "Satoshi Asami" at Nov 15, 95 00:52:22 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 410 Sender: owner-current@FreeBSD.org Precedence: bulk As Satoshi Asami wrote: > > * Somehow, BUFHASH() returns a bogus value (but is apparently believed > * to always return valid pointers /* CANTHAPPEN */). > > Hmm.... Ain't there anybody around who actually knows what BUFHASH() is about to do? -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Wed Nov 15 15:55:30 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA05808 for current-outgoing; Wed, 15 Nov 1995 15:55:30 -0800 Received: from wiley.muc.ditec.de (wiley.muc.ditec.de [194.120.126.9]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA05764 for ; Wed, 15 Nov 1995 15:55:22 -0800 Received: from vector.eikon.e-technik.tu-muenchen.de ([139.92.18.171]) by wiley.muc.ditec.de (8.6.12/8.6.9) with ESMTP id AAA00555 for ; Thu, 16 Nov 1995 00:55:13 +0100 Received: from localhost (localhost [127.0.0.1]) by vector.eikon.e-technik.tu-muenchen.de (8.6.12/8.6.9) with SMTP id WAA12142 for ; Tue, 14 Nov 1995 22:57:01 +0100 Message-Id: <199511142157.WAA12142@vector.eikon.e-technik.tu-muenchen.de> X-Authentication-Warning: vector.eikon.e-technik.tu-muenchen.de: Host localhost didn't use HELO protocol To: current@freebsd.org Subject: startslip Reply-To: "Julian H. Stacey" X-mailer: EXMH [version 1.6.4 10/10/95 Date: Tue, 14 Nov 1995 22:57:01 +0100 From: "Julian H. Stacey" Sender: owner-current@freebsd.org Precedence: bulk No point reinventing the wheel ..... Has anyone got patches to convert src/sbin/startslip to accept a syntax like: startslip ........ device user1 passwd1 user2 passwd ( where an arbitrary amount of crud may occur from a line switching box between the end of passwd1 and prior to the login: prompt for user2 ) I know the obvious Q.: why not write it yourself ? Well, because my old ISP is about to become permanently unavailable, so while I'm not sure which of several new ISPs I will be trying, I thought I'd try new alternate FreeBSD IP tools ( slip ppp * 2, auto dial & manual, dynamic & static ip adr allocation etc) on my old ISP site, before trying new tools on new sites. (I currently use a kermit script to do the double login) Julian Julian H. Stacey EMAIL: jhs@freebsd.org WEB: http://www.freebsd.org/~jhs/ From owner-freebsd-current Wed Nov 15 15:56:02 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA05924 for current-outgoing; Wed, 15 Nov 1995 15:56:02 -0800 Received: from devnull.mpd.tandem.com (devnull.mpd.tandem.com [131.124.4.29]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA05881 for ; Wed, 15 Nov 1995 15:55:50 -0800 Received: from olympus by devnull.mpd.tandem.com (8.6.8/8.6.6) id RAA29247; Wed, 15 Nov 1995 17:55:05 -0600 Received: by olympus (4.1/TSS2.1) id AA13863; Wed, 15 Nov 95 17:55:12 CST From: faulkner@mpd.tandem.com (Boyd Faulkner) Message-Id: <9511152355.AA13863@olympus> Subject: ext2fs partitions don't unmount at shutdown To: current@freebsd.org Date: Wed, 15 Nov 1995 17:55:11 -0600 (CST) X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 478 Sender: owner-current@freebsd.org Precedence: bulk ... or somesuch thing. I have two linux partitions mounted at shutdown, /linux and /linux/usr. At shutdown one disk fails to umount and the clean bits on the ufs' don't get set. The problem goes away if I umount the ext2fs partitions first. Thanks, Boyd -- _______________________________________________________________________ Boyd Faulkner - faulkner@isd.tandem.com - http://cactus.org/~faulkner _______________________________________________________________________ From owner-freebsd-current Wed Nov 15 16:20:29 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA11857 for current-outgoing; Wed, 15 Nov 1995 16:20:29 -0800 Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA11844 ; Wed, 15 Nov 1995 16:20:20 -0800 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id RAA07568; Wed, 15 Nov 1995 17:22:45 -0700 Date: Wed, 15 Nov 1995 17:22:45 -0700 From: Nate Williams Message-Id: <199511160022.RAA07568@rocky.sri.MT.net> To: "Julian H. Stacey" Cc: current@freebsd.org Subject: Re: startslip In-Reply-To: <199511142157.WAA12142@vector.eikon.e-technik.tu-muenchen.de> References: <199511142157.WAA12142@vector.eikon.e-technik.tu-muenchen.de> Sender: owner-current@freebsd.org Precedence: bulk > No point reinventing the wheel ..... > Has anyone got patches to convert src/sbin/startslip to accept > a syntax like: > startslip ........ device user1 passwd1 user2 passwd Excuse me, but *what*? > ( where an arbitrary amount of crud may occur from a line switching box > between the end of passwd1 and prior to the login: prompt for user2 ) This sounds like something that's already built-in to slattach. slattach -a -h -r /etc/sliphome/dial -s 115200 cuaa1 Where /etc/sliphome/dial is: #!/bin/sh # # # This program uses the chat program to (re)dial and connect back up to the # SLIP host PHONE=1234567 USER=Slipuser PASSWORD=secret DEVICE=cuaa1 # XXX - As it stands now, we try to dial the remote site every 10 seconds # or so until it answers. It would be better to have an exponential # backoff algorithm, but this way is much easier to write and guarantees # a connection as soon as one is available. # Wait just a little for the line to settle down sleep 10 (if chat -v ABORT "NO CARRIER" ABORT BUSY "" ATZ1 OK ATM0 OK ATDT$PHONE CONNECT "" ogin: $USER ssword: \\q$PASSWORD then exit 0 else exit 1 fi ) < /dev/$DEVICE > /dev/$DEVICE Is this what you are looking for? Nate From owner-freebsd-current Wed Nov 15 16:33:40 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA14669 for current-outgoing; Wed, 15 Nov 1995 16:33:40 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA14646 for ; Wed, 15 Nov 1995 16:33:32 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id LAA25698; Thu, 16 Nov 1995 11:28:22 +1100 Date: Thu, 16 Nov 1995 11:28:22 +1100 From: Bruce Evans Message-Id: <199511160028.LAA25698@godzilla.zeta.org.au> To: bde@zeta.org.au, wollman@lcs.mit.edu Subject: Re: ISP state their FreeBSD concerns Cc: current@FreeBSD.org Sender: owner-current@FreeBSD.org Precedence: bulk >> Because ifdefs are evil and simply changing RS_IBUFSIZE is not sufficient. >> It must satisfy the following: >> TTYHOG - 2*RS_IBUFSIZE > 0 (much greater, < TTYHOG/2 would be silly) >> RS_IBUFSIZE - 11520 * (1.0/hz + max_softtty_interrupt_latency) >= 0 >This is not a sufficient reason to keep intelligent users from >changing these parameters on their own. Try again. Intelligent users can use an editor. By the way, the ifndef for HZ is still broken. Bruc From owner-freebsd-current Wed Nov 15 16:38:18 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA15732 for current-outgoing; Wed, 15 Nov 1995 16:38:18 -0800 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id QAA14590 ; Wed, 15 Nov 1995 16:33:09 -0800 Received: by sequent.kiae.su id AA09222 (5.65.kiae-2 ); Thu, 16 Nov 1995 03:29:13 +0300 Received: by sequent.KIAE.su (UUMAIL/2.0); Thu, 16 Nov 95 03:29:12 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.12/8.6.12) id DAA00934; Thu, 16 Nov 1995 03:22:39 +0300 To: current@freebsd.org, "Julian H. Stacey" Cc: "Jordan K. Hubbard" References: <199511142157.WAA12142@vector.eikon.e-technik.tu-muenchen.de> In-Reply-To: <199511142157.WAA12142@vector.eikon.e-technik.tu-muenchen.de>; from "Julian H. Stacey" at Tue, 14 Nov 1995 22:57:01 +0100 Message-Id: Organization: Olahm Ha-Yetzirah Date: Thu, 16 Nov 1995 03:22:38 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: startslip Lines: 19 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 719 Sender: owner-current@freebsd.org Precedence: bulk In message <199511142157.WAA12142@vector.eikon.e-technik.tu-muenchen.de> Julian H. Stacey writes: >No point reinventing the wheel ..... >Has anyone got patches to convert src/sbin/startslip to accept >a syntax like: > startslip ........ device user1 passwd1 user2 passwd Proper scripting language in send-expect style must be implemented for both modem and login scripts. I remember Jordan was planning to do it. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-current Wed Nov 15 16:51:19 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA18110 for current-outgoing; Wed, 15 Nov 1995 16:51:19 -0800 Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA18085 for ; Wed, 15 Nov 1995 16:51:15 -0800 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.12/8.6.9) id QAA01015; Wed, 15 Nov 1995 16:50:26 -0800 Date: Wed, 15 Nov 1995 16:50:26 -0800 Message-Id: <199511160050.QAA01015@silvia.HIP.Berkeley.EDU> To: joerg_wunsch@uriah.heep.sax.de CC: freebsd-current@FreeBSD.org In-reply-to: <199511152124.WAA09160@uriah.heep.sax.de> (message from J Wunsch on Wed, 15 Nov 1995 22:24:07 +0100 (MET)) Subject: Re: Panic while reading CDROM with latest -current From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-current@FreeBSD.org Precedence: bulk * Ain't there anybody around who actually knows what BUFHASH() is about * to do? I don't know what bufhash does, but I moved one of the DEC disks to ID 0 the CDROM drive to ID 1, and it worked fine. So the "only happens when CDROM drive at highest ID#" theory seems to hold. Satoshi From owner-freebsd-current Wed Nov 15 16:55:31 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA18747 for current-outgoing; Wed, 15 Nov 1995 16:55:31 -0800 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA18725 ; Wed, 15 Nov 1995 16:55:23 -0800 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id QAA24677; Wed, 15 Nov 1995 16:45:49 -0800 To: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) cc: current@freebsd.org, "Julian H. Stacey" , "Jordan K. Hubbard" Subject: Re: startslip In-reply-to: Your message of "Thu, 16 Nov 1995 03:22:38 +0300." Date: Wed, 15 Nov 1995 16:45:49 -0800 Message-ID: <24675.816482749@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org Precedence: bulk > Proper scripting language in send-expect style must be > implemented for both modem and login scripts. > I remember Jordan was planning to do it. And still will, but this is on hold pending 2.1's release. Jordan From owner-freebsd-current Wed Nov 15 17:05:22 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA20218 for current-outgoing; Wed, 15 Nov 1995 17:05:22 -0800 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA20180 ; Wed, 15 Nov 1995 17:05:07 -0800 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id AAA06363; Thu, 16 Nov 1995 00:56:53 GMT From: Michael Smith Message-Id: <199511160056.AAA06363@genesis.atrad.adelaide.edu.au> Subject: Re: startslip To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Thu, 16 Nov 1995 00:56:53 +0000 () Cc: ache@astral.msk.su, current@freebsd.org, jhs@freebsd.org, jkh@freefall.freebsd.org In-Reply-To: <24675.816482749@time.cdrom.com> from "Jordan K. Hubbard" at Nov 15, 95 04:45:49 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 707 Sender: owner-current@freebsd.org Precedence: bulk Jordan K. Hubbard stands accused of saying: > > > Proper scripting language in send-expect style must be > > implemented for both modem and login scripts. > > I remember Jordan was planning to do it. > > And still will, but this is on hold pending 2.1's release. What's wrong with chat, as already discussed? > Jordan -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 041-122-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] My car has "demand start" -Terry Lambert UNIX: live FreeBSD or die! [[ From owner-freebsd-current Wed Nov 15 17:05:21 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA20213 for current-outgoing; Wed, 15 Nov 1995 17:05:21 -0800 Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA20192 for ; Wed, 15 Nov 1995 17:05:11 -0800 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id SAA07763; Wed, 15 Nov 1995 18:07:26 -0700 Date: Wed, 15 Nov 1995 18:07:26 -0700 From: Nate Williams Message-Id: <199511160107.SAA07763@rocky.sri.MT.net> To: asami@cs.berkeley.edu (Satoshi Asami) Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-current@FreeBSD.org Subject: Re: Panic while reading CDROM with latest -current In-Reply-To: <199511160050.QAA01015@silvia.HIP.Berkeley.EDU> References: <199511152124.WAA09160@uriah.heep.sax.de> <199511160050.QAA01015@silvia.HIP.Berkeley.EDU> Sender: owner-current@FreeBSD.org Precedence: bulk Satoshi Asami writes: > * Ain't there anybody around who actually knows what BUFHASH() is about > * to do? > > I don't know what bufhash does, but I moved one of the DEC disks to ID > 0 the CDROM drive to ID 1, and it worked fine. So the "only happens > when CDROM drive at highest ID#" theory seems to hold. Hmm, I've got a CD on my box 'at the highest ID#', and I use/abuse the CD for both data and audio disks w/out any problems. But, I'm also not running -current. aha0 at 0x330-0x333 irq 11 drq 5 on isa (aha0:0:0): "QUANTUM:PD1800S:3162" type 0 fixed SCSI 2 sd0(aha0:0:0): Direct-Access 1717MB (3517856 512 byte sectors) (aha0:1:0): "QUANTUM:P40S 940-40-94xx:A.2" type 0 fixed SCSI 1 sd1(aha0:1:0): Direct-Access 40MB (82029 512 byte sectors) (aha0:4:0): "NEC:CD-ROM DRIVE:500:2.8" type 5 removable SCSI 2 cd0(aha0:4:0): CD-ROM cd present.[190350 x 2048 byte records] Nate From owner-freebsd-current Wed Nov 15 17:16:22 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA21985 for current-outgoing; Wed, 15 Nov 1995 17:16:22 -0800 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA21951 ; Wed, 15 Nov 1995 17:16:12 -0800 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id RAA24815; Wed, 15 Nov 1995 17:04:04 -0800 To: Michael Smith cc: ache@astral.msk.su, current@freebsd.org, jhs@freebsd.org, jkh@freefall.freebsd.org Subject: Re: startslip In-reply-to: Your message of "Thu, 16 Nov 1995 00:56:53 GMT." <199511160056.AAA06363@genesis.atrad.adelaide.edu.au> Date: Wed, 15 Nov 1995 17:04:04 -0800 Message-ID: <24813.816483844@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org Precedence: bulk > Jordan K. Hubbard stands accused of saying: > > > > > Proper scripting language in send-expect style must be > > > implemented for both modem and login scripts. > > > I remember Jordan was planning to do it. > > > > And still will, but this is on hold pending 2.1's release. > > What's wrong with chat, as already discussed? I've never gotten it to work from slattach. Maybe it works for other people, but for me it croaks immediately after invocation when run by slattach, whereas it works fine when run with the same arguments (and script) if run by itself. Jordan From owner-freebsd-current Wed Nov 15 17:18:09 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA22308 for current-outgoing; Wed, 15 Nov 1995 17:18:09 -0800 Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA22285 for ; Wed, 15 Nov 1995 17:17:59 -0800 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.12/8.6.9) id RAA00718; Wed, 15 Nov 1995 17:17:42 -0800 Date: Wed, 15 Nov 1995 17:17:42 -0800 Message-Id: <199511160117.RAA00718@silvia.HIP.Berkeley.EDU> To: nate@rocky.sri.MT.net CC: joerg_wunsch@uriah.heep.sax.de, freebsd-current@FreeBSD.org In-reply-to: <199511160107.SAA07763@rocky.sri.MT.net> (message from Nate Williams on Wed, 15 Nov 1995 18:07:26 -0700) Subject: Re: Panic while reading CDROM with latest -current From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-current@FreeBSD.org Precedence: bulk * Hmm, I've got a CD on my box 'at the highest ID#', and I use/abuse the * CD for both data and audio disks w/out any problems. But, I'm also not * running -current. Actually, it worked before for me too -- I had ID 0 (Quantum), ID 1 (Microp), ID 6 (CDROM), both on the NCR and later Adaptec and it worked fine. Now the Microp (only wide device I have) is moved to ID 8 so the CDROM is not the highest anymore. Hmm, maybe I should try it again with this kernel.... Satoshi From owner-freebsd-current Wed Nov 15 17:30:21 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA23635 for current-outgoing; Wed, 15 Nov 1995 17:27:18 -0800 Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA23611 ; Wed, 15 Nov 1995 17:27:06 -0800 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id SAA07869; Wed, 15 Nov 1995 18:29:20 -0700 Date: Wed, 15 Nov 1995 18:29:20 -0700 From: Nate Williams Message-Id: <199511160129.SAA07869@rocky.sri.MT.net> To: "Jordan K. Hubbard" Cc: Michael Smith , current@freebsd.org, jhs@freebsd.org Subject: Re: startslip In-Reply-To: <24813.816483844@time.cdrom.com> References: <199511160056.AAA06363@genesis.atrad.adelaide.edu.au> <24813.816483844@time.cdrom.com> Sender: owner-current@freebsd.org Precedence: bulk [ Chat and slattach ] > I've never gotten it to work from slattach. Maybe it works for other > people, but for me it croaks immediately after invocation when run by > slattach, whereas it works fine when run with the same arguments (and > script) if run by itself. I *think* I might have a clue why it works for me and doesn't work other folks. I didn't get it work until I setup a getty on my new box running on ttydX, where X is the same port (cuaaX) I was trying to use startslip on. Why it works that way I don't know, but having the getty running is a nice backup solution. If/when slattach dies on my box, I can dial in remotely and start it backup. :) Nate From owner-freebsd-current Wed Nov 15 18:11:03 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA29014 for current-outgoing; Wed, 15 Nov 1995 18:08:45 -0800 Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA29007 for ; Wed, 15 Nov 1995 18:08:42 -0800 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.12/8.6.9) id SAA01076; Wed, 15 Nov 1995 18:08:23 -0800 Date: Wed, 15 Nov 1995 18:08:23 -0800 Message-Id: <199511160208.SAA01076@silvia.HIP.Berkeley.EDU> To: wosch@cs.tu-berlin.de CC: current@freebsd.org In-reply-to: <199510251635.RAA19353@localhost> (message from Wolfram Schneider on Wed, 25 Oct 1995 17:35:25 +0100) Subject: Re: absolute pathnames in /usr/share/mk/bsd.*.mk From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-current@freebsd.org Precedence: bulk (Old mail, quoted in full for context) * Date: Wed, 25 Oct 1995 17:35:25 +0100 * From: Wolfram Schneider * * * Some bsd.*.mk files use absolute pathnames, eg. /bin/rm or * /usr/sbin/pkg_create. * * I use FreeBSD 2.0A and install the pkg_create from 2.1 in * /usr/local/bin. This does not work because pkg_create was hard coded * as /usr/sbin/pkg_create in bsd.port.mk. Same for the new sed(1). * * In my opinion absolute pathnames should never used. * * * wosch@campa <17:22:18> [~/current/src/share/mk] 698 * $ for file in *.mk;do printf "%20s " $file;grep bin/ $file|wc;done|grep -v 0 * bsd.doc.mk 1 5 62 * bsd.info.mk 1 5 38 * bsd.kmod.mk 2 8 72 * bsd.port.mk 77 469 3887 * * Wolfram This is intentional, at least for bsd.port.mk. We have gotten lots of reports of bsd.port.mk failing because the user didn't have /usr/sbin or /sbin in the search path. I'm sorry it doesn't work for you, but we have to take care of the majority first.... ;< Satoshi From owner-freebsd-current Wed Nov 15 18:19:00 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA00709 for current-outgoing; Wed, 15 Nov 1995 18:17:24 -0800 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA00682 ; Wed, 15 Nov 1995 18:17:15 -0800 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id SAA25300; Wed, 15 Nov 1995 18:14:45 -0800 To: Nate Williams cc: Michael Smith , current@FreeBSD.ORG, jhs@FreeBSD.ORG Subject: Re: startslip In-reply-to: Your message of "Wed, 15 Nov 1995 18:29:20 MST." <199511160129.SAA07869@rocky.sri.MT.net> Date: Wed, 15 Nov 1995 18:14:45 -0800 Message-ID: <25298.816488085@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.ORG Precedence: bulk > I *think* I might have a clue why it works for me and doesn't work other > folks. I didn't get it work until I setup a getty on my new box running > on ttydX, where X is the same port (cuaaX) I was trying to use startslip > on. Why it works that way I don't know, but having the getty running is > a nice backup solution. If/when slattach dies on my box, I can dial in > remotely and start it backup. :) Just tried it. No difference - the start script cycles over and over and over, as usual. Bleh. Maybe someone can spot a bogon. First, I have the following in /etc/start_if.sl0 #!/bin/sh slattach -c -h -r /etc/ppp/slip-dial -s 115200 cuaa1 And /etc/ppp/slip-dial is as follows: #!/bin/sh # Slip dialer (that doesn't work) PHONE=#1740 USER=jkh-slip PASSWORD=haha,asifIwouldleavethathere DEVICE=cuaa1 # Wait just a little for the line to settle down sleep 10 (if chat -v ABORT "NO CARRIER" ABORT BUSY "" ATH OK ATD$PHONE CONNECT "" ogin: $ USER ssword: \\q$PASSWORD then exit 0 else exit 1 fi ) < /dev/$DEVICE > /dev/$DEVICE That's it. Any ideas? Jordan P.S. Yes, the phone number is correct.. That's what a centrex ISDN phone number looks like.. :) From owner-freebsd-current Wed Nov 15 18:59:07 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA06332 for current-outgoing; Wed, 15 Nov 1995 18:59:07 -0800 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA06296 ; Wed, 15 Nov 1995 18:58:54 -0800 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id CAA06920; Thu, 16 Nov 1995 02:52:27 GMT From: Michael Smith Message-Id: <199511160252.CAA06920@genesis.atrad.adelaide.edu.au> Subject: Re: startslip To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Thu, 16 Nov 1995 02:52:27 +0000 () Cc: msmith@atrad.adelaide.edu.au, nate@rocky.sri.MT.net, current@freebsd.org, jhs@freebsd.org In-Reply-To: <26091.816489686@time.cdrom.com> from "Jordan K. Hubbard" at Nov 15, 95 06:41:26 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 964 Sender: owner-current@freebsd.org Precedence: bulk Jordan K. Hubbard stands accused of saying: > > > ABORT BUSY > > ABORT "NO CARRIER" > > TIMEOUT 60 > > "" ATZ > > OK-AT-OK ATDTnumber > > ogin: username > > ssword: password > > > > The OK-AT-OK has been essential with a considerable number of modems; this > > may well be your problem. > > That isn't a factor here since this isn't really a modem, it's > an ISDN Terminal Adaptor.. :) Nonetheless, the idea is to ensure that the two are in sync, which is the issue. Have you tried watching the serial port with the snp device to see whether the two are talking? > Jordan -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 041-122-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] My car has "demand start" -Terry Lambert UNIX: live FreeBSD or die! [[ From owner-freebsd-current Wed Nov 15 18:59:23 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA06379 for current-outgoing; Wed, 15 Nov 1995 18:59:23 -0800 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA06360 ; Wed, 15 Nov 1995 18:59:17 -0800 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id CAA06930; Thu, 16 Nov 1995 02:52:59 GMT From: Michael Smith Message-Id: <199511160252.CAA06930@genesis.atrad.adelaide.edu.au> Subject: Re: startslip To: nate@rocky.sri.MT.net (Nate Williams) Date: Thu, 16 Nov 1995 02:52:59 +0000 () Cc: jkh@time.cdrom.com, msmith@atrad.adelaide.edu.au, current@FreeBSD.ORG, jhs@FreeBSD.ORG In-Reply-To: <199511160129.SAA07869@rocky.sri.MT.net> from "Nate Williams" at Nov 15, 95 06:29:20 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 877 Sender: owner-current@FreeBSD.ORG Precedence: bulk Nate Williams stands accused of saying: > I *think* I might have a clue why it works for me and doesn't work other > folks. I didn't get it work until I setup a getty on my new box running > on ttydX, where X is the same port (cuaaX) I was trying to use startslip > on. Why it works that way I don't know, but having the getty running is > a nice backup solution. If/when slattach dies on my box, I can dial in > remotely and start it backup. :) I never run gettys on my serial ports. > Nate -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 041-122-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] My car has "demand start" -Terry Lambert UNIX: live FreeBSD or die! [[ From owner-freebsd-current Wed Nov 15 19:05:55 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA04267 for current-outgoing; Wed, 15 Nov 1995 18:42:55 -0800 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA04255 ; Wed, 15 Nov 1995 18:42:49 -0800 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id SAA26093; Wed, 15 Nov 1995 18:41:27 -0800 To: Michael Smith cc: nate@rocky.sri.MT.net, current@FreeBSD.ORG, jhs@FreeBSD.ORG Subject: Re: startslip In-reply-to: Your message of "Thu, 16 Nov 1995 02:33:41 GMT." <199511160233.CAA06779@genesis.atrad.adelaide.edu.au> Date: Wed, 15 Nov 1995 18:41:26 -0800 Message-ID: <26091.816489686@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.ORG Precedence: bulk > ABORT BUSY > ABORT "NO CARRIER" > TIMEOUT 60 > "" ATZ > OK-AT-OK ATDTnumber > ogin: username > ssword: password > > The OK-AT-OK has been essential with a considerable number of modems; this > may well be your problem. That isn't a factor here since this isn't really a modem, it's an ISDN Terminal Adaptor.. :) Jordan From owner-freebsd-current Wed Nov 15 19:07:42 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA02543 for current-outgoing; Wed, 15 Nov 1995 18:29:55 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA02534 for ; Wed, 15 Nov 1995 18:29:50 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id NAA29871; Thu, 16 Nov 1995 13:28:12 +1100 Date: Thu, 16 Nov 1995 13:28:12 +1100 From: Bruce Evans Message-Id: <199511160228.NAA29871@godzilla.zeta.org.au> To: bde@zeta.org.au, hsu@cs.hut.fi Subject: Re: ISP state their FreeBSD concerns Cc: current@FreeBSD.ORG, j@uriah.heep.sax.de Sender: owner-current@FreeBSD.ORG Precedence: bulk >Could it be sensible to make RS_IBUFSIZE ((TTYHOG)/4) ? This would allow >tuning TTYHOG value only. It would be a kludge, though. Maybe serial Not very. RS_IBUFSIZE is the fundamental quantity. It should depend on the driver and on the line speed and TTYHOG should depend on RS_IBUFSIZE and the system load. All the values should be variables but there has to be some limit to stop unread input filling up all of memory. > > RS_IBUFSIZE - 11520 * (1.0/hz + max_softtty_interrupt_latency) >= 0 >Btw, lots of ISDN "modems" like ZyXEL's are connected with overclocked >16650/16550 serial ports. I have one at 460.8k. Does it have a higher clock speed or extra clocks? Extra clocks aren't supported (just as well they aren't as necessary as extra video clocks) and you would have to increase various constants for flow control to work and for good performance (output buffer sizes are a bit low but can't be increased much because some of the buffers are on the kernel stack...). Bruce From owner-freebsd-current Wed Nov 15 19:08:13 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA03989 for current-outgoing; Wed, 15 Nov 1995 18:40:36 -0800 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA03979 ; Wed, 15 Nov 1995 18:40:32 -0800 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id CAA06779; Thu, 16 Nov 1995 02:33:41 GMT From: Michael Smith Message-Id: <199511160233.CAA06779@genesis.atrad.adelaide.edu.au> Subject: Re: startslip To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Thu, 16 Nov 1995 02:33:41 +0000 () Cc: nate@rocky.sri.MT.net, msmith@atrad.adelaide.edu.au, current@FreeBSD.ORG, jhs@FreeBSD.ORG In-Reply-To: <25298.816488085@time.cdrom.com> from "Jordan K. Hubbard" at Nov 15, 95 06:14:45 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 806 Sender: owner-current@FreeBSD.ORG Precedence: bulk Jordan K. Hubbard stands accused of saying: > (if chat -v ABORT "NO CARRIER" ABORT BUSY "" ATH OK ATD$PHONE CONNECT "" ogin: $ > USER ssword: \\q$PASSWORD I normally keep my chatscripts in a seperate file : ABORT BUSY ABORT "NO CARRIER" TIMEOUT 60 "" ATZ OK-AT-OK ATDTnumber ogin: username ssword: password The OK-AT-OK has been essential with a considerable number of modems; this may well be your problem. > Jordan -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 041-122-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] My car has "demand start" -Terry Lambert UNIX: live FreeBSD or die! [[ From owner-freebsd-current Wed Nov 15 19:10:20 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA06214 for current-outgoing; Wed, 15 Nov 1995 18:57:45 -0800 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id SAA06152 ; Wed, 15 Nov 1995 18:56:46 -0800 Received: by sequent.kiae.su id AA25754 (5.65.kiae-2 ); Thu, 16 Nov 1995 05:52:45 +0300 Received: by sequent.KIAE.su (UUMAIL/2.0); Thu, 16 Nov 95 05:52:44 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.12/8.6.12) id FAA01478; Thu, 16 Nov 1995 05:39:27 +0300 To: "Jordan K. Hubbard" , Michael Smith Cc: current@FreeBSD.ORG, jhs@FreeBSD.ORG, jkh@freefall.freebsd.org References: <199511160056.AAA06363@genesis.atrad.adelaide.edu.au> In-Reply-To: <199511160056.AAA06363@genesis.atrad.adelaide.edu.au>; from Michael Smith at Thu, 16 Nov 1995 00:56:53 +0000 () Message-Id: Organization: Olahm Ha-Yetzirah Date: Thu, 16 Nov 1995 05:39:27 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: startslip Lines: 20 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 777 Sender: owner-current@FreeBSD.ORG Precedence: bulk In message <199511160056.AAA06363@genesis.atrad.adelaide.edu.au> Michael Smith writes: >Jordan K. Hubbard stands accused of saying: >> >> > Proper scripting language in send-expect style must be >> > implemented for both modem and login scripts. >> > I remember Jordan was planning to do it. >> >> And still will, but this is on hold pending 2.1's release. >What's wrong with chat, as already discussed? Nothing wrong with chat, but you need to teach startslip to use chat. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-current Wed Nov 15 19:15:35 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA08907 for current-outgoing; Wed, 15 Nov 1995 19:15:35 -0800 Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA08883 ; Wed, 15 Nov 1995 19:15:30 -0800 Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id TAA20307; Wed, 15 Nov 1995 19:13:33 -0800 From: "Rodney W. Grimes" Message-Id: <199511160313.TAA20307@GndRsh.aac.dev.com> Subject: Re: startslip To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 15 Nov 1995 19:13:33 -0800 (PST) Cc: nate@rocky.sri.MT.net, msmith@atrad.adelaide.edu.au, current@FreeBSD.ORG, jhs@FreeBSD.ORG In-Reply-To: <25298.816488085@time.cdrom.com> from "Jordan K. Hubbard" at Nov 15, 95 06:14:45 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1147 Sender: owner-current@FreeBSD.ORG Precedence: bulk > > > I *think* I might have a clue why it works for me and doesn't work other > > folks. I didn't get it work until I setup a getty on my new box running > > on ttydX, where X is the same port (cuaaX) I was trying to use startslip > > on. Why it works that way I don't know, but having the getty running is > > a nice backup solution. If/when slattach dies on my box, I can dial in > > remotely and start it backup. :) > > Just tried it. No difference - the start script cycles over and over > and over, as usual. Bleh. > > Maybe someone can spot a bogon. Yea, what is the setup of your /dev/cuaa1 device like, I suspect that as soon as chat closes /dev/cuaa1 it hangs up the modem. What is hupcl on /dev/cuaa1 set to?? I have my modem tweaked so that it ignores the control signals that cause it to hang up (when you have 24x7 slip it is kinda silly to have a reboot hang up the modem). You can do that, or use /etc/rc.serial to set the right control device to not do a hupcl. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Wed Nov 15 19:36:42 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA11650 for current-outgoing; Wed, 15 Nov 1995 19:36:42 -0800 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id TAA11467 ; Wed, 15 Nov 1995 19:35:38 -0800 Received: by sequent.kiae.su id AA00899 (5.65.kiae-2 ); Thu, 16 Nov 1995 06:30:47 +0300 Received: by sequent.KIAE.su (UUMAIL/2.0); Thu, 16 Nov 95 06:30:47 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.12/8.6.12) id GAA02112; Thu, 16 Nov 1995 06:30:10 +0300 To: current@freebsd.org Cc: nate@freebsd.org Message-Id: Organization: Olahm Ha-Yetzirah Date: Thu, 16 Nov 1995 06:30:10 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Link order needs to be fixed! Lines: 24 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 816 Sender: owner-current@freebsd.org Precedence: bulk I just try to build some application (speak_freely) and got following diagnostic from ld: setkey(3) not present in the system! BUT! I directly specify -lcipher (which have setkey()) into linker line, i.e.: cc ..objs.. -lcipher It means that setkey() picked not from shared libcipher but from shared libc instead independently of linking order. Using "/usr/lib/libcipher.a" instead of "-lcihper" not helps too. Of course, when I add -static, all becomes OK, but we need working ld for shared libraries in any case. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-current Wed Nov 15 19:47:51 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA12851 for current-outgoing; Wed, 15 Nov 1995 19:47:51 -0800 Received: from nandi.com (root@Nandi.COM [206.205.75.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA12842 for ; Wed, 15 Nov 1995 19:47:46 -0800 Received: from localhost (shiva@localhost [127.0.0.1]) by nandi.com (8.7/8.6.9) with SMTP id WAA25925 for ; Wed, 15 Nov 1995 22:48:43 GMT Message-Id: <199511152248.WAA25925@nandi.com> X-Authentication-Warning: nandi.com: Host shiva@localhost [127.0.0.1] didn't use HELO protocol To: current@freebsd.org Subject: Re: startslip In-reply-to: Your message of "Wed, 15 Nov 1995 17:04:04 PST." <24813.816483844@time.cdrom.com> Date: Wed, 15 Nov 1995 22:48:41 +0000 From: Shiva Ramabadran Sender: owner-current@freebsd.org Precedence: bulk In message <24813.816483844@time.cdrom.com> Jordan writes: } } I've never gotten it to work from slattach. Maybe it } works for other people, but for me it croaks immediately } after invocation when run by slattach, whereas it works } fine when run with the same arguments (and } script) if run by itself. } Works flawlessly for me. I don't even bother to dial first before invoking the slattach. I just pass the chat script to slattach as the "redial on carrier loss" script with the -r option. It forks the script off, a few seconds after starting up, when it realizes it does not have carrier detect. I'm running a vanilla 2.1.0-950726-SNAP. (I know, this is the current mailing list, and I'm not running current, but I provide this information just a point of reference.) -Shiva -=- From owner-freebsd-current Wed Nov 15 20:16:50 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA15361 for current-outgoing; Wed, 15 Nov 1995 20:16:50 -0800 Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA15353 ; Wed, 15 Nov 1995 20:16:43 -0800 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id VAA08251; Wed, 15 Nov 1995 21:16:34 -0700 Date: Wed, 15 Nov 1995 21:16:34 -0700 From: Nate Williams Message-Id: <199511160416.VAA08251@rocky.sri.MT.net> To: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) Cc: current@freebsd.org, nate@freebsd.org Subject: Re: Link order needs to be fixed! In-Reply-To: References: Sender: owner-current@freebsd.org Precedence: bulk KOI8-R writes: > BUT! I directly specify -lcipher (which have setkey()) into > linker line, i.e.: > > cc ..objs.. -lcipher > > It means that setkey() picked not from shared libcipher > but from shared libc instead independently of linking > order. If setkey() is in a shared libcipher, and you have a shared libc() it will follow link order. It's when you mix and match shared/static libraries there is a problem. That has *always* worked, and was never broken. Can ou provide me a tar-file with the offending code? Nate From owner-freebsd-current Wed Nov 15 20:24:21 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA15843 for current-outgoing; Wed, 15 Nov 1995 20:24:21 -0800 Received: from apricot.com (apricot.com [199.125.221.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA15837 for ; Wed, 15 Nov 1995 20:24:14 -0800 Received: from ryoohki.apricot.com (scanner@ryoohki.apricot.com [199.125.221.7]) by apricot.com (8.6.12/8.6.9) with ESMTP id XAA04100 for ; Wed, 15 Nov 1995 23:24:10 -0500 Received: from ryoohki.apricot.com (scanner@localhost) by ryoohki.apricot.com (8.6.12/8.6.12) with ESMTP id XAA27911 for ; Wed, 15 Nov 1995 23:24:06 -0500 Message-Id: <199511160424.XAA27911@ryoohki.apricot.com> X-Authentication-Warning: ryoohki.apricot.com: scanner owned process doing -bs To: current@freebsd.org Subject: Re: startslip In-reply-to: Your message of "Wed, 15 Nov 1995 22:48:41 GMT." <199511152248.WAA25925@nandi.com> X-URI: http://www.apricot.com/~scanner/ X-Face: 6K2.ZvQgQ.NDQLIx.1pW(xRu*">:}&PX-Ad_!!?wU7H4L"wF"0xEwYu=8Or0V+=5?-eO1XL 7-0Hom/|]B2C7Uznyol-NVnvEk:+sod^MyB4v4qVpPDemr;b@pZdRSXu.'Gm^t0?2l,j[&t.kbc[UW x6Lz^e$K$W Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 15 Nov 1995 23:24:05 -0500 From: Scanner Sender: owner-current@freebsd.org Precedence: bulk Shiva Ramabadran writes: > > In message <24813.816483844@time.cdrom.com> Jordan writes: > } > } I've never gotten it to work from slattach. Maybe it > } works for other people, but for me it croaks immediately > } after invocation when run by slattach, whereas it works > } fine when run with the same arguments (and > } script) if run by itself. > } > > Works flawlessly for me. I don't even bother to dial first > before invoking the slattach. I just pass the chat script > to slattach as the "redial on carrier loss" script with the > -r option. It forks the script off, a few seconds after > starting up, when it realizes it does not have carrier detect. > > I'm running a vanilla 2.1.0-950726-SNAP. Actually, I had the exact same behaviour that Jordan speaks of, and I am using the exact same script Shiva was. For kicks, I told slattach to use 57600 and.. voila, it works. I have not bothered to look any further since my net connection is now UP and working and have been too busy preparing to uproot my entire world from one coast to the other, but it sounds to me like a curiously misconfigured serial port. (BTW, I am running 2.0.5-RELEASE on this machine.) --Scanner (scanner@apricot.com) From owner-freebsd-current Wed Nov 15 21:17:06 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA20137 for current-outgoing; Wed, 15 Nov 1995 21:17:06 -0800 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id VAA19983 ; Wed, 15 Nov 1995 21:14:09 -0800 Received: by sequent.kiae.su id AA17606 (5.65.kiae-2 ); Thu, 16 Nov 1995 08:00:30 +0300 Received: by sequent.KIAE.su (UUMAIL/2.0); Thu, 16 Nov 95 08:00:30 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.12/8.6.12) id HAA02888; Thu, 16 Nov 1995 07:55:46 +0300 To: Nate Williams Cc: current@freebsd.org, nate@freebsd.org References: <199511160416.VAA08251@rocky.sri.MT.net> In-Reply-To: <199511160416.VAA08251@rocky.sri.MT.net>; from Nate Williams at Wed, 15 Nov 1995 21:16:34 -0700 Message-Id: Organization: Olahm Ha-Yetzirah Date: Thu, 16 Nov 1995 07:55:45 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: Link order needs to be fixed! Lines: 33 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1078 Sender: owner-current@freebsd.org Precedence: bulk In message <199511160416.VAA08251@rocky.sri.MT.net> Nate Williams writes: >KOI8-R writes: >> BUT! I directly specify -lcipher (which have setkey()) into >> linker line, i.e.: >> >> cc ..objs.. -lcipher >> >> It means that setkey() picked not from shared libcipher >> but from shared libc instead independently of linking >> order. >If setkey() is in a shared libcipher, and you have a shared libc() it >will follow link order. both libc and libcipher shared as I say. >It's when you mix and match shared/static libraries there is a problem. >That has *always* worked, and was never broken. Can ou provide me a >tar-file with the offending code? I have per-program static libraries, i.e.: cc ..objs.. ..program-static-libs.. -lcipher I'll mail tar file to you shortly. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-current Wed Nov 15 22:26:52 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA27393 for current-outgoing; Wed, 15 Nov 1995 22:26:52 -0800 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA27382 ; Wed, 15 Nov 1995 22:26:49 -0800 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id WAA27928; Wed, 15 Nov 1995 22:25:33 -0800 To: "Rodney W. Grimes" cc: nate@rocky.sri.MT.net, msmith@atrad.adelaide.edu.au, current@FreeBSD.ORG, jhs@FreeBSD.ORG Subject: Re: startslip In-reply-to: Your message of "Wed, 15 Nov 1995 19:13:33 PST." <199511160313.TAA20307@GndRsh.aac.dev.com> Date: Wed, 15 Nov 1995 22:25:33 -0800 Message-ID: <27926.816503133@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.ORG Precedence: bulk > Yea, what is the setup of your /dev/cuaa1 device like, I suspect that as > soon as chat closes /dev/cuaa1 it hangs up the modem. What is hupcl on > /dev/cuaa1 set to?? It shouldn't matter? The whole advantage of running chat under slattach is that it's supposed to be run on the fd that slattach already has open, so there's no question of the hangup-after-dial problem that would otherwise occur if you did the open-dial-close-slattach cycle. I know, I've been there too with my little kermit dialer scripts. Of course, if it turns out that you're right about this then slattach is deeply broken and has managed to nullify the whole advantage that was the point of adding the external dial agent capability to slattach! Jordan From owner-freebsd-current Wed Nov 15 22:55:45 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA01850 for current-outgoing; Wed, 15 Nov 1995 22:55:45 -0800 Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA01830 ; Wed, 15 Nov 1995 22:55:41 -0800 Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id WAA20629; Wed, 15 Nov 1995 22:55:07 -0800 From: "Rodney W. Grimes" Message-Id: <199511160655.WAA20629@GndRsh.aac.dev.com> Subject: Re: startslip To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 15 Nov 1995 22:55:07 -0800 (PST) Cc: nate@rocky.sri.MT.net, msmith@atrad.adelaide.edu.au, current@FreeBSD.ORG, jhs@FreeBSD.ORG In-Reply-To: <27926.816503133@time.cdrom.com> from "Jordan K. Hubbard" at Nov 15, 95 10:25:33 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1690 Sender: owner-current@FreeBSD.ORG Precedence: bulk > > > Yea, what is the setup of your /dev/cuaa1 device like, I suspect that as > > soon as chat closes /dev/cuaa1 it hangs up the modem. What is hupcl on > > /dev/cuaa1 set to?? > > It shouldn't matter? The whole advantage of running chat under > slattach is that it's supposed to be run on the fd that slattach > already has open, so there's no question of the hangup-after-dial > problem that would otherwise occur if you did the > open-dial-close-slattach cycle. I know, I've been there too with my > little kermit dialer scripts. It wouldn't be the first time this was broken. I don't ever see it when it is broken as my modem ignores the signals since I never want it to hang up no matter what happens, even if I power my box off my modem stays on line. > Of course, if it turns out that you're right about this then slattach > is deeply broken and has managed to nullify the whole advantage that > was the point of adding the external dial agent capability to > slattach! It also may have to do with calling a shell script that calls chat that is really a sub-shell with the device redirected onto standard in and standard out. The setup I use here is a very simple modem dial program written by Marc Frajola that is run directly by slattach (ie, no shell and no subshell in between). I do know that when I helped someone local setup his system using slattach and chat I had a real nightmore getting it to work correctly until I turned off either hupcl or made his modem ignore the signals, this was just after 2.0.5. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Wed Nov 15 23:13:14 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA04769 for current-outgoing; Wed, 15 Nov 1995 23:13:14 -0800 Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id XAA04760 ; Wed, 15 Nov 1995 23:13:11 -0800 Message-Id: <199511160713.XAA04760@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: Host localhost.cdrom.com didn't use HELO protocol To: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) cc: "Jordan K. Hubbard" , Michael Smith , current@FreeBSD.ORG, jhs@FreeBSD.ORG, jkh@freefall.freebsd.org Subject: Re: startslip In-reply-to: Your message of "Thu, 16 Nov 1995 05:39:27 +0300." Date: Wed, 15 Nov 1995 23:13:10 -0800 From: "Justin T. Gibbs" Sender: owner-current@FreeBSD.ORG Precedence: bulk >In message <199511160056.AAA06363@genesis.atrad.adelaide.edu.au> > Michael Smith writes: > >>Jordan K. Hubbard stands accused of saying: >>> >>> > Proper scripting language in send-expect style must be >>> > implemented for both modem and login scripts. >>> > I remember Jordan was planning to do it. >>> >>> And still will, but this is on hold pending 2.1's release. > >>What's wrong with chat, as already discussed? > >Nothing wrong with chat, but you need to teach startslip to use chat. Chat with startslip seems to have the same problems as expect does with slattach. I've recently lost my dedicated modem service, so I'll be digging in the attic for my old slattachs-expect scripts I used back in the 1.1.5 days when slattach had no problems with expect. I just wish I had someone more familiar with the tty code on my side when I try to figure out why this doesn't work with any slattach from 2.0 on... >-- >Andrey A. Chernov : And I rest so composedly, /Now, in my bed, >ache@astral.msk.su : That any beholder /Might fancy me dead - >http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. >RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Wed Nov 15 23:49:15 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA07430 for current-outgoing; Wed, 15 Nov 1995 23:49:15 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA07420 ; Wed, 15 Nov 1995 23:49:08 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id SAA08533; Thu, 16 Nov 1995 18:42:22 +1100 Date: Thu, 16 Nov 1995 18:42:22 +1100 From: Bruce Evans Message-Id: <199511160742.SAA08533@godzilla.zeta.org.au> To: jkh@time.cdrom.com, rgrimes@GndRsh.aac.dev.com Subject: Re: startslip Cc: current@FreeBSD.org, jhs@FreeBSD.org, msmith@atrad.adelaide.edu.au, nate@rocky.sri.MT.net Sender: owner-current@FreeBSD.org Precedence: bulk >> Maybe someone can spot a bogon. >Yea, what is the setup of your /dev/cuaa1 device like, I suspect that as >soon as chat closes /dev/cuaa1 it hangs up the modem. What is hupcl on >/dev/cuaa1 set to?? This shouldn't happen, because slattach keeps the device open. The redirection in the script is bogus - slattach has set up stdin and stdout, and changing them is either a no-op or can't work because slattach isn't keeping other devices open. Bruce From owner-freebsd-current Thu Nov 16 01:08:55 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA17689 for current-outgoing; Thu, 16 Nov 1995 01:08:55 -0800 Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id BAA17677 for ; Thu, 16 Nov 1995 01:08:53 -0800 Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0tG0JP-0003wlC; Thu, 16 Nov 95 01:08 PST Received: from localhost (localhost [127.0.0.1]) by critter.tfs.com (8.6.11/8.6.9) with SMTP id KAA04455; Thu, 16 Nov 1995 10:08:49 +0100 X-Authentication-Warning: localhost.tfs.com: Host localhost didn't use HELO protocol To: "Garrett A. Wollman" cc: current@freebsd.org Subject: Re: cvs commit: src/sys/kern kern_sysctl.c In-reply-to: Your message of "Wed, 15 Nov 1995 12:08:47 EST." <9511151708.AA26231@halloran-eldar.lcs.mit.edu> Date: Thu, 16 Nov 1995 10:08:48 +0100 Message-ID: <4453.816512928@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@freebsd.org Precedence: bulk > < said: > > >> The purpose of this is to prevent race conditions even in a > >> uniprocessor system. > > > what race-conditions ? > > Say process 1 and process 2 are both trying to change some variable. > Process 1 gets the old value, but blocks before the new value is > changed. Process 2 then gets the old value, sets the new value, and > returns success. Process 1 then wakes up, and sets its new value, > thereby obliterating what process 2 had done, with neither process 1 > nor process 2 aware of what happened (unless they go back and check > again), because they will see the same `old' result. Ok, I guess that means we need it for that case at least... -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Thu Nov 16 01:20:24 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA19530 for current-outgoing; Thu, 16 Nov 1995 01:20:24 -0800 Received: from pilhuhn.de (pilhuhn.de [193.141.89.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id BAA19516 for ; Thu, 16 Nov 1995 01:20:17 -0800 Received: by pilhuhn.de id ; Thu, 16 Nov 95 10:19 MET Message-Id: From: hwr@pilhuhn.de (Heiko W.Rupp) Subject: Re: 2.1-stable bombs at umount To: joerg_wunsch@uriah.heep.sax.de Date: Thu, 16 Nov 1995 10:19:05 +0100 (MET) Cc: hwr@pilhuhn.de, current@freebsd.org In-Reply-To: <199511152049.VAA08698@uriah.heep.sax.de> from "J Wunsch" at Nov 15, 95 09:49:02 pm X-Mailer: ELM [version 2.4 PL20] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 547 Sender: owner-current@freebsd.org Precedence: bulk Joerg Wunsch: | > | Fatal trap 12: page fault while in kernel mode | > | instruction pointer = 0x8:0xf0172ee8 | Please, run ``nm `sysctl -n kern.bootfile` | sort | more'', and | examine the region around 0xf0172ee8. This gives: f0172e70 F ufs_inode.o f0172e70 T _ufs_init f0172eb8 T _ufs_inactive f017307c T _ufs_reclaim f0173130 F ufs_lookup.o -- Heiko W.Rupp Gerwigstr.5 D-76131 Karlsruhe +49 721 9661524 In a hotel in Athens: Visitors are expected to complain at the office between the hours of 9 and 11 A.M. daily. From owner-freebsd-current Thu Nov 16 02:02:07 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA26930 for current-outgoing; Thu, 16 Nov 1995 02:02:07 -0800 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id CAA26914 ; Thu, 16 Nov 1995 02:02:02 -0800 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id CAA28650; Thu, 16 Nov 1995 02:00:32 -0800 To: Bruce Evans cc: rgrimes@GndRsh.aac.dev.com, current@FreeBSD.org, jhs@FreeBSD.org, msmith@atrad.adelaide.edu.au, nate@rocky.sri.MT.net Subject: Re: startslip In-reply-to: Your message of "Thu, 16 Nov 1995 18:42:22 +1100." <199511160742.SAA08533@godzilla.zeta.org.au> Date: Thu, 16 Nov 1995 02:00:31 -0800 Message-ID: <28648.816516031@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.org Precedence: bulk > redirection in the script is bogus - slattach has set up stdin and Erm. Jeeze, that's what I get for cloning procedures without actually looking at them, isn't it? I'll try this out tonite! Jordan From owner-freebsd-current Thu Nov 16 02:50:58 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA03406 for current-outgoing; Thu, 16 Nov 1995 02:50:58 -0800 Received: from mail.cs.tu-berlin.de (mail.cs.tu-berlin.de [130.149.17.13]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id CAA03359 for ; Thu, 16 Nov 1995 02:50:36 -0800 Received: from caramba.cs.tu-berlin.de (wosch@caramba.cs.tu-berlin.de [130.149.17.12]) by mail.cs.tu-berlin.de (8.6.12/8.6.12) with ESMTP id KAA08200; Thu, 16 Nov 1995 10:56:56 +0100 From: Wolfram Schneider Received: (wosch@localhost) by caramba.cs.tu-berlin.de (8.6.12/8.6.9) id KAA08085; Thu, 16 Nov 1995 10:56:50 +0100 Date: Thu, 16 Nov 1995 10:56:50 +0100 Message-Id: <199511160956.KAA08085@caramba.cs.tu-berlin.de> To: asami@cs.berkeley.edu (Satoshi Asami) Cc: current@freebsd.org Subject: Re: absolute pathnames in /usr/share/mk/bsd.*.mk In-Reply-To: <199511160208.SAA01076@silvia.HIP.Berkeley.EDU> References: <199510251635.RAA19353@localhost> <199511160208.SAA01076@silvia.HIP.Berkeley.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-current@freebsd.org Precedence: bulk Satoshi Asami writes: >This is intentional, at least for bsd.port.mk. We have gotten lots of >reports of bsd.port.mk failing because the user didn't have /usr/sbin >or /sbin in the search path. > >I'm sorry it doesn't work for you, but we have to take care of the >majority first.... ;< $ egrep /bin/ *.mk |wc -l 73 $ egrep /sbin/ *.mk |wc -l 6 $ egrep /sbin/ *.mk bsd.kmod.mk: /sbin/modload -o ${KMOD} -e${KMOD} ${PROG} bsd.kmod.mk: /sbin/modunload -n ${KMOD} bsd.port.mk:MD5?= /sbin/md5 bsd.port.mk:MTREE_CMD?= /usr/sbin/mtree bsd.port.mk:PKG_CMD?= /usr/sbin/pkg_create bsd.port.mk: if /sbin/ldconfig -r | grep -q -e "-l$$lib"; then \ Wolfram From owner-freebsd-current Thu Nov 16 05:26:24 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA16134 for current-outgoing; Thu, 16 Nov 1995 05:26:24 -0800 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA16123 for ; Thu, 16 Nov 1995 05:26:19 -0800 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id NAA08472 for current@freebsd.org; Thu, 16 Nov 1995 13:21:03 GMT From: Michael Smith Message-Id: <199511161321.NAA08472@genesis.atrad.adelaide.edu.au> Subject: -current kernel broken just now... To: current@freebsd.org Date: Thu, 16 Nov 1995 13:21:03 +0000 () MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 535 Sender: owner-current@freebsd.org Precedence: bulk Typeing errors (lpintr) in lpt.c, and _qsort called by kern_sysctl.c Have I cought some half-in commits? (I resupped ~10 hours later with no change...) -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 041-122-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] My car has "demand start" -Terry Lambert UNIX: live FreeBSD or die! [[ From owner-freebsd-current Thu Nov 16 06:03:44 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA18909 for current-outgoing; Thu, 16 Nov 1995 06:03:44 -0800 Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id GAA18900 for ; Thu, 16 Nov 1995 06:03:42 -0800 Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0tG4ue-0003vkC; Thu, 16 Nov 95 06:03 PST Received: from localhost (localhost [127.0.0.1]) by critter.tfs.com (8.6.11/8.6.9) with SMTP id PAA04779; Thu, 16 Nov 1995 15:03:37 +0100 X-Authentication-Warning: localhost.tfs.com: Host localhost didn't use HELO protocol To: Michael Smith cc: current@freebsd.org Subject: Re: -current kernel broken just now... In-reply-to: Your message of "Thu, 16 Nov 1995 13:21:03 GMT." <199511161321.NAA08472@genesis.atrad.adelaide.edu.au> Date: Thu, 16 Nov 1995 15:03:37 +0100 Message-ID: <4777.816530617@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@freebsd.org Precedence: bulk > > Typeing errors (lpintr) in lpt.c, and _qsort called by kern_sysctl.c > > Have I cought some half-in commits? (I resupped ~10 hours later with > no change...) recompile libkern for the qsort. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Thu Nov 16 08:15:34 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA24998 for current-outgoing; Thu, 16 Nov 1995 08:15:34 -0800 Received: from hutcs.cs.hut.fi (root@hutcs.cs.hut.fi [130.233.192.2]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id IAA24988 for ; Thu, 16 Nov 1995 08:15:30 -0800 Received: from shadows.cs.hut.fi by hutcs.cs.hut.fi with SMTP id AA19659 (5.65c8/HUTCS-S 1.4 for ); Thu, 16 Nov 1995 18:15:21 +0200 Received: (hsu@localhost) by shadows.cs.hut.fi (8.6.10/8.6.10) id SAA07825; Thu, 16 Nov 1995 18:15:20 +0200 Date: Thu, 16 Nov 1995 18:15:20 +0200 Message-Id: <199511161615.SAA07825@shadows.cs.hut.fi> From: Heikki Suonsivu To: Bruce Evans Cc: hsu@cs.hut.fi, current@FreeBSD.org, j@uriah.heep.sax.de Subject: Re: ISP state their FreeBSD concerns In-Reply-To: <199511160228.NAA29871@godzilla.zeta.org.au> References: <199511160228.NAA29871@godzilla.zeta.org.au> Sender: owner-current@FreeBSD.org Precedence: bulk Bruce Evans writes: > > > RS_IBUFSIZE - 11520 * (1.0/hz + max_softtty_interrupt_latency) >= 0 > > >Btw, lots of ISDN "modems" like ZyXEL's are connected with overclocked > >16650/16550 serial ports. I have one at 460.8k. > > Does it have a higher clock speed or extra clocks? Extra clocks aren't > supported (just as well they aren't as necessary as extra video clocks) Higher clock speed (setting terminal rate to 115.2 makes it 460.8k). -- Heikki Suonsivu, T{ysikuu 10 C 83/02210 Espoo/FINLAND, hsu@cs.hut.fi home +358-0-8031121 work -4513377 fax -4555276 riippu SN From owner-freebsd-current Thu Nov 16 11:56:33 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA09760 for current-outgoing; Thu, 16 Nov 1995 11:56:33 -0800 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA09755 for ; Thu, 16 Nov 1995 11:56:30 -0800 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA03640; Thu, 16 Nov 1995 12:51:27 -0700 From: Terry Lambert Message-Id: <199511161951.MAA03640@phaeton.artisoft.com> Subject: Re: 2.1-stable bombs at umount To: hwr@pilhuhn.de (Heiko W.Rupp) Date: Thu, 16 Nov 1995 12:51:27 -0700 (MST) Cc: joerg_wunsch@uriah.heep.sax.de, hwr@pilhuhn.de, current@freebsd.org In-Reply-To: from "Heiko W.Rupp" at Nov 16, 95 10:19:05 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2258 Sender: owner-current@freebsd.org Precedence: bulk > > Joerg Wunsch: > | > | Fatal trap 12: page fault while in kernel mode > | > | instruction pointer = 0x8:0xf0172ee8 > > | Please, run ``nm `sysctl -n kern.bootfile` | sort | more'', and > | examine the region around 0xf0172ee8. > > This gives: > f0172e70 F ufs_inode.o > f0172e70 T _ufs_init > f0172eb8 T _ufs_inactive > f017307c T _ufs_reclaim > f0173130 F ufs_lookup.o 48 instructions into ufs_inactive() in /sys/ufs/ufs/ufs_inode.c. int ufs_inactive(ap) struct vop_inactive_args /* { struct vnode *a_vp; } */ *ap; { register struct vnode *vp = ap->a_vp; register struct inode *ip = VTOI(vp); [ ... ] .globl _ufs_inactive .type _ufs_inactive,@function _ufs_inactive: pushl %ebp movl %esp,%ebp subl $40,%esp pushl %edi pushl %esi pushl %ebx movl 8(%ebp),%edx movl 4(%edx),%esi movl 100(%esi),%edi cmpl $0,_prtactive je L117 cmpw $0,4(%esi) je L117 pushl %esi pushl $LC0 call _vprint addl $8,%esp Someone passed a NULL vnode to ufs_inactive. When the inode pointer was dereferenced out, it blew. My guess is that the offending VOP_INACTIVE() is being called by vclean() which is being called by vflush(), which is being called with a NULLVP in /sys/ufs/ffs/ffs_vfsops.c from ffs_flushfiles(). Let me guess: You are running with quotas on this file system. This seems to be an unforseen side effect of the recent changes to the way unmounts are done on system shutdown. They are now explicit in reverse order (per David Greenman's recent posting about the use of circular queues for the mountlist). If you explicitly add the line: qsync(mp); Before the line: error = vflush(mp, NULLVP, SKIPSYSTEM|flags); in /sys/ufs/ffs/ffs_vfsops.c from ffs_flushfiles(), it *might* mask the problem for you. If you aren't running with quotas, reverting the unmount code to forward traverse the mountlist, focing each unmount, will fix the problem, or at least put the behaviour back the way it was before the problem became obvious. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Thu Nov 16 12:19:46 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA11028 for current-outgoing; Thu, 16 Nov 1995 12:19:46 -0800 Received: from pilhuhn.de (pilhuhn.de [193.141.89.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id MAA11022 for ; Thu, 16 Nov 1995 12:19:39 -0800 Received: by pilhuhn.de id ; Thu, 16 Nov 95 21:18 MET Message-Id: From: hwr@pilhuhn.de (Heiko W.Rupp) Subject: Re: 2.1-stable bombs at umount To: terry@lambert.org (Terry Lambert) Date: Thu, 16 Nov 1995 21:18:38 +0100 (MET) Cc: hwr@pilhuhn.de, joerg_wunsch@uriah.heep.sax.de, current@freebsd.org In-Reply-To: <199511161951.MAA03640@phaeton.artisoft.com> from "Terry Lambert" at Nov 16, 95 12:51:27 pm X-Mailer: ELM [version 2.4 PL20] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 683 Sender: owner-current@freebsd.org Precedence: bulk Terry Lambert: | Let me guess: You are running with quotas on this file system. No. This is a news spool filesystem - I did not set up any quota at all. | If you aren't running with quotas, reverting the unmount code to forward | traverse the mountlist, focing each unmount, will fix the problem, or | at least put the behaviour back the way it was before the problem became | obvious. Will look into this, but at the moment I don't have enough spare time (and want a _stable_ system ..) -- Heiko W.Rupp Gerwigstr.5 D-76131 Karlsruhe +49 721 9661524 ... den 80 Mark Fuerst auf den Schaedel und dann in die Eier hau'n, dann fuehlt der Typ sich wie ein Maedel. From owner-freebsd-current Thu Nov 16 17:15:10 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA27915 for current-outgoing; Thu, 16 Nov 1995 17:15:10 -0800 Received: from moa.cc.monash.edu.au (george@moa.cc.monash.edu.au [130.194.40.50]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA27910 for ; Thu, 16 Nov 1995 17:15:06 -0800 Received: (george@localhost) by moa.cc.monash.edu.au (8.6.10/8.6.4) id MAA02108 for freebsd-current@FreeBSD.org; Fri, 17 Nov 1995 12:13:38 +1100 Date: Fri, 17 Nov 1995 12:13:38 +1100 From: George Scott Message-Id: <199511170113.MAA02108@moa.cc.monash.edu.au> To: freebsd-current@FreeBSD.org Subject: Re: Disk I/O that binds Sender: owner-current@FreeBSD.org Precedence: bulk Julian Elischer wrote: > Last I checked it was a double que elevator sort... > any block requewsted that is behind you gets put in the "next pass" > queue, and anything in front of you get's put in front of you in the > "present pass" queue.. direction of travel never changes.. > (I just checked again, it hasn't changed) > > It's possible that if one process has started reading a large file that was > read onto the disk sequentially, then otehr processes may starve.. > it goes like this: > > process 1 reads block x, and the readahead puts in a request for block x+1 > process 1 reads plock x+1, readahead inserts block x+2 > > etc. > > > as the disk is walking slowely forwards along the disk, any process looking for a block BEFORE x is missing out.. > this should only be a problem for systems where the cpu is fast enough > to deal with the present block and put it's request for the next one in before the disk has completed transfer of the readahead block. > In effect the faster the system, the more problem you're going to have... What would happen if the requests were broken up into cylinders (preferably physical but arbitrary would probably work too) and the new request only added to the "present pass" queue if it's *cylinder* was greater than the cylinder of the request at the head of the queue? In other words, once the drive has started to process a cylinder new requests for that cylinder get added to the "next pass" queue. For the case where many processes are requesting random blocks from all over the disk you probably wouldn't notice much difference from the current algorithm. For the case where there is one process reading a large file from front to back and no other disk activity that process would see no difference; its next request would be added to the front of an empty queue. For the case where there is one process reading a large file from front to back and other processes requesting random blocks from all over the disk the one process would get a steady stream of blocks along with everyone else. The readahead would help but wouldn't be able to monopolise the disk; in the example above when the process reads block x, blocks x and x+1 get added to the "present pass" queue, when it reads x+1 the readahead would add block x+2 to the "next pass" queue. George. --------------------------------------------------------------------- George Scott Senior Systems Programmer Caulfield Computer Centre Email: George.Scott@cc.monash.edu.au Monash University Fax : +61 3 9903 2100 900 Dandenong Road Voice: +61 3 9903 2248 Caulfield East, 3145 Victoria, Australia From owner-freebsd-current Thu Nov 16 18:09:21 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA00931 for current-outgoing; Thu, 16 Nov 1995 18:09:21 -0800 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA00926 for ; Thu, 16 Nov 1995 18:09:12 -0800 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id SAA15221; Thu, 16 Nov 1995 18:09:00 -0800 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id SAA00803; Thu, 16 Nov 1995 18:06:37 -0800 Message-Id: <199511170206.SAA00803@corbin.Root.COM> To: Terry Lambert cc: hwr@pilhuhn.de (Heiko W.Rupp), joerg_wunsch@uriah.heep.sax.de, current@freebsd.org Subject: Re: 2.1-stable bombs at umount In-reply-to: Your message of "Thu, 16 Nov 95 12:51:27 MST." <199511161951.MAA03640@phaeton.artisoft.com> From: David Greenman Reply-To: davidg@Root.COM Date: Thu, 16 Nov 1995 18:06:35 -0800 Sender: owner-current@freebsd.org Precedence: bulk >Let me guess: You are running with quotas on this file system. > > >This seems to be an unforseen side effect of the recent changes to the >way unmounts are done on system shutdown. They are now explicit in >reverse order (per David Greenman's recent posting about the use of >circular queues for the mountlist). 2.1-stable does not have the mountlist circular queue changes. -DG From owner-freebsd-current Fri Nov 17 02:28:03 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA22170 for current-outgoing; Fri, 17 Nov 1995 02:28:03 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id CAA22084 for ; Fri, 17 Nov 1995 02:27:14 -0800 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id LAA23297; Fri, 17 Nov 1995 11:21:34 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id LAA03045; Fri, 17 Nov 1995 11:21:31 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id LAA15492; Fri, 17 Nov 1995 11:17:17 +0100 From: J Wunsch Message-Id: <199511171017.LAA15492@uriah.heep.sax.de> Subject: Re: absolute pathnames in /usr/share/mk/bsd.*.mk To: wosch@cs.tu-berlin.de (Wolfram Schneider) Date: Fri, 17 Nov 1995 11:17:16 +0100 (MET) Cc: asami@cs.berkeley.edu, current@FreeBSD.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199511160956.KAA08085@caramba.cs.tu-berlin.de> from "Wolfram Schneider" at Nov 16, 95 10:56:50 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 913 Sender: owner-current@FreeBSD.org Precedence: bulk As Wolfram Schneider wrote: > > $ egrep /sbin/ *.mk |wc -l > 6 > > $ egrep /sbin/ *.mk > bsd.kmod.mk: /sbin/modload -o ${KMOD} -e${KMOD} ${PROG} > bsd.kmod.mk: /sbin/modunload -n ${KMOD} > bsd.port.mk:MD5?= /sbin/md5 > bsd.port.mk:MTREE_CMD?= /usr/sbin/mtree > bsd.port.mk:PKG_CMD?= /usr/sbin/pkg_create > bsd.port.mk: if /sbin/ldconfig -r | grep -q -e "-l$$lib"; then \ I think the /sbin references in bsd.kmod.mk could go away. mod(un)loading is only allowed for the superuser anyway, who's expected to have /sbin in his $path. The absolute references in bsd.port.mk are okay. I'm not sure about the mtree command, the remaining commands must be executable for regular users, too. -- 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-current Fri Nov 17 03:01:13 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA24627 for current-outgoing; Fri, 17 Nov 1995 03:01:13 -0800 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id DAA24618 for ; Fri, 17 Nov 1995 03:01:05 -0800 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id DAA15733; Fri, 17 Nov 1995 03:01:04 -0800 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id CAA01067; Fri, 17 Nov 1995 02:57:31 -0800 Message-Id: <199511171057.CAA01067@corbin.Root.COM> To: hwr@pilhuhn.de (Heiko W.Rupp) cc: current@freebsd.org Subject: Re: 2.1-stable bombs at umount In-reply-to: Your message of "Wed, 15 Nov 95 16:50:47 +0100." From: David Greenman Reply-To: davidg@Root.COM Date: Fri, 17 Nov 1995 02:57:31 -0800 Sender: owner-current@freebsd.org Precedence: bulk >Hi, > >I had that box under 2.1-stable running and did a >umount -f /news ; mount /news > >the result was: > >| Fatal trap 12: page fault while in kernel mode >| fault virtual address = 0x80 >| fault code = supervisor read, page not present >| instruction pointer = 0x8:0xf0172ee8 >| code segment = base 0x0, limit 0xfffff, type 0x1b >| = DPL 0, pres 1, def32 1, gran 1 >| processor eflags = interrupt enabled, resume, IOPL = 0 >| current process = 7171 (umount) >| interrupt mask = >| panic: page fault > >I know that unmounting a filesystem which is not the best idea ... but >I think this should only lead to errors , not to panics .. I'm not able to reproduce this bug. [implode:davidg] umount -f /mnt umount: /mnt: not currently mounted When was the last time you updated your sources? -DG From owner-freebsd-current Fri Nov 17 03:05:34 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA24881 for current-outgoing; Fri, 17 Nov 1995 03:05:34 -0800 Received: from pilhuhn.de (pilhuhn.de [193.141.89.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id DAA24871 for ; Fri, 17 Nov 1995 03:05:17 -0800 Received: by pilhuhn.de id ; Fri, 17 Nov 95 12:05 MET Message-Id: From: hwr@pilhuhn.de (Heiko W.Rupp) Subject: 2.1-stable just hangs To: current@freebsd.org Date: Fri, 17 Nov 1995 12:02:55 +0100 (MET) X-Mailer: ELM [version 2.4 PL20] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 496 Sender: owner-current@freebsd.org Precedence: bulk Hello, another problem: sometimes (at elast 2 times a weak) a p55tp4xe with p90, 32mb Ram, 2940 , smc elite + just hangs. You can still enter commands on any ttys and ptys but as soon as the command is to be executed, the machine hangs. pressing reset is the only way to get it going again. Any hints on debugging this? -- Heiko W.Rupp Gerwigstr.5 D-76131 Karlsruhe +49 721 9661524 In the window of a Swedish furrier: Fur coats made for ladies from their own skin. From owner-freebsd-current Fri Nov 17 03:14:33 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA25419 for current-outgoing; Fri, 17 Nov 1995 03:14:33 -0800 Received: from pilhuhn.de (pilhuhn.de [193.141.89.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id DAA25370 for ; Fri, 17 Nov 1995 03:12:52 -0800 Received: by pilhuhn.de id ; Fri, 17 Nov 95 12:11 MET Message-Id: From: hwr@pilhuhn.de (Heiko W.Rupp) Subject: Re: 2.1-stable bombs at umount To: davidg@Root.COM Date: Fri, 17 Nov 1995 12:11:41 +0100 (MET) Cc: hwr@pilhuhn.de, current@freebsd.org In-Reply-To: <199511171057.CAA01067@corbin.Root.COM> from "David Greenman" at Nov 17, 95 02:57:31 am X-Mailer: ELM [version 2.4 PL20] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 717 Sender: owner-current@freebsd.org Precedence: bulk David Greenman: | I'm not able to reproduce this bug. | | [implode:davidg] umount -f /mnt | umount: /mnt: not currently mounted I guess I did not clearly enough explain what I did: the filesystem was in use (only reading not writing on it) at that time. I am able to reproduce this and also on NetBSD. I am not sure enough, but I think on SunOS 4.1.x this worked. But either way - I think this should return some ENODIR errors instead of bombing out. | When was the last time you updated your sources? Last monday. Thanks. -- Heiko W.Rupp Gerwigstr.5 D-76131 Karlsruhe +49 721 9661524 In a Bangkok temple: It is forbidden to enter a woman even a foreigner if dressed as a man. From owner-freebsd-current Fri Nov 17 03:46:45 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA27413 for current-outgoing; Fri, 17 Nov 1995 03:46:45 -0800 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id DAA27405 for ; Fri, 17 Nov 1995 03:46:41 -0800 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id DAA00197; Fri, 17 Nov 1995 03:46:39 -0800 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id DAA02309; Fri, 17 Nov 1995 03:43:00 -0800 Message-Id: <199511171143.DAA02309@corbin.Root.COM> To: hwr@pilhuhn.de (Heiko W.Rupp) cc: current@freebsd.org Subject: Re: 2.1-stable just hangs In-reply-to: Your message of "Fri, 17 Nov 95 12:02:55 +0100." From: David Greenman Reply-To: davidg@Root.COM Date: Fri, 17 Nov 1995 03:43:00 -0800 Sender: owner-current@freebsd.org Precedence: bulk >Hello, > >another problem: >sometimes (at elast 2 times a weak) a p55tp4xe with p90, 32mb Ram, >2940 , smc elite + just hangs. >You can still enter commands on any ttys and ptys but as soon as the >command is to be executed, the machine hangs. pressing reset is the >only way to get it going again. >Any hints on debugging this? Are you using NFS? You need to find out what condition things are sleeping on. You can do this by adding DDB to your kernel and then when it happens next, escape to the debugger (by typing cntrl-'print scrn' or cntrl-alt-esc) and then type 'ps'. This will give a list of processes. Then look at the wmesg column. Interpreting this information is difficult and can be misleading, however. There will be one process that starts the problem (and that's the one we need to know about) and a bunch of others which trip over side-effects of this. The wmesg/wchans of those processes are what is misleading. -DG From owner-freebsd-current Fri Nov 17 06:22:51 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA05691 for current-outgoing; Fri, 17 Nov 1995 06:22:51 -0800 Received: from pilhuhn.de (pilhuhn.de [193.141.89.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id GAA05680 for ; Fri, 17 Nov 1995 06:22:41 -0800 Received: by pilhuhn.de id ; Fri, 17 Nov 95 15:20 MET Message-Id: From: hwr@pilhuhn.de (Heiko W.Rupp) Subject: Re: 2.1-stable just hangs To: davidg@Root.COM Date: Fri, 17 Nov 1995 15:20:09 +0100 (MET) Cc: hwr@pilhuhn.de, current@freebsd.org In-Reply-To: <199511171143.DAA02309@corbin.Root.COM> from "David Greenman" at Nov 17, 95 03:43:00 am X-Mailer: ELM [version 2.4 PL20] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 299 Sender: owner-current@freebsd.org Precedence: bulk | Are you using NFS? No. Only local disks. I will add ddb on monday and then look at it. -- Heiko W.Rupp Gerwigstr.5 D-76131 Karlsruhe +49 721 9661524 Usenet is "the closest thing this planet has to a collective consciousness." - Ray Lampman (Ray.Lampman@FullFeed.Com) From owner-freebsd-current Fri Nov 17 08:04:55 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA12409 for current-outgoing; Fri, 17 Nov 1995 08:04:55 -0800 Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA12400 for ; Fri, 17 Nov 1995 08:04:50 -0800 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id JAA12042; Fri, 17 Nov 1995 09:07:03 -0700 Date: Fri, 17 Nov 1995 09:07:03 -0700 From: Nate Williams Message-Id: <199511171607.JAA12042@rocky.sri.MT.net> To: hwr@pilhuhn.de (Heiko W.Rupp) Cc: current@freebsd.org Subject: Re: 2.1-stable just hangs In-Reply-To: References: Sender: owner-current@freebsd.org Precedence: bulk > another problem: > sometimes (at elast 2 times a weak) a p55tp4xe with p90, 32mb Ram, > 2940 , smc elite + just hangs. > You can still enter commands on any ttys and ptys but as soon as the > command is to be executed, the machine hangs. pressing reset is the > only way to get it going again. Are you running with Barracuda drives by chance, or another one of the '7200' rpm drives? Nate From owner-freebsd-current Fri Nov 17 09:31:14 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA17134 for current-outgoing; Fri, 17 Nov 1995 09:31:14 -0800 Received: from haven.uniserve.com (haven.uniserve.com [198.53.215.121]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA17126 for ; Fri, 17 Nov 1995 09:31:04 -0800 Received: by haven.uniserve.com id <30751-2>; Fri, 17 Nov 1995 09:33:19 -0000 Date: Fri, 17 Nov 1995 09:33:15 -0800 (PST) From: Tom Samplonius To: "Heiko W.Rupp" cc: current@freebsd.org Subject: Re: 2.1-stable just hangs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk On Fri, 17 Nov 1995, Heiko W.Rupp wrote: > Hello, > > another problem: > sometimes (at elast 2 times a weak) a p55tp4xe with p90, 32mb Ram, > 2940 , smc elite + just hangs. > You can still enter commands on any ttys and ptys but as soon as the > command is to be executed, the machine hangs. pressing reset is the > only way to get it going again. > Any hints on debugging this? I have seen this before, with same motherboard and SCSI controller. It turned out to be heat related. I just left the cover off the system, and so far it is hasn't happened again. Tom From owner-freebsd-current Fri Nov 17 14:28:38 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA03294 for current-outgoing; Fri, 17 Nov 1995 14:28:38 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA03287 for ; Fri, 17 Nov 1995 14:28:33 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id JAA26103; Sat, 18 Nov 1995 09:26:35 +1100 Date: Sat, 18 Nov 1995 09:26:35 +1100 From: Bruce Evans Message-Id: <199511172226.JAA26103@godzilla.zeta.org.au> To: j@uriah.heep.sax.de, wosch@cs.tu-berlin.de Subject: Re: absolute pathnames in /usr/share/mk/bsd.*.mk Cc: asami@cs.berkeley.edu, current@FreeBSD.org Sender: owner-current@FreeBSD.org Precedence: bulk >I think the /sbin references in bsd.kmod.mk could go away. >mod(un)loading is only allowed for the superuser anyway, who's >expected to have /sbin in his $path. >The absolute references in bsd.port.mk are okay. I'm not sure about >the mtree command, the remaining commands must be executable for >regular users, too. mtree should be in /usr/bin (it's useful for managing your own trees) and absolute paths shouldn't be used except for security. Bruce From owner-freebsd-current Sat Nov 18 02:03:29 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA09180 for current-outgoing; Sat, 18 Nov 1995 02:03:29 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id CAA08884 for ; Sat, 18 Nov 1995 02:01:35 -0800 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id LAA00840 for ; Sat, 18 Nov 1995 11:01:01 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id LAA13256 for freebsd-current@FreeBSD.org; Sat, 18 Nov 1995 11:01:00 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id KAA20453 for freebsd-current@FreeBSD.org; Sat, 18 Nov 1995 10:52:02 +0100 From: J Wunsch Message-Id: <199511180952.KAA20453@uriah.heep.sax.de> Subject: Another panic in umount? To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sat, 18 Nov 1995 10:52:02 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 3297 Sender: owner-current@FreeBSD.org Precedence: bulk ...or simply the same one as reported by Heiko W. Rupp? This happened on sax.sax.de's 2.0.5 system when unmounting a UFS floppy: gdb -k kernel /var/crash/vmcore.2 ... IdlePTD 1e3000 current pcb at 1beb68 panic: page fault #0 boot (arghowto=256) at ../../i386/i386/machdep.c:870 870 dumppcb.pcb_ptd = rcr3(); (kgdb) where #0 boot (arghowto=256) at ../../i386/i386/machdep.c:870 #1 0xf0113653 in panic () #2 0xf01904ae in trap_fatal (frame=0xefbffe7c) at ../../i386/i386/trap.c:688 #3 0xf0190020 in trap_pfault (frame=0xefbffe7c, usermode=0) at ../../i386/i386/trap.c:610 #4 0xf018fce7 in trap (frame={tf_es = -266862576, tf_ds = -272695280, tf_edi = -259957504, tf_esi = -272630076, tf_ebp = -272630068, tf_isp = -272630108, tf_ebx = -247676184, tf_edx = 30, tf_ecx = -258942464, tf_eax = 0, tf_trapno = 12, tf_err = -260308992, tf_eip = -266831023, tf_cs = -266862584, tf_eflags = 66182, tf_esp = -258942464, tf_ss = 0}) at ../../i386/i386/trap.c:290 #5 0xf01892d1 in calltrap () #6 0xf012aab0 in dounmount (mp=0xf090da00, flags=0, p=0xf0806100) at ../../kern/vfs_syscalls.c:286 #7 0xf012aa28 in unmount (p=0xf0806100, uap=0xefbfff94, retval=0xefbfff8c) at ../../kern/vfs_syscalls.c:261 #8 0xf0190697 in syscall (frame={tf_es = -272695257, tf_ds = -266731481, tf_edi = -272640604, tf_esi = 199590, tf_ebp = -272639468, tf_isp = -272629788, tf_ebx = 0, tf_edx = 1, tf_ecx = 188474, tf_eax = 22, tf_trapno = 582, tf_err = 582, tf_eip = 14981, tf_cs = 31, tf_eflags = 582, tf_esp = -272640656, tf_ss = 39}) at ../../i386/i386/trap.c:828 #9 0xf018931b in Xsyscall () #10 0x1863 in ?? () #11 0x10e8 in ?? () (kgdb) up 4 #4 0xf018fce7 in trap (frame={tf_es = -266862576, tf_ds = -272695280, tf_edi = -259957504, tf_esi = -272630076, tf_ebp = -272630068, tf_isp = -272630108, tf_ebx = -247676184, tf_edx = 30, tf_ecx = -258942464, tf_eax = 0, tf_trapno = 12, tf_err = -260308992, tf_eip = -266831023, tf_cs = -266862584, tf_eflags = 66182, tf_esp = -258942464, tf_ss = 0}) at ../../i386/i386/trap.c:290 290 (void) trap_pfault(&frame, FALSE); (kgdb) frame frame.tf_ebp frame.tf_eip #0 0xf0187b51 in vnode_pager_umount (mp=0xf090da00) at ../../vm/vnode_pager.c:406 406 vp = ((vn_pager_t) pager->pg_data)->vnp_vp; (kgdb) list 401 /* 402 * Save the next pointer now since uncaching may terminate the 403 * object and render pager invalid 404 */ 405 npager = pager->pg_list.tqe_next; 406 vp = ((vn_pager_t) pager->pg_data)->vnp_vp; 407 if (mp == (struct mount *) 0 || vp->v_mount == mp) { 408 VOP_LOCK(vp); 409 (void) vnode_pager_uncache(vp); 410 VOP_UNLOCK(vp); (kgdb) p pager $1 = (struct pager_struct *) 0x0 Is this a known problem, or shall i investigate more? The core file is still lying around 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-current Sat Nov 18 03:25:29 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA15295 for current-outgoing; Sat, 18 Nov 1995 03:25:29 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id DAA15287 for ; Sat, 18 Nov 1995 03:25:16 -0800 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id MAA02412 for ; Sat, 18 Nov 1995 12:24:40 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id MAA14167 for current@FreeBSD.ORG; Sat, 18 Nov 1995 12:24:40 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id LAA20677 for current@FreeBSD.ORG; Sat, 18 Nov 1995 11:35:38 +0100 From: J Wunsch Message-Id: <199511181035.LAA20677@uriah.heep.sax.de> Subject: Re: absolute pathnames in /usr/share/mk/bsd.*.mk To: current@FreeBSD.ORG Date: Sat, 18 Nov 1995 11:35:37 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199511172226.JAA26103@godzilla.zeta.org.au> from "Bruce Evans" at Nov 18, 95 09:26:35 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 516 Sender: owner-current@FreeBSD.ORG Precedence: bulk As Bruce Evans wrote: > > mtree should be in /usr/bin (it's useful for managing your own trees) "system program, runnable by users" :-) > and absolute paths shouldn't be used except for security. That's somewhat impractical for ports. The absolute path names are a compromise (resulting from experience, they haven't been there in the first place). -- 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-current Sat Nov 18 05:40:28 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA24523 for current-outgoing; Sat, 18 Nov 1995 05:40:28 -0800 Received: from hauki.clinet.fi (root@hauki.clinet.fi [194.100.0.1]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA24506 for ; Sat, 18 Nov 1995 05:40:18 -0800 Received: from katiska.clinet.fi (root@katiska.clinet.fi [194.100.0.4]) by hauki.clinet.fi (8.6.12/8.6.4) with ESMTP id PAA24835 for ; Sat, 18 Nov 1995 15:40:03 +0200 Received: (news@localhost) by katiska.clinet.fi (8.6.12/8.6.4) id PAA23086; Sat, 18 Nov 1995 15:40:12 +0200 To: clinet-list-freebsd-current@clinet.fi Path: cs.hut.fi!hsu From: hsu@cs.hut.fi (Heikki Suonsivu) Newsgroups: clinet.list.freebsd-current Subject: Re: 2.1-stable just hangs Date: 18 Nov 1995 13:40:05 GMT Organization: Helsinki University of Technology, Finland Lines: 29 Message-ID: References: NNTP-Posting-Host: shadows.cs.hut.fi In-reply-to: Tom Samplonius's message of 17 Nov 1995 20:14:09 +0200 Sender: owner-current@FreeBSD.ORG Precedence: bulk In article Tom Samplonius writes: > sometimes (at elast 2 times a weak) a p55tp4xe with p90, 32mb Ram, > 2940 , smc elite + just hangs. ASUS SIS chipset based board + p90 + 64mB + 2 * NCR SCSI + probably smc isa ethernet board. Around same frequency, but we also get disk errors sometimes (seagate hawks currently). > You can still enter commands on any ttys and ptys but as soon as the > command is to be executed, the machine hangs. pressing reset is the > only way to get it going again. > Any hints on debugging this? I have seen this before, with same motherboard and SCSI controller. It turned out to be heat related. I just left the cover off the system, and so far it is hasn't happened again. The cause may be overheated disks getting looped, but there still is a bug in kernel if the situation is not detected (it should do *something*, even reboot would be better than getting hung). I also saw this after a nfs server (FreeBSD 1.1.5.1) got its nfsd processes killed somehow (out of swap, maybe), the -current machine deadlocked like above after printing couple of nfs errors. -- Heikki Suonsivu, T{ysikuu 10 C 83/02210 Espoo/FINLAND, hsu@cs.hut.fi home +358-0-8031121 work -4513377 fax -4555276 riippu SN From owner-freebsd-current Sat Nov 18 14:18:36 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA21232 for current-outgoing; Sat, 18 Nov 1995 14:18:36 -0800 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id OAA21226 for ; Sat, 18 Nov 1995 14:18:30 -0800 Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA32059; Sat, 18 Nov 1995 17:18:12 -0500 Date: Sat, 18 Nov 1995 17:18:12 -0500 From: "Garrett A. Wollman" Message-Id: <9511182218.AA32059@halloran-eldar.lcs.mit.edu> To: Peter Wemm Cc: current@freebsd.org Subject: Re: cvs commit: src/sys/pci if_de.c In-Reply-To: References: <199511172220.JAA25889@godzilla.zeta.org.au> Sender: owner-current@freebsd.org Precedence: bulk < said: > I think if we're going to distribute "patches", then we can't go past CTM > for safety. You can guarantee that it will apply in it's entireity or > not at all... Unfortunately, this highlights a fundamental brokenness of CTM for distributing this sort of material: if the user has changed the file, the delta won't apply, even if the patch is to a different part of the file and therefore applies cleanly. Not Good. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-current Sat Nov 18 16:27:28 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA27977 for current-outgoing; Sat, 18 Nov 1995 16:27:28 -0800 Received: from apollo.COSC.GOV (root@apollo.COSC.GOV [198.94.103.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA27971 for ; Sat, 18 Nov 1995 16:27:25 -0800 Received: (from vince@localhost) by apollo.COSC.GOV (8.6.12/8.6.9) id QAA04736; Sat, 18 Nov 1995 16:23:43 -0800 Date: Sat, 18 Nov 1995 16:23:40 -0800 (PST) From: -Vince- To: current@FreeBSD.ORG Subject: schg flag on make world in -CURRENT Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG Precedence: bulk Hi everyone, Is there anyway to remotely login to a FreeBSD box and 'su' to root to do a make world without having to do noflags schg on all the files with that flag on it generated by the last make world in -CURRENT? Thanks! Cheers, -Vince- vince@COSC.GOV - GUS Mailing Lists Admin UC Berkeley AstroPhysics - Electrical Engineering (Honorary B.S.) Chabot Observatory & Science Center - Board of Advisors Running FreeBSD - Real UN*X for Free! Linda Wong/Vivian Chow/Hacken Lee/Danny Chan Fan Club Mailiing Lists Admin From owner-freebsd-current Sat Nov 18 16:33:45 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA28475 for current-outgoing; Sat, 18 Nov 1995 16:33:45 -0800 Received: from hub.org (root@hub.org [199.166.238.138]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA28456 ; Sat, 18 Nov 1995 16:33:20 -0800 Received: (from scrappy@localhost) by hub.org (8.7.1/8.7.1) id TAA06422; Sat, 18 Nov 1995 19:33:06 -0500 (EST) Date: Sat, 18 Nov 1995 19:32:59 -0500 (EST) From: "Marc G. Fournier" To: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Question (or complaint) about sup Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk Hi... Someone just told me about what sup is all about, and how to use it, and whatnot...but it seems that some parts rely on other parts, some of which I'd rather not make use of... I know, kinda vague. For example, /usr/src/lib/libncurses is 1.8.6...from 1994. I'm on the ncurses mailing list, and the ncurses I have on the system right now is 1.9.8 (1.9.7a + a bunch of patches). I dont' want to do a 'make world' and have my ncurses replaced... ...similar with sendmail and any other software that I've already got newer versions of installed... I don't assume that make world is smart enough to know the difference in version numbers, or anything like that, so assume that it will wipe out all I've brought over in favor of what it thinks is the "new stuff"? Marc G. Fournier | Knowledge, Information and Communications, Inc (ki.net) scrappy@hub.org | soon to be: | scrappy@ki.net | For more information, send me email. From owner-freebsd-current Sat Nov 18 16:45:42 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA29445 for current-outgoing; Sat, 18 Nov 1995 16:45:42 -0800 Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA29439 for ; Sat, 18 Nov 1995 16:45:37 -0800 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id RAA15180; Sat, 18 Nov 1995 17:47:57 -0700 Date: Sat, 18 Nov 1995 17:47:57 -0700 From: Nate Williams Message-Id: <199511190047.RAA15180@rocky.sri.MT.net> To: "Garrett A. Wollman" Cc: Peter Wemm , current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/pci if_de.c In-Reply-To: <9511182218.AA32059@halloran-eldar.lcs.mit.edu> References: <199511172220.JAA25889@godzilla.zeta.org.au> <9511182218.AA32059@halloran-eldar.lcs.mit.edu> Sender: owner-current@FreeBSD.ORG Precedence: bulk > > I think if we're going to distribute "patches", then we can't go past CTM > > for safety. You can guarantee that it will apply in it's entireity or > > not at all... > > Unfortunately, this highlights a fundamental brokenness of CTM for > distributing this sort of material: if the user has changed the file, > the delta won't apply, even if the patch is to a different part of the > file and therefore applies cleanly. Not Good. While I'm not arguing that CTM *is* the best solution, after a very long and thoughtful Jordan had a *LONG* time ago (patchkit days), I don't think it's possible to build a 'simple' system which can get around the above problem. The amount of complexity required to build a system which can detect problems such as this is beyond the scope of this project, IMHO. (But, someone feel free to prove me wrong. *grin*) Basically, I think anyone capable of modifying their own local sources are capable of hand applying patches, in either CTM deltas or diff form. Nate From owner-freebsd-current Sat Nov 18 18:01:56 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA02743 for current-outgoing; Sat, 18 Nov 1995 18:01:56 -0800 Received: from jhome.DIALix.COM (root@jhome.DIALix.COM [192.203.228.69]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA02736 for ; Sat, 18 Nov 1995 18:01:46 -0800 Received: (from peter@localhost) by jhome.DIALix.COM (8.6.12/8.6.9) id KAA20962; Sun, 19 Nov 1995 10:01:40 +0800 Date: Sun, 19 Nov 1995 10:01:40 +0800 (WST) From: Peter Wemm To: current@freebsd.org Subject: nvi 1.49 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk We currently have nvi version 1.34 in the freebsd source. It has a most annoying bug (well, it annoys the hell out of me anyway.. :-). Specifically, if you have a line longer than 80 characters, and move to say the 90th character, and then leave the line and immediately return, the sticky positioning will incorrectly put you on the 10th character instead of the 90th. :-( What can I say.. I'm easily annoyed... :-) I would like to import nvi-1.49, which does not have this bug anymore. I've built it on my machine and it compiles and runs without difficulty so far.. -Peter From owner-freebsd-current Sat Nov 18 18:39:38 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA05642 for current-outgoing; Sat, 18 Nov 1995 18:39:38 -0800 Received: from irbs.irbs.com (irbs.com [199.182.75.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA05636 for ; Sat, 18 Nov 1995 18:39:31 -0800 Received: (from jc@localhost) by irbs.irbs.com (8.6.12/8.6.6) id VAA26591; Sat, 18 Nov 1995 21:37:43 -0500 From: John Capo Message-Id: <199511190237.VAA26591@irbs.irbs.com> Subject: Re: nvi 1.49 To: peter@jhome.DIALix.COM (Peter Wemm) Date: Sat, 18 Nov 1995 21:37:43 -0500 (EST) Cc: current@freebsd.org In-Reply-To: from "Peter Wemm" at Nov 19, 95 10:01:40 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 546 Sender: owner-current@freebsd.org Precedence: bulk Peter Wemm writes: > > I would like to import nvi-1.49, which does not have this bug anymore. > I've built it on my machine and it compiles and runs without difficulty > so far.. > I've been running nvi-1.49 on all of my machines since its release. It fixes a number of bugs in 1.34 but I can't remember what they are. :-( John Capo jc@irbs.com IRBS Engineering High performance FreeBSD systems (305) 792-9551 Unix/Internet Consulting - ISP Solutions From owner-freebsd-current Sat Nov 18 20:05:25 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA10147 for current-outgoing; Sat, 18 Nov 1995 20:05:25 -0800 Received: from jhome.DIALix.COM (root@jhome.DIALix.COM [192.203.228.69]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA10139 for ; Sat, 18 Nov 1995 20:05:17 -0800 Received: (from peter@localhost) by jhome.DIALix.COM (8.6.12/8.6.9) id MAA21340; Sun, 19 Nov 1995 12:04:15 +0800 Date: Sun, 19 Nov 1995 12:04:15 +0800 (WST) From: Peter Wemm To: "Garrett A. Wollman" cc: current@freebsd.org Subject: Re: cvs commit: src/sys/pci if_de.c In-Reply-To: <9511182218.AA32059@halloran-eldar.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk On Sat, 18 Nov 1995, Garrett A. Wollman wrote: > < said: > > > I think if we're going to distribute "patches", then we can't go past CTM > > for safety. You can guarantee that it will apply in it's entireity or > > not at all... > > Unfortunately, this highlights a fundamental brokenness of CTM for > distributing this sort of material: if the user has changed the file, > the delta won't apply, even if the patch is to a different part of the > file and therefore applies cleanly. Not Good. Yep. I think this would be the killer issue that could prevent us from goin that route. 1: CTM uses md5 checksums and complains loudly about them.. From memory you can "force" them though. 2: CTM uses ed-style deltas, not context diffs, meaning that if you force the delta to be applied, you'll most likely loose. 3: It's harder to manually apply the diffs... 4: It takes a large amount of disk space and cpu work to generate the deltas. (lack of disk space is the reason we're not doing -stable via ctm at the moment from memory). I doubt that these are unsolvable.. I dont see why mkCTM couldn't be changed to generate context diffs, or 'ctm' couldn't be changed to use 'patch' instead of 'ed' to apply them etc. I think we have two seperate needs here.. 1: We need (I think) a CTM of -stable when we get disk space so that we can have people keeping up to date automatically. We really need example configs for how to setup email aliases, scripts, etc etc. We *dont* want 10,000 people supping -stable... :-( 2: We need small, feature based patches. I doubt CTM would be the ideal tool for that, because that prevents people from making local changes without fear of being unable to use patches. I feel this implies an organised context diff wrapped in a shell script which checks checksums (and warns if they are wrong and asking if the user wants to attempt to proceed anyway) babysit's 'patch', does backups of the file, rolls back out of a failed patch, perhaps offers to recompile and reinstall the changed code if it's appropriate, or offers to recompile the GENERIC kernel if that's what they are using and so on. Easy, eh? :-) I most definately do not have the energy to do this, so I'm not volunteering.. I could help somebody else do it though. Cheers, -Peter > -GAWollman > > -- > Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... > wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. > Opinions not those of| It is a bond more powerful than absence. We like people > MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant > From owner-freebsd-current Sat Nov 18 20:22:45 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA10808 for current-outgoing; Sat, 18 Nov 1995 20:22:45 -0800 Received: from jhome.DIALix.COM (root@jhome.DIALix.COM [192.203.228.69]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA10788 for ; Sat, 18 Nov 1995 20:21:59 -0800 Received: (from peter@localhost) by jhome.DIALix.COM (8.6.12/8.6.9) id MAA21397; Sun, 19 Nov 1995 12:21:34 +0800 Date: Sun, 19 Nov 1995 12:21:34 +0800 (WST) From: Peter Wemm To: current@freebsd.org Subject: rlogind wont allow root without password... rshd will. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk I think this is a bug.. As root: I can do "rsh freebsdmachine sh -i" and get a root shell. I cannot do a "rlogin freebsdmachine" - it asks for a password. I think this is a futile attempt at "security-through-inconvenience" (worse than the infamous security-through-obscurity) as it achieves nothing but force people to use the non-wtmp-logged facility. rlogind (as in 4.4BSD) has a test for UID==0 to disable the .rhosts check, forcing the root password to go over the net in the clear. This IMHO is a bigger risk than the existing vouch-safe security. If a site is deliberatly allowing root to have a .rhosts file then they should be allowed to shoot their own foot if they haven't made enough safeguards. Note that FreeBSD has a random number mixed into the tcp iss variable, which makes IP spoofing at least several orders of magnitude harder to do. Having somebody sniff the root password is a far bigger risk than a successful IP spoofing attack. I'd like to take the test out... Have I forgotten something? Objections? (Yes, I know about ssh... :-) -Peter From owner-freebsd-current Sat Nov 18 20:23:38 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA10836 for current-outgoing; Sat, 18 Nov 1995 20:23:38 -0800 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA10831 for ; Sat, 18 Nov 1995 20:23:33 -0800 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id UAA00786; Sat, 18 Nov 1995 20:23:03 -0800 To: Peter Wemm cc: "Garrett A. Wollman" , current@freebsd.org Subject: Re: cvs commit: src/sys/pci if_de.c In-reply-to: Your message of "Sun, 19 Nov 1995 12:04:15 +0800." Date: Sat, 18 Nov 1995 20:23:03 -0800 Message-ID: <784.816754983@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org Precedence: bulk > without fear of being unable to use patches. I feel this implies an > organised context diff wrapped in a shell script which checks checksums > (and warns if they are wrong and asking if the user wants to attempt to > proceed anyway) babysit's 'patch', does backups of the file, rolls back Actually, pkg_add pretty much has the ability to do all of this now. I am working on a "patch creator" which automates the generation of the packages. Jordan From owner-freebsd-current Sat Nov 18 20:56:40 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA12426 for current-outgoing; Sat, 18 Nov 1995 20:56:40 -0800 Received: from asstdc.scgt.oz.au (root@asstdc.scgt.oz.au [202.14.234.65]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA12421 for ; Sat, 18 Nov 1995 20:56:28 -0800 Received: (from imb@localhost) by asstdc.scgt.oz.au (8.6.12/BSD-4.4) id PAA08080 for current@freebsd.org; Sun, 19 Nov 1995 15:56:17 +1100 From: michael butler Message-Id: <199511190456.PAA08080@asstdc.scgt.oz.au> Subject: joe, termcap and flow-control ? To: current@freebsd.org Date: Sun, 19 Nov 1995 15:56:16 +1100 (EST) In-Reply-To: from "Peter Wemm" at Nov 19, 95 10:01:40 am X-Mailer: ELM [version 2.4 PL24beta] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 741 Sender: owner-current@freebsd.org Precedence: bulk Peter Wemm writes: > We currently have nvi version 1.34 in the freebsd source. It has a most > annoying bug (well, it annoys the hell out of me anyway.. :-). > Specifically, if you have a line longer than 80 characters, and move to > say the 90th character, and then leave the line and immediately return, > the sticky positioning will incorrectly put you on the 10th character > instead of the 90th. :-( Speaking of which .. joe works fine locally but it does not over a telnet session .. the first screen displayed is offset by one character to the right. The whole screen :-( The only fix is to use control-R to redraw, after which it's fine. What is this .. a bug in joe, a termcap problem or a flow-control issue ? michael