|Subject:||Re: program cc1 got fatal signal 11|
|From:||Jordan K. Hubbard (jk...@time.cdrom.com)|
|Date:||Dec 19, 1995 5:48:41 am|
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.
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".)
------- FreeBSD 2.1.0-RELEASE #0: Fri Dec 15 22:20:06 PST 1995 ro...@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)