Some time ago, I bought second-hand PC to work late on evenings at home. At work I had relatively mighty Pentium 133 with 64MB of RAM and 17" monitor but I wanted something basic at home: just to do short computations and writing stories like this one. I got (actually assembled from old, used parts) a 386DX/40, with 387DX, 128KB cache, 5MB of 70 ns RAM, 160MB hard drive and EGA card/monitor. Not very powerful, of course, but I just didn't wanted more. Then the story began.
I have installed OS/2 3.0 on it - the system I am most familiar with (and like to work with). Then I put my solar evolution code (mostly intensive floating-point calculations) and compiled it (the code is 100% FORTRAN-77; I ought to make pages dedicated to it but haven't had the time yet... you might look at some excerpt). I compiled it with g77 0.5.20 (GNU FORTRAN-77 compiler) ported to OS/2. During compilation, I encountered several compiler crashes. That surprised me, but I just ran make again and finally I got an executable. It produced different results each time it was ran. One of my friends advised to replace coprocessor. I bought new one but machine didn't accept it (no NPU were reported). Without coprocessor, the thing worked just fine but incredibly slow, of course (I fell asleep and haven't measured how much slower exactly. It was late at night). DOS Grapher worked without a hitch with the suspected coprocessor, however. I started to poke around motherboard and discovered jumpers which controlled CPU clock. I set it to 33MHz instead of 40 and my program started to give correct results (verified by comparison to Pentium's numbers). I was relieved.
That was not all, however. Later I wanted to recompile my program (btw, 350KB of FORTRAN sources take about 15 min to compile without optimizations). Perhaps it was especially unhappy morning, because g77, f771, as crashed with signal 11, segmentation fault etc. every third-fourth file! Then machine hung when I switched to another session and tried to edit some file. OS/2 didn't respond to neither Ctrl-Esc nor Ctrl-Alt-Del, so I had to press Reset. Upon boot, chkdsk hung. I rebooted PC again. Chkdsk hung again. All my files were on HPFS partition, so they were unaccessible from DOS. But OS/2 refused to boot. I didn't remember how I came to disabling motherboard cache, but it solved the problem. Chkdsk ran through, and I was able to access my files. Even compilations ran successfully (although mindnumbingly slow without cache; Norton's SysInfo tells me it's 4 times slower without cache).
Then I tried to fiddle with cache and memory timings (as you can see, motherboard BIOS is relatively new and allowed it). When I set 2 wait states for main DRAM, the problem disappeared. Chkdsk now feels fine too.
If you still have some doubts left that famous signal 11 problem has hardware origins, I don't know what could convince you. May be example of my friend who experienced it from time to time during Linux kernel compilation. The problem went away after setting his Pentium back to 100MHz to which it was rated (instead of 120MHz). Apparently, compiler really pushes hardware to its limits, and some specimens just don't like it.
Finally, some side notes: yes, I was using gcc and g77 under OS/2. There's a port of gcc by Eberhard Mattes to OS/2 (called EMX) which I employ. Yes, GCC under OS/2 also talks about signal 11 (usually accompanied by system message about segmentation violation, SYS3157). Yes, it was done on 386DX/33 with 5MB of RAM.
Further reading: Signal 11 FAQ
Copyright (C) 1997 Sergey Ayukov. No part of this text can be reproduced without permission.