Hello all,
I am trying to untangle a strange segmentation fault
created by gcc using AMD-K6-2, but not with Pentium-II.
In particular, any hints on particular information bits
needed to pinpoint the error will be appreciated.

First, I have OpenBSD 4.2 running on this machine using
AMD-K6-2/350 on an AT-mainboard with VIA chipset VT82C598
and VT82C586B. (Well, both AT and ATX in fact.) I have not
detected any trouble until I patched libssl according to
the official suggestion, but already when performing
"make depend", the execution aborts prematurely and reports
a segmentation fault in cc1 that gnu.org ought to know about.
The very same thing happened three times with reboots
inbetween and even rearranged SDRAM just in case.

Next, when I take the very same harddisk and move it to
another machine everything goes well (except overheating
when I forgot to activate the fan!) This second mainboard
uses a Pentium-II 450 and Intel FW82443BX/FW82371EB chipset.

This is all the more worrying since that VIA board is also
not able to compile firewall kernel I originally planned
to use as a testing case for the system. Please, do not
be angry with me for this scant information, since my
primary concern is to resolve the issue for the benefit
of OpenBSD, but I am presently at loss due to the unexpected
hardware dependency of this particular segmentation fault.
Thus I would welcome hint or pointer as were I should
collect information decisive enough to go into a proper
bug report.

Best regards

M E Andersson

Segmentation faults during compilation is often a symptom of faulty memory.

(Old faq on this issue available at http://www.bitwizard.nl/sig11/)


-- ach

or memory subsystem... (which is an important difference in this


and if it finds a problem, fine.  If it doesn't, don't say it isn't
memory...

AMD-K6/2 systems are quirky with regard to RAM.  Hopefully, you have a
deep and wide spare parts pile to try different RAM in the things
until you find something that works in the machine.  Or, as is often
the case on these things, you can slow down the bus speed of the
processor (and sometimes, partly compensate by cranking the multiplier)
and solve these problems.  Failing that, try 133MHz RAM.

I'm not sure what the exact source of the problem is, but it's common.
It's not so much bad RAM as it is a quirky memory system.

I've got a slightly similar machine here which took four or five
restarts to get a complete custom kernel built for (which was needed
for a driver not in GENERIC), but once running, it is pretty solid.
I won't even try to build a system with it until I get around to
slowing it down/putting better RAM in it.

Nick.