From owner-freebsd-stable Sun Nov 3 10:53:18 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA14913 for stable-outgoing; Sun, 3 Nov 1996 10:53:18 -0800 (PST) Received: from ms1.hinet.net (root@ms1.hinet.net [168.95.4.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA14905 for ; Sun, 3 Nov 1996 10:53:12 -0800 (PST) Received: from ejun ([168.95.246.175]) by ms1.hinet.net (8.7.5/8.7.5) with SMTP id CAA27282 for ; Mon, 4 Nov 1996 02:49:56 +0800 (CST) Message-Id: <1.5.4.32.19961103185401.00662edc@ms1.hinet.net> X-Sender: ejun@ms1.hinet.net X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 04 Nov 1996 02:54:01 +0800 To: freebsd-stable@FreeBSD.ORG From: ejun Sender: owner-stable@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk subscribe freebsd-stable From owner-freebsd-stable Sun Nov 3 13:47:41 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA28476 for stable-outgoing; Sun, 3 Nov 1996 13:47:41 -0800 (PST) Received: from Rigel.orionsys.com (root@rigel.orionsys.com [205.148.224.9]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA28460; Sun, 3 Nov 1996 13:47:36 -0800 (PST) Received: from localhost (dbabler@localhost) by Rigel.orionsys.com (8.7.6/8.6.9) with SMTP id NAA00702; Sun, 3 Nov 1996 13:47:28 -0800 (PST) Date: Sun, 3 Nov 1996 13:47:27 -0800 (PST) From: Dave Babler To: questions@freebsd.org cc: freebsd-stable@freebsd.org Subject: Kernel tty problem Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've posed this problem a couple of times before and I'm really hoping that the third time is the charm because I'm pretty much out of ideas. I'm running 2.1.5-STABLE here; originally made from the CD-ROM sources. I'm using CTM, subscribed to the -STABLE branch. Everything was running just fine until I decided to recompile the kernel to add ipfw. After compiling the new kernel, I found that the interpretation of ansi was seriously confused. Thinking I might have had a library out of sync or some other oddity caused by CTM, I did a complete 'make world'. The new kernel was still incorrect, the old kernel still ran fine. What I get is that a large number of programs suddenly no longer understand control keys. Pico, for instance, won't intrepret a control-X as a control - it simply displays "^X" on the screen. Same for arrow keys. Console switching with Alt+1..Alt+n still works, and command line editing also works correctly with the new kernel - but virtually no application that uses control keys does. This is all using cons25. I did a 'tset -s' with the kernel that doesn't work and the one that does and they're identical, so I've more or less ruled out termcap.db problems. Starting a session from a telnet connection results in a refusal from pico to run because the terminal "isn't a terminal device". Again, it works fine with the old kernel. I've also rebuilt the kernel with exactly the same configuration as the kernel that works... and it still behaves the same (e.g. doesn't work). The remaining noticable oddity is that when you log in from the console (any ptty), your login name is repeated prior to the password prompt: login: bozo bozo password: I'm out of ideas here, and I'm hoping somebody can point me in a new direction. Would I be better off changing over to the -CURRENT branch, and if so, how can I do that? (Wipe off all the changes back to the CD sources and apply all the CTM -CURRENT changes?) Is anybody aware of any source changes that would have mangled this? Should I be posing this problem to a different list? Thanks in advance... -Dave From owner-freebsd-stable Sun Nov 3 14:52:08 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA06169 for stable-outgoing; Sun, 3 Nov 1996 14:52:08 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA06100; Sun, 3 Nov 1996 14:52:03 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.6/8.6.9) with ESMTP id OAA07210; Sun, 3 Nov 1996 14:51:12 -0800 (PST) To: Dave Babler cc: questions@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: Kernel tty problem In-reply-to: Your message of "Sun, 03 Nov 1996 13:47:27 PST." Date: Sun, 03 Nov 1996 14:51:12 -0800 Message-ID: <7208.847061472@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-stable@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > I'm running 2.1.5-STABLE here; originally made from the CD-ROM sources. > I'm using CTM, subscribed to the -STABLE branch. Everything was running > just fine until I decided to recompile the kernel to add ipfw. After You have to have spammed something in your kernel config file, there's no other practical explanation. Start again with the GENERIC file. If it works, carefully turn it into something more closely approximating your file, one line at a time, until it stops working. Done, you know now that the line you just removed should have stayed. :-) If GENERIC doesn't work then talk to us again because you've found a real problem. Jordan From owner-freebsd-stable Sun Nov 3 18:44:29 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA00439 for stable-outgoing; Sun, 3 Nov 1996 18:44:29 -0800 (PST) Received: from Rigel.orionsys.com (root@rigel.orionsys.com [205.148.224.9]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA00415; Sun, 3 Nov 1996 18:44:21 -0800 (PST) Received: from localhost (dbabler@localhost) by Rigel.orionsys.com (8.7.6/8.6.9) with SMTP id SAA00256; Sun, 3 Nov 1996 18:44:12 -0800 (PST) Date: Sun, 3 Nov 1996 18:44:12 -0800 (PST) From: Dave Babler To: "Jordan K. Hubbard" cc: questions@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: Kernel tty problem In-Reply-To: <7208.847061472@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-stable@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 3 Nov 1996, Jordan K. Hubbard wrote: > > I'm running 2.1.5-STABLE here; originally made from the CD-ROM sources. > > I'm using CTM, subscribed to the -STABLE branch. Everything was running > > just fine until I decided to recompile the kernel to add ipfw. After > > You have to have spammed something in your kernel config file, there's > no other practical explanation. > > Start again with the GENERIC file. If it works, carefully turn it > into something more closely approximating your file, one line at a > time, until it stops working. Done, you know now that the line you > just removed should have stayed. :-) > > If GENERIC doesn't work then talk to us again because you've found a > real problem. > Thank you for getting back to me. I started over with GENERIC and recreated my custom kernel config file... with one minor exception: my previous version, I'd been paring down things I didn't think I needed and optimizing. One of the options I took out was COMPAT_43. The new version from scratch includes it and it all works. I was under the impression that COMPAT_43 was only required for *some* older programs... apparently that was what was breaking quite a few of them, however. I suppose it could also be some of the things added to GENERIC since the 2.1.5 release, but at this point, COMPAT_43 seems to be the culprit. -Dave From owner-freebsd-stable Sun Nov 3 19:01:26 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA01554 for stable-outgoing; Sun, 3 Nov 1996 19:01:26 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA01549; Sun, 3 Nov 1996 19:01:22 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.6/8.6.9) with ESMTP id TAA09147; Sun, 3 Nov 1996 19:01:18 -0800 (PST) To: Dave Babler cc: questions@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: Kernel tty problem In-reply-to: Your message of "Sun, 03 Nov 1996 18:44:12 PST." Date: Sun, 03 Nov 1996 19:01:18 -0800 Message-ID: <9145.847076478@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-stable@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > previous version, I'd been paring down things I didn't think I needed and > optimizing. One of the options I took out was COMPAT_43. The new version >From /sys/i386/conf/LINT, which you probably should really become familiar with before hacking on your kernel config again: ##################################################################### # COMPATIBILITY OPTIONS # # Implement system calls compatible with 4.3BSD and older versions of # FreeBSD. You probably do NOT want to remove this as much current code # still relies on the 4.3 emulation. # options "COMPAT_43" From owner-freebsd-stable Tue Nov 5 04:50:15 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA00462 for stable-outgoing; Tue, 5 Nov 1996 04:50:15 -0800 (PST) Received: from NS.Contrib.Com (NS.Contrib.Com [194.77.12.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id EAA00455 for ; Tue, 5 Nov 1996 04:50:08 -0800 (PST) Received: (from src@localhost) by NS.Contrib.Com (8.6.9/8.6.9) id NAA11668; Tue, 5 Nov 1996 13:50:01 +0100 Date: Tue, 5 Nov 1996 13:50:01 +0100 From: Heiko Blume Message-Id: <199611051250.NAA11668@NS.Contrib.Com> To: stable@freebsd.org Subject: innd can't malloc - why? Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk hello maybe i'm a little ignorant, but my innd lately vanishes very often our of the blue (i.e. not during expire) telling me Nov 5 07:52:15 news innd: ME cant remalloc 8392960 bytes Cannot allocate memory i recently upgraded the machine to 128MB RAM (yes, i have the 'options "MAXMEM=131072"' in the kernel) and 300MB swap, which should be enough! for the life of me i can't see why it should fall short of memory. here's some data: {1027} news@news /var/log/news : uname -a FreeBSD news 2.1-STABLE FreeBSD 2.1-STABLE #0: Wed Oct 30 12:58:25 MET 1996 root@news:/usr/src/sys/compile/CONTRIB i386 {1025} news@news /var/log/news : swapinfo Device 1K-blocks Used Avail Capacity Type /dev/sd0s1b 131072 0 131008 0% Interleaved /dev/sd5b 204800 0 204736 0% Interleaved Total 335744 0 335744 0% before the upgrade swap was always used to some degree, i am a little suspicious to see 0% here all the time,... load averages: 0.61, 0.28, 0.25 13:29:25 63 processes: 2 running, 60 sleeping, 1 zombie Cpu states: 1.2% user, 41.6% nice, 54.5% system, 2.7% interrupt, 0.0% idle Memory: 84M Act 2280K Inact 12M Wired 272K Free PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 7410 news 88 4 2128K 2384K run 0:19 42.80% 42.57% in.nnrpd 23038 news -6 4 65M 47M sleep 11:15 6.90% 6.90% innd 7545 news 28 0 468K 892K run 0:00 1.04% 0.34% top 7393 news 2 0 688K 964K sleep 0:00 0.19% 0.19% innxmit 1968 news 2 0 688K 1052K sleep 0:16 0.08% 0.08% innxmit 27400 root 2 0 504K 940K sleep 0:19 0.00% 0.00% top 4706 root 18 0 1052K 1456K sleep 0:03 0.00% 0.00% tcsh 18959 src 18 0 1004K 1400K sleep 0:01 0.00% 0.00% tcsh 22932 news 18 0 976K 1368K sleep 0:01 0.00% 0.00% tcsh 5013 news 18 0 980K 1364K sleep 0:01 0.00% 0.00% tcsh 4986 root 18 0 772K 1168K sleep 0:01 0.00% 0.00% tcsh 4862 root 18 0 668K 1056K sleep 0:01 0.00% 0.00% tcsh 26980 root 18 0 676K 1040K sleep 0:00 0.00% 0.00% tcsh 26979 root 18 0 460K 304K sleep 0:00 0.00% 0.00% csh 107 root 18 0 280K 260K sleep 0:11 0.00% 0.00% cron help! hb From owner-freebsd-stable Tue Nov 5 08:58:04 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA10039 for stable-outgoing; Tue, 5 Nov 1996 08:58:04 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA10034 for ; Tue, 5 Nov 1996 08:58:00 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.7.6/8.7.3) with ESMTP id IAA03067; Tue, 5 Nov 1996 08:57:50 -0800 (PST) Message-Id: <199611051657.IAA03067@austin.polstra.com> To: src@NS.Contrib.Com Subject: Re: innd can't malloc - why? Newsgroups: polstra.freebsd.stable In-Reply-To: <199611051250.NAA11668@NS.Contrib.Com> References: <199611051250.NAA11668@NS.Contrib.Com> Organization: Polstra & Co., Seattle, WA Cc: stable@freebsd.org Date: Tue, 05 Nov 1996 08:57:50 -0800 From: John Polstra Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199611051250.NAA11668@NS.Contrib.Com> src@NS.Contrib.Com write: > maybe i'm a little ignorant, but my innd lately vanishes very often > our of the blue (i.e. not during expire) telling me > > Nov 5 07:52:15 news innd: ME cant remalloc 8392960 bytes Cannot allocate memory > > i recently upgraded the machine to 128MB RAM (yes, i have the > 'options "MAXMEM=131072"' in the kernel) and 300MB swap, > which should be enough! Check your "ulimit" values, and make sure that they're not too low. From sh or bash, type "ulimit -a". From csh, type "limit". Obviously, you have to do this in the same context your innd process is started in. You can increase these limits from "/etc/profile" or ".profile" in the home directory (for sh). See your shell's manual page for details. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-stable Tue Nov 5 09:08:56 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA10797 for stable-outgoing; Tue, 5 Nov 1996 09:08:56 -0800 (PST) Received: from mercury.uniserve.com (mercury.uniserve.com [204.191.197.248]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA10792 for ; Tue, 5 Nov 1996 09:08:52 -0800 (PST) Received: from haven.uniserve.com (haven.uniserve.com [198.53.215.121]) by mercury.uniserve.com (8.8.2/8.8.2) with SMTP id JAA18646; Tue, 5 Nov 1996 09:04:58 -0800 (PST) Date: Tue, 5 Nov 1996 09:11:42 -0800 (PST) From: Tom Samplonius To: Heiko Blume cc: stable@freebsd.org Subject: Re: innd can't malloc - why? In-Reply-To: <199611051250.NAA11668@NS.Contrib.Com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 5 Nov 1996, Heiko Blume wrote: > hello > > maybe i'm a little ignorant, but my innd lately vanishes very often > our of the blue (i.e. not during expire) telling me > > Nov 5 07:52:15 news innd: ME cant remalloc 8392960 bytes Cannot allocate memory Use the "unlimit" csh command to remove the per-process datasize limit. Tom From owner-freebsd-stable Wed Nov 6 00:52:07 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA02560 for stable-outgoing; Wed, 6 Nov 1996 00:52:07 -0800 (PST) Received: from birdland.rhein-neckar.de (root@birdland.rhein-neckar.de [193.197.88.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA02342 for ; Wed, 6 Nov 1996 00:50:07 -0800 (PST) Received: from localhost (bsd@localhost) by birdland.rhein-neckar.de (8.7.5/8.7.3) with SMTP id JAA09556; Wed, 6 Nov 1996 09:45:38 +0100 (MET) Date: Wed, 6 Nov 1996 09:45:37 +0100 (MET) From: BSD Mailinglisten-User To: Heiko Blume cc: stable@FreeBSD.org Subject: Re: innd can't malloc - why? In-Reply-To: <199611051250.NAA11668@NS.Contrib.Com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-stable@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 5 Nov 1996, Heiko Blume wrote: > hello > > maybe i'm a little ignorant, but my innd lately vanishes very often > our of the blue (i.e. not during expire) telling me > > Nov 5 07:52:15 news innd: ME cant remalloc 8392960 bytes Cannot allocate memory [...] > for the life of me i can't see why it should fall short of memory. > here's some data: [...] > 23038 news -6 4 65M 47M sleep 11:15 6.90% 6.90% innd ^^^ this is your problem There are several hard coded kernel parameters about the maximum sizes of processes. I had the same problem, but after a little searching in the mailinglist archives in www.freebsd.org (you didn't do that, didn't you???) I found out that changing the following parameters in /usr/src/sys/i386/include/vmparam.h did the trick for me: DFLDSIZE to 128M and MAXSSIZE to 128M Both are 64M in the default config. YMMV, Martin | Martin Jangowski E-Mail: maja@birdland.rhein-neckar.de | | Voice: +49 621/53 95 06 Fax: +49 621/53 95 07 | | Snail Mail: Koenigsbacher Str. 16 D-67067 Ludwigshafen Germany | | RNInet e.V. Rhein-Neckar Internet | From owner-freebsd-stable Wed Nov 6 06:42:46 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA22402 for stable-outgoing; Wed, 6 Nov 1996 06:42:46 -0800 (PST) Received: from house.multinet.net (house.multinet.net [204.138.173.37]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id GAA22396 for ; Wed, 6 Nov 1996 06:42:37 -0800 (PST) Received: from gabber.multinet.net (gabber.multinet.net [204.138.173.45]) by house.multinet.net (8.6.12/8.6.12) with SMTP id JAA23733 for ; Wed, 6 Nov 1996 09:42:27 -0500 Message-ID: <3280A3D2.3F54BC7E@multinet.net> Date: Wed, 06 Nov 1996 09:42:26 -0500 From: graydon hoare X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.1.0-RELEASE i386) MIME-Version: 1.0 To: freebsd-stable@FreeBSD.ORG Subject: (no subject) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-stable@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk subscribe admin@multinet.net From owner-freebsd-stable Thu Nov 7 14:47:40 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA24170 for stable-outgoing; Thu, 7 Nov 1996 14:47:40 -0800 (PST) Received: from nic.dataphone.se (root@nic.dataphone.se [194.23.92.66]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA24004 for ; Thu, 7 Nov 1996 14:47:11 -0800 (PST) Received: from nicole.dataphone.net ([194.23.94.31]) by nic.dataphone.se (8.8.2/8.8.2/tri) with ESMTP id XAA03818 for ; Thu, 7 Nov 1996 23:45:23 +0100 (MET) Message-Id: <199611072245.XAA03818@nic.dataphone.se> From: "Mikael Hugo" To: Date: Thu, 7 Nov 1996 23:44:36 +0100 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-stable@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk subscribe freebsd-stable From owner-freebsd-stable Thu Nov 7 22:40:04 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA12312 for stable-outgoing; Thu, 7 Nov 1996 22:40:04 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA12264; Thu, 7 Nov 1996 22:39:55 -0800 (PST) Received: from dcs.stu.rpi.edu (kdupuis@dcs.stu.rpi.edu [128.113.161.29]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id UAA19900 ; Thu, 7 Nov 1996 20:26:26 -0800 (PST) Received: from localhost (kdupuis@localhost) by dcs.stu.rpi.edu (8.7.6/8.7.3) with SMTP id XAA00237; Thu, 7 Nov 1996 23:26:25 -0500 (EST) Date: Thu, 7 Nov 1996 23:26:25 -0500 (EST) From: "Kenneth J. Dupuis" To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Compile error Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I just grabbed the latest -current via FTP and compiled it with no problems. Its been up and running on a heavily-used server for about 3 hours now. The only thing I can notice is that it takes a long time to close a TCP/IP port that sendmail was using. It says that the connection is "ESTABLISHED" long after the email has been delivered. Due to this problem and a lot of "open" ports I grabbed -stable and tried to compile it. About 3/4 of the way through it exits with this error: param.c - timezone value does not match That's the best I can remember it right now. Anyone heard of this and know a way to fix it? From owner-freebsd-stable Fri Nov 8 01:40:39 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA21375 for stable-outgoing; Fri, 8 Nov 1996 01:40:39 -0800 (PST) Received: from relay-7.mail.demon.net (relay-7.mail.demon.net [194.217.242.9]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id BAA21370 for ; Fri, 8 Nov 1996 01:40:36 -0800 (PST) Received: from aaaaaaaa.demon.co.uk ([158.152.178.85]) by relay-6.mail.demon.net id aa624417; 8 Nov 96 9:35 GMT Received: (from andrew@localhost) by aaaaaaaa.demon.co.uk (8.7.6/8.6.9) id JAA01920 for stable@freefall.freebsd.org; Fri, 8 Nov 1996 09:35:36 GMT From: Andrew Wilson Message-Id: <199611080935.JAA01920@aaaaaaaa.demon.co.uk> Subject: CTM coredumps on src-2.1.0196.gz... To: stable@freefall.freebsd.org Date: Fri, 8 Nov 1996 09:35:36 +0000 (GMT) X-Mailer: ELM [version 2.4 PL24 ME8a] Content-Type: text Sender: owner-stable@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, this morning's src-2.1.0196.gz from ftp.uk.freebsd.org coredumps with: Working on <../src-2.1.0196.gz> Expecting Global MD5 <41f3b45de198f7905a760d8a8dda49bd> Reference Global MD5 <41f3b45de198f7905a760d8a8dda49bd> FR: games/hack/hack.onames.h doesn't exist. Segmentation fault (core dumped) Buh? Ay. From owner-freebsd-stable Fri Nov 8 02:12:54 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA22649 for stable-outgoing; Fri, 8 Nov 1996 02:12:54 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id CAA22637 for ; Fri, 8 Nov 1996 02:12:51 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.2/8.6.9) with ESMTP id CAA10474 for ; Fri, 8 Nov 1996 02:09:05 -0800 (PST) To: stable@freebsd.org Subject: The curtain is going down on 2.1-stable in 5 days! Date: Fri, 08 Nov 1996 02:09:05 -0800 Message-ID: <10472.847447745@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Basically, I need to get 2.1.6 off my plate if I'm to have any hope of working constructively on 2.2, and managing 3 different branches during this transitional period is also something of a headache which I'd like to avoid prolonging. So. David and I have decided that next Tuesday, the 12th of November, would be an excellent time to start putting FreeBSD 2.1.6 to bed, and if you've got any critical bug fixes or security problems to report in 2.1-stable, now would be an excellent time to raise them before it's too late. Testing from your own release: ------------------------------ Those wishing to build their own releases from 2.1-stable and test them are, of course, more than encouraged to do so. I guess I've never really given reasonable instructions on doing this, so what the heck. Assuming you've got a good 600MB or so of disk space to burn and a CVS repository online being pointed at with your CVSROOT, you can build a release by saying: # cd /usr/src/release # make release CHROOTDIR=/free/space BUILDNAME=2.1.6-RELEASE \ RELEASETAG=RELENG_2_1_0 >& release.out & After anywhere from a day to 4 hours, depending on the speed of your machine, you should have an installable release in /free/space and can do an FTP install from the bits by doing: # rcp -pr /free/space/R/ftp ftphost:~ftp/pub/2.1.6-RELEASE [stick a floppy in the drive] # fdwrite < /free/space/R/stage/floppies/boot.flp (if your ftp host and build host are the same, you can also just mv the file hierarchy over rather than rcp'ing it :) Now go to another machine on the network with your new floppy and do an FTP install with ``ftp://ftphost/pub/'' as the media (select Other in the FTP host selection menu). In case of problems encountered which cannot be attributed to pilot error, please contact me as soon as possible. Let's test the heck out of this and make 2.1.6 the kind of release that we'd be pleased to recommend for commercial use for some time to come! Thanks! Jordan From owner-freebsd-stable Fri Nov 8 03:15:23 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA25517 for stable-outgoing; Fri, 8 Nov 1996 03:15:23 -0800 (PST) Received: from NS.Contrib.Com (NS.Contrib.Com [194.77.12.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id DAA25512 for ; Fri, 8 Nov 1996 03:15:20 -0800 (PST) Received: (from src@localhost) by NS.Contrib.Com (8.6.9/8.6.9) id MAA01301; Fri, 8 Nov 1996 12:15:11 +0100 Date: Fri, 8 Nov 1996 12:15:11 +0100 From: Heiko Blume Message-Id: <199611081115.MAA01301@NS.Contrib.Com> CC: stable@FreeBSD.org In-reply-to: (message from BSD Mailinglisten-User on Wed, 6 Nov 1996 09:45:37 +0100 (MET)) Subject: Re: innd can't malloc - why? Sender: owner-stable@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk hello thanks for the help, i've got it running stable now. btw, is it possible for a process to distinguish between really-out-of-memory and i-will-not-give-you-anymore? hb From owner-freebsd-stable Fri Nov 8 03:20:27 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA25796 for stable-outgoing; Fri, 8 Nov 1996 03:20:27 -0800 (PST) Received: from NS.Contrib.Com (NS.Contrib.Com [194.77.12.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id DAA25791 for ; Fri, 8 Nov 1996 03:20:23 -0800 (PST) Received: (from src@localhost) by NS.Contrib.Com (8.6.9/8.6.9) id MAA01340; Fri, 8 Nov 1996 12:20:21 +0100 Date: Fri, 8 Nov 1996 12:20:21 +0100 From: Heiko Blume Message-Id: <199611081120.MAA01340@NS.Contrib.Com> To: stable@FreeBSD.org Subject: UFS no_atime patch? Sender: owner-stable@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk hello, in i read about a patch for the linux ext2fs filesystem, that disables updating the access time of files to speed up news spool filesystems. needless to say, that would be useful. hb From owner-freebsd-stable Fri Nov 8 03:30:53 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA26272 for stable-outgoing; Fri, 8 Nov 1996 03:30:53 -0800 (PST) Received: from salsa.gv.ssi1.com (salsa.gv.ssi1.com [146.252.44.194]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id DAA26255; Fri, 8 Nov 1996 03:30:46 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.ssi1.com (8.7.5/8.7.3) id DAA19832; Fri, 8 Nov 1996 03:30:40 -0800 (PST) From: Don Lewis Message-Id: <199611081130.DAA19832@salsa.gv.ssi1.com> Date: Fri, 8 Nov 1996 03:30:40 -0800 In-Reply-To: "Jordan K. Hubbard" "The curtain is going down on 2.1-stable in 5 days!" (Nov 8, 2:09am) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: "Jordan K. Hubbard" , stable@freebsd.org Subject: Re: The curtain is going down on 2.1-stable in 5 days! Cc: freebsd-hardware@freebsd.org Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Nov 8, 2:09am, "Jordan K. Hubbard" wrote: } Subject: The curtain is going down on 2.1-stable in 5 days! } } So. David and I have decided that next Tuesday, the 12th of November, } would be an excellent time to start putting FreeBSD 2.1.6 to bed, and } if you've got any critical bug fixes or security problems to report in } 2.1-stable, now would be an excellent time to raise them before it's } too late. Security: the rwhod buffer overflow patch that's been circulating lately Bug fix: The de driver doesn't work especially well with the SMC 9332 10/100 card. About one in ten times, it is initialized to some funny state at boot time that causes the fault light on its hub to flash and all the HP-UX boxes on that hub to shut down their network interfaces. The de driver swiped from from -current a few weeks ago and butchered so that compiles under -stable seems to work perfectly. Judging by some of the comments in that version of the driver, I suspect this problem may affect other cards with the DC21140. --- Truck From owner-freebsd-stable Fri Nov 8 03:48:25 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA27193 for stable-outgoing; Fri, 8 Nov 1996 03:48:25 -0800 (PST) Received: from NS.Contrib.Com (NS.Contrib.Com [194.77.12.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id DAA27188 for ; Fri, 8 Nov 1996 03:48:21 -0800 (PST) Received: (from src@localhost) by NS.Contrib.Com (8.6.9/8.6.9) id MAA01500; Fri, 8 Nov 1996 12:48:19 +0100 Date: Fri, 8 Nov 1996 12:48:19 +0100 From: Heiko Blume Message-Id: <199611081148.MAA01500@NS.Contrib.Com> To: stable@FreeBSD.org Subject: systat beautification patch Sender: owner-stable@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk well, as self-punishment for asking stupid questions, i did something. it's cosmetic, but i like it. the 'systat -vmstat' output becomes a little ugly when the numbers get large and run into each other. i changed it, so that there are spaces between them (until you reach 10G numbers :-) regards, hb *** /usr/src/usr.bin/systat/vmstat.c.orig Fri Nov 8 12:23:10 1996 --- /usr/src/usr.bin/systat/vmstat.c Tue Nov 5 15:52:56 1996 *************** *** 166,173 **** #define MEMROW 2 /* uses 4 rows and 31 cols */ #define MEMCOL 0 #define PAGEROW 2 /* uses 4 rows and 26 cols */ ! #define PAGECOL 36 ! #define INTSROW 2 /* uses all rows to bottom and 17 cols */ #define INTSCOL 61 #define PROCSROW 7 /* uses 2 rows and 20 cols */ #define PROCSCOL 0 --- 166,173 ---- #define MEMROW 2 /* uses 4 rows and 31 cols */ #define MEMCOL 0 #define PAGEROW 2 /* uses 4 rows and 26 cols */ ! #define PAGECOL 46 ! #define INTSROW 6 /* uses all rows to bottom and 17 cols */ #define INTSCOL 61 #define PROCSROW 7 /* uses 2 rows and 20 cols */ #define PROCSCOL 0 *************** *** 275,286 **** clear(); mvprintw(STATROW, STATCOL + 4, "users Load"); ! mvprintw(MEMROW, MEMCOL, "Mem:KB REAL VIRTUAL"); ! mvprintw(MEMROW + 1, MEMCOL, " Tot Share Tot Share"); mvprintw(MEMROW + 2, MEMCOL, "Act"); mvprintw(MEMROW + 3, MEMCOL, "All"); ! mvprintw(MEMROW + 1, MEMCOL + 31, "Free"); mvprintw(PAGEROW, PAGECOL, " VN PAGER SWAP PAGER "); mvprintw(PAGEROW + 1, PAGECOL, " in out in out "); --- 275,286 ---- clear(); mvprintw(STATROW, STATCOL + 4, "users Load"); ! mvprintw(MEMROW, MEMCOL, "Mem:KB REAL VIRTUAL"); ! mvprintw(MEMROW + 1, MEMCOL, " Tot Share Tot Share"); mvprintw(MEMROW + 2, MEMCOL, "Act"); mvprintw(MEMROW + 3, MEMCOL, "All"); ! mvprintw(MEMROW + 1, MEMCOL + 41, "Free"); mvprintw(PAGEROW, PAGECOL, " VN PAGER SWAP PAGER "); mvprintw(PAGEROW + 1, PAGECOL, " in out in out "); *************** *** 425,439 **** putfloat(avenrun[2], STATROW, STATCOL + 29, 6, 2, 0); mvaddstr(STATROW, STATCOL + 53, buf); #define pgtokb(pg) ((pg) * cnt.v_page_size / 1024) ! putint(pgtokb(total.t_arm), MEMROW + 2, MEMCOL + 3, 6); ! putint(pgtokb(total.t_armshr), MEMROW + 2, MEMCOL + 9, 6); ! putint(pgtokb(total.t_avm), MEMROW + 2, MEMCOL + 15, 7); ! putint(pgtokb(total.t_avmshr), MEMROW + 2, MEMCOL + 22, 7); ! putint(pgtokb(total.t_rm), MEMROW + 3, MEMCOL + 3, 6); ! putint(pgtokb(total.t_rmshr), MEMROW + 3, MEMCOL + 9, 6); ! putint(pgtokb(total.t_vm), MEMROW + 3, MEMCOL + 15, 7); ! putint(pgtokb(total.t_vmshr), MEMROW + 3, MEMCOL + 22, 7); ! putint(pgtokb(total.t_free), MEMROW + 2, MEMCOL + 29, 6); putint(total.t_rq - 1, PROCSROW + 1, PROCSCOL + 3, 3); putint(total.t_pw, PROCSROW + 1, PROCSCOL + 6, 3); putint(total.t_dw, PROCSROW + 1, PROCSCOL + 9, 3); --- 425,439 ---- putfloat(avenrun[2], STATROW, STATCOL + 29, 6, 2, 0); mvaddstr(STATROW, STATCOL + 53, buf); #define pgtokb(pg) ((pg) * cnt.v_page_size / 1024) ! putint(pgtokb(total.t_arm), MEMROW + 2, MEMCOL + 3, 8); ! putint(pgtokb(total.t_armshr), MEMROW + 2, MEMCOL + 11, 8); ! putint(pgtokb(total.t_avm), MEMROW + 2, MEMCOL + 19, 9); ! putint(pgtokb(total.t_avmshr), MEMROW + 2, MEMCOL + 28, 9); ! putint(pgtokb(total.t_rm), MEMROW + 3, MEMCOL + 3, 8); ! putint(pgtokb(total.t_rmshr), MEMROW + 3, MEMCOL + 11, 8); ! putint(pgtokb(total.t_vm), MEMROW + 3, MEMCOL + 19, 9); ! putint(pgtokb(total.t_vmshr), MEMROW + 3, MEMCOL + 28, 9); ! putint(pgtokb(total.t_free), MEMROW + 2, MEMCOL + 37, 8); putint(total.t_rq - 1, PROCSROW + 1, PROCSCOL + 3, 3); putint(total.t_pw, PROCSROW + 1, PROCSCOL + 6, 3); putint(total.t_dw, PROCSROW + 1, PROCSCOL + 9, 3); From owner-freebsd-stable Fri Nov 8 04:06:05 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA28165 for stable-outgoing; Fri, 8 Nov 1996 04:06:05 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id EAA28159 for ; Fri, 8 Nov 1996 04:06:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id EAA05266; Fri, 8 Nov 1996 04:04:07 -0800 (PST) Message-Id: <199611081204.EAA05266@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Heiko Blume cc: stable@FreeBSD.org Subject: Re: UFS no_atime patch? In-reply-to: Your message of "Fri, 08 Nov 1996 12:20:21 +0100." <199611081120.MAA01340@NS.Contrib.Com> From: David Greenman Reply-To: dg@root.com Date: Fri, 08 Nov 1996 04:04:07 -0800 Sender: owner-stable@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >in i read >about a patch for the linux ext2fs filesystem, that >disables updating the access time of files to speed >up news spool filesystems. > >needless to say, that would be useful. I added a "noatime" filesystem mount option a few months ago to FreeBSD. It will be available in the upcoming 2.2 release. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-stable Fri Nov 8 04:16:00 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA28618 for stable-outgoing; Fri, 8 Nov 1996 04:16:00 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id EAA28610 for ; Fri, 8 Nov 1996 04:15:57 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.2/8.6.9) with ESMTP id EAA24553; Fri, 8 Nov 1996 04:11:34 -0800 (PST) To: Don Lewis cc: stable@freebsd.org Subject: Re: The curtain is going down on 2.1-stable in 5 days! In-reply-to: Your message of "Fri, 08 Nov 1996 03:30:40 PST." <199611081130.DAA19832@salsa.gv.ssi1.com> Date: Fri, 08 Nov 1996 04:11:34 -0800 Message-ID: <24551.847455094@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > their network interfaces. The de driver swiped from from -current > a few weeks ago and butchered so that compiles under -stable seems > to work perfectly. Judging by some of the comments in that version Could you elaborate on "butchered" a bit here? :-) I believe that David's still responsible for the de driver, so if any merging is to be done then he's the guy to talk to about it. I'll look for the rwhod fix, though if you've got a more exact pointer that would help. Thanks. Jordan From owner-freebsd-stable Fri Nov 8 04:32:39 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA29993 for stable-outgoing; Fri, 8 Nov 1996 04:32:39 -0800 (PST) Received: from salsa.gv.ssi1.com (salsa.gv.ssi1.com [146.252.44.194]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id EAA29981 for ; Fri, 8 Nov 1996 04:32:31 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.ssi1.com (8.7.5/8.7.3) id EAA20373; Fri, 8 Nov 1996 04:32:13 -0800 (PST) From: Don Lewis Message-Id: <199611081232.EAA20373@salsa.gv.ssi1.com> Date: Fri, 8 Nov 1996 04:32:12 -0800 In-Reply-To: "Jordan K. Hubbard" "Re: The curtain is going down on 2.1-stable in 5 days!" (Nov 8, 4:11am) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: "Jordan K. Hubbard" , Don Lewis Subject: Re: The curtain is going down on 2.1-stable in 5 days! Cc: stable@freebsd.org Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Nov 8, 4:11am, "Jordan K. Hubbard" wrote: } Subject: Re: The curtain is going down on 2.1-stable in 5 days! } > their network interfaces. The de driver swiped from from -current } > a few weeks ago and butchered so that compiles under -stable seems } > to work perfectly. Judging by some of the comments in that version } } Could you elaborate on "butchered" a bit here? :-) I believe that } David's still responsible for the de driver, so if any merging is } to be done then he's the guy to talk to about it. It's mostly things like what include files are pulled in. That kind of stuff seems to have changed between the 2.1 branch and the 2.2 branch. It looks like 2.1 also doesn't have ether_ioctl(), so I put in the code from the -stable driver. Unfortunately, I don't seem can't seem to find an unhacked version of the driver, but here's a diff between the latest version in current and my hacked version (which still has one compiler warning): *** if_de.c Tue Oct 15 16:15:13 1996 --- hacked_de.c Fri Nov 8 04:22:30 1996 *************** *** 21,27 **** * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. * ! * $Id: if_de.c,v 1.54 1996/10/15 19:22:39 bde Exp $ * */ --- 21,27 ---- * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. * ! * $Id: if_de.c,v 1.52 1996/09/20 04:35:15 davidg Exp $ * */ *************** *** 35,40 **** --- 35,45 ---- * board which support DC21040, DC21041, or DC21140 (mostly). */ + #if defined(__FreeBSD__) + #include "de.h" + #endif + #if NDE > 0 || !defined(__FreeBSD__) + #include #include #include *************** *** 46,51 **** --- 51,57 ---- #include #include /* only for declaration of wakeup() used by vm.h */ #if defined(__FreeBSD__) + #include #include #elif defined(__bsdi__) || defined(__NetBSD__) #include *************** *** 52,60 **** #endif #include - #include - #include #include #include #include --- 58,65 ---- #endif #include #include + #include #include #include *************** *** 82,89 **** #include #if defined(__FreeBSD__) ! #include ! #include "pci.h" #if NPCI > 0 #include #include --- 87,93 ---- #include #if defined(__FreeBSD__) ! #include #if NPCI > 0 #include #include *************** *** 520,526 **** #endif struct ifqueue tulip_txq; struct ifqueue tulip_rxq; ! struct ifmib_iso_8802_3 tulip_dot3stats; tulip_ringinfo_t tulip_rxinfo; tulip_ringinfo_t tulip_txinfo; tulip_desc_t tulip_rxdescs[TULIP_RXDESCS]; --- 524,530 ---- #endif struct ifqueue tulip_txq; struct ifqueue tulip_rxq; ! tulip_dot3_stats_t tulip_dot3stats; tulip_ringinfo_t tulip_rxinfo; tulip_ringinfo_t tulip_txinfo; tulip_desc_t tulip_rxdescs[TULIP_RXDESCS]; *************** *** 540,552 **** "DC21142 [10-100Mb/s]", }; - #define chip(x) DOT3CHIPSET(dot3VendorDigital, dot3ChipSetDigital##x) - static u_int32_t const tulip_chip2mib[] = { - chip(DC21040), chip(DC21040), chip(DC21041), chip(DC21140), - chip(DC21140A), chip(DC21142) - }; - #undef chip - static const char * const tulip_mediums[] = { "unknown", /* TULIP_MEDIA_UNKNOWN */ "10baseT", /* TULIP_MEDIA_10BASET */ --- 544,549 ---- *************** *** 3320,3325 **** --- 3317,3323 ---- caddr_t data) { tulip_softc_t * const sc = TULIP_IFP_TO_SOFTC(ifp); + struct ifaddr *ifa = (struct ifaddr *) data; struct ifreq *ifr = (struct ifreq *) data; tulip_spl_t s; int error = 0; *************** *** 3330,3339 **** s = splimp(); #endif switch (cmd) { ! case SIOCSIFADDR: ! case SIOCGIFADDR: ! ether_ioctl(ifp, cmd, data); break; case SIOCSIFFLAGS: { /* --- 3328,3385 ---- s = splimp(); #endif switch (cmd) { ! case SIOCSIFADDR: { ! ! ifp->if_flags |= IFF_UP; ! switch(ifa->ifa_addr->sa_family) { ! #ifdef INET ! case AF_INET: { ! sc->tulip_ac.ac_ipaddr = IA_SIN(ifa)->sin_addr; ! tulip_init(sc); ! #if defined(__FreeBSD__) || defined(__NetBSD__) ! arp_ifinit(&sc->tulip_ac, ifa); ! #elif defined(__bsdi__) ! arpwhohas(&sc->tulip_ac, &IA_SIN(ifa)->sin_addr); ! #endif ! break; ! } ! #endif /* INET */ ! ! #ifdef NS ! /* ! * This magic copied from if_is.c; I don't use XNS, ! * so I have no way of telling if this actually ! * works or not. ! */ ! case AF_NS: { ! struct ns_addr *ina = &(IA_SNS(ifa)->sns_addr); ! if (ns_nullhost(*ina)) { ! ina->x_host = *(union ns_host *)(sc->tulip_ac.ac_enaddr); ! } else { ! ifp->if_flags &= ~IFF_RUNNING; ! bcopy((caddr_t)ina->x_host.c_host, ! (caddr_t)sc->tulip_ac.ac_enaddr, ! sizeof sc->tulip_ac.ac_enaddr); ! } ! ! tulip_init(sc); ! break; ! } ! #endif /* NS */ ! ! default: { ! tulip_init(sc); ! break; ! } ! } break; + } + case SIOCGIFADDR: { + bcopy((caddr_t) sc->tulip_ac.ac_enaddr, + (caddr_t) ((struct sockaddr *)&ifr->ifr_data)->sa_data, + 6); + break; + } case SIOCSIFFLAGS: { /* *************** *** 3743,3749 **** ifp->if_ioctl = tulip_ifioctl; ifp->if_start = tulip_ifstart; ifp->if_watchdog = tulip_ifwatchdog; ! ifp->if_init = (if_init_f_t*)tulip_init; ifp->if_timer = 1; #if !defined(__bsdi__) || _BSDI_VERSION < 199401 ifp->if_output = ether_output; --- 3789,3795 ---- ifp->if_ioctl = tulip_ifioctl; ifp->if_start = tulip_ifstart; ifp->if_watchdog = tulip_ifwatchdog; ! ifp->if_init = tulip_init; ifp->if_timer = 1; #if !defined(__bsdi__) || _BSDI_VERSION < 199401 ifp->if_output = ether_output; *************** *** 3779,3787 **** TULIP_EADDR_ARGS(sc->tulip_hwaddr)); #endif - sc->tulip_dot3stats.dot3Compliance = DOT3COMPLIANCE_STATS; - sc->tulip_dot3stats.dot3StatsEtherChipSet = - tulip_chip2mib[sc->tulip_chipid]; if (sc->tulip_boardsw->bd_mii_probe != NULL) (*sc->tulip_boardsw->bd_mii_probe)(sc); --- 3825,3830 ---- *************** *** 3796,3804 **** tulip_reset(sc); sc->tulip_flags &= ~TULIP_DEVICEPROBE; - ifp->if_linkmib = &sc->tulip_dot3stats; - ifp->if_linkmiblen = sizeof sc->tulip_dot3stats; - #if defined(__bsdi__) && _BSDI_VERSION >= 199510 sc->tulip_pf = printf; ether_attach(ifp); --- 3839,3844 ---- *************** *** 4372,4378 **** return; } } - at_shutdown(tulip_shutdown, sc, SHUTDOWN_POST_SYNC); #endif #if defined(__bsdi__) if ((sc->tulip_flags & TULIP_SLAVEDINTR) == 0) { --- 4412,4417 ---- *************** *** 4408,4410 **** --- 4447,4450 ---- splx(s); } } + #endif /* NDE > 0 */ } I'll look for the rwhod fix, though if you've got a more exact pointer } that would help. Ok, here it is: On Nov 3, 9:16pm, Warner Losh wrote: } Subject: Re: rwhod buffer overflow bug } In message <199611010236.SAA05376@salsa.gv.ssi1.com> Don Lewis writes: } : The wd_hostname buffer overflow bug in rwhod that came to light a couple } : months ago appears to have been fixed in -current, but the fix never } : seems to have been made to -stable. } } Guido beat me to the punch on this one. Here's his patch that you can } test. We plan on committing it to -stable soon. } } Warner } } From: Guido van Rooij } Subject: Re: rwhod buffer overflow bug } To: imp@village.org (Warner Losh) } Date: Sun, 3 Nov 1996 20:50:22 +0100 (MET) } X-Mailer: ELM [version 2.4ME+ PL28 (25)] } MIME-Version: 1.0 } Content-Type: text/plain; charset=US-ASCII } Content-Transfer-Encoding: 7bit } } Warner Losh wrote: } > In message <199611010236.SAA05376@salsa.gv.ssi1.com> Don Lewis writes: } > : The wd_hostname buffer overflow bug in rwhod that came to light a couple } > : months ago appears to have been fixed in -current, but the fix never } > : seems to have been made to -stable. } > } > I can do the CVS legwork if someone has a -stable system to test it } > on. } > } > Warner } > } > P.S. I just noticed and fixed two minor buffer related problems in } > rwhod.c that I happened to notice as I was looking at this code. Yow! } > } } Underneath the complete patch. It works on mu 2.1.5 system. } Don't be scared bu the master.passwd change. It didnt seem to bother } anyone in current at the time and it makes real sense ;-) } Please review it. I can commit it but please mail back if you wnat } me to. } } -Guido } } --- etc/master.passwd.orig Sun Nov 3 20:43:22 1996 } +++ etc/master.passwd Sun Nov 3 20:43:50 1996 } @@ -1,6 +1,6 @@ } root::0:0::0:0:Charlie &:/root:/bin/csh } toor:*:0:0::0:0:Bourne-again Superuser:/root: } -daemon:*:1:31::0:0:Owner of many system processes:/root: } +daemon:*:1:1::0:0:Owner of many system processes:/root: } operator:*:2:20::0:0:System &:/usr/guest/operator:/bin/csh } bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/nonexistent } games:*:7:13::0:0:Games pseudo-user:/usr/games: } --- etc/mtree/BSD.var.dist.orig Mon Jun 17 11:17:40 1996 } +++ etc/mtree/BSD.var.dist Sun Nov 3 20:21:00 1996 } @@ -40,7 +40,7 @@ } .. } run uname=bin } .. } - rwho uname=bin } + rwho uname=bin gname=daemon mode=0775 } .. } /set type=dir uname=uucp gname=daemon mode=0755 } spool uname=bin gname=bin } --- usr.sbin/rwhod/rwhod.c.orig Thu May 26 07:22:40 1994 } +++ usr.sbin/rwhod/rwhod.c Sun Nov 3 20:44:16 1996 } @@ -65,6 +65,10 @@ } #include } #include } #include } +#include } + } +#define UNPRIV_USER "daemon" } +#define UNPRIV_GROUP "daemon" } } /* } * Alarm interval. Don't forget to change the down time check in ruptime } @@ -94,15 +98,17 @@ } } #define WHDRSIZE (sizeof(mywd) - sizeof(mywd.wd_we)) } } +void run_as __P((uid_t *, gid_t *)); } int configure __P((int)); } void getboottime __P((int)); } void onalrm __P((int)); } void quit __P((char *)); } void rt_xaddrs __P((caddr_t, caddr_t, struct rt_addrinfo *)); } -int verify __P((char *)); } +int verify __P((char *, int)); } #ifdef DEBUG } char *interval __P((int, char *)); } -void Sendto __P((int, char *, int, int, char *, int)); } +void Sendto __P((int, const void *, size_t, int, } + const struct sockaddr *, int)); } #define sendto Sendto } #endif } } @@ -117,11 +123,16 @@ } int on = 1; } char *cp; } struct sockaddr_in sin; } + uid_t unpriv_uid; } + gid_t unpriv_gid; } } if (getuid()) { } fprintf(stderr, "rwhod: not super user\n"); } exit(1); } } } + } + run_as(&unpriv_uid, &unpriv_gid); } + } sp = getservbyname("who", "udp"); } if (sp == NULL) { } fprintf(stderr, "rwhod: udp/who: unknown service\n"); } @@ -146,7 +157,8 @@ } } } if ((cp = index(myname, '.')) != NULL) } *cp = '\0'; } - strncpy(mywd.wd_hostname, myname, sizeof(myname) - 1); } + strncpy(mywd.wd_hostname, myname, sizeof(mywd.wd_hostname) - 1); } + mywd.wd_hostname[sizeof(mywd.wd_hostname) - 1] = '\0'; } utmpf = open(_PATH_UTMP, O_RDONLY|O_CREAT, 0644); } if (utmpf < 0) { } syslog(LOG_ERR, "%s: %m", _PATH_UTMP); } @@ -168,6 +180,8 @@ } syslog(LOG_ERR, "bind: %m"); } exit(1); } } } + setgid(unpriv_gid); } + setuid(unpriv_uid); } if (!configure(s)) } exit(1); } signal(SIGALRM, onalrm); } @@ -192,7 +206,7 @@ } continue; } if (wd.wd_type != WHODTYPE_STATUS) } continue; } - if (!verify(wd.wd_hostname)) { } + if (!verify(wd.wd_hostname, sizeof wd.wd_hostname)) { } syslog(LOG_WARNING, "malformed host name from %x", } from.sin_addr); } continue; } @@ -234,22 +248,47 @@ } } } } } } + } +void } +run_as(uid, gid) } + uid_t *uid; } + gid_t *gid; } +{ } + struct passwd *pw; } + } + pw = getpwnam(UNPRIV_USER); } + if (!pw) { } + syslog(LOG_ERR, "getpwnam(%s): %m", UNPRIV_USER); } + exit(1); } + } } + *uid = pw->pw_uid; } + } + pw = getpwnam(UNPRIV_GROUP); } + if (!pw) { } + syslog(LOG_ERR, "getpwnam(%s): %m", UNPRIV_GROUP); } + exit(1); } + } } + *gid = pw->pw_gid; } +} } + } /* } * Check out host name for unprintables } * and other funnies before allowing a file } * to be created. Sorry, but blanks aren't allowed. } */ } int } -verify(name) } +verify(name, maxlen) } register char *name; } + register int maxlen; } { } register int size = 0; } } - while (*name) { } + while (*name && size < maxlen - 1) { } if (!isascii(*name) || !(isalnum(*name) || ispunct(*name))) } return (0); } name++, size++; } } } + *name = '\0'; } return (size > 0); } } } } @@ -477,16 +516,18 @@ } void } Sendto(s, buf, cc, flags, to, tolen) } int s; } - char *buf; } - int cc, flags; } - char *to; } + const void *buf; } + size_t cc; } + int flags; } + const struct sockaddr *to; } int tolen; } { } register struct whod *w = (struct whod *)buf; } register struct whoent *we; } struct sockaddr_in *sin = (struct sockaddr_in *)to; } } - printf("sendto %x.%d\n", ntohl(sin->sin_addr), ntohs(sin->sin_port)); } + printf("sendto %x.%d\n", ntohl(sin->sin_addr.s_addr), } + ntohs(sin->sin_port)); } printf("hostname %s %s\n", w->wd_hostname, } interval(ntohl(w->wd_sendtime) - ntohl(w->wd_boottime), " up")); } printf("load %4.2f, %4.2f, %4.2f\n", } }-- End of excerpt from Warner Losh --- Truck From owner-freebsd-stable Fri Nov 8 04:47:32 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA00908 for stable-outgoing; Fri, 8 Nov 1996 04:47:32 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id EAA00902; Fri, 8 Nov 1996 04:47:26 -0800 (PST) Received: (from jkh@localhost) by time.cdrom.com (8.8.2/8.6.9) id EAA01694; Fri, 8 Nov 1996 04:43:00 -0800 (PST) Date: Fri, 8 Nov 1996 04:43:00 -0800 (PST) From: "Jordan K. Hubbard" Message-Id: <199611081243.EAA01694@time.cdrom.com> To: wpaul@freebsd.org Subject: Weirdie in mountd perhaps you can help me with... Cc: dfr@freebsd.org, stable@freebsd.org Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As has been reported by several people, including myself, there's still some problem with "NFS" in 2.1.5 where essentially mountd "goes away" and refuses to answer further requests. Sometimes it goes away entirely, in fact, and has to be restarted. In order to try and get to the bottom of this one, I compiled up a version of mountd with debugging and attached to it with gdb right after the system came up. I've been running this way all day, and just now reproduced one of the failures, which was the "long hang" (I haven't had it outright die yet, thought it's been mysteriously HUP'd twice by the system when an *outgoing* mount request was made, and for no reason that I can see). The debugger shows the following stack trace: #0 0x27345 in select () #1 0x18bbc in res_send () #2 0x168c7 in res_query () #3 0x1057a in _gethostbydnsaddr () #4 0xf6c0 in gethostbyaddr () #5 0x1d2d in mntsrv (rqstp=0xefbfda1c, transp=0x4d080) at /usr/src/sbin/mountd/mountd.c:413 #6 0xa082 in svc_getreqset () #7 0x48db in svc_run () #8 0x1a39 in main (argc=1, argv=0xefbfdadc) at /usr/src/sbin/mountd/mountd.c:317 Where it appears to be hanging in res_send()'s select. This, after a long interval, finally does time out and drops us back to mountd's usual select, e.g.: #0 0x27345 in select () #1 0x48c9 in svc_run () #2 0x1a39 in main (argc=1, argv=0xefbfdadc) at /usr/src/sbin/mountd/mountd.c:317 The corresponding mount request also succeeds at the end of this timeout. Any ideas? Jordan From owner-freebsd-stable Fri Nov 8 04:59:01 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA01293 for stable-outgoing; Fri, 8 Nov 1996 04:59:01 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id EAA01288 for ; Fri, 8 Nov 1996 04:58:55 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.2/8.6.9) with ESMTP id EAA01738; Fri, 8 Nov 1996 04:53:26 -0800 (PST) To: Heiko Blume cc: stable@freebsd.org Subject: Re: systat beautification patch In-reply-to: Your message of "Fri, 08 Nov 1996 12:48:19 +0100." <199611081148.MAA01500@NS.Contrib.Com> Date: Fri, 08 Nov 1996 04:53:26 -0800 Message-ID: <1736.847457606@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > as self-punishment for asking stupid questions, i did something. > it's cosmetic, but i like it. the 'systat -vmstat' output > becomes a little ugly when the numbers get large and run > into each other. i changed it, so that there are spaces between > them (until you reach 10G numbers :-) Nice! I've often grimaced at systat's unusable vmstat display, and this is a real improvement. Thanks! Committed. Jordan From owner-freebsd-stable Fri Nov 8 05:38:57 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA03445 for stable-outgoing; Fri, 8 Nov 1996 05:38:57 -0800 (PST) Received: from salsa.gv.ssi1.com (salsa.gv.ssi1.com [146.252.44.194]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA03440 for ; Fri, 8 Nov 1996 05:38:55 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.ssi1.com (8.7.5/8.7.3) id FAA20634; Fri, 8 Nov 1996 05:38:50 -0800 (PST) From: Don Lewis Message-Id: <199611081338.FAA20634@salsa.gv.ssi1.com> Date: Fri, 8 Nov 1996 05:38:50 -0800 In-Reply-To: "Jordan K. Hubbard" "The curtain is going down on 2.1-stable in 5 days!" (Nov 8, 2:09am) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: "Jordan K. Hubbard" , stable@freebsd.org Subject: Re: The curtain is going down on 2.1-stable in 5 days! Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Another security problem: named/db_lookup.c should get the hash fix from BIND 4.9.4-P1 since the version in the tree has the hash aliasing bug. I'm not in a good position to test this since none of our FreeBSD boxes are currently running BIND, and in any case I've pulled 4.9.5-BETAsomething into my local tree. --- Truck From owner-freebsd-stable Fri Nov 8 05:39:09 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA03469 for stable-outgoing; Fri, 8 Nov 1996 05:39:09 -0800 (PST) Received: from minnow.render.com (render.demon.co.uk [158.152.30.118]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id FAA03458; Fri, 8 Nov 1996 05:39:04 -0800 (PST) Received: from minnow.render.com (minnow.render.com [193.195.178.1]) by minnow.render.com (8.6.12/8.6.9) with SMTP id NAA01039; Fri, 8 Nov 1996 13:38:54 GMT Date: Fri, 8 Nov 1996 13:38:54 +0000 (GMT) From: Doug Rabson To: "Jordan K. Hubbard" cc: wpaul@freebsd.org, dfr@freebsd.org, stable@freebsd.org Subject: Re: Weirdie in mountd perhaps you can help me with... In-Reply-To: <199611081243.EAA01694@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 8 Nov 1996, Jordan K. Hubbard wrote: > As has been reported by several people, including myself, there's still > some problem with "NFS" in 2.1.5 where essentially mountd "goes away" and > refuses to answer further requests. Sometimes it goes away entirely, in fact, > and has to be restarted. > > In order to try and get to the bottom of this one, I compiled up a version > of mountd with debugging and attached to it with gdb right after the system > came up. I've been running this way all day, and just now reproduced one > of the failures, which was the "long hang" (I haven't had it outright die yet, > thought it's been mysteriously HUP'd twice by the system when an *outgoing* > mount request was made, and for no reason that I can see). The debugger Mountd wakes up when any filesystem (local or remote) is mounted so that it can correctly export local filesystems depending on the contents of /etc/exports. > shows the following stack trace: > > #0 0x27345 in select () > #1 0x18bbc in res_send () > #2 0x168c7 in res_query () > #3 0x1057a in _gethostbydnsaddr () > #4 0xf6c0 in gethostbyaddr () > #5 0x1d2d in mntsrv (rqstp=0xefbfda1c, transp=0x4d080) > at /usr/src/sbin/mountd/mountd.c:413 > #6 0xa082 in svc_getreqset () > #7 0x48db in svc_run () > #8 0x1a39 in main (argc=1, argv=0xefbfdadc) > at /usr/src/sbin/mountd/mountd.c:317 > > Where it appears to be hanging in res_send()'s select. This, after a long > interval, finally does time out and drops us back to mountd's usual select, > e.g.: > > #0 0x27345 in select () > #1 0x48c9 in svc_run () > #2 0x1a39 in main (argc=1, argv=0xefbfdadc) > at /usr/src/sbin/mountd/mountd.c:317 > > The corresponding mount request also succeeds at the end of this timeout. > > Any ideas? My guess is that it is trying to DNS resolve a badly formed address. The timeouts for this are pretty long. Impossible to tell without knowing the arguments to gethostbyaddr and res_query :-(. -- Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com Phone: +44 171 734 3761 FAX: +44 171 734 6426 From owner-freebsd-stable Fri Nov 8 05:49:00 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA04006 for stable-outgoing; Fri, 8 Nov 1996 05:49:00 -0800 (PST) Received: from salsa.gv.ssi1.com (salsa.gv.ssi1.com [146.252.44.194]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA03997; Fri, 8 Nov 1996 05:48:57 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.ssi1.com (8.7.5/8.7.3) id FAA20656; Fri, 8 Nov 1996 05:48:52 -0800 (PST) From: Don Lewis Message-Id: <199611081348.FAA20656@salsa.gv.ssi1.com> Date: Fri, 8 Nov 1996 05:48:52 -0800 In-Reply-To: "Jordan K. Hubbard" "Weirdie in mountd perhaps you can help me with..." (Nov 8, 4:43am) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: "Jordan K. Hubbard" , wpaul@freebsd.org Subject: Re: Weirdie in mountd perhaps you can help me with... Cc: dfr@freebsd.org, stable@freebsd.org Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Nov 8, 4:43am, "Jordan K. Hubbard" wrote: } Subject: Weirdie in mountd perhaps you can help me with... } I've been running this way all day, and just now reproduced one } of the failures, which was the "long hang" (I haven't had it outright die yet, } thought it's been mysteriously HUP'd twice by the system when an *outgoing* } mount request was made, and for no reason that I can see). The debugger } shows the following stack trace: } } #0 0x27345 in select () } #1 0x18bbc in res_send () } #2 0x168c7 in res_query () } #3 0x1057a in _gethostbydnsaddr () } #4 0xf6c0 in gethostbyaddr () } #5 0x1d2d in mntsrv (rqstp=0xefbfda1c, transp=0x4d080) } at /usr/src/sbin/mountd/mountd.c:413 } #6 0xa082 in svc_getreqset () } #7 0x48db in svc_run () } #8 0x1a39 in main (argc=1, argv=0xefbfdadc) } at /usr/src/sbin/mountd/mountd.c:317 } } Where it appears to be hanging in res_send()'s select. This, after a long } interval, finally does time out and drops us back to mountd's usual select, } e.g.: Define "long hang". How many name servers are listed in /etc/resolv.conf? Are the name servers responding to queries in a reasonable amount of time? --- Truck From owner-freebsd-stable Fri Nov 8 05:49:10 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA04036 for stable-outgoing; Fri, 8 Nov 1996 05:49:10 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA04028; Fri, 8 Nov 1996 05:49:08 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.2/8.6.9) with ESMTP id FAA04599; Fri, 8 Nov 1996 05:45:16 -0800 (PST) To: Doug Rabson cc: wpaul@freebsd.org, dfr@freebsd.org, stable@freebsd.org Subject: Re: Weirdie in mountd perhaps you can help me with... In-reply-to: Your message of "Fri, 08 Nov 1996 13:38:54 GMT." Date: Fri, 08 Nov 1996 05:45:16 -0800 Message-ID: <4597.847460716@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Mountd wakes up when any filesystem (local or remote) is mounted so that > it can correctly export local filesystems depending on the contents of > /etc/exports. Ah, OK, that makes sense.. > My guess is that it is trying to DNS resolve a badly formed address. The > timeouts for this are pretty long. Impossible to tell without knowing the > arguments to gethostbyaddr and res_query :-(. Understood. It might also have been a transient error of other origins. I've still got the patient under guard and will report any further suspicious behavior. :-) I'll also try to figure out why I'm not getting argument values in my stack traces. Jordan From owner-freebsd-stable Fri Nov 8 06:26:50 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA05942 for stable-outgoing; Fri, 8 Nov 1996 06:26:50 -0800 (PST) Received: from fty-ss20.cisco.com (fty-ss20.cisco.com [171.69.162.81]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id GAA05935 for ; Fri, 8 Nov 1996 06:26:48 -0800 (PST) Received: by fty-ss20.cisco.com (8.8.0/1.34) id OAA19088; Fri, 8 Nov 1996 14:25:30 GMT Date: Fri, 8 Nov 1996 14:25:30 GMT From: Frank Terhaar-Yonkers Message-Id: <199611081425.OAA19088@fty-ss20.cisco.com> To: andrew@aaaaaaaa.demon.co.uk, stable@freefall.freebsd.org Subject: Re: CTM coredumps on src-2.1.0196.gz... X-Face: ,fjtWiMPydUaSQl%8[eTg`u:^BXt&T)Sny(6w\*U"5D9H[Z$kG%Q/z;Z=NwrPiXf-aMF3R) Rsand$,]26-8>5@HD(A3A79gN|0%NHsdek4mT8E,>j+\w!~d2#nH;~NV!5a0"`5$Cj8d\or(Jy/JQ_ |uc;C[filmZ(~#lre*l:|O%d/PJFy`.5w8)sMZ-)QI3TaV"j'k X-Mailer: [XMailTool v3.1.0] Sender: owner-stable@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk You're not the only one. My system threw up on this patch as well. Most (if not all) of the files it's trying to delete are not there, and the rest fail the MD5 checksum. I'm stuck at this CTM. - Frank In reference to your message: >From owner-freebsd-stable@freefall.freebsd.org Fri Nov 8 09:52:50 1996 >From: Andrew Wilson >Subject: CTM coredumps on src-2.1.0196.gz... >To: stable@freefall.freebsd.org >Date: Fri, 8 Nov 1996 09:35:36 +0000 (GMT) > >Hi, > > this morning's src-2.1.0196.gz from ftp.uk.freebsd.org coredumps with: > >Working on <../src-2.1.0196.gz> >Expecting Global MD5 <41f3b45de198f7905a760d8a8dda49bd> >Reference Global MD5 <41f3b45de198f7905a760d8a8dda49bd> > FR: games/hack/hack.onames.h doesn't exist. >Segmentation fault (core dumped) > >Buh? > >Ay. > \\\\////\\\\////\\\\\////\\\\\////\\\\////\\\\////\\\\////\\\\////\\\\////\\\\ Frank Terhaar-Yonkers Cisco Systems, Inc. Engineering Services, W2 F3 5 7025 Kit Creek Road PO Box 14987 Research Triangle Park, North Carolina 27709 fty@cisco.com voice (919)472-2101 FAX (919)472-2940 pager (800)796-7363 pin 100-8366 -or- fty@airnote.net From owner-freebsd-stable Fri Nov 8 06:37:41 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA06511 for stable-outgoing; Fri, 8 Nov 1996 06:37:41 -0800 (PST) Received: (from wpaul@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA06505; Fri, 8 Nov 1996 06:37:39 -0800 (PST) From: Bill Paul Message-Id: <199611081437.GAA06505@freefall.freebsd.org> Subject: Re: Weirdie in mountd perhaps you can help me with... To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Fri, 8 Nov 1996 06:37:38 -0800 (PST) Cc: dfr@render.com, dfr@freebsd.org, stable@freebsd.org In-Reply-To: <4597.847460716@time.cdrom.com> from "Jordan K. Hubbard" at Nov 8, 96 05:45:16 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > Mountd wakes up when any filesystem (local or remote) is mounted so that > > it can correctly export local filesystems depending on the contents of > > /etc/exports. > > Ah, OK, that makes sense.. You can also test it somewhat using the rpcinfo command by asking it to ping mountd's NULLPROC (RPC procudure 0 is usually reserved for a null function that basically acts as a loopback of sorts; rpcinfo can be used to call the null procedure and if you get an answer, you know the RPC server is still alive). If the process is blocked inside a select loop in the DNS code though, I'm not sure you would get an immediate answer. > > My guess is that it is trying to DNS resolve a badly formed address. The > > timeouts for this are pretty long. Impossible to tell without knowing the > > arguments to gethostbyaddr and res_query :-(. This is my guess too. If all the hosts you export too are local and the primary nameserver for them is close by, you shouldn't see much trouble like this unless perhaps you try mounting a filesystem at the same time that someone is reloading the nameserver or something. One way you might get around this is to put the names of all your permitted NFS clients (and other important hosts) in /etc/hosts and fixing /etc/host.conf so that it searches /etc/hosts first and then DNS. One case where this workaround will not work is if someone at a remote location tries to NFS mount your filesystems without permission (perhaps for nefarious purposes like breaking in or stealing your memoirs.) If they are really far away, or on a crummy network (like Sprint :), or they're using an unregistered IP, or the nameservers for their domain are hosed, mountd could get stuck for a while trying to resolve (or reverse resolve) them. If you suspect this may be the case, you can easily add code to the procedure in mountd where mount requests are processed to syslog(3) the IP addresses of requesting hosts. Now that I think of it, this may be a good idea in general. I don't remember if mountd flags unauthorized mount attempts. > Understood. It might also have been a transient error of other > origins. I've still got the patient under guard and will report any > further suspicious behavior. :-) Take two SIMM modules and call us in the morning. > I'll also try to figure out why I'm not getting argument values in > my stack traces. Well, the DNS code is inside libc, so unless you compile libc with -g or extract the libc/net code, compile that with -g and link against it explicitly, gdb won't be able to show your more than function names. (You can also poke around in registers but this is a drag.) Come to think of it, the RPC code would have to be compiled with -g too. -Bill From owner-freebsd-stable Fri Nov 8 06:44:19 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA06877 for stable-outgoing; Fri, 8 Nov 1996 06:44:19 -0800 (PST) Received: from solar.os.com (craigs@solar.os.com [199.232.136.65]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id GAA06871 for ; Fri, 8 Nov 1996 06:44:16 -0800 (PST) Received: (from craigs@localhost) by solar.os.com (8.7/8.7.0) id JAA19823; Fri, 8 Nov 1996 09:55:52 -0500 Date: Fri, 8 Nov 1996 09:55:51 -0500 From: Craig Shrimpton Subject: Re: The curtain is going down on 2.1-stable in 5 days! To: "Jordan K. Hubbard" cc: stable@freebsd.org In-Reply-To: <10472.847447745@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 8 Nov 1996, Jordan K. Hubbard wrote: > > So. David and I have decided that next Tuesday, the 12th of November, > would be an excellent time to start putting FreeBSD 2.1.6 to bed, and > if you've got any critical bug fixes or security problems to report in > 2.1-stable, now would be an excellent time to raise them before it's > too late. > Thanks for the "heads-up." What is the proper method for keeping a 2.1.5-RELEASE kernel up to date? Is it 2.1-STABLE (via sup) until the 12th or is another method recommended? -Craig +-----------------------------------+------------------------------------+ | Craig Shrimpton | e-mail: craigs@os.com | | Orbit Systems | information: info@os.com | | Worcester, MA 508.753.8776 | http://www.os.com/ | +-----------------------------------+------------------------------------+ From owner-freebsd-stable Fri Nov 8 06:54:10 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA07293 for stable-outgoing; Fri, 8 Nov 1996 06:54:10 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id GAA07288 for ; Fri, 8 Nov 1996 06:54:08 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.2/8.6.9) with ESMTP id GAA10585; Fri, 8 Nov 1996 06:50:19 -0800 (PST) To: Craig Shrimpton cc: stable@freebsd.org Subject: Re: The curtain is going down on 2.1-stable in 5 days! In-reply-to: Your message of "Fri, 08 Nov 1996 09:55:51 EST." Date: Fri, 08 Nov 1996 06:50:19 -0800 Message-ID: <10583.847464619@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Thanks for the "heads-up." What is the proper method for keeping a > 2.1.5-RELEASE kernel up to date? Is it 2.1-STABLE (via sup) until the 12th > or is another method recommended? 2.1-stable via CVSup (recommended over sup) or CTM, yes. Both will be maintained right up until the end (and, in the case of the former, for some time afterwards since a tag's a tag). Jordan From owner-freebsd-stable Fri Nov 8 07:28:03 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA12253 for stable-outgoing; Fri, 8 Nov 1996 07:28:03 -0800 (PST) Received: from eel.dataplex.net (eel.dataplex.net [208.2.87.2]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA12205 for ; Fri, 8 Nov 1996 07:27:55 -0800 (PST) Received: from [208.2.87.4] (cod [208.2.87.4]) by eel.dataplex.net (8.7.5/8.7.3) with ESMTP id JAA10857; Fri, 8 Nov 1996 09:27:25 -0600 (CST) X-Sender: rkw@mail.dataplex.net Message-Id: In-Reply-To: <199611081425.OAA19088@fty-ss20.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 8 Nov 1996 09:20:03 -0600 To: Frank Terhaar-Yonkers From: Richard Wackerbarth Subject: Re: CTM coredumps on src-2.1.0196.gz... Cc: andrew@aaaaaaaa.demon.co.uk, stable@freefall.freebsd.org Sender: owner-stable@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >You're not the only one. My system threw up on this patch as well. >Most (if not all) of the files it's trying to delete are not there, and >the rest >fail the MD5 checksum. I'm stuck at this CTM. It looks as if there is a problem. It happened when I was changing to CVSup and starting up the 2.2 feed. :-( I'll work out a fix tonight. I'll have to reconstruct things. In the interim, I'm turning the feed off. Hopefully I'll get it straight this weekend. From owner-freebsd-stable Fri Nov 8 07:38:21 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA14491 for stable-outgoing; Fri, 8 Nov 1996 07:38:21 -0800 (PST) Received: from eel.dataplex.net (eel.dataplex.net [208.2.87.2]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA14475 for ; Fri, 8 Nov 1996 07:38:17 -0800 (PST) Received: from [208.2.87.4] (cod [208.2.87.4]) by eel.dataplex.net (8.7.5/8.7.3) with ESMTP id JAA10997; Fri, 8 Nov 1996 09:38:08 -0600 (CST) X-Sender: rkw@mail.dataplex.net Message-Id: In-Reply-To: References: <10472.847447745@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 8 Nov 1996 09:35:27 -0600 To: Craig Shrimpton From: Richard Wackerbarth Subject: Re: The curtain is going down on 2.1-stable in 5 days! Cc: stable@freebsd.org Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Craig Shrimpton writes: >Thanks for the "heads-up." What is the proper method for keeping a >2.1.5-RELEASE kernel up to date? Is it 2.1-STABLE (via sup) until the 12th >or is another method recommended? Yes, use CVSup or CTM to track "-stable" which is the whole generation of 2.1 development. From owner-freebsd-stable Fri Nov 8 07:39:34 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA14803 for stable-outgoing; Fri, 8 Nov 1996 07:39:34 -0800 (PST) Received: from eel.dataplex.net (eel.dataplex.net [208.2.87.2]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA14785 for ; Fri, 8 Nov 1996 07:39:30 -0800 (PST) Received: from [208.2.87.4] (cod [208.2.87.4]) by eel.dataplex.net (8.7.5/8.7.3) with ESMTP id JAA11000; Fri, 8 Nov 1996 09:38:09 -0600 (CST) X-Sender: rkw@mail.dataplex.net Message-Id: In-Reply-To: <10583.847464619@time.cdrom.com> References: Your message of "Fri, 08 Nov 1996 09:55:51 EST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 8 Nov 1996 09:36:53 -0600 To: "Jordan K. Hubbard" From: Richard Wackerbarth Subject: Re: The curtain is going down on 2.1-stable in 5 days! Cc: stable@FreeBSD.ORG Sender: owner-stable@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> Thanks for the "heads-up." What is the proper method for keeping a >> 2.1.5-RELEASE kernel up to date? Is it 2.1-STABLE (via sup) until the 12th >> or is another method recommended? > >2.1-stable via CVSup (recommended over sup) or CTM, yes. Both will be >maintained right up until the end (and, in the case of the former, for >some time afterwards since a tag's a tag). And in the case of the latter, no changes == no mail :-) From owner-freebsd-stable Fri Nov 8 08:00:04 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA17097 for stable-outgoing; Fri, 8 Nov 1996 08:00:04 -0800 (PST) Received: from night.primate.wisc.edu (night.primate.wisc.edu [144.92.43.19]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA17058 for ; Fri, 8 Nov 1996 07:59:48 -0800 (PST) Received: (from dubois@localhost) by night.primate.wisc.edu (8.8.2/8.8.2) id KAA17338; Fri, 8 Nov 1996 10:00:32 -0600 (CST) Message-Id: <199611081600.KAA17338@night.primate.wisc.edu> Date: Fri, 8 Nov 1996 10:00:32 -0600 From: dubois@primate.wisc.edu (Paul DuBois) To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: stable@FreeBSD.org Subject: Re: The curtain is going down on 2.1-stable in 5 days! In-Reply-To: <10472.847447745@time.cdrom.com>; from Jordan K. Hubbard on Nov 8, 1996 02:09:05 -0800 References: <10472.847447745@time.cdrom.com> X-Mailer: Mutt 0.47 Mime-Version: 1.0 Sender: owner-stable@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Jordan K. Hubbard writes: > In case of problems encountered which cannot be attributed to pilot > error, please contact me as soon as possible. Let's test the heck out > of this and make 2.1.6 the kind of release that we'd be pleased to > recommend for commercial use for some time to come! What does it mean to recommend it "for commercial use"? I ask because it seems the FreeBSD project has somewhat conflicting goals. Let me illustrate using the yes-I-know-it's-a-sore-point illustration of IDE CD drives. I would expect that "for commericial use" means suitable for people to *use*, not hack on. That means when someone buys a CD-ROM set and then points out on one of the mailing lists that the installation fails to find his drive, it's not legitimate for the developers to respond (as they frequently do): 1) "Oh yeah!?! Why don't YOU fix the driver, then!" or 2) "Get a SCSI CD drive." These are not reasonable responses if the goal is for FreeBSD to be a system for *use*. A user wants to install FreeBSD and use it, not mess around hacking it, or working on development for it. Or having to ditch the kind of CD that increasingly is being shipped in today's systems. I understand that most of the developers have SCSI devices. I also understand that it's probably a bore to work on making IDE drivers work properly, especially given what an abominate the IDE standard apparently is. Still, letting this long-standing problem continue to go unresolved really doesn't help the goal of positioning an OS for commercial use. Note that I'm not complaining here (even though I have an IDE CD that the install has problems with). I'm simply commenting on what seems to be a contradictory goals: developer's paradise vs. user's system. I hope the point is clear enough and that no flame war will ensue. -- Paul DuBois dubois@primate.wisc.edu Home page: http://www.primate.wisc.edu/people/dubois Software: http://www.primate.wisc.edu/software From owner-freebsd-stable Fri Nov 8 08:49:52 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA21623 for stable-outgoing; Fri, 8 Nov 1996 08:49:52 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA21608 for ; Fri, 8 Nov 1996 08:49:48 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.2/8.6.9) with ESMTP id IAA00472; Fri, 8 Nov 1996 08:49:43 -0800 (PST) To: dubois@primate.wisc.edu (Paul DuBois) cc: stable@FreeBSD.org Subject: Re: The curtain is going down on 2.1-stable in 5 days! In-reply-to: Your message of "Fri, 08 Nov 1996 10:00:32 CST." <199611081600.KAA17338@night.primate.wisc.edu> Date: Fri, 08 Nov 1996 08:49:43 -0800 Message-ID: <470.847471783@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-stable@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > I would expect that "for commericial use" means suitable for people to > *use*, not hack on. That means when someone buys a CD-ROM set and then You haven't followed this to its logical conclusion, however, and one which the evidence we've gathered so far strongly supports: If you're truly *commercial*, you'll buy whatever you need to buy in order to make it work and achieve your end-goal (which is not fiddling with FreeBSD hardware). If you were smart enough to order your machine *after* consulting our supported hardware list and/or reading the recommendations I have up at http://www.freebsd.org/handbook/hw.html, it's not even any extra work. If you order your entire PC from an established BSD PC vendor like Rod Grimes, Apache Digital, or Telsys, it's less work still - the thing comes preloaded and ready to go. In all cases, if you're commercial then you don't spend a week jumping up and down in the mailing lists about, say, IDE CDROMs, you go "oh, I should have gotten a SCSI one? Bummer. OK, back in an hour - I'm off to the store again!" In fact, it's almost become something of a problem because dealing with buggy hardware reports can be a real chore when all you're able to note on the follow-up contact is "customer has already replaced hardware and moved on." In any case, people have gotten used to the fact that a lot of PC hardware out there is crap, and buying a machine to fit known specifications is only common sense in the PC market if you're actually trying to use it for serious work. Nonetheless, taking on another of your points: > find his drive, it's not legitimate for the developers to respond (as > they frequently do): > > 1) "Oh yeah!?! Why don't YOU fix the driver, then!" > or > 2) "Get a SCSI CD drive." Both can actually be perfectly legitimate responses, depending on the situation. 1. If you've got a burning need to have something work (be you a corporation or a private user) and there's nobody able to currently devote a week to jamming away on the problem for you, then yeah, you kinda have to do it yourself. Many of our best developers and code came from people in the throes of just such motivated self- interest. Simply crying about it certainly won't fix it, and there are only so many developer hours in the day (and lots of other tasks that someone *else* is clamoring for them to finish). This is an answer you should get used to until some kind foundation decides to throw a few $mil at me so that i can hire and house some full-time, accountable, engineering talent. 2. If you're a corporation, this is good advice. Buying a new SCSI drive will cost you $200-$300, plus an hour of someone's time to go pick it up if you don't order it over the phone. Say $400 total. Having a developer struggle for just one day with an IDE CDROM will easily cost you twice this much in lost productivity - it's just not worth it. If you're a user, this advice is somewhat less easy to take and maybe you don't want to hear it, in which case at worst you're a little annoyed. On the otherhand, perhaps you were already 90% decided to get a SCSI drive now that the NEC 8X SCSI drives have dropped down below $200, and our recommendation has simply sealed your decision. You get a drive that Just Works, life is good, the suggestion was actually positive. > Note that I'm not complaining here (even though I have an IDE CD that > the install has problems with). I'm simply commenting on what seems to > be a contradictory goals: developer's paradise vs. user's system. I > hope the point is clear enough and that no flame war will ensue. There are no contradictory goals, simply less emphasis on setting impractical ones for the sake of setting them. We're a volunteer organization and things get done as people find the time and energy to do them, period. I could write down "IDE CDROMS real problem. Big problem. Get someone on this immediately!!!" in my TODO list 20 times and it wouldn't necessarily achieve anything except to use up some more bytes on my disk. I'm already doing all I can do to solve the IDE CDROM problem (along with many others), and the solution will take as long as it takes. Jordan From owner-freebsd-stable Fri Nov 8 08:52:51 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA21843 for stable-outgoing; Fri, 8 Nov 1996 08:52:51 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id IAA21836; Fri, 8 Nov 1996 08:52:46 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA12255; Fri, 8 Nov 1996 09:42:43 -0700 From: Terry Lambert Message-Id: <199611081642.JAA12255@phaeton.artisoft.com> Subject: Re: Compile error To: kdupuis@dcs.stu.rpi.edu (Kenneth J. Dupuis) Date: Fri, 8 Nov 1996 09:42:42 -0700 (MST) Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org In-Reply-To: from "Kenneth J. Dupuis" at Nov 7, 96 11:26:25 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-stable@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > I just grabbed the latest -current via FTP and compiled it with no > problems. Its been up and running on a heavily-used server for about 3 > hours now. The only thing I can notice is that it takes a long time to > close a TCP/IP port that sendmail was using. It says that the connection > is "ESTABLISHED" long after the email has been delivered. > > Due to this problem and a lot of "open" ports I grabbed -stable and tried > to compile it. About 3/4 of the way through it exits with this error: > > param.c - timezone value does not match > > That's the best I can remember it right now. Anyone heard of this and > know a way to fix it? Is this inbound or outbound sendmail connections? For inbound connections, if your clients are WINSOCK machines, this is a well known problem with Microsoft engineers being unable (or unwilling) to read IETF documents and distinguish connection close packets from abort packets. If it's outbound, it's because the remote side did not do a correct teardown after the in-band "QUIT" was sent and acknowledged (in which case: "is the SMTP server running on an MS OS?"). 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-stable Fri Nov 8 09:00:37 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA22223 for stable-outgoing; Fri, 8 Nov 1996 09:00:37 -0800 (PST) Received: from neworder.cc.uky.edu (neworder.cc.uky.edu [128.163.18.198]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA22215 for ; Fri, 8 Nov 1996 09:00:32 -0800 (PST) Received: (from soward@localhost) by neworder.cc.uky.edu (8.7/Soward0.1) id MAA25192 for stable@FreeBSD.org; Fri, 8 Nov 1996 12:00:28 -0500 (EST) Message-Id: <199611081700.MAA25192@neworder.cc.uky.edu> MIME-Version: 1.0 (NeXT Mail 4.0 v141) Content-Type: text/plain Received: by NeXT.Mailer (1.141) From: John Soward Date: Fri, 8 Nov 96 12:00:27 -0500 To: stable@FreeBSD.org Subject: Re: The curtain is going down on 2.1-stable in 5 days! Reply-To: soward@service1.uky.edu References: <10472.847447745@time.cdrom.com> <199611081600.KAA17338@night.primate.wisc.edu> Organization: University of Kentucky Technical Services X-URL: "http://neworder.cc.uky.edu/" Sender: owner-stable@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > Note that I'm not complaining here (even though I have an IDE CD that > the install has problems with). I'm simply commenting on what seems to > be a contradictory goals: developer's paradise vs. user's system. I > hope the point is clear enough and that no flame war will ensue. > And even though this isn't a commercial endeavor, every 'Delveloper's paradise' system I've had the pleasure to witness has floundered and died, becasue developers need to develop for more that just other developers (e.g. NeXTSTEP ;-) --- John Soward JpS Systems Programmer 'The Midnight sun will burn you up.' University of Kentucky (NeXT and MIME mail OK) -R. Smith From owner-freebsd-stable Fri Nov 8 09:59:48 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA26219 for stable-outgoing; Fri, 8 Nov 1996 09:59:48 -0800 (PST) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA26193; Fri, 8 Nov 1996 09:59:37 -0800 (PST) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.7.5/8.7.3) id JAA00761; Fri, 8 Nov 1996 09:58:43 -0800 (PST) From: "Rodney W. Grimes" Message-Id: <199611081758.JAA00761@GndRsh.aac.dev.com> Subject: Re: The curtain is going down on 2.1-stable in 5 days! In-Reply-To: <199611081130.DAA19832@salsa.gv.ssi1.com> from Don Lewis at "Nov 8, 96 03:30:40 am" To: Don.Lewis@tsc.tdk.com (Don Lewis) Date: Fri, 8 Nov 1996 09:58:43 -0800 (PST) Cc: jkh@time.cdrom.com, stable@freebsd.org, freebsd-hardware@freebsd.org X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > On Nov 8, 2:09am, "Jordan K. Hubbard" wrote: > } Subject: The curtain is going down on 2.1-stable in 5 days! > } > } So. David and I have decided that next Tuesday, the 12th of November, > } would be an excellent time to start putting FreeBSD 2.1.6 to bed, and > } if you've got any critical bug fixes or security problems to report in > } 2.1-stable, now would be an excellent time to raise them before it's > } too late. > > Security: > the rwhod buffer overflow patch that's been circulating lately > > Bug fix: > The de driver doesn't work especially well with the SMC 9332 > 10/100 card. About one in ten times, it is initialized to some > funny state at boot time that causes the fault light on its > hub to flash and all the HP-UX boxes on that hub to shut down > their network interfaces. The de driver swiped from from -current > a few weeks ago and butchered so that compiles under -stable seems > to work perfectly. Judging by some of the comments in that version > of the driver, I suspect this problem may affect other cards with > the DC21140. Further notes on the if_de.c driver... D-Link has revised the DFE-500TX from revision B-1 to C-1, the card no longer works under RELENG_2_1_0, and infact behaves just like the Kingston KNE100TX card. So it now looks like the only card that I have qualified for 100MB/s operation is the SMC9332, and above is a report about problems with it :-(. Bottom line... the if_de.c driver in -stable is in need of some serious attention :-(. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation, Inc. Reliable computers for FreeBSD From owner-freebsd-stable Fri Nov 8 10:57:00 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA29618 for stable-outgoing; Fri, 8 Nov 1996 10:57:00 -0800 (PST) Received: from freefall.freebsd.org (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA29613; Fri, 8 Nov 1996 10:56:58 -0800 (PST) Message-Id: <199611081856.KAA29613@freefall.freebsd.org> To: dubois@primate.wisc.edu (Paul DuBois) cc: jkh@time.cdrom.com (Jordan K. Hubbard), stable@FreeBSD.org Subject: Re: The curtain is going down on 2.1-stable in 5 days! In-reply-to: Your message of "Fri, 08 Nov 1996 10:00:32 CST." <199611081600.KAA17338@night.primate.wisc.edu> Date: Fri, 08 Nov 1996 10:56:58 -0800 From: "Justin T. Gibbs" Sender: owner-stable@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >What does it mean to recommend it "for commercial use"? I ask because >it seems the FreeBSD project has somewhat conflicting goals. Let me >illustrate using the yes-I-know-it's-a-sore-point illustration of IDE >CD drives. It means "suitable for use in commercial applications". This means that people like ISPs, that need a stable realeas of FreeBSD should use 2.1.6. Most of the commercial users of FreeBSD stay far - far away from our ATAPI CDROM support because they know its broken and has been repeatedly documented as such. Fortunately, that doesn't prevent most commercial users from getting what they need to get done with FreeBSD done. >-- >Paul DuBois >dubois@primate.wisc.edu >Home page: http://www.primate.wisc.edu/people/dubois > Software: http://www.primate.wisc.edu/software -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-stable Fri Nov 8 12:11:30 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA05812 for stable-outgoing; Fri, 8 Nov 1996 12:11:30 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA05807 for ; Fri, 8 Nov 1996 12:11:28 -0800 (PST) Received: from deceased.hb.north.de (deceased.hb.north.de [194.94.232.249]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id MAA21538 for ; Fri, 8 Nov 1996 12:11:00 -0800 (PST) Received: from jelal.hb.north.de by deceased.hb.north.de with uucp (Smail3.2) id m0vLxCr-0016KJC; Fri, 8 Nov 1996 21:07:13 +0100 (MET) Received: by jelal.hb.north.de (SMail-ST 0.95gcc/2.5+) id AA00231; Fri, 8 Nov 1996 20:58:04 +0100 (CET) Received: (from nox@localhost) by saturn.hb.north.de (8.7.5/8.7.3) id TAA13349; Fri, 8 Nov 1996 19:44:37 +0100 (MET) Date: Fri, 8 Nov 1996 19:44:37 +0100 (MET) From: Juergen Lock Message-Id: <199611081844.TAA13349@saturn.hb.north.de> To: jkh@time.cdrom.com Subject: Re: The curtain is going down on 2.1-stable in 5 days! In-Reply-To: <10472.847447745@time.cdrom.com> Organization: none Cc: stable@freebsd.org Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <10472.847447745@time.cdrom.com> you write: >Basically, I need to get 2.1.6 off my plate if I'm to have any hope of >working constructively on 2.2, and managing 3 different branches >during this transitional period is also something of a headache which >I'd like to avoid prolonging. > >So. David and I have decided that next Tuesday, the 12th of November, >would be an excellent time to start putting FreeBSD 2.1.6 to bed, and >if you've got any critical bug fixes or security problems to report in >2.1-stable, now would be an excellent time to raise them before it's >too late. I don't know if its just me but has anyone tried building a -stable with the `international' des/secure stuff recently (using int-cvs-cur* off ftp.za.freebsd.org)? i haven't yet tried tracking this one down and really don't know if i'll get to in five days :) but just in case there really is something wrong there i thought i'd better ask... also here is an old list of things that may be worth merging: (i think only the first one actually went in at that time) >From nox Sun Jun 30 19:17:52 1996 >Subject: misc things possibly worth merging? >To: stable@freebsd.org >Date: Sun, 30 Jun 1996 19:17:52 +0200 (MET DST) This is from a cvs diff -u -rRELENG_2_1_0 which i just looked thru: (I guess there are many more little things of this kind... :) Index: src/gnu/usr.bin/ld/rrs.c =================================================================== RCS file: /home/cvs/cvs/src/gnu/usr.bin/ld/rrs.c,v retrieving revision 1.14 diff -u -r1.14 rrs.c --- rrs.c 1995/03/04 17:46:09 1.14 +++ rrs.c 1996/05/28 01:33:30 @@ -1185,6 +1185,7 @@ sodp[i].sod_library = 1; } else sodp[i].sod_library = 0; + sodp[i].sod_reserved = 0; pos += 1 + strlen(name); sodp[i].sod_next = (i == number_of_shobjs - 1) ? 0 : (thats from: revision 1.15 date: 1996/05/27 18:06:02; author: jdp; state: Exp; lines: +2 -1 Zero out an unused field in a structure that is written to the output file. The field formerly contained random garbage, leading to spurious differences between otherwise identical executables and libraries.) Index: src/sys/ddb/db_ps.c =================================================================== RCS file: /home/cvs/cvs/src/sys/ddb/db_ps.c,v retrieving revision 1.6.4.2 diff -u -r1.6.4.2 db_ps.c --- db_ps.c 1995/09/12 04:21:43 1.6.4.2 +++ db_ps.c 1996/06/15 10:39:48 @@ -82,6 +82,10 @@ return; } } + if (p == NULL) { + printf("oops, ran out of processes early!\n"); + break; + } pp = p->p_pptr; if (pp == NULL) pp = p; (from: revision 1.12 date: 1996/06/15 07:08:02; author: peter; state: Exp; lines: +5 -1 A small bit of defensive programming in case the panic is during process exit and cleanup. the 'ps' command assumes that there are always 'nproc' processes on the lists and will walk off the end without checking if not, causing ddb to trap during the 'ps' command. ) i have not yet had such a panic, just looked useful when i saw it... Index: src/usr.sbin/lpr/lpd/printjob.c =================================================================== RCS file: /home/cvs/cvs/src/usr.sbin/lpr/lpd/printjob.c,v retrieving revision 1.4.4.2 diff -u -r1.4.4.2 printjob.c --- printjob.c 1995/10/06 10:30:44 1.4.4.2 +++ printjob.c 1996/06/11 10:21:34 @@ -622,6 +622,13 @@ printer, format); return(ERROR); } + if (prog == NULL) { + (void) close(fi); + syslog(LOG_ERR, + "%s: no filter found in printcap for format character '%c'", + printer, format); + return(ERROR); + } if ((av[0] = rindex(prog, '/')) != NULL) av[0]++; else (from: revision 1.8 date: 1996/05/05 22:40:48; author: joerg; state: Exp; lines: +173 -75 Pull a bunch of fixes from the 4.4BSD-Lite2 branch. It's really surprising how many trivial errors there have been... :-) Some more cleanup is needed, but i'd like to separate the Lite2 changes from other work, that's why this goes into a different commit. People with serial printers should see whether i have broken the stty- style printcap options (i hope not). Inspired by: Sergey Shkonda ) this was after a lpr -dlqhi (which should have been lpr -P.. as you can guess) got me messages of coredumping lpd processes :) (haven't looked at the other fixes in that commit, i guess many of them could also go in?) and finally some USER_LDT fixes from current, they make wine work at least a little better. just in case someone still finds the time and look at this... Juergen Index: src/sys/i386/i386/machdep.c =================================================================== RCS file: /home/cvs/cvs/src/sys/i386/i386/machdep.c,v retrieving revision 1.128.4.8 diff -u -r1.128.4.8 machdep.c --- machdep.c 1996/06/25 20:19:29 1.128.4.8 +++ machdep.c 1996/06/26 19:44:34 @@ -1003,6 +1003,19 @@ { int *regs = p->p_md.md_regs; +#ifdef USER_LDT + struct pcb *pcb = &p->p_addr->u_pcb; + + /* was i386_user_cleanup() in NetBSD */ + if (pcb->pcb_ldt) { + if (pcb == curpcb) + lldt(GSEL(GUSERLDT_SEL, SEL_KPL)); + kmem_free(kernel_map, (vm_offset_t)pcb->pcb_ldt, + pcb->pcb_ldt_len * sizeof(union descriptor)); + pcb->pcb_ldt_len = (int)pcb->pcb_ldt = 0; + } +#endif + bzero(regs, sizeof(struct trapframe)); regs[tEIP] = entry; regs[tESP] = stack; Index: src/sys/i386/i386/sys_machdep.c =================================================================== RCS file: /home/cvs/cvs/src/sys/i386/i386/sys_machdep.c,v retrieving revision 1.9 diff -u -r1.9 sys_machdep.c --- sys_machdep.c 1995/05/30 07:59:40 1.9 +++ sys_machdep.c 1996/04/30 19:22:55 @@ -45,6 +45,13 @@ #include /* for kernel_map */ +#define MAX_LD 8192 +#define LD_PER_PAGE 512 +#define NEW_MAX_LD(num) ((num + LD_PER_PAGE) & ~(LD_PER_PAGE-1)) +#define SIZE_FROM_LARGEST_LD(num) (NEW_MAX_LD(num) << 3) + + + void set_user_ldt __P((struct pcb *pcb)); int i386_get_ldt __P((struct proc *, char *, int *)); int i386_set_ldt __P((struct proc *, char *, int *)); @@ -80,6 +87,10 @@ } #ifdef USER_LDT +/* + * Update the GDT entry pointing to the LDT to point to the LDT of the + * current process. + */ void set_user_ldt(struct pcb *pcb) { @@ -107,17 +118,19 @@ int nldt, num; union descriptor *lp; int s; - struct i386_get_ldt_args ua, *uap; + struct i386_get_ldt_args ua; + struct i386_get_ldt_args *uap = &ua; - if ((error = copyin(args, &ua, sizeof(struct i386_get_ldt_args))) < 0) + if ((error = copyin(args, uap, sizeof(struct i386_get_ldt_args))) < 0) return(error); - uap = &ua; #ifdef DEBUG - printf("i386_get_ldt: start=%d num=%d descs=%x\n", uap->start, uap->num, uap->desc); + printf("i386_get_ldt: start=%d num=%d descs=%x\n", uap->start, + uap->num, uap->desc); #endif - if (uap->start < 0 || uap->num < 0) + /* verify range of LDTs exist */ + if ((uap->start < 0) || (uap->num <= 0)) return(EINVAL); s = splhigh(); @@ -157,7 +170,9 @@ int *retval; { int error = 0, i, n; + int largest_ld; struct pcb *pcb = &p->p_addr->u_pcb; + union descriptor desc; union descriptor *lp; int s; struct i386_set_ldt_args ua, *uap; @@ -171,25 +186,36 @@ printf("i386_set_ldt: start=%d num=%d descs=%x\n", uap->start, uap->num, uap->desc); #endif - if (uap->start < 0 || uap->num < 0) - return(EINVAL); - - /* XXX Should be 8192 ! */ - if (uap->start > 512 || - (uap->start + uap->num) > 512) - return(EINVAL); - - /* allocate user ldt */ - if (!pcb->pcb_ldt) { - union descriptor *new_ldt = - (union descriptor *)kmem_alloc(kernel_map, 512*sizeof(union descriptor)); - bcopy(ldt, new_ldt, sizeof(ldt)); - pcb->pcb_ldt = (caddr_t)new_ldt; - pcb->pcb_ldt_len = 512; /* XXX need to grow */ -#ifdef DEBUG - printf("i386_set_ldt(%d): new_ldt=%x\n", p->p_pid, new_ldt); -#endif - } + /* verify range of descriptors to modify */ + if ((uap->start < NLDT) || (uap->start >= MAX_LD) || (uap->num < 0) || + (uap->num > MAX_LD)) + { + return(EINVAL); + } + largest_ld = uap->start + uap->num - 1; + if (largest_ld >= MAX_LD) + return(EINVAL); + + /* allocate user ldt */ + if (!pcb->pcb_ldt || (largest_ld >= pcb->pcb_ldt_len)) { + union descriptor *new_ldt = (union descriptor *)kmem_alloc( + kernel_map, SIZE_FROM_LARGEST_LD(largest_ld)); + if (new_ldt == NULL) { + return ENOMEM; + } + if (pcb->pcb_ldt) { + bcopy(pcb->pcb_ldt, new_ldt, pcb->pcb_ldt_len + * sizeof(union descriptor)); + kmem_free(kernel_map, (vm_offset_t)pcb->pcb_ldt, + pcb->pcb_ldt_len * sizeof(union descriptor)); + } else { + bcopy(ldt, new_ldt, sizeof(ldt)); + } + pcb->pcb_ldt = (caddr_t)new_ldt; + pcb->pcb_ldt_len = NEW_MAX_LD(largest_ld); + if (pcb == curpcb) + set_user_ldt(pcb); + } /* Check descriptors for access violations */ for (i = 0, n = uap->start; i < uap->num; i++, n++) { @@ -199,63 +225,71 @@ if (error) return(error); - /* Only user (ring-3) descriptors */ - if (desc.sd.sd_dpl != SEL_UPL) - return(EACCES); - - /* Must be "present" */ - if (desc.sd.sd_p == 0) - return(EACCES); - switch (desc.sd.sd_type) { - case SDT_SYSNULL: - case SDT_SYS286CGT: - case SDT_SYS386CGT: - break; - case SDT_MEMRO: - case SDT_MEMROA: - case SDT_MEMRW: - case SDT_MEMRWA: - case SDT_MEMROD: - case SDT_MEMRODA: - case SDT_MEME: - case SDT_MEMEA: - case SDT_MEMER: - case SDT_MEMERA: - case SDT_MEMEC: - case SDT_MEMEAC: - case SDT_MEMERC: - case SDT_MEMERAC: { -#if 0 - unsigned long base = (desc.sd.sd_hibase << 24)&0xFF000000; - base |= (desc.sd.sd_lobase&0x00FFFFFF); - if (base >= KERNBASE) - return(EACCES); -#endif + case SDT_SYSNULL: /* system null */ + desc.sd.sd_p = 0; + break; + case SDT_SYS286TSS: /* system 286 TSS available */ + case SDT_SYSLDT: /* system local descriptor table */ + case SDT_SYS286BSY: /* system 286 TSS busy */ + case SDT_SYSTASKGT: /* system task gate */ + case SDT_SYS286IGT: /* system 286 interrupt gate */ + case SDT_SYS286TGT: /* system 286 trap gate */ + case SDT_SYSNULL2: /* undefined by Intel */ + case SDT_SYS386TSS: /* system 386 TSS available */ + case SDT_SYSNULL3: /* undefined by Intel */ + case SDT_SYS386BSY: /* system 386 TSS busy */ + case SDT_SYSNULL4: /* undefined by Intel */ + case SDT_SYS386IGT: /* system 386 interrupt gate */ + case SDT_SYS386TGT: /* system 386 trap gate */ + case SDT_SYS286CGT: /* system 286 call gate */ + case SDT_SYS386CGT: /* system 386 call gate */ + /* I can't think of any reason to allow a user proc + * to create a segment of these types. They are + * for OS use only. + */ + return EACCES; + + /* memory segment types */ + case SDT_MEMEC: /* memory execute only conforming */ + case SDT_MEMEAC: /* memory execute only accessed conforming */ + case SDT_MEMERC: /* memory execute read conforming */ + case SDT_MEMERAC: /* memory execute read accessed conforming */ + /* Must be "present" if executable and conforming. */ + if (desc.sd.sd_p == 0) + return (EACCES); + break; + case SDT_MEMRO: /* memory read only */ + case SDT_MEMROA: /* memory read only accessed */ + case SDT_MEMRW: /* memory read write */ + case SDT_MEMRWA: /* memory read write accessed */ + case SDT_MEMROD: /* memory read only expand dwn limit */ + case SDT_MEMRODA: /* memory read only expand dwn lim accessed */ + case SDT_MEMRWD: /* memory read write expand dwn limit */ + case SDT_MEMRWDA: /* memory read write expand dwn lim acessed */ + case SDT_MEME: /* memory execute only */ + case SDT_MEMEA: /* memory execute only accessed */ + case SDT_MEMER: /* memory execute read */ + case SDT_MEMERA: /* memory execute read accessed */ break; - } default: - return(EACCES); + return(EINVAL); /*NOTREACHED*/ } + + /* Only user (ring-3) descriptors may be present. */ + if ((desc.sd.sd_p != 0) && (desc.sd.sd_dpl != SEL_UPL)) + return (EACCES); } s = splhigh(); /* Fill in range */ - for (i = 0, n = uap->start; i < uap->num && !error; i++, n++) { - union descriptor desc, *dp; - dp = &uap->desc[i]; - lp = &((union descriptor *)(pcb->pcb_ldt))[n]; -#ifdef DEBUG - printf("i386_set_ldt(%d): ldtp=%x\n", p->p_pid, lp); -#endif - error = copyin(dp, lp, sizeof(union descriptor)); - } - if (!error) { - *retval = uap->start; -/* need_resched(); */ - } + error = copyin(uap->desc, + &((union descriptor *)(pcb->pcb_ldt))[uap->start], + uap->num * sizeof(union descriptor)); + if (!error) + *retval = uap->start; splx(s); return(error); Index: src/sys/i386/i386/vm_machdep.c =================================================================== RCS file: /home/cvs/cvs/src/sys/i386/i386/vm_machdep.c,v retrieving revision 1.39.4.4 diff -u -r1.39.4.4 vm_machdep.c --- vm_machdep.c 1996/06/20 08:08:29 1.39.4.4 +++ vm_machdep.c 1996/06/22 21:00:02 @@ -580,10 +580,23 @@ cpu_exit(p) register struct proc *p; { +#ifdef USER_LDT + struct pcb *pcb; +#endif #if NNPX > 0 npxexit(p); #endif /* NNPX */ +#ifdef USER_LDT + pcb = &p->p_addr->u_pcb; + if (pcb->pcb_ldt != 0) { + if (pcb == curpcb) + lldt(GSEL(GUSERLDT_SEL, SEL_KPL)); + kmem_free(kernel_map, (vm_offset_t)pcb->pcb_ldt, + pcb->pcb_ldt_len * sizeof(union descriptor)); + pcb->pcb_ldt_len = (int)pcb->pcb_ldt = 0; + } +#endif cnt.v_swtch++; cpu_switch(p); panic("cpu_exit"); >From nox@jelal.hb.north.de Sat Aug 3 22:22:03 MET DST 1996 >Subject: another one (was: misc things possibly worth merging?) >Date: 10 Jul 1996 06:16:48 +0200 >Message-ID: <199607100340.FAA01767@saturn.hb.north.de> I wrote: > This is from a cvs diff -u -rRELENG_2_1_0 which i just looked thru: > (I guess there are many more little things of this kind... :) > > Index: src/gnu/usr.bin/ld/rrs.c > =================================================================== >... here is another one... Index: src/gnu/usr.bin/texinfo/info-files/dir =================================================================== RCS file: /home/cvs/cvs/src/gnu/usr.bin/texinfo/info-files/dir,v retrieving revision 1.3.4.3 diff -u -r1.3.4.3 dir --- dir 1996/06/05 02:44:02 1.3.4.3 +++ dir 1996/07/07 17:16:22 @@ -15,6 +15,9 @@ System utilities: * AMD: (amdref). AMD Reference Manual. +* CVS: (cvs). CVS Reference Manual. +* CVS-CLIENT: (cvsclient). CVS client/server Reference Manual. +* DIFF: (diff). DIFF/PATCH Reference Manual. * DC: (dc). The GNU desk calculator. * GAWK: (gawk). The GNU AWK language interpreter manual. * Info: (info). Manual for this documentation browsing system. @@ -43,6 +46,7 @@ * GXX Internals: (gxxint). Guide to the internals of the GNU C++ compiler. * GDB: (gdb). The GNU Debugger (C & C++) manual. * GDB Internals: (gdbint). Guide to the internals of GDB. +* GMP: (gmp). The GNU MP Math library. * History: (history). The GNU History library. * Readline: (readline). The GNU Readline library * Regex: (regex). The GNU regular expression library. cheers Juergen From owner-freebsd-stable Fri Nov 8 15:03:25 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA16384 for stable-outgoing; Fri, 8 Nov 1996 15:03:25 -0800 (PST) Received: from salsa.gv.ssi1.com (salsa.gv.ssi1.com [146.252.44.194]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA16378 for ; Fri, 8 Nov 1996 15:03:21 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.ssi1.com (8.7.5/8.7.3) id PAA21275; Fri, 8 Nov 1996 15:03:09 -0800 (PST) From: Don Lewis Message-Id: <199611082303.PAA21275@salsa.gv.ssi1.com> Date: Fri, 8 Nov 1996 15:03:09 -0800 In-Reply-To: Frank Terhaar-Yonkers "Re: CTM coredumps on src-2.1.0196.gz..." (Nov 8, 2:25pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Frank Terhaar-Yonkers , andrew@aaaaaaaa.demon.co.uk, stable@freefall.freebsd.org Subject: Re: CTM coredumps on src-2.1.0196.gz... Sender: owner-stable@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Nov 8, 2:25pm, Frank Terhaar-Yonkers wrote: } Subject: Re: CTM coredumps on src-2.1.0196.gz... } } You're not the only one. My system threw up on this patch as well. } Most (if not all) of the files it's trying to delete are not there, and the rest } fail the MD5 checksum. I'm stuck at this CTM. Interesting ... it works fine for me. FYI, I populated my source tree starting with src-2.1.0146A.gz. --- Truck From owner-freebsd-stable Fri Nov 8 15:27:05 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA18179 for stable-outgoing; Fri, 8 Nov 1996 15:27:05 -0800 (PST) Received: from salmon.maths.tcd.ie (mmdf@salmon.maths.tcd.ie [134.226.81.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA18170 for ; Fri, 8 Nov 1996 15:27:00 -0800 (PST) Received: from hamilton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id aa29259; 8 Nov 96 23:26 +0000 To: freebsd-stable@freebsd.org Subject: Background mounts occuring in the wrong order. Date: Fri, 08 Nov 1996 23:26:34 GMT From: David Malone Message-ID: <9611082326.aa29259@salmon.maths.tcd.ie> Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk We've been having some problems where when machines reboot they background their nfs mounts. After that the background mounts occur out of the order they are in fstab. So for our news stuff ( for instance ) we mount : /news /news/spool /news/var If the mount for either /news/var or /news spool is "sucessful" before /news they then fail because they don't have a directory to mount on. Somehow our SunOS 4.1.3 machines seem to handel this OK. I had a look at the source code for mount_nfs in 2.1.5-STABLE. I can think of two possible fixes : 1) Once the rpc call to the server goes OK retry for retrycnt times to do the mount call. 2) Do some sort of "build a tree of dependancies" and use this to determine the order in which mount calls are done. The first solution is easy to code, but a bit of a hack. The second would be clever -- probably too. Has anyone any suggestions ? I've tagged on some crude diffs for the first solution, they're a patch for mount_nfs.c ( I've had a look at one of the 2.2 snapshots and its no better ) David. 182d181 < int mount_retrycnt; 370,387c369,370 < if( opflags & ISBGRND ) < { < mount_retrycnt = retrycnt ; < while( mount_retrycnt > 0 ) < { < if (mount(vfc ? vfc->vfc_index : MOUNT_NFS, name, mntflags, nfsargsp)) < err(1, "%s", name); < else < mount_retrycnt = 0; < if( mount_retrycnt-- > 0 ) < sleep(120); < } < } < else < { < if (mount(vfc ? vfc->vfc_index : MOUNT_NFS, name, mntflags, nfsargsp)) < err(1, "%s", name); < } - - --- > if (mount(vfc ? vfc->vfc_index : MOUNT_NFS, name, mntflags, nfsargsp)) > err(1, "%s", name); 463d445 < int rpc_retrycnt = retrycnt; 539c521 < while (rpc_retrycnt > 0) { - - --- > while (retrycnt > 0) { 571c553 < rpc_retrycnt = 0; - - --- > retrycnt = 0; 575c557 < if (--rpc_retrycnt > 0) { - - --- > if (--retrycnt > 0) { From owner-freebsd-stable Fri Nov 8 16:35:50 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA22460 for stable-outgoing; Fri, 8 Nov 1996 16:35:50 -0800 (PST) Received: from salsa.gv.ssi1.com (salsa.gv.ssi1.com [146.252.44.194]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA22452; Fri, 8 Nov 1996 16:35:45 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.ssi1.com (8.7.5/8.7.3) id QAA21653; Fri, 8 Nov 1996 16:35:10 -0800 (PST) From: Don Lewis Message-Id: <199611090035.QAA21653@salsa.gv.ssi1.com> Date: Fri, 8 Nov 1996 16:35:09 -0800 In-Reply-To: Doug Rabson "Re: Weirdie in mountd perhaps you can help me with..." (Nov 8, 1:38pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Doug Rabson , "Jordan K. Hubbard" Subject: Re: Weirdie in mountd perhaps you can help me with... Cc: wpaul@freebsd.org, dfr@freebsd.org, stable@freebsd.org Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Nov 8, 1:38pm, Doug Rabson wrote: } Subject: Re: Weirdie in mountd perhaps you can help me with... } > } > The corresponding mount request also succeeds at the end of this timeout. } > } > Any ideas? } } My guess is that it is trying to DNS resolve a badly formed address. The } timeouts for this are pretty long. Impossible to tell without knowing the } arguments to gethostbyaddr and res_query :-(. That would be my suspicion. Try: env RES_OPTIONS=debug mountd -d to turn on debugging in the resolver and enable the undocumented mountd debug mode so that it doesn't go into the background. --- Truck From owner-freebsd-stable Fri Nov 8 16:37:08 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA22580 for stable-outgoing; Fri, 8 Nov 1996 16:37:08 -0800 (PST) Received: from salsa.gv.ssi1.com (salsa.gv.ssi1.com [146.252.44.194]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA22571; Fri, 8 Nov 1996 16:37:02 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.ssi1.com (8.7.5/8.7.3) id QAA21664; Fri, 8 Nov 1996 16:36:52 -0800 (PST) From: Don Lewis Message-Id: <199611090036.QAA21664@salsa.gv.ssi1.com> Date: Fri, 8 Nov 1996 16:36:52 -0800 In-Reply-To: Bill Paul "Re: Weirdie in mountd perhaps you can help me with..." (Nov 8, 6:37am) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Bill Paul , jkh@time.cdrom.com (Jordan K. Hubbard) Subject: Re: Weirdie in mountd perhaps you can help me with... Cc: dfr@render.com, dfr@FreeBSD.ORG, stable@FreeBSD.ORG Sender: owner-stable@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Nov 8, 6:37am, Bill Paul wrote: } Subject: Re: Weirdie in mountd perhaps you can help me with... } } You can also test it somewhat using the rpcinfo command by asking it to } ping mountd's NULLPROC (RPC procudure 0 is usually reserved for a null } function that basically acts as a loopback of sorts; rpcinfo can be used } to call the null procedure and if you get an answer, you know the RPC } server is still alive). If the process is blocked inside a select loop } in the DNS code though, I'm not sure you would get an immediate answer. I believe that you would not get an immediate answer, since the code is likely non-threaded and non-event driven other than the outer select() loop. --- Truck From owner-freebsd-stable Fri Nov 8 16:51:13 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA23498 for stable-outgoing; Fri, 8 Nov 1996 16:51:13 -0800 (PST) Received: from tahoma.cwu.edu (skynyrd@tahoma.cwu.edu [198.104.65.220]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA23492 for ; Fri, 8 Nov 1996 16:51:08 -0800 (PST) Received: by tahoma.cwu.edu; id AA02134; Fri, 8 Nov 1996 16:51:01 -0800 Date: Fri, 8 Nov 1996 16:51:01 -0800 (PST) From: Chris Timmons To: "Jordan K. Hubbard" Cc: stable@FreeBSD.ORG Subject: FDDI DRIVER: The curtain is going down on 2.1-stable in 5 days! In-Reply-To: <10472.847447745@time.cdrom.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-stable@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Matt Thomas mentioned sending updated FDDI code last summer which has at least one fix for fast CPUs. Additionally the 'unknown packet type' messages which have become a FAQ are zapped in the updated code. Considering the relatively small amount of work to integrate and the highly reliable source of the code, do you think it could be committed prior to 2.1.6? Regards, -Chris On Fri, 8 Nov 1996, Jordan K. Hubbard wrote: > Basically, I need to get 2.1.6 off my plate if I'm to have any hope of > working constructively on 2.2, and managing 3 different branches > during this transitional period is also something of a headache which > I'd like to avoid prolonging. > > So. David and I have decided that next Tuesday, the 12th of November, > would be an excellent time to start putting FreeBSD 2.1.6 to bed, and > if you've got any critical bug fixes or security problems to report in > 2.1-stable, now would be an excellent time to raise them before it's > too late. From owner-freebsd-stable Fri Nov 8 17:04:51 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA24197 for stable-outgoing; Fri, 8 Nov 1996 17:04:51 -0800 (PST) Received: from irbs.irbs.com (irbs.irbs.com [199.182.75.129]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA24189 for ; Fri, 8 Nov 1996 17:04:45 -0800 (PST) Received: (from jc@localhost) by irbs.irbs.com (8.8.2/8.8.0) id UAA15328; Fri, 8 Nov 1996 20:04:02 -0500 (EST) Message-Id: <199611090104.UAA15328@irbs.irbs.com> Date: Fri, 8 Nov 1996 20:04:02 -0500 From: jc@irbs.com (John Capo) To: freebsd-stable@freebsd.org Subject: ipfw LKM patches X-Mailer: Mutt 0.48.1 Mime-Version: 1.0 Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Index: lkm/Makefile =================================================================== RCS file: /usr/cvs/src/lkm/Makefile,v retrieving revision 1.9.4.4 diff -c -r1.9.4.4 Makefile *** Makefile 1996/06/23 13:47:31 1.9.4.4 --- Makefile 1996/09/13 22:34:36 *************** *** 1,7 **** # $Id$ # XXX present but broken: ip_mroute_mod mfs ! SUBDIR= cd9660 coff fdesc ibcs2 if_disc if_ppp if_sl if_tun \ kernfs linux msdos nfs nullfs \ portal procfs socksys syscons umapfs --- 1,7 ---- # $Id$ # XXX present but broken: ip_mroute_mod mfs ! SUBDIR= cd9660 coff fdesc ibcs2 if_disc if_ppp if_sl ipfw if_tun \ kernfs linux msdos nfs nullfs \ portal procfs socksys syscons umapfs Index: lkm/ipfw/Makefile =================================================================== RCS file: /usr/cvs/src/lkm/ipfw/Makefile,v retrieving revision 1.3 diff -c -r1.3 Makefile *** Makefile 1995/05/30 06:06:07 1.3 --- Makefile 1996/09/14 00:21:43 *************** *** 2,10 **** .PATH: ${.CURDIR}/../../sys/netinet KMOD= ipfw_mod ! SRCS= ipfw_lkm.c ip_fw.c NOMAN= ! CFLAGS+= -DIPFIREWALL -DIPACCT # #If you want it verbose #CFLAGS+= -DIPFIREWALL_VERBOSE --- 2,10 ---- .PATH: ${.CURDIR}/../../sys/netinet KMOD= ipfw_mod ! SRCS= ip_fw.c NOMAN= ! CFLAGS+= -DACTUALLY_LKM_NOT_KERNEL -DIPFIREWALL -DIPACCT # #If you want it verbose #CFLAGS+= -DIPFIREWALL_VERBOSE Index: sys/netinet/ip_fw.c =================================================================== RCS file: /usr/cvs/src/sys/netinet/ip_fw.c,v retrieving revision 1.14.4.9 diff -c -r1.14.4.9 ip_fw.c *** ip_fw.c 1996/06/25 03:16:41 1.14.4.9 --- ip_fw.c 1996/09/14 00:29:14 *************** *** 731,741 **** #ifdef ACTUALLY_LKM_NOT_KERNEL #include #include #include ! MOD_MISC(ipfw); static int ipfw_load(struct lkm_table *lkmtp, int cmd) --- 731,743 ---- #ifdef ACTUALLY_LKM_NOT_KERNEL + #include #include #include #include ! static int (*old_chk_ptr)(struct mbuf *, struct ip *, struct ifnet *, int dir); ! static int (*old_ctl_ptr)(int, struct mbuf **); static int ipfw_load(struct lkm_table *lkmtp, int cmd) *************** *** 770,778 **** return 0; } int ipfw_mod(struct lkm_table *lkmtp, int cmd, int ver) { ! DISPATCH(lkmtp, cmd, ver, ipfw_load, ipfw_unload, lkm_nullcmd); } #endif --- 772,782 ---- return 0; } + MOD_MISC("ipfw_mod") + int ipfw_mod(struct lkm_table *lkmtp, int cmd, int ver) { ! DISPATCH(lkmtp, cmd, ver, ipfw_load, ipfw_unload, nosys); } #endif From owner-freebsd-stable Fri Nov 8 17:26:51 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA26128 for stable-outgoing; Fri, 8 Nov 1996 17:26:51 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA26123 for ; Fri, 8 Nov 1996 17:26:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id RAA06679; Fri, 8 Nov 1996 17:24:40 -0800 (PST) Message-Id: <199611090124.RAA06679@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Chris Timmons cc: stable@FreeBSD.ORG Subject: Re: FDDI DRIVER: The curtain is going down on 2.1-stable in 5 days! In-reply-to: Your message of "Fri, 08 Nov 1996 16:51:01 PST." From: David Greenman Reply-To: dg@root.com Date: Fri, 08 Nov 1996 17:24:40 -0800 Sender: owner-stable@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Matt Thomas mentioned sending updated FDDI code last summer which has at >least one fix for fast CPUs. Additionally the 'unknown packet type' >messages which have become a FAQ are zapped in the updated code. > >Considering the relatively small amount of work to integrate and the >highly reliable source of the code, do you think it could be committed >prior to 2.1.6? Actually, it doesn't look that trivial to me. It requires a file reorganization at the very least. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-stable Fri Nov 8 18:07:13 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA28746 for stable-outgoing; Fri, 8 Nov 1996 18:07:13 -0800 (PST) Received: from netcomsv.netcom.com (uucp5.netcom.com [163.179.3.5]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id SAA28740 for ; Fri, 8 Nov 1996 18:07:11 -0800 (PST) Received: from asic11.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id RAA19355; Fri, 8 Nov 1996 17:41:10 -0800 Received: from madmax.iecorp.com by asic11.iecorp.com (4.1/SMI-4.1) id AA02886; Fri, 8 Nov 96 17:16:20 PST Received: by madmax.iecorp.com (4.1/SMI-4.1) id AA22888; Fri, 8 Nov 96 17:16:35 PST From: bartleym@iecorp.com (Matt Bartley) Message-Id: <9611090116.AA22888@madmax.iecorp.com> Subject: Re: CTM coredumps on src-2.1.0196.gz... To: freebsd-stable@freebsd.org Date: Fri, 8 Nov 1996 17:16:35 -0800 (PST) In-Reply-To: <199611082303.PAA21275@salsa.gv.ssi1.com> from "Don Lewis" at Nov 8, 96 03:03:09 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > On Nov 8, 2:25pm, Frank Terhaar-Yonkers wrote: > } You're not the only one. My system threw up on this patch as well. > } Most (if not all) of the files it's trying to delete are not there, and > } the rest > } fail the MD5 checksum. I'm stuck at this CTM. > Interesting ... it works fine for me. FYI, I populated my source tree > starting with src-2.1.0146A.gz. Same thing happened to me. I was tracking -stable starting from the 2.1.5 live filesystem, and it worked up until #196, at which point I got the errors described. Just today I deleted the source code tree, restarted from src-2.1.0146A.gz, and was able to CTM it all the way up through level 202. From owner-freebsd-stable Fri Nov 8 18:59:01 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA00897 for stable-outgoing; Fri, 8 Nov 1996 18:59:01 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA00887; Fri, 8 Nov 1996 18:58:58 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.7.6/8.7.3) with ESMTP id SAA28177; Fri, 8 Nov 1996 18:56:35 -0800 (PST) Message-Id: <199611090256.SAA28177@austin.polstra.com> To: nox@jelal.hb.north.de Subject: Re: The curtain is going down on 2.1-stable in 5 days! Newsgroups: polstra.freebsd.stable In-Reply-To: <199611081844.TAA13349@saturn.hb.north.de> References: <199611081844.TAA13349@saturn.hb.north.de> Organization: Polstra & Co., Seattle, WA Cc: stable@freebsd.org, jkh@freebsd.org Date: Fri, 08 Nov 1996 18:56:35 -0800 From: John Polstra Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199611081844.TAA13349@saturn.hb.north.de> nox@jelal.hb.north.de writes: > also here is an old list of things that may be worth merging: > (i think only the first one actually went in at that time) ... > Index: src/gnu/usr.bin/ld/rrs.c > =================================================================== > RCS file: /home/cvs/cvs/src/gnu/usr.bin/ld/rrs.c,v > retrieving revision 1.14 > diff -u -r1.14 rrs.c > --- rrs.c 1995/03/04 17:46:09 1.14 > +++ rrs.c 1996/05/28 01:33:30 > @@ -1185,6 +1185,7 @@ > sodp[i].sod_library = 1; > } else > sodp[i].sod_library = 0; > + sodp[i].sod_reserved = 0; Yes, I already merged this one in July. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-stable Fri Nov 8 23:32:03 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA12366 for stable-outgoing; Fri, 8 Nov 1996 23:32:03 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA12361 for ; Fri, 8 Nov 1996 23:32:01 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.2/8.6.9) with ESMTP id XAA17058; Fri, 8 Nov 1996 23:31:52 -0800 (PST) To: Chris Timmons cc: stable@FreeBSD.ORG Subject: Re: FDDI DRIVER: The curtain is going down on 2.1-stable in 5 days! In-reply-to: Your message of "Fri, 08 Nov 1996 16:51:01 PST." Date: Fri, 08 Nov 1996 23:31:52 -0800 Message-ID: <17056.847524712@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-stable@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Considering the relatively small amount of work to integrate and the > highly reliable source of the code, do you think it could be committed > prior to 2.1.6? Well, my first impulse is to say "why wait this late?! We can't even test it now! :-(" But I don't know how many people are even using FDDI under 2.1.5. What do the folks here who actually have a vested interest in this issue think? On general principles, this is simply too late. An exception might be possible if I really get the feeling that it's not going to come back to haunt me, like some 11th hour changes in 2.1.5 did. :-( Jordan From owner-freebsd-stable Sat Nov 9 02:43:54 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA19452 for stable-outgoing; Sat, 9 Nov 1996 02:43:54 -0800 (PST) Received: from david.siemens.de (david.siemens.de [146.254.1.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id CAA19446 for ; Sat, 9 Nov 1996 02:43:50 -0800 (PST) Received: from salomon.mchp.siemens.de (salomon.mchp.siemens.de [139.23.33.13]) by david.siemens.de (8.8.0/8.8.0) with ESMTP id LAA16546 for ; Sat, 9 Nov 1996 11:40:20 +0100 (MET) Received: from curry.zfe.siemens.de (root@curry.zfe.siemens.de [146.180.31.23]) by salomon.mchp.siemens.de (8.8.2/8.8.0) with ESMTP id LAA13281 for ; Sat, 9 Nov 1996 11:43:47 +0100 (MET) Received: from server.us.tld (server.us.tld [192.168.16.33]) by curry.zfe.siemens.de (8.8.2/8.8.2) with ESMTP id LAA24505 for ; Sat, 9 Nov 1996 11:43:45 +0100 (MET) Received: from indy.us.tld (indy.us.tld [192.168.20.4]) by server.us.tld (8.8.2/8.8.2) with ESMTP id LAA10957 for ; Sat, 9 Nov 1996 11:43:45 +0100 (MET) Received: (from andre@localhost) by indy.us.tld (8.8.2/8.8.2) id LAA28736 for freebsd-stable@freebsd.org; Sat, 9 Nov 1996 11:43:42 +0100 (MET) From: Andre Albsmeier Message-Id: <199611091043.LAA28736@indy.us.tld> Subject: LINT for 2.1.5 stable To: freebsd-stable@freebsd.org Date: Sat, 9 Nov 1996 11:43:42 +0100 (MET) X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > So. David and I have decided that next Tuesday, the 12th of November, > would be an excellent time to start putting FreeBSD 2.1.6 to bed, and > if you've got any critical bug fixes or security problems to report in > 2.1-stable, now would be an excellent time to raise them before it's > too late. OK, here we go :-) In LINT we find the follwing two things: ----------------- Part 1 ----------------------- # BOUNCE_BUFFERS provides support for ISA DMA on machines with more # than 16 megabytes of memory. It doesn't hurt on other machines. # Some broken EISA and VLB hardware may need this, too. pseudo-device ccd 4 #Concatenated disk driver # # DUMMY_NOPS disables extra delays for some bus operations. The delays # are mostly for older systems and aren't used consistently. Probably # works OK on most EISA bus machines. --------------- Part 2 ----------------------- # The `tun' pseudo-device implements the User Process PPP (iijppp) # pseudo-device ether #Generic Ethernet pseudo-device fddi #Generic FDDI pseudo-device sppp #Generic Synchronous PPP options USERCONFIG_BOOT #imply -c and parse info area pseudo-device loop #Network loopback device pseudo-device sl 2 #Serial Line IP pseudo-device ppp 2 #Point-to-point protocol pseudo-device bpfilter 4 #Berkeley packet filter pseudo-device disc #Discard device pseudo-device tun 1 #Tunnel driver(user process ppp) ---------------------------------------------- Shouldn't the ccd line and the USERCONFIG_BOOT line be put somwhere else? I just looke at the LINT at ftp.FreeBSD.org to ensure I didn't break something at home, but it is the same. Just wondering... Andre From owner-freebsd-stable Sat Nov 9 05:32:15 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA26789 for stable-outgoing; Sat, 9 Nov 1996 05:32:15 -0800 (PST) Received: from dfw-ix10.ix.netcom.com (dfw-ix10.ix.netcom.com [206.214.98.10]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id FAA26782 for ; Sat, 9 Nov 1996 05:32:11 -0800 (PST) Received: from baloon.mimi.com (sjx-ca34-11.ix.netcom.com [204.31.236.107]) by dfw-ix10.ix.netcom.com (8.6.13/8.6.12) with ESMTP id FAA03075; Sat, 9 Nov 1996 05:31:39 -0800 Received: (from asami@localhost) by baloon.mimi.com (8.8.2/8.6.12) id FAA11567; Sat, 9 Nov 1996 05:31:37 -0800 (PST) Date: Sat, 9 Nov 1996 05:31:37 -0800 (PST) Message-Id: <199611091331.FAA11567@baloon.mimi.com> To: jkh@time.cdrom.com CC: stable@freebsd.org In-reply-to: <10472.847447745@time.cdrom.com> (jkh@time.cdrom.com) Subject: Re: The curtain is going down on 2.1-stable in 5 days! From: asami@freebsd.org (Satoshi Asami) Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk * So. David and I have decided that next Tuesday, the 12th of November, * would be an excellent time to start putting FreeBSD 2.1.6 to bed, and * if you've got any critical bug fixes or security problems to report in * 2.1-stable, now would be an excellent time to raise them before it's * too late. I will put in the latest bsd.port.mk (there should not be any difference between -current and -stable) before that, but it will likely change again. Is it ok to swap it right before the release? Satoshi From owner-freebsd-stable Sat Nov 9 05:44:09 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA28999 for stable-outgoing; Sat, 9 Nov 1996 05:44:09 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA28992; Sat, 9 Nov 1996 05:44:04 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.2/8.6.9) with ESMTP id FAA09849; Sat, 9 Nov 1996 05:44:04 -0800 (PST) To: asami@freebsd.org (Satoshi Asami) cc: stable@freebsd.org Subject: Re: The curtain is going down on 2.1-stable in 5 days! In-reply-to: Your message of "Sat, 09 Nov 1996 05:31:37 PST." <199611091331.FAA11567@baloon.mimi.com> Date: Sat, 09 Nov 1996 05:44:04 -0800 Message-ID: <9847.847547044@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I will put in the latest bsd.port.mk (there should not be any > difference between -current and -stable) before that, but it will > likely change again. Is it ok to swap it right before the release? Sure, just so long as it works, and you'd be the best judge of that. :-) How goes the 2.1 package building, BTW? Jordan From owner-freebsd-stable Sat Nov 9 06:34:05 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA01425 for stable-outgoing; Sat, 9 Nov 1996 06:34:05 -0800 (PST) Received: from tahoma.cwu.edu (skynyrd@tahoma.cwu.edu [198.104.65.220]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id GAA01420 for ; Sat, 9 Nov 1996 06:34:03 -0800 (PST) Received: by tahoma.cwu.edu; id AA01987; Sat, 9 Nov 1996 06:33:57 -0800 Date: Sat, 9 Nov 1996 06:33:57 -0800 (PST) From: Chris Timmons To: "Jordan K. Hubbard" Cc: stable@FreeBSD.ORG Subject: Re: FDDI DRIVER: The curtain is going down on 2.1-stable in 5 days! In-Reply-To: <17056.847524712@time.cdrom.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-stable@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Oops... this will teach me to to read before I leap! As David G. pointed out the changes are more than just drop-in replacements; I should have been more careful to complete the research before I spoke up. I think you're right; it is too late for 2.1.6 and probably 2.2. I'm shuffling hardware at the moment but will hopefully have the P5/166 defpa machine upgraded to a P6/200 in a couple of weeks - I'll try the new driver in 3.0-current and make a more credible report/integration request at that time. With respect to 2.1.6, how about this small comprimise: remove the two offending printf()'s in fddi_input() to keep the message buffer from overflowing with debug output when an fddi ring has something other than IP on it (kern/1859). There seemed to be some consensus for doing this when I brought it up in -hackers a little while ago. -Chris On Fri, 8 Nov 1996, Jordan K. Hubbard wrote: > > Considering the relatively small amount of work to integrate and the > > highly reliable source of the code, do you think it could be committed > > prior to 2.1.6? > > Well, my first impulse is to say "why wait this late?! We can't even > test it now! :-(" But I don't know how many people are even using FDDI > under 2.1.5. What do the folks here who actually have a vested > interest in this issue think? On general principles, this is simply > too late. An exception might be possible if I really get the feeling > that it's not going to come back to haunt me, like some 11th hour > changes in 2.1.5 did. :-( > > Jordan > From owner-freebsd-stable Sat Nov 9 06:39:07 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA01585 for stable-outgoing; Sat, 9 Nov 1996 06:39:07 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id GAA01578 for ; Sat, 9 Nov 1996 06:39:04 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.2/8.6.9) with ESMTP id GAA11488; Sat, 9 Nov 1996 06:39:02 -0800 (PST) To: Chris Timmons cc: stable@FreeBSD.ORG Subject: Re: FDDI DRIVER: The curtain is going down on 2.1-stable in 5 days! In-reply-to: Your message of "Sat, 09 Nov 1996 06:33:57 PST." Date: Sat, 09 Nov 1996 06:39:02 -0800 Message-ID: <11486.847550342@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-stable@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > With respect to 2.1.6, how about this small comprimise: remove the two > offending printf()'s in fddi_input() to keep the message buffer from > overflowing with debug output when an fddi ring has something other than > IP on it (kern/1859). There seemed to be some consensus for doing this > when I brought it up in -hackers a little while ago. Well, let's see what David comes up with, and I will make that change for 2.1.6 if nothing else is done. I don't want to make the mods now only to have the entire file change out from under. Your version of the de driver fixes aren't actually the only ones, and there may be some more attractive alternatives yet available. David's call in any case. Jordan From owner-freebsd-stable Sat Nov 9 07:29:22 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA03908 for stable-outgoing; Sat, 9 Nov 1996 07:29:22 -0800 (PST) Received: from arl-img-2.compuserve.com (arl-img-2.compuserve.com [149.174.217.132]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id HAA03899 for ; Sat, 9 Nov 1996 07:29:19 -0800 (PST) Received: by arl-img-2.compuserve.com (8.6.10/5.950515) id KAA01326; Sat, 9 Nov 1996 10:28:46 -0500 Date: 09 Nov 96 10:27:55 EST From: Berend de Boer <100120.3121@CompuServe.COM> To: FreeBSD stable Subject: Intel Atlantis board problems Message-ID: <961109152754_100120.3121_EHQ49-1@CompuServe.COM> Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello All, We had some severe problems installing FreeBSD 2.1.5 from the Walnut Creet CD Rom on an Intel Atlantis board (AS/Advanced it's called now). One of the options its bios has is that it recognizes IDE cd-roms. That gives nice results when installing FreeBSD on the 2nd hard-drive (at least I think that is the problem). This system has two ide hd controllers. The first controller has an 1GB IDE and a CD-rom attached, the 2nd controller has a 2GB IDE drive. When installing FreeBSD on the 2nd harddrive drive it thinks it is installing on wd2. After installation, when you reboot, you reboot the kernel with wd(2,a)/kernel. The kernel loads fine, however at the end of the boot process it tries to mount root on wd1. I'm not sure who's to blame here, but I think this is going to be a common problem with PnP boards?? OK, next we installed on the first drive. Installation went ok. Now if you try to boot you get the ':' prompt. If you press Enter it reboots. If you type wd(0,a)/kernel it boots fine. Luckily we have the source (and some spare time). Here some info printed by the openrd function in sys.c: If you press Enter after the ':' prompt you get: dosdev=3b, biosdrive=59, unit=59, maj=2 (and the system reboots spontanuously) If you enter 'wd(0,a)/kernel' it says: dosdev=80, biosdrive=0, unit=0, maj=0 (and boots fine) We tracked this problem down until the boot function in boot.c. It has a drive parameter with value 0x333b. The fix is easy: add a line drive = 0x80; as the first line of boot()... Can someone help us further? We are trying to figure out who is calling boot with this strange parameter. But if someone has that information or a pointer to where we can find that information that would be nice. Groetjes, Berend. (-: From owner-freebsd-stable Sat Nov 9 10:49:13 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA13668 for stable-outgoing; Sat, 9 Nov 1996 10:49:13 -0800 (PST) Received: from gvr.win.tue.nl (gvr.win.tue.nl [131.155.210.19]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA13663 for ; Sat, 9 Nov 1996 10:49:06 -0800 (PST) Received: (from guido@localhost) by gvr.win.tue.nl (8.8.2/8.8.2) id TAA00304; Sat, 9 Nov 1996 19:48:20 +0100 (MET) From: Guido van Rooij Message-Id: <199611091848.TAA00304@gvr.win.tue.nl> Subject: Re: Intel Atlantis board problems In-Reply-To: <961109152754_100120.3121_EHQ49-1@CompuServe.COM> from Berend de Boer at "Nov 9, 96 10:27:55 am" To: 100120.3121@CompuServe.COM (Berend de Boer) Date: Sat, 9 Nov 1996 19:48:19 +0100 (MET) Cc: freebsd-stable@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > OK, next we installed on the first drive. Installation went ok. > > Now if you try to boot you get the ':' prompt. If you press Enter it reboots. If > you type wd(0,a)/kernel it boots fine. > > Luckily we have the source (and some spare time). Here some info printed by the > openrd function in sys.c: > > If you press Enter after the ':' prompt you get: > > dosdev=3b, biosdrive=59, unit=59, maj=2 > > (and the system reboots spontanuously) > > If you enter 'wd(0,a)/kernel' it says: > > dosdev=80, biosdrive=0, unit=0, maj=0 > > (and boots fine) > This looks like a similar problem I found. Try to edit /sys/i386/boot/biosboot/boot.c Look for this line: for(ret = 0; ret < N_BIOS_GEOM; ret ++) Replace N_BIOS_GEOM by 3 (which is the number of devices you have on you hd controllers). Then type make make install cd /usr/mdec disklabel -B wd0 If I'm correct, this would solve the fact that FreeBSD does not automatically boots from wd(0,a)/kernel. Could you report back to this list if this fixes it? -Guido From owner-freebsd-stable Sat Nov 9 12:10:18 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA17543 for stable-outgoing; Sat, 9 Nov 1996 12:10:18 -0800 (PST) Received: from hil-img-6.compuserve.com (hil-img-6.compuserve.com [149.174.177.136]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA17538 for ; Sat, 9 Nov 1996 12:10:14 -0800 (PST) Received: by hil-img-6.compuserve.com (8.6.10/5.950515) id PAA13739; Sat, 9 Nov 1996 15:09:38 -0500 Date: 09 Nov 96 15:08:34 EST From: Berend de Boer <100120.3121@CompuServe.COM> To: FreeBSD stable Subject: Follow on Atlantis board Message-ID: <961109200834_100120.3121_EHQ22-1@CompuServe.COM> Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Some more info: in start.S (called immediately after booteasy passes control?) we added a mov $0x0080, %edx so the code looks like: /* bootstrap passes us drive number in %dl */ mov $0x0080, %edx cmpb $0x80, %dl data32 jae hd However in boot() in boot.c drive is still 0x333b. After that we removed this line, and added it to the last lines of boot2.S: mov $0x0080, %edx movzbl %dl, %edx /* discard head (%dh) and random high bits */ pushl %edx call EXT(boot) Still in boot() drive was 0x333b... I thought i went crazy. Next we added a printf(drive) immediately after the boot() int ret with the above patch intact. We also had a printf before the dosdev = drive; line. Now the first printf showed 0x0080, but the 2nd was 0x333b. It seemed boot() was screwing up the stack somehow?? After some printf's the following line screws the stack: for(ret = 0; ret < N_BIOS_GEOM; ret ++) bootinfo.bi_bios_geom[ret] = get_diskinfo(ret + 0x80); I think it's get_diskinfo. But get_diskinfo seems too difficult for me to investigate. Maybe some FreeBSD boot guru has an idea? Groetjes, Berend. From owner-freebsd-stable Sat Nov 9 12:35:51 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA18968 for stable-outgoing; Sat, 9 Nov 1996 12:35:51 -0800 (PST) Received: from gvr.win.tue.nl (root@gvr.win.tue.nl [131.155.210.19]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA18960 for ; Sat, 9 Nov 1996 12:35:39 -0800 (PST) Received: (from guido@localhost) by gvr.win.tue.nl (8.8.2/8.8.2) id VAA02746; Sat, 9 Nov 1996 21:35:21 +0100 (MET) From: Guido van Rooij Message-Id: <199611092035.VAA02746@gvr.win.tue.nl> Subject: Re: Follow on Atlantis board In-Reply-To: <961109200834_100120.3121_EHQ22-1@CompuServe.COM> from Berend de Boer at "Nov 9, 96 03:08:34 pm" To: 100120.3121@CompuServe.COM (Berend de Boer) Date: Sat, 9 Nov 1996 21:35:21 +0100 (MET) Cc: freebsd-stable@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Have you applied my patch? -Guido From owner-freebsd-stable Sat Nov 9 13:02:50 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA20173 for stable-outgoing; Sat, 9 Nov 1996 13:02:50 -0800 (PST) Received: from arl-img-5.compuserve.com (arl-img-5.compuserve.com [149.174.217.135]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA20166 for ; Sat, 9 Nov 1996 13:02:44 -0800 (PST) Received: by arl-img-5.compuserve.com (8.6.10/5.950515) id QAA18365; Sat, 9 Nov 1996 16:02:12 -0500 Date: 09 Nov 96 15:59:34 EST From: Berend de Boer <100120.3121@CompuServe.COM> To: FreeBSD stable Subject: Re: Intel Atlantis board problems Message-ID: <961109205933_100120.3121_EHQ79-1@CompuServe.COM> Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Look for this line: for(ret = 0; ret < N_BIOS_GEOM; ret ++) > Replace N_BIOS_GEOM by 3 (which is the number of devices you have > on you hd controllers). It didn't help. Thanks for the message, Berend. (-: From owner-freebsd-stable Sat Nov 9 15:20:20 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA27799 for stable-outgoing; Sat, 9 Nov 1996 15:20:20 -0800 (PST) Received: from pat.idt.unit.no (pat.idt.unit.no [129.241.103.5]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA27772; Sat, 9 Nov 1996 15:20:08 -0800 (PST) Received: from idt.unit.no (hyll.idt.unit.no [129.241.200.3]) by pat.idt.unit.no (8.7.5/8.7.3) with ESMTP id AAA04767; Sun, 10 Nov 1996 00:19:56 +0100 (MET) Message-Id: <199611092319.AAA04767@pat.idt.unit.no> To: 100120.3121@compuserve.com Cc: freebsd-stable@freebsd.org, freebsd-current@freebsd.org Subject: Re: Follow on Atlantis board In-Reply-To: Your message of "09 Nov 96 15:08:34 EST" References: <961109200834_100120.3121_EHQ22-1@CompuServe.COM> X-Mailer: Mew version 1.06 on Emacs 19.31.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Sun, 10 Nov 1996 00:19:55 +0100 From: Tor Egge Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [ cc-ed to freebsd-current due to boot blocks in -current still being oversensitive to bios quirks ] > Some more info: > > in start.S (called immediately after booteasy passes control?) we added a > > mov $0x0080, %edx > > so the code looks like: > > /* bootstrap passes us drive number in %dl */ > mov $0x0080, %edx > cmpb $0x80, %dl > data32 > jae hd > > However in boot() in boot.c drive is still 0x333b. > > After that we removed this line, and added it to the last lines of boot2.S: > > mov $0x0080, %edx > movzbl %dl, %edx /* discard head (%dh) and random high bits */ > pushl %edx > call EXT(boot) > > Still in boot() drive was 0x333b... I thought i went crazy. > > Next we added a printf(drive) immediately after the boot() int ret with the > above patch intact. We also had a printf before the dosdev = drive; line. Now > the first printf showed 0x0080, but the 2nd was 0x333b. > > It seemed boot() was screwing up the stack somehow?? After some printf's > the following line screws the stack: > > for(ret = 0; ret < N_BIOS_GEOM; ret ++) > bootinfo.bi_bios_geom[ret] = get_diskinfo(ret + 0x80); > > I think it's get_diskinfo. But get_diskinfo seems too difficult for me to > investigate. Maybe some FreeBSD boot guru has an idea? I'm not a FreeBSD boot guru, but I've had similar problems using NetBSD boot blocks, due to a combination of the bios not preserving the upper 16 bits in registers, and the boot blocks not saving/restoring the correct registers in the routines calling bios. When using gdb on /usr/obj/usr/src/sys/i386/boot/biosboot/boot in FreeBSD 3.0-current and disassembling the boot function, you'll see that early in the function, the boot device is placed in %edi. The compiler correctly (according to the calling conventions) assumes that %edi is not modified by any routine called. Both memsize() and get_diskinfo() are called before the content of %edi is saved in the dosdev variable. They have a good chance of stomping upon the contents of %edi on some bioses. FreeBSD is not alone with these problems: I have a 486 with a DC-2000VL IDE controller that runs NetBSD 1.2 behind me. Standard NetBSD 1.2 boot blocks just freezes, when loading a kernel from the IDE drive. Loading the same kernel from a floppy with the same boot blocks works. Saving/restoring the appropiate registers in the routines that calls bios and changing prot_to_real to use ljmp instead of lret caused all these problems to disappear. Cut from /usr/src/contrib/gcc/config/i386/i386.h: ---- /* 1 for registers not available across function calls. These must include the FIXED_REGISTERS and also any registers that can be used without being saved. The latter must include the registers where values are returned and the register where structure-value addresses are passed. Aside from that, you can include as many other registers as you like. */ #define CALL_USED_REGISTERS \ /*ax,dx,cx,bx,si,di,bp,sp,st,st1,st2,st3,st4,st5,st6,st7,arg*/ \ { 1, 1, 1, 0, 0, 0, 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1 } ---- This means that it's OK to clobber most registers except %ebx, %esi, %edi and %ebp. (%eax is a special case, it may contain a return value). Thus, I recommend a patch similar to this one (which is for FreeBSD 3.0-current): Index: asm.S =================================================================== RCS file: /export/akg1/cvs/src/sys/i386/boot/biosboot/asm.S,v retrieving revision 1.9 diff -u -r1.9 asm.S --- asm.S 1996/03/08 07:27:52 1.9 +++ asm.S 1996/11/09 21:28:48 @@ -221,7 +221,6 @@ push %es push %esi push %edi - push %ecx cld @@ -236,7 +235,6 @@ rep stosb - pop %ecx pop %edi pop %esi pop %es @@ -254,7 +252,6 @@ push %es push %esi push %edi - push %ecx cld @@ -269,7 +266,6 @@ rep movsb - pop %ecx pop %edi pop %esi pop %es Index: bios.S =================================================================== RCS file: /export/akg1/cvs/src/sys/i386/boot/biosboot/bios.S,v retrieving revision 1.5 diff -u -r1.5 bios.S --- bios.S 1995/09/03 05:36:13 1.5 +++ bios.S 1996/11/09 21:33:29 @@ -75,8 +75,8 @@ mov %esp, %ebp push %ebx - push %ecx - push %edx + push %esi + push %edi push %es movb 0x10(%ebp), %dh @@ -110,8 +110,8 @@ movb %bh, %al /* return value in %ax */ pop %es - pop %edx - pop %ecx + pop %edi + pop %esi pop %ebx pop %ebp @@ -132,7 +132,8 @@ push %ebp mov %esp, %ebp push %ebx - push %ecx + push %esi + push %edi movb 0x8(%ebp), %cl @@ -149,7 +150,8 @@ data32 call EXT(real_to_prot) - pop %ecx + pop %edi + pop %esi pop %ebx pop %ebp ret @@ -167,6 +169,8 @@ push %ebp mov %esp, %ebp push %ebx /* save %ebx */ + push %esi + push %edi call EXT(prot_to_real) @@ -183,6 +187,8 @@ xor %eax, %eax movb %bl, %al + pop %edi + pop %esi pop %ebx pop %ebp ret @@ -203,6 +209,8 @@ push %ebp mov %esp, %ebp push %ebx + push %esi + push %edi call EXT(prot_to_real) /* enter real mode */ @@ -222,6 +230,8 @@ xor %eax, %eax movb %bl, %al + pop %edi + pop %esi pop %ebx pop %ebp ret @@ -238,8 +248,8 @@ mov %esp, %ebp push %es push %ebx - push %ecx - push %edx + push %esi + push %edi movb 0x8(%ebp), %dl /* diskinfo(drive #) */ call EXT(prot_to_real) /* enter real mode */ @@ -288,8 +298,8 @@ andb $0x3f, %cl /* mask of cylinder gunk */ movb %cl, %al /* max sector (and # sectors) */ - pop %edx - pop %ecx + pop %edi + pop %esi pop %ebx pop %es pop %ebp @@ -309,6 +319,8 @@ push %ebp mov %esp, %ebp push %ebx + push %esi + push %edi mov 8(%ebp), %ebx @@ -336,6 +348,8 @@ call EXT(real_to_prot) mov %ebx, %eax + pop %edi + pop %esi pop %ebx pop %ebp ret -------- - Tor Egge