Date: Tue, 19 Dec 1995 05:49:00 -0800 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: asami@cs.berkeley.edu (Satoshi Asami) Cc: stable@freebsd.org Subject: Re: program cc1 got fatal signal 11 Message-ID: <17790.819380940@time.cdrom.com> In-Reply-To: Your message of "Tue, 19 Dec 1995 04:20:29 PST." <199512191220.EAA02774@silvia.HIP.Berkeley.EDU>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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<FPU,VME,PSE,MCE,CX8,APIC> > 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 <Intel 82437 (Triton)> rev 2 on pci0:0 > chip1 <Intel 82371 (Triton)> rev 2 on pci0:7 > de0 <Digital DC21140 Fast Ethernet> 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 <Adaptec 2940 Ultra SCSI host adapter> 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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?17790.819380940>