From owner-freebsd-stable Tue Dec 19 00:10:44 1995 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA29778 for stable-outgoing; Tue, 19 Dec 1995 00:10:44 -0800 (PST) Received: from mail.barrnet.net (mail.barrnet.net [131.119.246.7]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id AAA29773 for ; Tue, 19 Dec 1995 00:10:42 -0800 (PST) Received: from sunny.bog.msu.su (sunny.bog.msu.su [158.250.20.1]) by mail.barrnet.net (8.7.1/MAIL-RELAY-LEN) with SMTP id GAA02915 for ; Tue, 12 Dec 1995 06:36:48 -0800 (PST) Received: (from dima@localhost) by sunny.bog.msu.su (8.6.12/8.6.12) id RAA15120; Tue, 12 Dec 1995 17:20:43 +0300 Date: Tue, 12 Dec 1995 17:20:42 +0300 (????) From: Dmitry Khrustalev To: "Jordan K. Hubbard" cc: Nate Williams , stable@freebsd.org Subject: Re: Bringing stuff into 2.1? In-Reply-To: <17174.818735027@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-stable@freebsd.org Precedence: bulk On Mon, 11 Dec 1995, Jordan K. Hubbard wrote: > > Since the next release is going to be 2.1.1, what's the policy for > > bringing in changes to the 2.1 branch from -current? > > 1. If you're sure of the change. > 2. It doesn't represent radically new functionality (like devfs or IPX) Jordan, while IPX represents new functionality, it is independent from the rest of the kernel and is optional. It's like a driver for new device. Why not bring it into -stable ? -Dima > 3. It fixes a bugs or otherwise corrects something that needs correcting > (like a missing man page or re-written for clarity doc) > 4. It's been tested for awhile in -current. > > Go for it! > > > For example, the sliplogin/slattach changes could go in (they've been > > running here for months now), but I'm not sure if we want them to go in. > > I'd say that this qualifies since the 2.1 slattach was already > substantially merged from 2.2 before we shipped (you'll recall my > railing against our broken slattach). If the evolutionary process > has continued in 2.2, and it doesn't jeopardize functionality, cool. > > > I'd also like to see the PPP stuff move in, and even the ibcs2 kernel > > stuff, but I'm not heading in that direction until we have an idea what > > the policy is going to be. > > The iBCS2 stuff is a little iffy, but I'd argue that #2 could be > ammended slightly for anything not on the critical path. ibcs2 stuff > doesn't fall into that category, and if the changes result in better > ability to run MORE binaries, I don't see why it shouldn't be brought > across (given provision 4). > > My (and I believe everyone's) chief concern is that we not break the > tree. That means being _really_ careful the ensure that any changes > brought across don't have dependencies on other areas of -current > which may not also make it in. The last thing we need is to break > _all_ ibcs2 binaries (or something) because only half of the > components were brought over. :-) > > Jordan > From owner-freebsd-stable Tue Dec 19 02:45:23 1995 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA06944 for stable-outgoing; Tue, 19 Dec 1995 02:45:23 -0800 (PST) Received: from pilhuhn.de (pilhuhn.de [193.141.89.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id CAA06917 for ; Tue, 19 Dec 1995 02:44:37 -0800 (PST) Received: by pilhuhn.de id from snert.pilhuhn.de ([193.141.89.2]); Tue, 19 Dec 95 11:45 MET Received: by snert.pilhuhn.de id ; Tue, 19 Dec 95 11:37 MET To: stable@freebsd.org Path: hwr From: hwr@pilhuhn.de (Heiko W.Rupp) Newsgroups: pilhuhn.freebsd.stable Subject: Re: 2.1-stable just hangs Date: 19 Dec 1995 10:38:01 GMT Organization: The Home Of The Pilhuhn Lines: 13 Message-ID: References: <199511202106.OAA22815@rocky.sri.MT.net> NNTP-Posting-Host: pilhuhn.de X-Newsreader: slrn (0.8.4) Sender: owner-stable@freebsd.org Precedence: bulk In <199512011527.IAA25886@rocky.sri.MT.net>, Nate Williams wrote: :|My box has been stable now that I've quit using NFS heavily. Yesterday :|it ran load averages of 3+ for about 8 hours straight w/out a whimper. As my RAM is brave now - the box ran for >5days with a good newsfeed. But then it locked up - no input on keyboard or pty possible. There is definiteley a bug somewhere... -- Heiko W.Rupp Gerwigstr.5 D-76131 Karlsruhe +49 721 9661524 "In 1980, a single person could understand the UNIX kernel. In 1990, a single person couldn't even lift it!" -- Steve Zucker (?) From owner-freebsd-stable Tue Dec 19 04:20:36 1995 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA12822 for stable-outgoing; Tue, 19 Dec 1995 04:20:36 -0800 (PST) Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id EAA12812 for ; Tue, 19 Dec 1995 04:20:31 -0800 (PST) Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.7.3/8.6.9) id EAA02774; Tue, 19 Dec 1995 04:20:29 -0800 (PST) Date: Tue, 19 Dec 1995 04:20:29 -0800 (PST) Message-Id: <199512191220.EAA02774@silvia.HIP.Berkeley.EDU> To: stable@freebsd.org Subject: program cc1 got fatal signal 11 From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-stable@freebsd.org Precedence: bulk I've seen cc1 occasionally die with signals (usually 11, but I've seen 6 and 10 before too) on a 2.1R machine recently. Although I suspected hardware problems, as it disappeared when I disabled the internal cache (disabling the external cache only didn't help) on an ASUS 55something (with PB cache) motherboard, I just saw it happen again on a replacement board (forgot the manufacturer, made in USA, also uses Triton), I thought I'd send you guys a note. The problem always occurs on the same file when I compile the kernel. However, if I type "make", it will compile that file and goes on to others as well, but it usually fails again after a few more files. Also, according to the vendor's engineers, the ASUS board works fine with 256K cache but not with 512K of cache. The replacement board goes much further in compilation but still fails occasionally. Nothing except the motherboard and cache has changed. We tried two CPUs (Pentium 133) on the first board with the same result. (That's why it's so puzzling, as the problem disappeared when we disabled the INTERNAL cache.) Anyone else seen something like this? Is it possible that an OS can cause a problem like this, could it be something with cache invalidation (just a wild guess)? (Thank god at least the vendor is not pulling a "it works for DOS and Windows, so it is fine".) Satoshi ------- FreeBSD 2.1.0-RELEASE #0: Fri Dec 15 22:20:06 PST 1995 root@kirkland.cs.berkeley.edu:/usr/src/sys/compile/BUGSPRAY CPU: 133-MHz Pentium 735\\90 or 815\\100 (Pentium-class CPU) Origin = "GenuineIntel" Id = 0x525 Stepping=5 Features=0x1bf real memory = 33554432 (32768K bytes) avail memory = 30785536 (30064K bytes) Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 not found at 0x2f8 sio2 not found at 0x3e8 sio3 not found at 0x2e8 lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface lpt1 not found at 0xffffffff lpt2 not found at 0xffffffff fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 72065B fd0: 1.44MB 3.5in wdc0 not found at 0x1f0 npx0 on motherboard npx0: INT 16 interface Probing for devices on the PCI bus: chip0 rev 2 on pci0:0 chip1 rev 2 on pci0:7 de0 rev 18 int a irq 10 on pci0:17 de0: DC21140 [10-100Mb/s] pass 1.2 Ethernet address 00:00:c0:fc:4f:cf de0: enabling 10baseT UTP port ahc0 rev 0 int a irq 11 on pci0:20 ahc0: aic7870 Ultra Wide Channel, SCSI Id=7, aic7870, 255 SCBs ahc0 waiting for scsi devices to settle (ahc0:0:0): "SEAGATE ST31230W 0510" type 0 fixed SCSI 2 sd0(ahc0:0:0): Direct-Access 1010MB (2069860 512 byte sectors) (ahc0:1:0): "SEAGATE ST15150W 0011" type 0 fixed SCSI 2 sd1(ahc0:1:0): Direct-Access 4095MB (8388315 512 byte sectors) changing root device to sd0a pid 1684: cc1: uid 5531: exited on signal 11 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (many more of this omitted) From owner-freebsd-stable Tue Dec 19 05:49:48 1995 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA21512 for stable-outgoing; Tue, 19 Dec 1995 05:49:48 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id FAA21500 for ; Tue, 19 Dec 1995 05:49:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id FAA17792; Tue, 19 Dec 1995 05:49:01 -0800 To: asami@cs.berkeley.edu (Satoshi Asami) cc: stable@freebsd.org Subject: Re: program cc1 got fatal signal 11 In-reply-to: Your message of "Tue, 19 Dec 1995 04:20:29 PST." <199512191220.EAA02774@silvia.HIP.Berkeley.EDU> Date: Tue, 19 Dec 1995 05:49:00 -0800 Message-ID: <17790.819380940@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-stable@freebsd.org Precedence: bulk > I've seen cc1 occasionally die with signals (usually 11, but I've seen > 6 and 10 before too) on a 2.1R machine recently. Although I suspected > hardware problems, as it disappeared when I disabled the internal I have this happen too, though nowhere near as often as you seem to! It stops about one in three `make worlds' in their tracks, and always during a large C compile - typically one in libg++ or groff someplace. It's cc1 that, furthermore, is always the one croaking! When run a second time, it always makes it through. Go figure! Also FYI: This did *not* happen until I went from a 90Mhz part to a 133Mhz part in my ASUS P55TP4-XE MB. Yes, my memory is 60ns. Using 256K pipeline burst module. Jordan > cache (disabling the external cache only didn't help) on an ASUS > 55something (with PB cache) motherboard, I just saw it happen again on > a replacement board (forgot the manufacturer, made in USA, also uses > Triton), I thought I'd send you guys a note. > > The problem always occurs on the same file when I compile the kernel. > However, if I type "make", it will compile that file and goes on to > others as well, but it usually fails again after a few more files. > Also, according to the vendor's engineers, the ASUS board works fine > with 256K cache but not with 512K of cache. The replacement board > goes much further in compilation but still fails occasionally. > > Nothing except the motherboard and cache has changed. We tried two > CPUs (Pentium 133) on the first board with the same result. (That's > why it's so puzzling, as the problem disappeared when we disabled the > INTERNAL cache.) > > Anyone else seen something like this? Is it possible that an OS can > cause a problem like this, could it be something with cache > invalidation (just a wild guess)? (Thank god at least the vendor is > not pulling a "it works for DOS and Windows, so it is fine".) > > Satoshi > ------- > FreeBSD 2.1.0-RELEASE #0: Fri Dec 15 22:20:06 PST 1995 > root@kirkland.cs.berkeley.edu:/usr/src/sys/compile/BUGSPRAY > CPU: 133-MHz Pentium 735\\90 or 815\\100 (Pentium-class CPU) > Origin = "GenuineIntel" Id = 0x525 Stepping=5 > Features=0x1bf > real memory = 33554432 (32768K bytes) > avail memory = 30785536 (30064K bytes) > Probing for devices on the ISA bus: > sc0 at 0x60-0x6f irq 1 on motherboard > sc0: VGA color <16 virtual consoles, flags=0x0> > sio0 at 0x3f8-0x3ff irq 4 on isa > sio0: type 16550A > sio1 not found at 0x2f8 > sio2 not found at 0x3e8 > sio3 not found at 0x2e8 > lpt0 at 0x378-0x37f irq 7 on isa > lpt0: Interrupt-driven port > lp0: TCP/IP capable interface > lpt1 not found at 0xffffffff > lpt2 not found at 0xffffffff > fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa > fdc0: NEC 72065B > fd0: 1.44MB 3.5in > wdc0 not found at 0x1f0 > npx0 on motherboard > npx0: INT 16 interface > Probing for devices on the PCI bus: > chip0 rev 2 on pci0:0 > chip1 rev 2 on pci0:7 > de0 rev 18 int a irq 10 on pci0:17 > de0: DC21140 [10-100Mb/s] pass 1.2 Ethernet address 00:00:c0:fc:4f:cf > de0: enabling 10baseT UTP port > ahc0 rev 0 int a irq 11 on pci0:20 > ahc0: aic7870 Ultra Wide Channel, SCSI Id=7, aic7870, 255 SCBs > ahc0 waiting for scsi devices to settle > (ahc0:0:0): "SEAGATE ST31230W 0510" type 0 fixed SCSI 2 > sd0(ahc0:0:0): Direct-Access 1010MB (2069860 512 byte sectors) > (ahc0:1:0): "SEAGATE ST15150W 0011" type 0 fixed SCSI 2 > sd1(ahc0:1:0): Direct-Access 4095MB (8388315 512 byte sectors) > changing root device to sd0a > pid 1684: cc1: uid 5531: exited on signal 11 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > (many more of this omitted) From owner-freebsd-stable Tue Dec 19 06:24:45 1995 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA01060 for stable-outgoing; Tue, 19 Dec 1995 06:24:45 -0800 (PST) Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id GAA01053 for ; Tue, 19 Dec 1995 06:24:42 -0800 (PST) Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id GAA02923; Tue, 19 Dec 1995 06:24:41 -0800 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id GAA00214; Tue, 19 Dec 1995 06:24:41 -0800 Message-Id: <199512191424.GAA00214@corbin.Root.COM> To: "Jordan K. Hubbard" cc: asami@cs.berkeley.edu (Satoshi Asami), stable@freebsd.org Subject: Re: program cc1 got fatal signal 11 In-reply-to: Your message of "Tue, 19 Dec 95 05:49:00 PST." <17790.819380940@time.cdrom.com> From: David Greenman Reply-To: davidg@Root.COM Date: Tue, 19 Dec 1995 06:24:40 -0800 Sender: owner-stable@freebsd.org Precedence: bulk >> I've seen cc1 occasionally die with signals (usually 11, but I've seen >> 6 and 10 before too) on a 2.1R machine recently. Although I suspected >> hardware problems, as it disappeared when I disabled the internal > >I have this happen too, though nowhere near as often as you seem to! > >It stops about one in three `make worlds' in their tracks, and always >during a large C compile - typically one in libg++ or groff someplace. >It's cc1 that, furthermore, is always the one croaking! When run a >second time, it always makes it through. Go figure! > >Also FYI: This did *not* happen until I went from a 90Mhz part to a >133Mhz part in my ASUS P55TP4-XE MB. Yes, my memory is 60ns. Using >256K pipeline burst module. I thought you told me that the problem went away once you figured out the correct voltage setting for the CPU?? -DG From owner-freebsd-stable Tue Dec 19 06:29:24 1995 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA02407 for stable-outgoing; Tue, 19 Dec 1995 06:29:24 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id GAA02385 for ; Tue, 19 Dec 1995 06:29:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id GAA18007; Tue, 19 Dec 1995 06:28:32 -0800 To: davidg@Root.COM cc: asami@cs.berkeley.edu (Satoshi Asami), stable@freebsd.org Subject: Re: program cc1 got fatal signal 11 In-reply-to: Your message of "Tue, 19 Dec 1995 06:24:40 PST." <199512191424.GAA00214@corbin.Root.COM> Date: Tue, 19 Dec 1995 06:28:32 -0800 Message-ID: <18005.819383312@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-stable@freebsd.org Precedence: bulk > I thought you told me that the problem went away once you figured out the > correct voltage setting for the CPU?? No, I said that the problem went back to "hardly ever" from "every 2 minutes" when I switched the voltage to (then back from) VRE! :) To recap: It's always been an intermittant problem. At one point I thought that I saw a reference to the P5-133 being a 3.6V part and went to the VRE jumper setting, at which point my crashes went from "occasional" to "all the time." Dropping back has returned me to the realm of "acceptable lossage" :-) Jordan From owner-freebsd-stable Tue Dec 19 10:23:26 1995 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA26673 for stable-outgoing; Tue, 19 Dec 1995 10:23:26 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA26668 for ; Tue, 19 Dec 1995 10:23:25 -0800 (PST) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id KAA07627 for ; Tue, 19 Dec 1995 10:23:20 -0800 Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id KAA12428; Tue, 19 Dec 1995 10:21:22 -0800 From: "Rodney W. Grimes" Message-Id: <199512191821.KAA12428@GndRsh.aac.dev.com> Subject: Re: program cc1 got fatal signal 11 To: asami@cs.berkeley.edu (Satoshi Asami) Date: Tue, 19 Dec 1995 10:21:22 -0800 (PST) Cc: stable@freebsd.org In-Reply-To: <199512191220.EAA02774@silvia.HIP.Berkeley.EDU> from "Satoshi Asami" at Dec 19, 95 04:20:29 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-stable@freebsd.org Precedence: bulk > > I've seen cc1 occasionally die with signals (usually 11, but I've seen > 6 and 10 before too) on a 2.1R machine recently. Although I suspected > hardware problems, as it disappeared when I disabled the internal > cache (disabling the external cache only didn't help) on an ASUS > 55something (with PB cache) motherboard, I just saw it happen again on > a replacement board (forgot the manufacturer, made in USA, also uses > Triton), I thought I'd send you guys a note. > > The problem always occurs on the same file when I compile the kernel. > However, if I type "make", it will compile that file and goes on to > others as well, but it usually fails again after a few more files. > Also, according to the vendor's engineers, the ASUS board works fine > with 256K cache but not with 512K of cache. The replacement board > goes much further in compilation but still fails occasionally. > > Nothing except the motherboard and cache has changed. We tried two > CPUs (Pentium 133) on the first board with the same result. (That's > why it's so puzzling, as the problem disappeared when we disabled the > INTERNAL cache.) > > Anyone else seen something like this? Is it possible that an OS can > cause a problem like this, could it be something with cache > invalidation (just a wild guess)? (Thank god at least the vendor is > not pulling a "it works for DOS and Windows, so it is fine".) I strongly suspect hardware problems given that I have run 100's if not thousands of passes of make world on 2.1-stable since 2.1-release occured using ASUS PCI/I-P-55TP4XE's, including 512K cache 133Mhz setups. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-stable Tue Dec 19 13:39:31 1995 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA08233 for stable-outgoing; Tue, 19 Dec 1995 13:39:31 -0800 (PST) Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id NAA08227 for ; Tue, 19 Dec 1995 13:39:27 -0800 (PST) Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.7.3/8.6.9) id NAA03622; Tue, 19 Dec 1995 13:39:12 -0800 (PST) Date: Tue, 19 Dec 1995 13:39:12 -0800 (PST) Message-Id: <199512192139.NAA03622@silvia.HIP.Berkeley.EDU> To: rgrimes@GndRsh.aac.dev.com CC: stable@freebsd.org In-reply-to: <199512191821.KAA12428@GndRsh.aac.dev.com> (rgrimes@GndRsh.aac.dev.com) Subject: Re: program cc1 got fatal signal 11 From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-stable@freebsd.org Precedence: bulk * I strongly suspect hardware problems given that I have run 100's if not * thousands of passes of make world on 2.1-stable since 2.1-release occured * using ASUS PCI/I-P-55TP4XE's, including 512K cache 133Mhz setups. I see. What kind of hardware problem do you suspect? It happens on two different motherboards (the ASUS board you mentioned, and a different Triton board), two different CPUs (both Pentium 133 on ASUS) and the motherboards have different cache modules. The things that are in common: memory (60ns EDO, 32MB), SCSI adapter (2940UW), disk, video card, keyboard, etc. Satoshi From owner-freebsd-stable Wed Dec 20 10:32:27 1995 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA09029 for stable-outgoing; Wed, 20 Dec 1995 10:32:27 -0800 (PST) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA09024 for ; Wed, 20 Dec 1995 10:32:21 -0800 (PST) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id KAA13198; Wed, 20 Dec 1995 10:32:11 -0800 From: "Rodney W. Grimes" Message-Id: <199512201832.KAA13198@GndRsh.aac.dev.com> Subject: Re: program cc1 got fatal signal 11 To: asami@cs.berkeley.edu (Satoshi Asami) Date: Wed, 20 Dec 1995 10:32:11 -0800 (PST) Cc: stable@freebsd.org In-Reply-To: <199512192139.NAA03622@silvia.HIP.Berkeley.EDU> from "Satoshi Asami" at Dec 19, 95 01:39:12 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 Precedence: bulk > > * I strongly suspect hardware problems given that I have run 100's if not > * thousands of passes of make world on 2.1-stable since 2.1-release occured > * using ASUS PCI/I-P-55TP4XE's, including 512K cache 133Mhz setups. > > I see. What kind of hardware problem do you suspect? It happens on > two different motherboards (the ASUS board you mentioned, and a > different Triton board), two different CPUs (both Pentium 133 on ASUS) > and the motherboards have different cache modules. > > The things that are in common: memory (60ns EDO, 32MB), SCSI adapter > (2940UW), disk, video card, keyboard, etc. Memory. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD